Server External Authentication. FileMaker 9 Product Line

Transcription

1 Server External Authentication FileMaker 9 Product Line

2 Table of Contents What is Server External Authentication?...3 Why Use Server External Authentication?...3 Making Server External Authentication work...4 TheCompany with only Windows Operating Systems...7 TheCompany with only Macintosh Systems...8 Configuring the Computers and Software...8 What configurations are required for Server External Authentication to work?...8 The FileMaker Pro 9 solution (hosted by FileMaker Server 9)...9 FileMaker Server 9 or FileMaker Server 9 Advanced...15 FileMaker Server 9 Computer...19 Scenario 1: FileMaker Server 9 computer performs authentication...21 OS X Server...27 Windows...28 Macintosh...31 Scenario 2: Domain Controller Performs the Authentication...33 Making the FileMaker Server computer part of the domain...33 The Domain Controller...37 Windows...37 Macintosh...41 FileMaker Pro 9 Client Computers...44 Other FileMaker Server settings and their relationship to External Authentication...46 File Display Filter (otherwise known as Database Visibility)...46 Encryption...47 LDAP...47 Using UPN/UNC to force authentication...48 Troubleshooting: What if it does not work as you expect it should?...50 Does the Account work?...50 Group Membership...50 Double Check Authentication Order...52 Double Check the FileMaker Server 9 version...53 Check the clock on the computer...53 Event Logs...54 Clean up the Keychain...56 Summary...56 Server External Authentication Page 2 of 57

3 What is Server External Authentication? FileMaker Server 9 and FileMaker Server 9 Advanced both support Server External Authentication of FileMaker Pro 9 Accounts including those Accounts accessed from Web Browsers when using either version of FileMaker Server 9. This Technical Brief discusses in detail what Server External Authentication is and how to configure it on both Windows and Macintosh platforms. First, a bit of review about Accounts in FileMaker Pro 9. Accounts consist of both an Account name and a password. FileMaker Server 9 using OS level Accounts can authenticate these either internally by FileMaker Pro 9 or externally. On Windows OS these are Active Directory Accounts and on OS X (Macintosh) they are Open Directory Accounts. Accounts can also be local Accounts and Groups on either platform. Additionally, depending on the specific network configuration, directory services from one platform can authenticate users on the other platform. In other words, Active Directory might authenticate a Macintosh user while an OS X Server s Open Directory might authenticate a Windows XP Pro user. Accounts can reside either on the local FileMaker Server 9 computer or they can reside on a Domain Controller elsewhere on an accessible network. When the user s credentials are deemed authentic and valid, the user is admitted to the FileMaker Pro 9 file with a level of access determined by the Privilege Set attached to the user s Group. Internally authenticated Accounts have the Account Name and password; externally authenticated Accounts have a Group name that must match a Group in the local or domain listing. Each of those local or domain Groups can have one or more Accounts, each with an Account name and a password. This Technical Brief is based on features found in FileMaker Server 9.0 and FileMaker Server Advanced 9.0 on both the Macintosh and Windows platforms. We strongly recommend that developers and Administrators update their installations to the latest version of FileMaker Server 9.0 before following any of the advise in this technical brief. The current version of FileMaker Server at the time this paper was written was 9.0v3. Why Use Server External Authentication? There are several compelling reasons for selecting Server External Authentication of FileMaker Pro files: 1. Account Management - External Authentication allows separation of Account management from the FileMaker Pro files. In multiple file solutions, this can be especially helpful. Administrators can create and manage Accounts and their passwords in one central location, rather than being required to maintain or update them in each individual file. While scripted Account management can administer internally authenticated Accounts, this process can easily become cumbersome and error prone with a larger number of files. 2. Leverage Existing IS / IT Assets - Server External Authentication takes advantage of IS/IT security assets already in place. For IT personnel who may not be familiar with FileMaker Pro 9 or FileMaker Server 9, this allows them to continue to administer and construct their organization s security schema without having to delve into the FileMaker Pro realm. IT professionals are very accustomed to creating and deleting Groups and Accounts. It is an integral part of IT management. Server External Authentication Page 3 of 57

4 As long as there is a Group defined in FileMaker Pro that matches a domain or local Group, authenticated external Accounts that are members of those Groups can access the FileMaker Pro files with privileges defined by the Privilege Set attached to the Group in FileMaker Pro. That Privilege Set is selected in the same UI as the Group as shown in Figure Better Password Management - OS level password management allows more control and flexibility over password selection and design than does FileMaker Pro. While FileMaker Pro enforces password aging and length and can require the user to change the password after first log on, the OS level management extends these options to include prohibitions against password reuse and can also require specific alphanumeric mixes. 4. Single Sign On - Server External Authentication supports Single Sign On for the Windows platform and an analogous behavior on Macintosh OS X. This is a commonly employed technique in IS/IT system and network management. The concept behind Single Sign On, sometimes called universal authentication log on or single source log on, is the fact that it simplifies user credential management activity by requiring the user to remember only one set of credentials to access digital assets and network based assets. Strictly speaking Single Sign On for FileMaker Pro 9 is a Windows OS client to Windows OS server feature only. However, in Macintosh OS X the feature can be emulated by storing the credential information in the Keychain. 5. Improved Access Control - Use of OS level Accounts permits additional controls on what Account is allowed to connect from what specific workstation. In some instances, the organization s security policies may dictate that a user can connect only from a specific computer or Group of computers and only at specific times of the day. Making Server External Authentication work There are two different core scenarios for configuring and using Server External Authentication. This section describes them both and presents all the practical configuration steps necessary to make Server External Authentication work in each. Scenario 1 - Authentication by the FileMaker Server computer: When a user opens a hosted file, FileMaker Server 9 or FileMaker Server 9 Advanced asks the computer it is installed on to authenticate the user against the Accounts that are created in the Operating System on that computer (Figure 1). This is a simple scenario since the entire configuration is done on the FileMaker Server computer; there are no other computers involved. Server External Authentication Page 4 of 57

5 Figure 1: The Simple Scenario Scenario 2 - Authentication by a Domain Controller: In this scenario the authentication is not done by the computer that runs FileMaker Server but by a higher authority (Figure 2) Server External Authentication Page 5 of 57

6 Figure 2: The more complex scenario There are only two higher authorities that FileMaker Server 9 addresses: the Windows Active Directory and the Apple Open Directory. There are many more Directory Services in existence (see later reference information) but FileMaker Server External Authentication only works with these two. The schematics of Figure 1 and Figure 2 repeat throughout the document for ready reference. Each schematic will indicate with a red dot what part of the setup we are discussing. Server External Authentication Page 6 of 57

7 Setting Up An Example To Illustrate Many Concepts The Example Company Throughout this Technical Brief, an example company, aptly called the company, will be used. Furthermore, the Business Tracker solution from FileMaker Inc will be used to show examples of how to configure Server External Authentication for that company. This Technical Brief will show examples of how to configure Server External Authentication for both the Windows and Macintosh platform. The following are example hardware configurations for the company that will be used throughout this Technical Brief. One shows an all Windows configuration and the other shows an all Macintosh configuration. TheCompany with only Windows Operating Systems Figure 3: The Computers at "TheCompany" 1. A Microsoft Windows XP Professional workstation named company-ws 2. A Microsoft Windows Server 2003 computer dedication to run FileMaker Server 9 named company-fmsa 3. A Microsoft Windows Server 2003 domain controller named company-dc 4. A Domain named the company.com (and the company_ad for pre- Windows 2000 compatibilty.) Server External Authentication Page 7 of 57

8 5. There are no Accounts and Groups in the domain of on the local FileMaker Sevrer computer except those created by default by Windows. Note: Information on how to configure Server External Authentication WITHOUT a domain controller will be discussed later in this technical brief. TheCompany with only Macintosh Systems 1. A workstation compauter named NiMac running OSX A FileMaker Server named FMS_OSX running OSX An Open Directory master named odmaster.thecompanyod.com running OSX Server There are no Accounts on the FileMaker Server computer or on the Open Directory master except those created by the installation. Configuring the Computers and Software What configurations are required for Server External Authentication to work? There are five components to Server External Authentication: 1. The FileMaker Pro 9 solution (one or more files, each having tables) 2. FileMaker Server 9 or FileMaker Server 9 Advanced 3. FileMaker Server 9 computer 4. Domain Controller (only for scenario 2) 5. FileMaker Pro 9 client computer This section describes each component above and shows screenshots of how configure them. Server External Authentication Page 8 of 57

9 The FileMaker Pro 9 solution (hosted by FileMaker Server 9) Scenario 1: FileMaker Server Machine takes care of the External Authentication Server External Authentication Page 9 of 57

10 Scenario 2: Domain Controller takes care of the External Authentication In the FileMaker Pro 9 solution, you need to configure Accounts. As you will see from Figure 4 and Figure 5, there are two types of Accounts in FileMaker Pro 9: Accounts that FileMaker Pro 9 itself will authenticate and Accounts that will be authenticated outside FileMaker Pro 9. Server External Authentication Page 10 of 57

11 Figure 4: The "normal" FileMaker Pro 9 account - the combination of an Account Name and a password Figure 5: An externally authenticated Account: the Group name that matches a Group on the server where the authentication happens For Server External Authentication, you will need Accounts of the second type. Note that there are no passwords involved. All that is required is a Group name that matches the existing Group name on the computer that will do the authenticating. Each Account must be assigned to a Privilege Set. It is the Privilege Set, not the Account, which dictates what the user once authenticated can and cannot do in the FileMaker Pro solution. This is an important distinction to bear in mind: authentication vs. authorization. Authentication: Determines whether a user is valid and legitimate Authorization: Controls the privileges that an authenticated user has. Server External Authentication Page 11 of 57

12 In other words, an Account is just for authentication who are you? while a Privilege Set is for Privilege authorization and determines are you allowed to print/edit/...? Discussions of FileMaker Privilege Sets are beyond the scope of this document. However, there is one important toggle however that needs to be set in each Privilege Set assigned to externally authenticated Accounts. This toggle is the permission to access the file remotely from a FileMaker Pro 9 client (Figure 6). Without that option set, the file will not appear in the list of the hosted files and will not be accessible. Figure 6: A crucial setting in any Privilege Set assigned to external Accounts All the Accounts in a FileMaker Pro 9 file can be viewed in the Account list (Figure 7). Not only is this list a nice overview but it also shows how important the order that Accounts appear in the list is when it comes to external authentication. Server External Authentication Page 12 of 57

13 Figure 7: Accounts are tested in the order the appear here - the Authentication Order The very first time you move an Account around in this list, FileMaker Pro 9 will display a warning (Figure 8) asking if you are sure about this. The warning underlines the importance of the Authentication Order. The consequences of reordering Accounts will be discussed later in this Technical Brief. Figure 8: This warning underlines the importance of the Authentication Order Out of the box, the Business Tracker solution contained one internal Administrator Account (Admin) and two internal user Accounts: geoff and andy (Figure 9.) For this example you will leave the Administrator Account untouched, but you will create two new Externally Authenticated Accounts: managers and data_entry (Figure 10). You will move geoff and andy from being internally authenticated Accounts with internal FileMaker Pro Account names and passwords to being members of external Groups whose authentication occurs outside of FileMaker Pro. Their privileges as defined by their respective attached Privilege Sets can remain the same, because you will assign each Group to a specific Privilege Set as shown in Figure 5. This is the essence of Server External Authentication. Server External Authentication Page 13 of 57

14 Figure 9: The original Accounts in Business Tracker Figure 10: The Business Tracker Accounts ready for Server External Authentication An important point about the FileMaker Pro 9 GET Function (GET(AccountName)) if you use it in your solution: If a user logs onto a file with an Account that is internally authenticated by FileMaker Pro, this function will return that internal Account name: for example, andy. If the user logs onto the same file with an Account that is a member of a Group that is externally authenticated, that Account name will still be returned: andy, not the name of the Group to which andy belongs: data_entry. Server External Authentication Page 14 of 57

15 FileMaker Server 9 or FileMaker Server 9 Advanced Scenario 1: FileMaker Server Machine takes care of the External authentication Server External Authentication Page 15 of 57

16 Scenario 2: Domain Controller takes care of the External authentication FileMaker Server 9 needs to be changed from its default configuration to allow for Server External Authentication. You will use the Uniform Administration Console (UAC) tool to do this. This tool configures the FileMaker Server 9 software itself here --- not the computer where FileMaker Server 9 is installed. The computer where FileMaker Server 9 is installed will be discussed next. The Console can be used remotely right out of the box. Point your browser to: or name of your FMS machine>:16000/ Server External Authentication Page 16 of 57

17 for the Admin Console start page and from there you can install the Admin Console on your workstation.. You can log in with the account and password you defined when setting up FileMaker Server 9. Figure 11: Admin Console Login However, you can also configure FileMaker Server 9 to allow access to the Admin Console to users that belong to the fmsadmin group (see Figure 12). Figure 12: Allowing fmsadmin users access to the Admin Console The wording on this screen can be a bit misleading. It creates the impression that the fmsadmin group must exist on the local FileMaker Server 9 machine. But in fact, in a domain setup, it can also exist on the domain controller instead of the local FileMaker Server machine. A couple of interesting tidbits on logging into the Admin Console: The user name input box is limited to 25 characters so if you want to use UPN (user@domain.com) or UNC (domain\user) syntax for the user name you may hit that limit. UNC and UPN usernames will be discussed in detail later in the Special Scenarios section of this document. Server External Authentication Page 17 of 57

18 If the FileMaker Server machine belongs to the domain and the fmsadmin group exists on the domain then using just the user name is enough. UPN or UNC syntax is not needed unless you work with a complex setup involving multiple domains. Single Sign-On (SSO) is not supported for signing into the Admin Console. The Admin Console does not recognize the credentials with which you are currently logged into your workstation. So if you are logged into your workstation with an account that belongs the fmsadmin group you will still need to enter your user name and password to access the Admin Console. These credentials are just for administration and not for letting users into the solution. For client authentication we need to be on the Security tab of the Database Server section (Figure 13). Figure 13: The Security properties where you configure FileMaker Server 9 to use External Accounts As you can see from the options in Figure 13, the choice is not between using FileMaker Accounts or External Accounts. Even with Server External Authentication on, FileMaker Pro 9 Accounts can still be used to access the solution. Every FileMaker Pro 9 file must have at least one internally authenticated [Full Access] Account. It is strongly recommend that Administrators and developers never authenticate such [Full Access] Accounts externally. Because both types of Accounts can be used at the same time - it is a good idea to disable the old internal Accounts. But notice that in Figure 10 the [Full Access] Admin Account remains active. Additional information will be provided about the other configuration options shown in Figure 13 (File Display Filter & Secure Connections) in the Other FileMaker Server settings and their relationship to External Authentication section towards the end of this Technical Brief. For now it is enough to know that they are not necessary to make Server External Authentication work. Server External Authentication Page 18 of 57

19 FileMaker Server 9 Computer Scenario 1: FileMaker Server Machine takes care of the External authentication Server External Authentication Page 19 of 57

20 Scenario 2: Domain Controller takes care of the External Authentication The computer FileMaker Server 9 runs on plays a different role depending on the scenario being examined. In scenario 1 where the computer itself is in charge of authenticating users, the Accounts and Groups required need to be created on that computer. If there is a domain controller involved then the required Accounts do not need to be created on the FileMaker Server computer, but you do have to confirm that the FileMaker Server computer is part of the domain where those Accounts exist so that it knows who to contact to authenticate an Account. Server External Authentication Page 20 of 57

21 Scenario 1: FileMaker Server 9 computer performs authentication In this scenario you need to create Accounts and Groups on the FileMaker Server 9 Computer. Windows Before starting, make sure you are logged into the computer with an Administrator Account. The easiest way to create local Accounts and Groups on a Windows Server is to right-click on the My Computer icon and choose Manage from the context menu (Figure 14). If you do not have Windows configured to display the My Computer icon on the Desktop it can also be found in the Start menu. Additionally, you can get to the Management Console to create Accounts and Groups by accessing it directly at Start > All Programs > Administrative Tools > Computer Management. If you do not see local Accounts and Groups then the computer is configured as a domain controller. Domain Controllers do not have local Accounts and cannot be used for scenario 1. It is not recommended to use a domain controller computer as a FileMaker Server computer. Domain controllers can get very busy and therefore could affect FileMaker Server performance. This also specifically includes replication of Open Directory on servers running OS X Server and FileMaker Server 9 or the use of Active Directory slaves on similar Windows OS computers running FileMaker Server 9. Server External Authentication Page 21 of 57

22 Figure 14: The quickest way to create Accounts and Groups on the local FileMaker Server 9 computer You need to create an Account for both geoff and andy (the two original users of Business Tracker) and two Groups: managers and data_entry. Start with the Accounts by following the flow as shown in Figure 15. Click on the users folder in the left panel and from the Action Menu, choose New User. Create the user geoff and repeat the process for user andy. Server External Authentication Page 22 of 57

23 Figure 15: How to create a new local user Next, create the Groups. Click on the Groups folder in the left panel and from the Action menu choose New Group. Click the Add button so that you can add user geoff to this Group. On the dialog that comes up (Figure 17) note the location of from where you will pick the name. This should be the name of the local computer company-fmsa in this case. If it is not the same as the computer s name then that computer is configured as a member server in a domain. If you have domain Accounts that match the local Accounts (same Account name and password) then the FileMaker Server will examine the groups to which the domain Account belongs, not the local account. The best way to avoid this is to remove the FileMaker Server machine from the domain. The method for removing the FileMaker Server machine from the domain will be explained at the end of this section. Figure 16: Check the Location from where the users will be added If the location is correct, type in the name of the user ( geoff ) and click Check Names. If the name appears underlined then user was found (Figure 17). Click OK to add the user and back on the New Group dialog click Create to commit the new Group. Server External Authentication Page 23 of 57

24 Figure 17: The name was found - it appears underlined Repeat the process to create another Group named data_entry and add user andy to it. (Figure 18) Figure 18: Finished. Two local Groups and two local Accounts are created. Server External Authentication Page 24 of 57

25 Macintosh OS X: It is recommended that OSX Server be used to run FileMaker Server. How to set up accounts and groups on OS Server will be discussed in the next section. FileMaker Server 9 runs quite well using regular OSX. Creating user accounts in regular OSX is handled by the Accounts pane in the System Preferences. Figure 19: Accessing the Accounts from the System Preferences Creating groups is a little more involved and requires the use of the Netinfo Manager utility in OSX 10.4 or the Directory utility in OSX Server External Authentication Page 25 of 57

26 Figure 20: Adding a user to the Group using OSX 10.4 Figure 21: Adding a user using OSX 10.5 Both the Netinfo Manager and Directory utility can be found in the /Applications/Utiilities folder. In OSX 10.4 you can also use the popular donationware utility called SharePoints to make creating Groups easier. Server External Authentication Page 26 of 57

27 It is important to note the use of the short name when creating groups. FileMaker Server 9 on OSX Server looks only for the Group short name returned from the Directory Services. This is the official name that identifies the Group to the system, not the long (user-friendly) name. Thus, in the definition of Accounts in FileMaker Pro 9 for External Server authentication, the defined Group name must match the Directory Service Group short name. In many instances the long and short names will be identical. However, in some instances they will be not be. OS X Server Figure 22: Adding the "managers" Group through SharePoint Creating groups and Accounts using OS X Server is very similar to the method used when using SharePoints. OS X Server installs the WorkGroup Manager utility for managing Accounts and Groups. Just as was the case with OS X, you will want to create the two Accounts, geoff and andy, and the two Groups, data-entry and managers. You will then assign each Account to the correct Group. All this is done within the WorkGroup Manager. Figure 23 through Figure 26 illustrates this process. Figure 23: Create the two groups in WorkGroup Manager Figure 24: Create the two Accounts for "andy" and "geoff" in Workgroup Manager Server External Authentication Page 27 of 57

28 Figure 25: Assign Account geoff to managers Group in WorkGroup Manager As far as scenario 1 is concerned FileMaker Server authenticates users based on the Accounts and Groups on its own computer therefore no further configuration should be required. The only remaining thing to do is to make sure that the FileMaker Server computer only looks locally for Accounts and doesn t look anywhere else. Windows Figure 26: Assign Account "andy" to "dataentry" Group in WorkGroup Manager On Windows the only foolproof way of making sure only local Accounts are being used is to remove the FileMaker Server machine from the domain. Remember that when FileMaker Server is part of the domain it will always look on the domain for a matching Account, and only examine the local Accounts if it did not find a match for the account on the domain. While it is entirely possible to use FileMaker Server local authentication when the FileMaker Server computer is part of the domain, it does add a level of complexity especially for troubleshooting. Additionally there is potentially a security risk when a user might receive a Privilege Set and authorization level that he is not intended to get. Right-click on the My Computer icon again (see Figure 14) but choose Properties from the context menu. In the tabbed dialog that appears choose Computer Name Server External Authentication Page 28 of 57

29 (Figure 27). The computer will either be listed as part of a domain or part of a workgroup. Figure 27: Checking if the FileMaker Server 9 computer is part of a domain; it is not. Server External Authentication Page 29 of 57

30 Figure 28: Checking if the FileMaker Server 9 computer is part of a domain: It is. If the computer is part of a domain then you need to decide whether to leave the computer as part of the domain or to remove it from the domain and avoid any potential authentication conflicts between the domain Accounts and the local Accounts. You will need to have the Domain Administrator user name and password to complete the process, or have a Domain Admin do it for you. Server External Authentication Page 30 of 57

31 The Change button will let you join a domain (for scenario 2) or leave a domain (for scenario 1). For scenario 1 (only local authentication) you will need to change Member of Workgroup. The workgroup name is not very important; it serves mainly to group computers together in the Network Neighborhood. Macintosh Figure 29: After clicking the "Change" button: here you can join or leave a domain To force the FileMaker Server computer to use only the local Accounts and Groups we need to use the Directory Access utility (in the /Applications/Utilities/ folder). Switch to the Authentication tab and make sure that the Search value list is set to Local Directory and click Apply. Server External Authentication Page 31 of 57

32 Figure 30: Making sure the FileMaker Server computer only uses local Accounts That is all there is to it. The configurations in the Services tab will be ignored with this setting. The other two choices in the Search drop-down (Automatic, Custom Path) will be discussed in scenario 2. Server External Authentication Page 32 of 57

33 Scenario 2: Domain Controller Performs the Authentication Making the FileMaker Server computer part of the domain Scenario 2: Domain Controller takes care of the External Authentication If you want the domain controller to handle all the authentication requests then you do not create Accounts and Groups on the local FileMaker Server computer. However, you have to make sure that the computer is a member server of the domain otherwise it does not know how to contact the domain controller for authentication. This is how you do that. Windows Typically joining a domain is part of the installation process for Windows Server The first thing to check is if the computer is already a member of the domain. The method for doing this was discussed in the previous section. If the FileMaker Server External Authentication Page 33 of 57

34 Server computer is currently not part of the domain you will need to use the Change button to join the domain. This will require a Domain Admin username and password to complete. Macintosh For the FileMaker Server computer to talk to the Apple Open Directory, you need to make a few configuration changes. You need to use the Directory Access utility to accomplish this. On the first tab, you need to configure the LDAPv3 setting. This should not be confused with registering a FileMaker Server computer with the LDAP directory. This is an important point; do not overlook it. It has been the cause of considerable confusion among developers and Administrators. Figure 31: The LDAPv3 service connects to the Open Directory The Configure button will take you to this screen where you need to create the correct connection to your Open Directory (click the New button at the bottom). The configuration name can be anything you like but the Server Name or IP address must be of the Open Directory master. Server External Authentication Page 34 of 57

35 Figure 32: The LDAPv3 service configured to connect to the Open Directory master With the correct settings applied here, go to the second tab of the Directory Access utility: Authentication. As you can see from Figure 33, custom path has been selected from the Search dropdown list. The first choice ( Automatic ) would take its feed from the DHCP settings of the computer. Since you are configuring a FileMaker Server computer it must have a static IP address, and thus it will not get any Open Directory information from DHCP parameters. The Custom Path setting lets you set the sequence of authorities the computer will contact in order to authenticate a user. Figure 33: Setting the authentication path to the Open Directory master Server External Authentication Page 35 of 57

36 Click on the Add button and select the /LDAPv3/ entry. The result will look something like Figure 34. Figure 34: The finished Authentication parth for scenario 2 Note that the grayed-out /NetInfo/root/ entry remains the start node of the authentication process. There is no way around that; OS X will always evaluate its local Accounts first before contacting the Open Directory master. The implication of this behavior is of course that you should make sure there are no local Accounts with the same names as the Open Directory Accounts. If you have a local user named geoff with password 123 and a user geoff in the Open Directory with password abc and you want to log in to the solution with the Open Directory Account (geoff/abc), FileMaker Server will not let you in. It will have found geoff on the local computer and will expect 123 as the password, not abc. Server External Authentication Page 36 of 57

37 The Domain Controller This component only plays a role in the scenario where the domain controller handles authentication requests and not the FileMaker Server 9 computer. The decision whether or not to use a domain is not always a decision that you as the FileMaker Pro developer can take; sometimes it will be dictated by the IT department you are dealing with. If there is a domain controller then you may need to configure the Accounts and Groups there. Even if the IT department takes care of that, it is useful to know where they are and what the dynamics are that make them work. Windows Creating Accounts and Groups on the domain requires Domain Admin privileges. Depending on the situation and configuration involved, this might mean getting the IT department involved. Server External Authentication Page 37 of 57

38 Physical access to the domain controller computer could be another problem. For that reason there is a remote admin toolkit: the Server 2003 Administration Pack. You will find it on the install CD or you can download it directly from the Microsoft website. Note though that you can only run the Server 2003 Administration Pack from Windows XP Professional workstations or other Windows Server 2003 computers. Whether you decide to use the Server 2003 Administration Pack or access the local computer directly the interface to create Accounts and Groups is the same. Start with creating Accounts for geoff and andy. Navigate from the Start button to the Administrative Tools. That is where you will find the tools to configure the Active Directory (Figure 35). Select Active Directory Users and Computers. Figure 35: Active Directory consoles in the Administrative Tools From the Action menu, choose New and then User. The bottom two entries on the middle window of Figure 36 are for the logon name that the user will use. On the next screen, you will need to provide a password and set the Account properties as needed (except Account is disabled which will render the Account useless). Side note: the Action menu is context sensitive. It will show different actions depending on what you have selected in the right or left pane. In the left pane, select the Users folder to have access to the New option. Server External Authentication Page 38 of 57

39 Figure 36: Creating a user Account in Active Directory Repeat the process for andy and you will end up with two Accounts as in Figure 37. The other Accounts and Groups you see are those created by Windows. Figure 37: Finished creating two domain user accounts What you need next is two Groups: managers and data_entry and add geoff and andy to their respective Groups. Still in the same Active Directory Users and Computers console, choose New and Group from the Action menu. The dialog from Figure 38 will display and you type in the name of the Group. This is where it has to match exactly the name you have given the Account in the FileMaker Pro solution. Server External Authentication Page 39 of 57

40 Figure 38 (left) - Creating a new Domain Group & Figure 39 (right) - Domain Group name must match the FileMaker Pro Account name What about those Group scope and Group type options? The Group type is easy: you always want Security Groups because they are the only type that is involved in authentication. Distribution is mainly for creating lists. The scope is a little more complex. However, Global is the default and is a good choice in almost all circumstances. Only in very large deployments with complex domain structures would domain local and Universal be used. If you want to learn more about the differences, we suggest browsing the Microsoft web site or utilizing a good book about Windows Active Directory. Repeat the process to create new Groups named data_entry and fmsadmin. Figure 40: Finished creating new domain Groups Server External Authentication Page 40 of 57

41 With the Groups created as in Figure 40, you still need to add the users to them. Double-click the data_entry Group and click the Add button. In the dialog that comes up you can just type a username (andy) and have it checked. Alternatively, you can click the Advanced button; click Find now on the next dialog to see a list of all users and Groups that exist on the domain. When the name shows up underlined then everything is good. Repeat the process by adding geoff to the managers Group. Give some thought to whom you want to add in the fmsadmin Group. Anyone in that Group will be able to administer FileMaker Server remotely (see Figure 11), including changing the settings and viewing the connected users or the list of hosted files. This completes the description of creating Accounts and Groups on the domain controller. Macintosh To create Accounts and Groups you need to be on the Open Directory master or an OS X computer that has the server utilities installed (from the OS X Server CD). The utility you need is called Workgroup Manager and is usually in the Dock already. If the WorkGroup Manager is not in the dock, you can find it in the Applications/Utilities/Server/ folder. You will want to create two Accounts for geoff and andy. Make sure the Users tab is active and click on New User (Figure 41). Type in the user name and a password and click Save. Figure 41: Creating a new user in the Workgroup Manager Server External Authentication Page 41 of 57

42 Figure 42: Both user Accounts in Open Directory Switch to the Groups tab and select New Group (Figure 43). Figure 43: Creating Groups in Open Directory The + button will show a drawer of available users that you can double-click or drag to the Group (Figure 44). Do this for the three Groups you need: data_entry, managers and fmsadmin (see Figure 45). Server External Authentication Page 42 of 57

43 Figure 44: Adding users to a Group Figure 45: Finished Groups & Users in the Open Directory This completes the Open Directory part. More settings apply to Users and Groups here that have not been discussed. These settings are part of the network security and privileges setup specific to your deployment and beyond the scope of just getting users authenticated with these external Accounts. Server External Authentication Page 43 of 57

44 FileMaker Pro 9 Client Computers Server External Authentication Page 44 of 57

45 The final part of the puzzle is the workstation where FileMaker Pro 9 will run and connect to the hosted solution. As was the case with the FileMaker Server 9 computer, workstations can either be part of a domain or not. However, it is less important than the configuration of the FileMaker Server 9 computer. It is only truly important if you want to achieve SSO (Single Sign On). In the introduction, it was mentioned that one of the benefits of using Server External Authentication is SSO since it allows users to open hosted FileMaker Pro solutions with their proper Privilege Set without being prompted for an Account name or password. This works only on Windows and only in the following scenario: A user is logged into the Windows workstation using a domain Account (the workstation needs to be part of the domain for that). In other words, the user is already authenticated and there is an existing connection between that user and the domain. The domain Group name the user s domain Account belongs to is properly set up in the FileMaker Pro 9 solution as an externally authenticated Account. The FileMaker Server 9 computer is part of the same domain as the user s workstation. With these options in place, the user will not be prompted for an Account name or password when they open the solution. FileMaker makes use of the existing connection between the user and the domain to ask the Domain Controller for a list of Groups that the user belongs to. Since one of those Groups matches an Account in FileMaker Pro 9, the user gets access to the files. To make a Windows workstation part of a domain, follow the instructions given earlier in this Technical Brief. What about SSO on Macintosh OS X? Something very similar can be achieved but only if the Account/password combination is stored in the Keychain. Strictly speaking, this is not true SSO since FileMaker does not use an existing connection but extracts the Account name/password combo from the Keychain and sends that to FileMaker Server to have it authenticated. The result is close to SSO. There is no need to make the OS X workstation part of a domain; the Keychain stores all the necessary information for the connection. To get the information in the Keychain the user does need to log on once manually to FileMaker Server and opt to save the Account name and password (Figure 46). In addition, if the Account name or password changes the Keychain needs to be updated. Server External Authentication Page 45 of 57

46 Figure 46: Storing the Account name and password in the KeyChain Except for SSO on Windows, how the workstation is configured does not matter at all. If you send an Account name and password to FileMaker Server, it is both the configuration of the FileMaker Server computer and the behavior of the respective operating system that will dictate where those credentials will be authenticated: locally or by Active Directory/Open Directory. If the FileMaker Server 9 machine is part of the domain, it will try to use the credentials authenticated by the domain controller. If the machine is standalone, it will look at its own accounts. Windows behaves a little different than OSX in this matter: if the FileMaker Server machine is part of the domain, the domain has precedence over the local accounts, whereas OSX will always look at the local accounts before asking the domain controller. Other FileMaker Server settings and their relationship to External Authentication File Display Filter (otherwise known as Database Visibility) On the security tab of the FileMaker Server configuration (Figure 13) there is a setting for File Display Filter. With this toggled on a user will only see the files for which he or she has an Account. For that to happen, FileMaker Server 9 needs to know who that user is before it can compile the list of files for that user. Unless the deployment is one where SSO works or where credentials are stored in the keychain, the user will be prompted for an Account name and password after selecting a server in the open remote list. In short, the authentication process is the same, only it happens earlier when Database Visibility (Database Filtering) is on. Unless all the conditions for SSO (Windows) are met or the Account name/password is stored in the keychain (Macintosh) the user will be challenged twice: once to see the list of files, a second time to open the selected file. Windows XP Pro Service Pack 3 released in mid 2008 disrupts the SSO capability for Windows users. When Database Visibility is enabled, users running Windows XP Pro SP3 will be challenged for access to FileMaker Server 9 even if they have previously authenticated to the network or to the local Group. Users simply enter their credentials again at the challenge. The list of available databases will then Server External Authentication Page 46 of 57

47 display; a user can then select one and be connected to it without further challenge. Encryption The last setting on the security tab (Figure 13) is to enable Secure connections to FileMaker Server. Using this setting means that the traffic between FileMaker Pro clients and FileMaker Server 9 is SSL encrypted. This can include if properly configured Web browsers if SSL is enabled for either Apache (Macintosh OS X Server) or IIS 6 (Windows Server 2003). It has nothing to do with external authentication. The authentication process is encrypted in itself, but that is because the Operating System takes care of that; FileMaker Server 9 has no say in it. LDAP The Lightweight Directory Access Protocol (LDAP) is an application protocol for querying and modifying directory services running over TCP/IP Just as HTTP (Hypertext Transfer Protocol) is a protocol to communicate between a web browser and a web server, LDAP is a set of rules about communicating with a Directory Service. There are other protocols for doing that, but LDAP has very much become the standard. Nevertheless, before we can make the link with FileMaker Server we need to explain briefly what a Directory Service is. We all know what a phone directory is; a directory service is very similar. A directory service is a list of people with a collection of data including Account names and passwords (so we can retrieve that for authentication). It can also store people s phone numbers, addresses, departments, and so on. LDAP can also list other resources such as printers and locations of databases A Directory Service is an essential part of a networked organization. It centralizes information and makes it easy to locate. The Directory Service sits at the heart of the network part of our operating systems. FileMaker Server has a Directory Service tab (Figure 47) where you can list the FileMaker Server 9 computer in a Directory Service. This is purely so that users or Administrators can easily find where various servers running FileMaker Server 9 are located. It has nothing to do at all with authentication. Additionally while Windows Active Directory and Apple Open Directory are both Directory Services and while they both support the LDAP protocol this has nothing to do with the Directory Service configuration in the FileMaker Server settings. Server External Authentication Page 47 of 57

48 Figure 47: The "Directory Service" configuration in FileMaker Server - the only place where you will get close to LDAP. Special Scenarios Figure 48: Clicking the button in Figure 47 opens this window Using UPN/UNC to force authentication FileMaker Server on OS X Server always looks to its local Account first before looking on the domain if there is one. FileMaker Server on Windows does the opposite: It always looks on the domain before looking at the local Accounts. That may not always be the behavior you want. What do you do when you have Accounts that are the same both on the local machine and in the domain (same Account name and password) but they belong to different groups and therefore they have different Privilege Sets? What if you want to let the user in with the Account that is different than the one FileMaker Server would use by default (the domain Account on Windows or the local Account on OS X Server)? What you will need to do then is to use either the UPN or UNC logon syntax explicitly to tell FileMaker Server 9 where to look. That respective syntax for UPN and for UNC looks like this: Server External Authentication Page 48 of 57

49 (UPN) or thecompany-fmsa\geoff in UNC (Figure 49). When logging in with these Account names, FileMaker Server will not pass the authentication request on to the domain master as it would do by default, but will ask its own computer (named the company-fmsa ) to take care of it. UNC Universal Naming Convention format. The UNC syntax of a domain Account looks like this: thedomain\theusername UPN - User Principal Name is a second and relatively new format of specifying the domain and a username in one. This one is very familiar: it looks just like an address: theusername@thedomain The equivalent syntax for a local account would use the machine s name instead of the domain name. You can find both formats in the middle window of Figure 49. Figure 49: UPN and UNC logons to the local FileMaker Server computer Note that in this instance, the FileMaker Pro 9 function GET(AccountName) will return the full Account string you entered, not just geoff (Figure 50). Figure 50: Get(AccountName) results when using UPN/UNC format login names. Server External Authentication Page 49 of 57

50 Troubleshooting: What if it does not work as you expect it should? Does the Account work? Probably the first and the easiest test is to use the Account and to try to log in to the OS. Ideally, you would want to do this on the FileMaker Server computer because it is that computer that either authenticates or sends the authentication request somewhere else. However, in both scenarios you should always be able to log into the FileMaker Server computer if the Account is valid. If it does not work then either the Account name or password are not correct or the FileMaker Server computer is not set up correctly to handle that Account. Using the FileMaker Server computer as a test bed is not always practical or advisable though, so you might need to set up another computer in exactly the same way to do your testing. If the Account works then the next step is to determine the Groups the user is a member of. Group Membership The obvious place to look at Group memberships is where the local or domain Group have been created. However, that does not always paint the full picture. Groups can be a member of other Groups. Domain Groups can be a member of a local Group. The result is that a user may be a member of more Groups than you think. Luckily, some tools can help us out with this. Windows Windows XP has a command line utility that is part of the Resource Kit that can show you information about the current active user Account. To use it, you would log in to a computer with the Account you want to test, go to a command line window and type in whoami /Groups. Figure 51: Using "whoami" to view all the Groups a user belongs to. Figure 56 is a real life example of a user (Wim) logged in to his XP Professional workstation (P4) with a domain Account (domain is named CONNECTINGDATA ). As you can see, he belongs to twenty Groups including one local Group. On the Server External Authentication Page 50 of 57

51 other hand, under Wim s Account properties on the Domain Controller we see only 12 Groups listed. (Figure 52). Figure 52: Group membership reported by the Domain Controller Note that you would have to run this command on the FileMaker Server computer to get a relevant list of local Groups. What local Groups the Account belongs to on any other computer is irrelevant. Another command line tool you can use is the universal Net command. The Net command is installed by default and does not require that you are currently logged in to the workstation with the Account you want to test. Unlike the whoami command, however it can only give you the Group memberships on one level (local or domain) and it does not follow your Account through Groups in Groups membership. Therefore, you need to use the command in a couple of different ways to get the overall overview. At the command prompt type in: NET USER username /DOMAIN You will get an overview of the domain Groups to which that user belongs. Figure 53 shows fmuser1 on the connectingdata domain. Server External Authentication Page 51 of 57