server authentication wp - · pdf filethere are several compelling reasons for selecting...

Server External Authentication page 1

Technology Brief

Server ExternalAuthentication

FileMaker Pro 8, FileMaker Server 8, FileMaker Server 8 Advanced

Server External Authenticationpage 2

Table of Contents

What is Server External Authentication? ....................................................................................... 3

Why Use Server External Authentication? .................................................................................... 3

Making Server External Authentication Work ...............................................................................Making Server External Authentication Work ...............................................................................Making Server External Authentication Work 5

Scenario 1: Authentication by FileMaker Server Computer .................................................. Scenario 1: Authentication by FileMaker Server Computer .................................................. Scenario 1: Authentication by FileMaker Server Computer 5

Scenario 2: Authentication By a Domain Controller ............................................................. Scenario 2: Authentication By a Domain Controller ............................................................. Scenario 2: Authentication By a Domain Controller 6

Setting Up An Example To Illustrate Many Concepts .................................................................. 7

Windows Only ................................................................................................................................. 7

Macintosh Only ............................................................................................................................... 8

Confi guring The Computers and Software .................................................................................... 8

• The FileMaker Pro solution ........................................................................................................ 9

• FileMaker Server 8 or FileMaker Server 8 Advanced ........................................................16

• FileMaker Server 8 Computer ................................................................................................ • FileMaker Server 8 Computer ................................................................................................ • FileMaker Server 8 Computer 20

FileMaker Server 8 Computer Performs Authentication ............................................21

Domain Controller Performs Authentication ...............................................................38

• The Domain Controller (Scenario 2) ....................................................................................42

• FileMaker Pro 8 Client Computers .......................................................................................51

Other FileMaker Settings and their relationship to External Authentication ......................53

Database Visibility .........................................................................................................................53

Encryption ......................................................................................................................................54

LDAP ................................................................................................................................................54

Special Scenarios ................................................................................................................................56

Using UPN/UNC to force authentication ...............................................................................56

Troubleshooting:

What if it does not work as you expect it should? ....................................................................57

Does the Account Work? ............................................................................................................57

Group Membership ......................................................................................................................57

Double Check the Authentication order ................................................................................ Double Check the Authentication order ................................................................................ Double Check the Authentication order 61

Check the computer’s clock ....................................................................................................... Check the computer’s clock ....................................................................................................... Check the computer’s clock 61

Event logs ........................................................................................................................................61

Clean up the Keychain .................................................................................................................64


What is Server External Authentication?FileMaker® Server 8 and FileMaker Server 8 Advanced both support Server External Authentication of FileMaker Pro 8 Accounts including those Accounts accessed from Web Browsers when using FileMaker Server 8 Advanced. This Technical Brief discusses in detail what Server External Authentication is and how to confi gure it on both Windows and Macintosh platforms.

First, a bit of review about Accounts in FileMaker Pro 8. Accounts consist of both an Account name and a password. These can be checked and authenticated either internally by FileMaker Pro 8 or externally by FileMaker Server 8 using operating system (OS) level Accounts. On Windows OS these are Active Directory Accounts; on Mac OS X they are Open Directory Accounts. Additionally, depending on the specifi c network confi guration, directory services from one platform can authenticate users on the other platform. In other words, a Macintosh user might be authenticated by Active Directory; a Windows XP Pro user might be authenticated by OS X Server’s Open Directory.

Accounts can reside either on the local FileMaker Server 8 computer or they can reside on a Domain Controller elsewhere on an accessible network. When a user’s credentials are deemed to be authentic and valid, the user is admitted to the FileMaker Pro 8 fi le 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 a name and a password.

This Tech Brief was originally based on features found in FileMaker Server 7.0v2 and FileMaker Server 7.0v3 on both the Macintosh and Windows platforms. We strongly recommend that developers and Administrators update their installations to the latest version (7.0v3).

Please note: this Technical Brief is relevant to both FileMaker 8 and FileMaker 7 products.

Why Use Server External Authentication?There are several compelling reasons for selecting Server External Authentication of FileMaker fi les:

• Account Management. First, it allows separation of Account management from the FileMaker Pro fi les. This gets the developer out of the Account management business. In multiple fi le solutions, this can be especially helpful. Accounts and their passwords are established and managed in one central location, rather than having to be maintained or updated in each individual fi le. While scripted Account management can administer internally authenticated Accounts, this process can easily become cumbersome and error prone with a larger number of fi les.


• Leverage Existing IS/IT Assets. Second, Server External Authentication takes advantage of IS/IT security assets already in place. For IT personnel who may not be familiar with FileMaker Pro 8 or FileMaker Server 8, this allows them to continue to administer and construct the 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.

As long as there is a Group defi ned in FileMaker Pro that matches a domain or local Group, authenticated external Accounts that are members of those Groups can access the FileMaker Pro fi les with privileges defi ned 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 5.

• Better password management. Third, OS level password management allows more control and fl exibility over password selection and design than does using FileMaker Pro alone. While FileMaker Pro enforces password aging and length and can require the user to change the password after fi rst log–on, the OS level management extends these options to include prohibitions against password reuse and can also require specifi c alphanumeric mixes.

• Single Sign On. Fourth, 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 belief that it simplifi es user credential management activity by requiring the user to remember only one set of credentials to access digital assets and network based assets. While this belief is almost certainly a correct one, nevertheless it does transfer the security of the database to something outside of FileMaker Pro. Developers may wish therefore to learn more about network security and authentication generally.

Strictly speaking Single Sign On for FileMaker Pro 8 is a Windows OS client to Windows OS server feature only. However, in Macintosh OS X the feature can be mimicked by storing the credential information in the Keychain.

• Improved Access Control. Fifth, use of OS level Accounts permits additional controls on what Account is allowed to connect from what specifi c workstation. In some instances, the organization’s security policies may dictate that a user can connect only from a specifi c computer or Group of computers.


Making Server External Authentication work

The two core scenarios. There are two different core scenarios for confi guring and using Server External Authentication. This section describes them both and presents all the practical confi guration steps necessary to make Server External Authentication work in each.

Here is a brief description of those scenarios to help developers and Administrators understand what is happening.

• Scenario 1: Authentication by the FileMaker Server computer:

When a user opens a hosted fi le, FileMaker Server 8 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 confi guration is done on the FileMaker Server computer; there are no other computers involved.

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).

Figure 2 - The more complex scenario.


There are two higher authorities that FileMaker Server 8 addresses: the Windows Active Directory and the Apple Open Directory. 1 There are many more Directory Services in existence (see later reference information) but 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.

Setting Up An Example To Illustrate Many Concepts

The example companyAside from explaining the concepts, we will use an example company (aptly called “the company”) and prepare the Business Tracker solution for Server External Authentication for that company. We will do the confi guration for both Windows and Macintosh.

Thecompany with only Windows Operating Systems

Figure 3 - The computers at “thecompany”.

1 See Mac OS X Server Open Directory Administration White Paper. {Cupertino, CA. Apple Computer} 2004


There are 3 computers at “the company”: a Windows XP Professional workstation (named “company-ws”), a Windows Server 2003 computer dedicated to FileMaker Server 8 (named “company-fmsa”) and a Windows Server 2003 domain controller (named “company-dc”). (Note: we will also show how to do Server External Authentication without a domain controller). There is a domain named “thecompany.com” (and “thecompany_ad” for pre-Windows 2000 compatibility). There are no Accounts and Groups in the domain or on the local FileMaker Server computer except those created by default by Windows.

Thecompany with only Macintosh Operating systemsIn the example scenario where the company uses only Macintosh computers, the workstation (named “NiMac”) and FileMaker Server (named FMS_OSX) are OS X 10.3.7 computers and there is an Open Directory master running on OS X Server 10.3.7. that is named “odmaster.thecompanyod.com”.

When we start off 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 confi gurations are required for Server External Authentication to work?There are 5 components to the Server External Authentication mix:

• The FileMaker Pro 8 solution (one or more fi les, each having tables)4

• FileMaker Server 8 or FileMaker Server 8 Advanced (software)

• FileMaker Server 8 computer

• Domain Controller (only for scenario 2)

• FileMaker Pro 8 client computer

2 Note that for the actual domain name, we follow standard nomenclature with no spaces in the name.

3 The Business Tracker is a free solution you can download from the FileMaker, Inc. website: http://www.fi lemaker.com/collection/. It is a functional business tracking system showcasing some of the many new features in FileMaker Pro 8.

4 It is, of course, possible for a fi le to have no tables.


This section describes each component and shows screenshots of how to do the confi guration.

• The FileMaker Pro 8 solution (hosted by FileMaker Server 8)


In the FileMaker Pro 8 solution, we need Accounts of course. As you can see from Figure 4 and Figure 5, there are two types of Accounts in FileMaker Pro 8: Accounts that FileMaker Pro 8 itself will authenticate and Accounts that will be authenticated outside FileMaker Pro 8.


Figure 4 - The “normal” FileMaker Pro 8 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 wherethe authentication happens


For Server External Authentication we 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 authentication.

Each Account must be assigned to a Privilege Set. It is the Privilege Set, not the Account, that 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. The former determines whether a user is valid and legitimate. The latter controls the privileges that a previously authenticated user has. In other words, an Account is just for authentication (who are you?); the Privilege Set is for authorization (are you allowed to print/edit/...?).

This Tech Brief does not discuss Privilege Sets since they are beyond the scope of this document.5 There is one important toggle however that needs to be set in each Privilege Set assigned to externally authenticated Accounts: the permission to access the fi le remotely from a FileMaker Pro 8 client (Figure 6). Without that option set, the fi le will not appear in the list of the hosted fi les and will not be accessible.

Figure 6 - A crucial setting in any Privilege Set assigned to external Accounts

5But see the various Technical Briefs on FileMaker Pro 8 Security and FileMaker Server 8 found on the FileMaker, Inc. website at: http://www.fi lemaker.com/upgrade/techbriefs.html


All the Accounts in a FileMaker Pro 8 fi le can be viewed in the Account list (Figure 7). This list is not just a nice overview; how the Accounts are ordered in this list plays a crucial role in external authentication.

Figure 7 - Accounts are tested in the order the appear here: the Authentication Order

The very fi rst time you move an Account around in this list, FileMaker Pro 8 will display a warning (Figure 8) asking if you are sure about this. The warning underlines the importance of the Authentication Order. More about the consequence of ordering Accounts later.

Figure 8 - this warning underlines the importance of the Authentication Order


The Business Tracker solution you download contains internal FileMaker Pro 8 Accounts (Figure 9). One Administrator Account (Admin) and two user Accounts: geoff and geoff and geoff andy. We will leave the Administrator Account untouched, but we will create two new Externally Authenticated Accounts: “managers” and “data_entry” (Figure 10). We will move geoff and geoff and geoff andy from being internally authenticated Accounts with andy from being internally authenticated Accounts with andy internal FileMaker Pro Account internal FileMaker Pro Account internalnames and passwords to being members of external Groups whose authentication occurs outside of FileMaker Pro. Their privileges—as defi ned by their respective attached Privilege Sets—can remain exactly the same, because we assign each Group to a specifi c Privilege Set as shown in Figure 5. 6 This is the essence of Server External Authentication.

Figure 9 - The original Accounts in Business Tracker.

6 Developers could of course create an entirely new Privilege Set, with entirely different privileges, for each of these Groups.


Figure 10 - The Business Tracker Accounts ready for Server External Authentication

We also create an “fmsadmin” Account, which we will explain later when we discuss remote administration of FileMaker Server 8. The existing internal Accounts for andy and geoff were left in place but disabled so that they cannot be used. The internal existing web Account was also left in place, but it remains active for users that require it. 7

• An important point about the FileMaker Pro 8 GET Function (GET(AccountName)) if you use it in your solution:

If a user logs onto a fi le 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 fi le 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.andy belongs: data_entry.andy

7 It is perfectly possible to have a Web based Account be externally authenticated. Extensive discussion of that is beyond the scope of this Technical Brief.


• FileMaker Server 8 or FileMaker Server 8 Advanced (software)


FileMaker Server 8 needs to be changed from its default confi guration to allow for Server External Authentication. The SAT tool is the instrument to do this. This tool confi gures the FileMaker Server 8 software itself here, not the computer where FileMaker Server 8 is installed. The computer where FileMaker Server 8 is installed will be discussed next.

The SAT tool can be used remotely, but not right out of the box. After installation, FileMaker Server 8 allows only local administration. To change that, toggle the option at the bottom of the “Administration” tab (Figure 11).

Figure 11 - Allowing remote administration in FileMaker Server 8

If you allow remote administration we strongly recommend that you change the setting from its default of “require no password.” You can hard-code a password here, but since this Tech Brief is about Server External Authentication we chose the third option: membership in the “fmsadmin” Group. It is a Group you need to create on either the FileMaker Server computer (for scenario 1) or on the domain controller (for scenario 2) and all of the Group’s members will be able to perform administration tasks in FileMaker Server.


Sidenote: In case you wonder how to get to this nice tabbed interface in the FileMaker Server 8 SAT tool on Windows: in the management console, right-click on the FileMaker Server entry after you logged into it, choose properties from the context menu (Figure 12).

Figure 12 - How to get to the tabbed confi guration screen of FileMaker Server 8


This is just for administration of course, not for letting users into the solution. For client authentication we need to be on the “Security” tab (Figure 13).

Figure 13 - The Security properties where you confi gure FileMaker Server 8 to use External Accounts

As you can see from the options in Figure 13, the choice is not between using FileMaker Accounts or External not between using FileMaker Accounts or External notAccounts. Even with Server External Authentication on, FileMaker Pro 8 Accounts can still be used to access the solution. Every FileMaker Pro 8 fi le must have at least one internally authenticated [Full Access] Account. We strongly recommend that Administrators and developers not authenticate such [Full Access] Accounts externally. It is because both types of Accounts can be used at the same time that we disabled the old internal Accounts in our example fi le (Figure 10). But notice that in Figure 10 the [Full Access] Admin Account remains active.

We will give more information about the other confi guration options shown in Figure 13 (database visibility & secure connections) in the “Other FileMaker Server settings and their relationship to External Authentication” section towards the end of this Tech Brief. For now it is enough to know that they are not necessary to make Server External Authentication work.


• FileMaker Server 8 computer


The computer FileMaker Server 8 runs on plays a different role depending on the scenario.

In scenario 1 where the computer itself is in charge of authenticating users, we need to create those user Accounts and Groups on that computer.

If there is a domain controller involved, then we do not create Accounts on the FileMaker Server computer, but we do have to make sure that the FileMaker Server computer is part of the domain where those Accounts exist so that it knows who to contact to authenticate and Account.

• Scenario 1: FileMaker Server 8 computer performs authentication:

In this scenario we need to create Accounts and Groups on the FileMaker Server 8 Computer.

WindowsBefore we start, 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). Sometimes you can fi nd the “My Computer” icon on the desktop but always in the Start menu. The long way to the management console is through Start -> All Programs -> Administrative Tools -> Computer Management. If you do not see local Accounts and Groups then the computer is confi gured as a domain controller. Domain Controllers do not have local Accounts and cannot be used for Scenario 1.


We do not recommend using a domain controller computer as a FileMaker Server computer. Domain controllers can get very busy, and that may hurt the FileMaker Server performance. This also specifi cally includes replication of Open Directory on servers running Mac OS X Server and FileMaker Server 8 or the use of Active Directory ‘slaves’ on similar Windows OS computers running FileMaker Server 8.

Figure 14 - The shortest way to creating Accounts and Groups on the local FileMaker Server 8 computer

But back to the local FileMaker Server 8 computer. What we need to do here is create an Account for both geoffand andy (the two original users of Business Tracker) and two Groups: managers and data_entry. Let us start with andy (the two original users of Business Tracker) and two Groups: managers and data_entry. Let us start with andythe Accounts. You can follow the fl ow 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 “geoff” and repeat the process for user “geoff andy”.


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 we can add user “geoff” to this Group. On the dialog that comes up (Figure 16) note the location of from where we will pick the name. This should be name of the local computer “company-fmsa” in our case. If it is not the same as the computer’s name then that computer is confi gured 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. We explain how 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 a 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.

Figure 17 - The name was found: it appears underlined.


Repeat this process to create another Group named “data_entry” and add user “andy” to it. (Figure 18).

Figure 18 - Finished. 2 local Groups are created and 2 local Accounts

Note that on Windows 2000 Server this whole process looks almost completely identical.


Mac OSWe need to open the System Preferences on the FileMaker Server computer to create Accounts (see Figure 19). Click on “Accounts” in the System Group.

Figure 19 – Accessing the Accounts from the System Preferences.


The process itself is very straightforward: provide a username, a short name and a password. Done.

Figure 20 - Creating the local “geoff” Account

With these Accounts you can now log into the FileMaker Server computer which is not really our purpose. What we want is to give users access to the FileMaker Pro solution. You may want to limit the system privileges for those Accounts in case they can have physical access to the FileMaker Server computer. How and why is beyond the scope of this document.

Creating Groups is a little more involved. Please note the importance of using the short name. FileMaker Server 8 on Mac OS X Server looks for the Group short name returned from the Directory Services. That is the offi cial name that identifi es the Group to the system, not the long (user-friendly) name. Thus, in the defi nition of Accounts in FileMaker Pro 8 for External Server authentication, the defi ned Group name must match the Directory Service Group short name. {See Figure 5 for an illustration of where the Group is defi ned in FileMaker Pro.} In many instances the long and short names will be identical; however, in some instances they will not be. 8 Developers and Administrators should check for the short name.

8 Spaces and high ASCII characters might be removed, for example. So we recommend avoiding them altogether.


The standard utility to create Group names is the “NetInfo Manager” you fi nd in the /Applications/Utilities/ folder. As you can see from Figure 21 you will fi nd the two users andy and geoff that we have just created listed in the user’s section. In the Group’s section you will fi nd the Groups that already exist on the computer.

Figure 21 - The local Accounts in the NetInfo utility.


While you can create a Group from scratch, probably the easiest way of doing this is by duplicating an existing Group. This avoids having to manually add all the properties that a Group needs. Take the “guest” Group for instance and click the duplicate button (Figure 22).

Figure 22 - Duplicate an existing Group to make it easy.

In the bottom pane you need to change the name of the Group and the unique identifi er (GID). You can pick any 3-digit number for the GID but it must be unique.


Figure 23 - Setting the properties for the new Group.

Next select the “users” property in the bottom pane and from the Directory menu choose “New Value” (Figure 24). Type the username you want to add. In our example (Figure 25) we are creating the “data_entry” Group and add “andy” to it. Do not forget to save the changes (from the “Domain” menu).


Figure 24 - Adding a user to the Group.

Figure 25 - Adding “andy” to the data_entry Group.


A great alternative to using NetInfo is a Donation-ware utility called “SharePoints.”9 Creating Groups with SharePoints reduces the risk of making errors. It will assign an unique GID automatically and adding users is a simple point and click process. It also hides the system Users & Groups (those that were created by the Operating System) since you are only interested in seeing the Users and Groups that you have created. We still need to create the “managers” Group and add geoff to it; let us show how it is done with SharePoints. In the “Groups” geoff to it; let us show how it is done with SharePoints. In the “Groups” geofftab, type in “managers” for Group name and click the “Get Next GID” button. Finally click the “Add new Group” button (Figure 26).

Figure 26 - Adding the “managers” Group through SharePoints.

9 Created by HornWare (http://www.hornware.com/sharepoints/)


Select your new Group and from the users list on the right, select geoff and click the big “+” button (Figure 27). geoff and click the big “+” button (Figure 27). geoffThat is it. Done.

Figure 27 - Adding “geoff” to the new Group.

As far as Scenario 1 is concerned—FileMaker Server authenticates users based on the Accounts and Groups on its own computer—this is about the entire confi guration you need to do.

The only remaining thing to do now is to make sure that the FileMaker Server computer does not look elsewhere for Accounts, but that it looks only locally.

WindowsOn Windows a 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 8 is part of the domain it will look on the domain for a matching Account, and examine the local Accounts if it did not fi nd a match for the account on the domain. While it is entirely possible to use FileMaker Server local authentication when the FileMaker Server 8 computer is part of the domain, it does add a level of complexity especially for troubleshooting. Additionally there may be a security risk if a user receives 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” (Figure 28). The computer will either be listed as part of a domain or part of a workgroup.

Figure 28 - Checking if the FileMaker Server 8 computer is part of a domain: it is NOT.


Figure 29 - Checking if the FileMaker Server 8 computer is part of a domain: it IS.

If the computer is part of a domain, then we need to decide to leave that or to remove it from the domain and avoid any potential authentication confl icts 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.


Figure 30 - After clicking the “Change” button: here you can join or leave a domain.

The “Change ...” button will let you join a domain (for Scenario 2) or leave a domain (for Scenario 1). For our Scenario 1 (only local authentication) we need to change Figure 30 to “Member of Workgroup”. The workgroup name is not very important; it serves mainly to group computers together in the Network Neighborhood.

Mac OSTo cause 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”.


Figure 31 - Making sure the FileMaker Server computer only uses local Accounts.

That is all there is to it. The confi gurations 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.


• Scenario 2. Domain Controller Performs the Authentication

Making the FileMaker Server computer part of the domainMaking the FileMaker Server computer part of the domain

If we want the domain controller to handle all the authentication requests, then we do not create Accounts and Groups on the local FileMaker Server computer. But we 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. More specifi cally:


WindowsTypically joining a domain is part of the installation process for Windows 2000 Server and Windows Server 2003. So unless you did the initial install, the fi rst thing would be to check if the computer is already a member of the domain. We explained how to do that in the previous section. If the FileMaker Server computer is currently not part of the domain you will need to use the “Change” button on Figure 28 to join the domain. This will require a Domain Admin username and password to complete.

Mac OSFor the FileMaker Server computer to talk to the Apple Open Directory, we need to make a few confi guration changes. So back to the “Directory Access” utility. On the fi rst tab we need to confi gure the LDAPv3 setting. 10

Figure 32 - The LDAPv3 service connects to the Open Directory

The “Confi gure” button will take you to this screen where you need to create the correct connection to your Open Directory. The confi guration name can be anything you like but the Server Name or IP address must be of the Open Directory master.

10 This should not be confused with registering a FileMaker Server computer with an LDAP directory. See the section on LDAP later in this Tech Brief. This is an important point. It has been the cause of considerable confusion among developers and Administrators.


Figure 33 – The LDAPv3 service confi gured to connect to the Open Directory master.

With the correct settings applied here, we go to the second tab of the “Directory Access” utility: Authentication. As you can see from Figure 34 we have selected the “custom path” from the Search dropdown. The fi rst choice (“Automatic”) would take its feed from the DHCP settings of the computer. But since we are confi guring 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 us set the sequence of authorities the computer will contact in order to authenticate a user.


Figure 34 - Setting the authentication path to the Open Directory master.

Click on the “Add” button and select the /LDAPv3/ entry. The end result will look something like Figure 35.


Note that the grayed-out “/NetInfo/root/” entry remains the start node of the authentication process. There is no way around that; Mac OS X will evaluate its local Accounts fi rst 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”.

• The Domain Controller


This component only plays a role in the scenario where the domain controller handles authentication requests and not the FileMaker Server 8 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 your client’s IT department.

If there is a domain controller then you may need to confi gure 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.

WindowsCreating Accounts and Groups on the domain requires Domain Admin privileges. Depending on the client that may mean getting the IT department involved.

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 fi nd it on the install CD11 or you can download it directly from the Microsoft website. 12

Note though that you can only run this from Windows XP Professional workstations or other Windows Server 2003 computers.

With the admin pack remotely or from the local computer the interface to create Accounts and Groups is exactly the same.

Let us start with creating Accounts for geoff and andy. Navigate from the Start button to the “Administrative Tools”. That is where you will fi nd the tools to confi gure the Active Directory (Figure 36). Select “Active Directory Users and Computers”.

11 “Adminpak.msi” in the \I386 folder

12 http://support.microsoft.com/?kbid=304718


Figure 36 - 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 37 are for the logon name that the user will use. On the next screen provide a password and set the Account properties as needed (except “Account is disabled” which will render the Account useless).

Sidenote: 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.


Figure37 - Ccreating two domain user Accounts

Repeat the process for “andy” and you will end up with two Accounts as in Figure 38. The other Accounts and Groups you see are those created by Windows.

Figure 38 - Finished creating two domain user Accounts


What we need next is two Groups: “managers” and “data_entry” and add geoff and geoff and geoff andy to their Group. Still in the andy to their Group. Still in the andysame “Active Directory Users and Computers” console, choose “New” and “Group” from the Action menu. The dialog from Figure 39 will show 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.

Figure 39 - Creating a new Domain Group. Figure 40 - domain Group name must match the FileMaker Pro Account name

What about those “Group scope” and “Group type” options? The Group type is easy: we always want Security Groups because they are the only type that is involved in authentication. “Distribution” is mainly for creating email lists. The scope is a little more complex. But “Global” is the default and in almost all circumstances it will be the good choice. 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 site13

or utilizing a good book about Windows Active Directory. 14

Repeat the process to create new Groups named “data_entry” and “fmsadmin”.

13 http://www.microsoft.com/windows2000/server/evaluation/features/dirlist.asphttp://www.microsoft.com/windowsserver2003/technologies/directory/activedirectory/default.mspx

14 Willis, Will and Watts, David. Windows® Server 2003 Active Directory Infrastructure {Indianapolis, IN Que Publishing} 2004.


Figure 41 - Finished creating new domain Groups.

With the Groups created as in Figure 41 we 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 andy) and have it andychecked. Or 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 who you want to add in the geoff to the managers Group. Give some thought to who you want to add in the geoff“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 fi les.

This completes the description of creating Accounts and Groups on the domain controller.

Mac OSTo create Accounts and Groups we need to be on the Open Directory master or an Mac OS X computer that has the server utilities installed (from the OS X Server CD). The utility we need is called “Workgroup Manager” and is usually in the Dock already. If not you will fi nd it in the /Applications/Utilities/Server/ folder.


Let us fi rst create the two Accounts for geoff and geoff and geoff andy. Make sure the Users tab is active and click on “New User” (Figure 42). Type in the user name and a password and click “Save”.

Figure 42 - Creating a new user in the Workgroup Manager.

Figure 43 - Both user Accounts in Open Directory.


Switch to the Groups tab and select “New Group” (Figure 44).

Figure 44 - 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 45). Do this for the 3 Groups we need: data_entry, managers and fmsadmin (see Figure 46).

Figure 45 - Adding users to a Group.


Figure 46 - Finished Groups & Users in the Open Directory.

This completes the Open Directory part. There are many more settings that apply to Users and Groups here that we did not discuss but that would be part of the network security and privileges setup specifi c to your deployment and beyond the scope of just getting users authenticated with these external Accounts.


• FileMaker Pro 8 client computers


The fi nal part of the puzzle is the workstation where FileMaker Pro 8 will run and connect to the hosted solution.

As was the case with the FileMaker Server 8 computer, a workstation can either be part of a domain or not. But it is less important than the confi guration of the FileMaker Server 8 computer.

It is only truly important if you want to achieve SSO (Single Sign On). 15 In the introduction we mentioned that one of the benefi ts 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 a username or password. This works only on Windows and only in the following scenario:

• 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 his domain Account belongs to is properly set up in the FileMaker Pro 8 solution as an externally authenticated Account.

• the FileMaker Server 8 computer is part of the same domain as the user’s workstation. With this in place, the user will not get prompted for a username or password when the user opens 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 8, the user gets access to the fi les.

To make a Windows workstation part of a domain, follow the instructions given earlier in this tech 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.16 Strictly speaking this is not SSO since FileMaker does not use an existing connection but extracts the username/password combo from the Keychain and sends that to FileMaker Server to have it authenticated. The end result is close to SSO. There is no need to make the Mac OS X workstation part of a domain; the Keychain stores 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 username and password (Figure 47). And if the Account name or password changes, the Keychain needs to be updated.

15 Also variously called Single Source Log–On, Single Access Log–On, etc.

16 Enabling Secure Storage With Keychain Services White Paper. {Cupertino, CA. Apple Computer} 2004


Figure 47 - Storing the username and password in the keychain.

Except for SSO on Windows, how the workstation is confi gured does not matter at all. If you send a username and password to FileMaker Server, it is both the confi guration 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 .17

Other FileMaker Server settingsand their relationship to External Authentication

• Database Visibility

On the security tab of the FileMaker server confi guration (Figure 13) there is a setting to “Filter the Display of Files”. With this toggled on a user will only see the fi les for which he has an Account. For that to happen, FileMaker Server 8 needs to know who that user is before it can compile the list of fi les for that user. So unless the deployment is one where SSO works or where credentials are stored in the keychain, the user will be prompted for a username 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.

Sidenote: unless all the conditions for SSO (Windows) are met or the username/password is stored in the keychain (Macintosh) the user will be challenged twice: once to see the list of fi les, a second time to open the selected fi le.

17 As we have discussed FileMaker Server on Mac OS X Server looks to its local Account fi rst before looking on the domain if there is one. FileMaker Server on Windows does the opposite: It looks on the domain before looking at the local Accounts. See the discussion about UPN and UNC formats in the Special Scenarios section of this Tech Brief.


• Encryption

The last setting on the security tab (Figure 13) is to enable “Secure connections to FileMaker Server”. Using this setting means that the traffi c between FileMaker Pro clients and FileMaker Server 8 is SSL encrypted. This can include—if properly confi gured—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 8 has no say in it.

• LDAP

LDAP is a protocol, namely the Lightweight Directory Access Protocol. Just like 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. But before we can make the link with FileMaker Server we need to explain briefl y what a Directory Service is.

We all know what a phone directory is; a directory service is very similar: it 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, email 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 48) where you can list the FileMaker Server 8 computer in a Directory Service. This is purely so that users or Administrators can easily fi nd where various servers running FileMaker Server 8 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” tab in the FileMaker Server settings.


Figure 48 - the “Directory Service” tab in FileMaker Server: the only place where you will get close to LDAP.


Special Scenarios

• Using UPN/UNC to ensure authentication

As we have discussed, FileMaker Server on Mac OS X Server always looks to its local Account fi rst before looking on the domain if there is one. FileMaker Server on Windows does the opposite: It looks on the domain before looking at the local Accounts. 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 that FileMaker Server would use by default (the domain Account on Windows or the local Account on OS X Server)? What we need to do then is to use either the UPN or UNC logon syntax explicitly to tell FileMaker Server 8 where to look. That respective syntax for UPN and for UNC looks like this:

geoff@thecompany-fmsa (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 to take care of it.

UNC stands for the Universal Naming Convention format. The UNC syntax of an Account looks like this: theDomain\theUserName

UPN or 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 email address:

theUserName@theDomain

You can fi nd both formats in the middle window of Figure 37.

Figure 49 - UPN and UNC logons to the local FileMaker Server computer


Note that in this instance, the FileMaker Pro 8 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.

Troubleshooting: what if it does not work as you expect it should?

• Does the Account work?

Probably the fi rst 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. But 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 username or password or 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 of what Groups the user is a member.

• Group membership

The obvious place to look at Group memberships is where the local or domain Group are created. But 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 end result is that a user may be a member of more Groups than you think. Luckily there are some tools that can help us out with this.

WindowsMicrosoft Windows 2000 and Microsoft Windows XP have a command line utility that is part of the Resource Kit 18 that can show you a wealth of 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”.whoami /Groups”.whoami

Figure 51 - Using “whoami” to view all the Groups a user belongs to.

Figure 51 is a real–life example of Wim logged in to his Windows 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 other hand under Wim’s Account properties on the Domain Controller we see only 12 Groups listed. (Figure 52).

18 You can fi nd the installer on the XP install CD, or you can download the tool from the Microsoft website.


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 that is installed by default and does not require that you are currently logged in to the workstation with the Account you want to test, is the universal “Net” command. 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. So 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

and you will get an overview of the domain Groups to which that user belongs. Figure 53 shows fmuser1 on the connectingdata domain.

Figure 53 - Checking domain Group membership with the NET command.

If you omit the /DOMAIN switch from the command the user will be checked against the local computer.

Mac OSMac OS X has a similar command line tool called “id”. This one too requires that you be logged into the computer with the Account you want to test. Figure 54 shows geoff ’s local and domain Group memberships.


Figure 54 - Running the ID command line tool on OS X.

• Double-check Authentication order

Once you are sure what Groups the user belongs to, use that list to double-check where those Groups are listed in the authentication order of your FileMaker Pro 8 solution. You might fi nd that the user is part of a Group that comes earlier in the Authentication order than does the Group where you thought he would authenticate.

A second check is to be sure that the Group name in the FileMaker Pro 8 fi le exactly matches the Domain Group name or the local Group name.

• Double check the FileMaker Server 8 version.

Administrators should assure that they have updated to FileMaker Server 8.0v3.

• Check the computer’s clock.

Both Macintosh and Windows can use different internal authentication processes. Some of these are very time–sensitive. If the client’s clock is not within a certain margin of the Domain Controller’s clock then the authentication will fail, even if the Account and password are correct.

For that reason it is not a bad idea to have all the client computers synch their clock with the domain controller’s, or at least all use the same time server.

• Event logs

While the information captured in the various system logs may be beyond the average user, it may still yield some interesting troubleshooting clues. Without going too deeply into this very technical material, let us show you where to fi nd those logs.


WindowsThe FileMaker SAT tool provides easy access to all the relevant logs. But remember that if you run the SAT tool remotely those “Windows Administrative Tools” including the event logs will be those of your local computer.

Figure 55 - Access to the Windows event logs from the SAT tool.

If you right-click “Event Viewer” through you can then connect to the computer running FileMaker Server or your Domain Controller and view the event logs from that computer.

Figure 56 - Connecting to another computer from the SAT tool to view its event logs.


Mac OSThe easiest way to view all the different log fi les is to open the Console application from the /Applications/Utilities/ folder (Figure 57). This tool will give you access to all the various system logs.

Figure 57 - The OS X console app to view system logs.

On Mac OS X Server you can also access the logs from the Server Management application (Figure 58). The logs are accessible per Server task through a tab at the bottom. If you select the top of the tree in the left pane you have access to the overall system log.


Figure 58 - Viewing logs from the OS X Server management application.

• Clean up the Keychain

On Mac OS X there is the chance that the credentials (username/password) stored in the Keychain are out of date. Launch the Keychain Access utility as shown in Figure 59, usually found in the Applications folder. You may be challenged for credentials as part of this process. Click the Attributes tab to see a list of credentials stored in the Keychain. Clicking on the heading for Kind will group all the FileMaker Pro passwords together. Check them to be sure they are correct for the selected Account.


Figure 59 - Cleaning up the Keychain.

About the AuthorsSTEVEN H. BLACKWELL is a Partner Member of the FileMaker Solutions Alliance and President and CEO of Management Counseling Services [http://www.FMP-Power.com]. A two–time winner of the FileMaker Excellence Award, he specializes in custom FileMaker Pro development, FileMaker Pro security consulting, and FileMaker Server deployment.

WIM DECORTE is a FileMaker Solutions Alliance Associate located in Germany and is the owner of Connecting Data (www.connectingdata.com). Connecting Data specializes in server deployments and integrating FileMaker with other applications.

©2005 FileMaker, Inc. All rights reserved. FileMaker is a trademark of FileMaker, Inc., registered in the U.S. and other countries, and the fi le folder logo is a trademark of FileMaker, Inc. All other trademarks are the property of their respective owners. FileMaker makes no warranties, express or implied, with respect to the performance or reliability of any products presented herein that are manufactured by independent vendors. All understandings, agreements or warranties, if any, take place between the vendors and prospective users. Product specifi cations and availability subject to change without notice. (Docv2)

THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, AND FILEMAKER DISCLAIMS ALL WARRANTIES, EITHER EXPRESS

OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE,

OR THE WARRANTY OF NON-INFRINGEMENT. IN NO EVENT SHALL FILEMAKER OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER

INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS, PUNITIVE OR SPECIAL DAMAGES, EVEN IF

FILEMAKER OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION

OR LIMITATION OF LIABILITY. FILEMAKER MAY MAKE CHANGES TO THIS DOCUMENT AT ANY TIME WITHOUT NOTICE. THIS DOCUMENT MAY

BE OUT OF DATE AND FILEMAKER MAKES NO COMMITMENT TO UPDATE THIS INFORMATION.

server authentication wp - · pdf filethere are several compelling reasons for selecting...

Documents