External authentication and user identification

[bluearrow]

Hi,

I am upgrading from 5.5 to 8. I administer a Windows 2000 domain. I would like to use the external authentication feature of FM Server 8.

In my current version, I use SecureFM to eliminate all menus, and a personal logon system to authenticate users and audit / script user functionality. Users do not access FM files hosted in the server directly, but using an opener file.

I do not understand how should I implement this in version 8.

This are the steps that I do / do not understand right now:

1.- I create the privilege sets in FM. Is it compulsory to also create user accounts if I am going to use external authentication? (besides the administrator account for FM)

2.- I configure external authentication in FM Server.

3.- In my Windows domain I have users and groups. For accesing network shares and applying policies, the users logon to the domain providing user name and password. They do this only once, when they first logon to the domain. What would happen when they clic the opener file? Would they have to provide their user name and password again? (in any event, I understand that this credentials would be the same as the domain credentials)

4.- If they do not have to provide user / password again: how can I identify the user in FM. For instance, I would like to show certain menus, or functions / trigger scripts according to the user. I would also like to log user actions. How can this be done? Privilege sets are obviously out of this question, because to identify users I need accounts. Would I need to re-create every Windows account for every FM user? What functions would allow me to identify my user if I am using external authentication?

5.- If the user does not have to provide user / password again, I understand that FM is assuming that the FM user is the same user that logged in the machine. This is not always the case in my situation, for many reasons that are beyond this forum. Can I force a FM login in this case?

[Steven H. Blackwell]

First, let me say generally that you should read the three Tech Briefs on Security, Server, and External Server Authentication found on the FMI web site at:

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

Second, the Get(AccountName) function will return the current user's Account name irrespective of whether the user is authenticated externally or internally.

Third, do not externally authenticate a [Full Access] Account.

Fourth, you can mix both internal FileMaker Pro authentication Accounts and External Server Authentication Accounts.

Fifth, to link this to privileges, define a Privilege Set, and then link it to an Account. When you change the authentication option of that Account to external it will change from an Account to a Group. That Group name must **exactly** match the Group name in the Directory Service, in this instance Active Directory. Any AD Accounts in that same AD Group will connect to the file with the privileges defined in the Privilege Set.

Sixth, regarding the opener file, if you want to continue to use that system, the file needs to call the hosted file with the externally authenticated Account. You may have to experiment with that some to get it to work as you want it to do.

Seventh, in FMS 7 and FMS7A, Domain Groups inside Domain Groups and trusted Domains are not supported. In FileMaker Server 8, they are supported. As a practical matter, make an OU, and define Groups relevant to the FileMaker Pro files into that OU. Then you can place the Domain level Accounts in the OU Groups.

Eighth, and finally, Single Sign On is a Windows OS client to Windows OS server feature only. Macintosh OS clients--if you have any of them--should use the KeyChain to emulate SSO. FileMaker Server will query the KeyChain of a Macintosh OS user to see if there are valid credentials. Be sure that the FileMaker Server CPU is itself a member of the same Domain to which the Accounts belong.

HTH--and check out those Tech Briefs.

Steven

[bluearrow]

Dear Steven,

Thank you very much for your reply. I understand some points, but not all of them. I insert my comments / questions in between lines. I would appreciate if you could clarify some of the matters.

First, let me say generally that you should read the three Tech Briefs on Security, Server, and External Server Authentication found on the FMI web site at:

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

Before I posted the original message, I did read all those articles, and some others, including posts to this and other similar forums. However, I did not find the information I needed. Most info is about the system, but not about how it works.

Second, the Get(AccountName) function will return the current user's Account name irrespective of whether the user is authenticated externally or internally.

Third, do not externally authenticate a [Full Access] Account.

Fourth, you can mix both internal FileMaker Pro authentication Accounts and External Server Authentication Accounts.

Fifth, to link this to privileges, define a Privilege Set, and then link it to an Account. When you change the authentication option of that Account to external it will change from an Account to a Group. That Group name must **exactly** match the Group name in the Directory Service, in this instance Active Directory. Any AD Accounts in that same AD Group will connect to the file with the privileges defined in the Privilege Set.

I do not fully understand this. From your comments I infer that if I use external authentication, first I need to create all the user accounts in FileMaker, then assign priviledges in FileMaker, then select external authentication in FileMaker. Fine.

This assumes that in my Windows domain I have my users accounts with exactly the same name as the user accounts in FileMaker, and this Windows accounts are inside Windows groups specifically tailored for FileMaker purposes. Fine too.

Is all this correct?

If it is so: My user will enter the Windows domain, then open the FileMaker application. Windows knows the user, but: how does FileMaker knows what user is? If FileMaker authentication is based on Windows groups, but not users, then there must be an extra step somewhere to tell FileMaker what user is currently using the system. On the other hand, maybe the user authenticate in the domain and then must authenticate again upon opening the FileMaker file, inserting its user name and password, identically as he / she did in the domain. Am I completely lost in my thinking?

Sixth, regarding the opener file, if you want to continue to use that system, the file needs to call the hosted file with the externally authenticated Account. You may have to experiment with that some to get it to work as you want it to do.

Yes, but if all my users use external authentication because I have configured the FM server as such, I assume I do not need to create additional accounts just for the opener file: the users will be calling the file with their externally authenticated account. Is this right? or do I need to create additional account just to call the hosted files through and opener file? what kind of accounts?

Seventh, in FMS 7 and FMS7A, Domain Groups inside Domain Groups and trusted Domains are not supported. In FileMaker Server 8, they are supported. As a practical matter, make an OU, and define Groups relevant to the FileMaker Pro files into that OU. Then you can place the Domain level Accounts in the OU Groups.

Eighth, and finally, Single Sign On is a Windows OS client to Windows OS server feature only...

OK. I am using Windows clients in a Windows based domain. Do I need to register both in the domain and then in FileMaker after clicking in the opener file? Not that I mind registering twice (this is the situation now in FM 5.5), but I do not have a clear picture about it regarding FM 8.

Thanks again

[Steven H. Blackwell]

First, please downlaod the Server External Authentication Tech Brief. It covers your questions in great detail.

Short versions:

When your user authenticates to Active Directory and then seeks access to a FileMaker Pro file hosted by FileMaker Server 7, FMS will query AD to see if the user's credentials are valid. If they are, then the domain controller will tell FMS that and will also return a list of the AD Domains to which that user belongs. FMS comapres that to its own list of Groups (externally authenticated Accounts). The first match based on authentication order controls the Privilege Set that the user enjoys when he or she accesses the file.

The SSO is seamless if the user is properly authenticated and the Groups are set up correctly. There is no further challenge for credentials. You can force a challenge--if you wanted to use another valid Account--by holding down the SHIFT key when clicking on the name of the file.

HTH

Steven

[Steven H. Blackwell]

This assumes that in my Windows domain I have my users accounts with exactly the same name as the user accounts in FileMaker, and this Windows accounts are inside Windows groups specifically tailored for FileMaker purposes. Fine too.

Not exactly. The Group in the FMP file, for example fm_SalesManager, should have a matching Group in the Domain Controller or in an OU. Make the FMP match the Domain or vice versa, it doesn't matter, so long as they match.

I know this is a bit complex, but you've got the essentials. Group matches Group, then when a user is valid, he or she get access with the privileges defined by the Privilege Set attached to that first matching Group.

HTH

Steven

[bluearrow]

Thank you Steven.

I must apologize, because for some reason I did skipped reading the document you mention before sending the question to this forum. I have read it now, and it was exactly what I was looking for.

Thanks again for pointing it out.

Regards.

[Steven H. Blackwell]

Most welcome. Glad it helped you. The reason we did the document--the reason FMI sponsored it--is that we wanted to get the correct information into the hands of developers and IT Administrators.

There are some changes with Server 8 and External Authentication, but as long as you stay within Active Directory and Windows Server 2003 for your OS, you should be OK.

More details on this will be forthcoming soon.

Steven

Edited October 26, 2005 by Guest