8 replies to this topic

[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]

Quote

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: theDomain\theUserName 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
workgroup\vaughanbromfield
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.

[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]

jasonwood, on 22 February 2012 - 11:15 AM, said:

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