Short name or long name?

[jasonwood]

If I use external authentication with a Mac OS X Server, will users login to FileMaker with their short name or their long name, or both?

If I use Get ( AccountName ), will it return the short name, long name, or does it depend on which one they used to login?

[Steven H. Blackwell]

Use the short name; it works better. And it's what the OD controller returns to FileMaker Server. There are ways around this, but they just complicate matters. Get(AccountNAme) returns whatever the user entered as the Account name.

Steven

[jasonwood]

Thanks Steven,

but I'm confused by this part... The OD controller returns the short name, but Get(AccountName) returns whatever was entered? What good is knowing what the OD controller returns if it's not what's used by Get(AccountName)?

My issue is that I want to have a "Users" table that could contain individual user preferences and can also be used for value lists to select other database users. In an external authentication environment, this table would have to be driven by a check of Get(AccountName) on login, creating a new record if necessary.

My concern is that even if I set a policy of using the short name to access FileMaker, a user could still use their long name. As a result, my database would think they are two different users, resulting in the user appearing twice in value lists... is there a way around that problem?

[Vaughan]

but I'm confused by this part... The OD controller returns the short name, but Get(AccountName) returns whatever was entered? What good is knowing what the OD controller returns if it's not what's used by Get(AccountName)

The OD controller returns the short name of the OD group which is the name of the externally authenticated account, not the user name that was typed into the FMP authentication dialog.

Get( AccountName ) will return whatever the user typed into the authentication dialog, however it was typed, because that's all FMS knows about.

Where it gets more interesting is when the user types their account name in UPN or UNC format: theDomaintheUserName or theUserName@theDomain respectively.

This means that it is possible for the Get( AccountName ) function to return the following strings for the same user, depending on what they authenticated with for the current session: (This assumes that the OD or AD accepts the UNC or UPN formats and is not case sensitive.)

VaughanBromfield

vaughanbromfield

VAUGHANBROMFIELD

workgroupvaughanbromfield

vaughanbromfield@workgroup

This shows that the Get( AccountName ) function cannot be relied upon for generating keys that uniquely identify accounts, because users can legitimately authenticate with different strings.

[LaRetta]

Good information, Vaughan!

[Vaughan]

Thanks LaRetta.

Since posting I've realised that the situation is not as bad as it seems. The "username" can easily be parsed out of both the UPN and the UNC strings (after the and before the @ characters respectively). Then make them all upper or lower case so they are consistent.

That's assuming the AD/OD is not case sensitive and only allows one account named "vaughan" in any combination of case. If it is case sensitive and allows one account named "VAUGHAN" and another "Vaughan" then all bets are off, and the situation really is complicated. :D

[Steven H. Blackwell]

These scenarios are covered in some detail in the External Server Authentication Tech Brief that Wim Decorte and I prepared for FileMaker, Inc. That paper can be found on their website.

The Group name returned by Open Directory must match the Group name in the FileMaker Pro file that provides the link to the designated Privilege Set. That's how the database know what the privileges are for any given external Account that is a member of the Group.

This business with the Account names gets especially interesting when using Record Level Access.

Steven

[jasonwood]

I'm thinking the best way to deal with this would be to require an administrator to "register" each new user with the database, creating a user record with all of the possible names they could use to login. Then upon login, even if the user is authenticated, if Get(AccountName) fails to return a registered name that matches a user record, the database kicks them out immediately.

[Steven H. Blackwell]

Then upon login, even if the user is authenticated, if Get(AccountName) fails to return a registered name that matches a user record, the database kicks them out immediately.

Such a system probably cannot meet any reasonable parameters of security testing. This process, especially if done by script, is manipulatable and fairly easily so.

Steven

[Chris Scalzi]

I realize this topic was nearly two years about now but I came accross this problem and at the very least found a solution that I was happy with for consistently reporting what the username was. Since the other way of authenticating was the long name in the Open directory the way to differentiate them was always that one contained a space between the first and last name and the other ( the short name ) had no spaces.

 

So I did indeed "register" each user with my database by way of adding the short name to their individual record within the database and then called it up on the database opening script. The script that only runs when the database is first opened. I also added this script to a function for re-logging in as another user.

 

I did:

Set Variable [If ( PatternCount ( Get ( AccountName )  ; " " ) ; 
Let ( [ 
User=Get ( AccountName );
Result=ExecuteSQL( " SELECT accountname FROM FacultySPR WHERE EmployeeFullName = ? " ; "" ; "" ; User )
];
Result
)
 ; Get ( AccountName ) )
]

And then after that I set another variable:

 

Set Variable [
$$CurrentUser; Value:$$CurrentUserCheck]

This way if I ever needed to report the current user I could reliably do so by their short name whether or not they used their full name to log in or not.

 

 

[Steven H. Blackwell]

 

So I did indeed "register" each user with my database by way of adding the short name to their individual record within the database and then called it up on the database opening script.

 

So, what happens if the file opens and the Opening Script does not run?  And are the names in the records in the table where they are stored secured?  Can someone manipulate them?

 

Steven

[Chris Scalzi]

If the open script doesn't run on this particular solution more than just the names would get messed up. I have a variety of variables and settings that are grabbed for the database session that are necessary for the core functionality for the solution.

 

The names are in two places:

1. The OS X Open Directory server where you could only log in as Full Name or Short Name. That is secured by physically being locked in a server cabinet, then software locked on the local level and on the OD level for Server Account access. Various groups in the OD are linked to the filemaker pro security groups with limited names for access to different tables.

2. The table of names in filemaker has strict read and modify access. And only super-administrators are able to modify the long name or short name. The thing is though, even if the table of names gets modified it's only really for reference. Access and privileges are always driven by the OS X OD Server and FMP security groups.