Account name and User name using external authentication

[bluearrow]

Hi,

I just need to confirm that the following assumptions are right for external authentication using Active Directory. Assume I already have everything setup (Windows domain with domain accounts/groups created in AD and equivalent local accounts/groups created in FM).

The domain will be "domain.com"

The domain user account will be "[email protected]"

The group name in AD and FM will be "FMgroup"

The user account in FM will be "username". This account will be externally authenticated in AD.

The user "username" will be a member of the FMgroup in AD

1.- The user logs into Windows domain. The user would not be required to log to FileMaker when opening the solution.

2.- The Get (AccountName) function in FileMaker will return "username", not "[email protected]".

3.- If I need to convert "username" into the user real name, for instance, FirstName/LastName, I can setup a table Users which might contain a field for logonName ("username"), FirstName, LastName, etc.

4.- The best way to open the solution in FM 8.5 would still be a local opener file that runs a script to open the server files locally (the files in the server will already be opened by FileMaker service, of course).

Thank you

[Steven H. Blackwell]

No, this is not correct. At least as I read your description of it is is not correct.

There will be one or more Groups in AD, e.g. Sales, Marketing, Executives, etc.

There must be corresponding Groups in the FMP file with the same names. Each Group is attached to a Privilege Set.

If you want to group your AD groups for FMP, create an OU and place all the AD groups used for FMP authentication into that OU.

In each AD Group, you can have as many AD Accounts as you want. These are the log-on Accounts.

When a user logs onto the domain and is authenticated, when that user wishes to connect to files hosted by FileMaker Server, provided that FMS has been told to use External Serevr Authentication, FMS will query the domain controller to see if the user is valid. If so, the Domain Controller returns that OK with a list of the groups to which the user belongs. The first matching group in FMP as determined by authentication order is the one that admits the user to the file with the respective privilege set.

Get(AccountName) returns the AD Account name, not the group name.

See the External Server Authentication Tech Brief:

http://www.filemaker.com/support/upgrade/techbriefs.html

HTH

Steven

[Wim Decorte]

2.- The Get (AccountName) function in FileMaker will return "username", not "[email protected]".

The get(AccountName) will return the exact syntax that user used to log in. Can be "username" or can be "[email protected]" or even "DOMAINusername"

so whatever the user types into the login box in Windows will be used by FileMaker.

[Wim Decorte]

The group name in AD and FM will be "FMgroup"

The user account in FM will be "username". This account will be externally authenticated in AD.

The user "username" will be a member of the FMgroup in AD

It could just be lingo confusion here but to clarify:

- the name of the account in FM will be "FMgroup", this account is set in FM to "external account"

- there is no account in FM that matches the user name

[bluearrow]

The get(AccountName) will return the exact syntax that user used to log in. Can be "username" or can be "[email protected]" or even "DOMAINusername"

so whatever the user types into the login box in Windows will be used by FileMaker.

This makes it more difficult to match a logon name to a real user name in FileMaker table (this is not an issue in the Windows domain). I guess it implies that if I want to find out the real user name, I have to parse whatever the user types in ther login box, and leave the field match content in my user table.

For instance, the options to log into a Windows domain could be:

username

[email protected]

DOMAINusername

If I have a table with a Logon field and FirstName /LastName fields, I have to parse the input to leave just the part I have in my table, this is "username". Other option I can think of is to user PatternCount, but this is a bit dangerous.

Is this the way you manage it? If not, how?

[Genx]

... I don't know what makes you think that the persons name will be in the user name in the frist place... just set up a preferences table that stores whatever their windows account name is and then their real details

[bluearrow]

No, this is not correct. At least as I read your description of it is is not correct.

There will be one or more Groups in AD, e.g. Sales, Marketing, Executives, etc.

There must be corresponding Groups in the FMP file with the same names. Each Group is attached to a Privilege Set.

OK. I got this part right. This is what I meant in my description. I just did not want to extent too much in my message. Sorry for any confusion I created.

If you want to group your AD groups for FMP, create an OU and place all the AD groups used for FMP authentication into that OU.

In each AD Group, you can have as many AD Accounts as you want. These are the log-on Accounts.

This is exactly what I was going to do, and it is standard practice in Windows (at least, it is what Microsoft recommends). This way, I can apply personalized domain policies to the FM OU (and subsequently, to whatever it is inside the OU, this is, the FM Groups and Users).

When a user logs onto the domain and is authenticated, when that user wishes to connect to files hosted by FileMaker Server, provided that FMS has been told to use External Serevr Authentication, FMS will query the domain controller to see if the user is valid. If so, the Domain Controller returns that OK with a list of the groups to which the user belongs. The first matching group in FMP as determined by authentication order is the one that admits the user to the file with the respective privilege set.

OK, this is very important, because a user in FM could be part of several groups (for instance, an administrator). If the administrator group in FM is not placed first in the list of Privilege sets, it could end up login on with a different set of rights in FileMaker.

Get(AccountName) returns the AD Account name, not the group name.

Right. I meant that. The user does not even know the Windows group name (nor the FileMaker group name), neither that the group exists. Generally, the only thing that the user is aware of is the username to log into the domain (unless the company has several domains or a compelling reason to force the user to specify a domain to logon to)

What I was asking was that, provided that the user has logged on to the domain (FileMaker solution is still closed), then the user will not need to provide credentials again to open the FileMaker solution (well, he does, but FileMaker will take care of that on the background). FileMaker knows the username. I assume this is true. Is it?

Then, I can use Get(AccountName) to get the name used to logon to the domain in that specific machine. Finally, if I have a table of users, I could use this table to link this name to a real username. This real username is the one to use for my fields CreationUser, ModificationUser, etc. The Get(AccountName) function is only valid to lookup the real name in the user table. Not to fill in CreationUser fields (logon names are not really usernames in most applications). Does this sound correct to you?

Finally, I spot a security issue in all this. A user log into the domain. His machine knows his username, so does FileMaker. The user goes for a coffe or whatever. Another user thakes his place and start the FileMaker application. Is there any way to force to relogon to FileMaker?

I have implemented security measures inside the domain like screen saver turned on automatically every x minutes, request a password to unlock the screen saver, etc. But even implementing this measures, it might (just might) be convenient to provide an additional security inside the FileMaker application itself (forcing to relog in FileMaker after a shorter period of inactivity, or another creative measure :-)

) Will the Re-login function work fine under this circumstances?

Thank you

[bluearrow]

... I don't know what makes you think that the persons name will be in the user name in the frist place... just set up a preferences table that stores whatever their windows account name is and then their real details

No, I am not thinking it is the persons name. On the contrary, I assume it will not be. And yes, I was thinking of having a preferences table (I call it Users table in my solution) to store the AccounName and RealName (among other deatils). But I was describing the issues with this approach (please read my responses to Will and Steve about this point).

Thank you

[bluearrow]

See the External Server Authentication Tech Brief:

http://www.filemaker.com/support/upgrade/techbriefs.html

I've read it before posting. It is excellent, really. But I wanted to be absolutely sure about some points. I am developing a solution without access to the FMServer (at the moment), so I cannot test what it is described in the technical brief.

Thanks

[Steven H. Blackwell]

Finally, if I have a table of users, I could use this table to link this name to a real username. This real username is the one to use for my fields CreationUser, ModificationUser, etc. The Get(AccountName) function is only valid to lookup the real name in the user table. Not to fill in CreationUser fields (logon names are not really usernames in most applications). Does this sound correct to you?

Finally, I spot a security issue in all this. A user log into the domain. His machine knows his username, so does FileMaker. The user goes for a coffe or whatever. Another user thakes his place and start the FileMaker application. Is there any way to force to relogon to FileMaker?

Good questions.

I see no issue with using the value from Get(AccountName). It all depends on how you set up your Account names in AD to begin with. As you note there are many options and many different possible syntaxes. But a standard item such as SBlackwell or WDecorte or DGoupil would suffice in most instances properly to identify the user. FMP allows for auto entry of Account Name as the creator or modifier of a record.

Regarding the unattended workstation, there are any number of ways to deal with this; they differ on Windows from Mac OS. FileMaker Server allows for an auto-disconnect after specified idle time on a Privilege Set by Privilege Set basis (role based security). Additionally the standard items for hardening workstations--some of which you suggested--can also be employed. If this is a particularly high security environment, two factor proximity tokens can be used.

I want to avoid advertising here, but FileMaker Security: The Book talks a lot about these issues.

http://www.filemakersecurity.com

HTH, and thanks for the kind words about the tech brief.

Steven