Jump to content
  • entries
    44
  • comments
    59
  • views
    88,280

The Power and Advantages Of External Server Authentication With FileMaker Server

Steven H. Blackwell

3,744 views

The Power and Advantages Of External Server Authentication With FileMaker Server

By

Steven H. Blackwell

May 9th 2011

Since the advent of FileMaker® Server 7 in 2004, FileMaker developers have been able to employ External Server Authentication for controlling Identity and Access Management to FileMaker files when hosted by FileMaker Server. Yet, either from lack of knowledge or from incorrect assumptions about the process, many do not employ this powerful option.

First, a little background information might be useful to further understanding of this process. Most developers are aware that a FileMaker file can contain multiple Accounts and that each individual Account is attached to a given Privilege Set. The Account, together with its password, serves to determine who is accessing the file and that the person accessing is who he or she claims to be. Who are you, and are you actually whom you claim to be? Once authenticated, the user is admitted to the file with the privileges defined in the Privilege Set associated with the Account.

When a system contains one or two Accounts and maybe only a couple of files, this construct of Accounts and Privileges is reasonably easy to manage. But for many users across many files, management is far more complex. This has lead some developers to construct ersatz log-on and security systems of varying degrees of complexity in an attempt to manage the system. I have seen literally scores of these over the past seven years. Almost completely without exception, they have proved highly vulnerable, easy to defeat, and susceptible to manipulation. They detract from, and damage, security in the files where they are used.

External Server Authentication allows us to remove the Accounts and passwords from the FileMaker file and place those Accounts and passwords either on a Domain Controller or directly on the FileMaker Server machine itself. Accounts on the server are placed into Groups, each of which can contain many Accounts. In the FileMaker files themselves, instead of individual Accounts, developers can create identically named Groups and attach each to an individual Privilege Set. These Groups must exactly match those created on the server.

When a user seeks access to a file hosted by FileMaker Server where External Server Authentication is employed, FileMaker Server queries the server (either itself or the Domain Controller) to determine the authenticity of the Account. If the Account is deemed valid, then the user is connected to the FileMaker file with the correct set of privileges. FileMaker Server matches the Group name in the file to the Group name on the server that houses the Account to determine what that set of Privileges should be. This process works to authenticate users connecting by FileMaker Pro clients as well as by Instant Web Publishing and by Custom Web Publishing.

This process works with Active Directory on Windows Server, with Open Directory on Macintosh Server, and with local security groups on either platform, although in slightly different ways. However, contrary to popular belief, it does not work with generic LDAP server connections. Part of the FileMaker Server Administration Console has a configuration panel for LDAP. This has nothing at all to do with External Server Authentication. Additionally, and again contrary to popular belief, a Domain Controller is not required to make External Server Authentication work. The external Groups can be on the FileMaker Server itself.

So why use External Server Authentication? What are its capabilities? What are its benefits? What are its advantages? There are a number of these.

1. Use of External Server Authentication dramatically simplifies Account management, especially for many users across multiple files. Once the system is set up correctly, the Account name and password need be entered only one time and in only one place. It does not have to be entered individually in each file. For a system with 25 users and 15 files, that would be 375 separate entries in individual files, versus 25 entries in one place with External Server Authentication. The likelihood for error is dramatically reduced.

2. When using External Server Authentication and updating an existing FileMaker solution, the developer does not have to worry about reconciliation of Accounts and passwords added or deleted since the prior update. This is very helpful, especially when using The Separation Model™ construct. Accounts are not in the files, including UI and logic files. So there is nothing there that changes when a older version of a file is swapped out for a newer one.

3. External Server Authentication takes advantage of the security system that an IT department has already established in either a small organization or a large one. FileMaker developers can thereby leverage the usefulness and power of these assets. FileMaker developers and DBA’s are freed of the burden of managing Identity and Access Management by utilizing assets already in place.

4. In some circumstances, developers can take advantage of the power, usefulness, and convenience of Single SignOn, (SSO) also called Single Source LogOn. In such a system, once a user is authenticated by the Domain Controller for access to network assets such as file servers, printers, etc., that same authentication can be passed seamlessly to FileMaker Server. The user is then not required to enter additional credentials to access the FileMaker files. Users need to remember only one set of credentials; they are therefore thought not to be as likely to write their credentials down somewhere and leave them where they can be discovered. SSO works from Windows OS workstations to FileMaker Server running on a Windows OS Server. It does not work in any other configuration of Operating Systems; however, it can be emulated on Macintosh OS workstations by use of the KeyChain. Inappropriate KeyChain use can itself be a problem; such misuse can be managed. That is a topic perhaps for a future Blog posting here.

5. External Server Authentication, when used with a Domain Controller, can extend the scope of tools for Credentials Lifecycle Management. Length and complexity of passwords are better controlled. The same is true for blocking the repetitive use of the same password. Additionally Domain Controllers can manage the permissible days and times and locations of log-ons. Additionally, Domain Controllers can prevent simultaneous log-ons with the same credentials. External Server Authentication thus expands the range of Identity and Access Management controls beyond those found in the native FileMaker file itself.

There are a number of different configuration scenarios for External Server Authentication depending on the specific mix of Operating Systems in place among FileMaker Server machines, user workstations, and Domain Controllers. This topic is covered in vast detail in a White Paper I co-authored with FileMaker Server world class expert Wim Decorte. That paper, Server External Authentication, was last updated for FileMaker® Server 9 in 2008. However it contains information still pertinent and useful for FileMaker® Server 11.

To recap, External Server Authentication offers FileMaker developers and DBA’s as well as IT managers flexibility, ease of Account management, and utilization of a range of IT created security assets. It should be a core part of every FileMaker developer’s arsenal.



9 Comments


Recommended Comments

Very welcome. Be sure to take a look at the FMI Tech Brief on External Server Authentication if you're headed in this direction.

Steven

Share this comment


Link to comment

Thanks for another great post on External Authentication. I've been reading a number of your posts in the forum regarding this, as well as the 2008 white paper. I'm sold on the concept and want to begin moving several of my solutions to this model.

The problem is in the details; for me. I'm having a lot of difficulty determining the steps I need to take to actually establish the connection. I have a number of installed solutions with the same basic scenario:

- OS X Workstation 10.6.x running FileMaker Server 10 or 11 (Advanced in same cases). Users are mixed Mac and Windows.

- Installed at a client site where IT has already established Active Directory for many Windows workstations; and all users already use an Active Directory login (both Windows and Mac users).

- IT on site generally does not touch the FileMaker Server (they are usually more Windows focused and prefer to let me maintain and manage the FileMaker Server).

So I'd like all my FileMaker users to be able to log into their databases using their Active Directory login/password. The changes I need to make to my databases are clear to me. The connection to AD is what confuses me.

Do I need to "Bind" the OS X Workstation running FM Server to Active Directory? IT at these sites generally does not touch the FileMaker server. Is it possible to simply have FileMaker Server query the AD controller without the box itself actually being bound to the domain? If I do need to "bind" it; how is this done with OS X 10.6?

Do you know of any walk-throughs, white papers, or tutorials specific to the type of scenario I have described? For the last few months I feel as if I have 95% of the information I need to make the transition; but I can't quite determine what is necessary to actually connect my OS X based FileMaker servers to Active Directory for authentication.

Thanks in advance for any advice. I keep digging for information, and reading everything I come across, but I feel like there is some key piece of the puzzle I am missing.

Share this comment


Link to comment

The FileMaker Server machine must be a member of the domain. You would be better advised in this instance to be running a server with Windows Server and binding it to the domain. But if you want to use OS X Server, you can do that. It's just more trick, as you've discovered, to join the server to the domain.

I believe that the Tech Brief on External Authentication covers this.

Steven

Share this comment


Link to comment

Do I need to "Bind" the OS X Workstation running FM Server to Active Directory? IT at these sites generally does not touch the FileMaker server. Is it possible to simply have FileMaker Server query the AD controller without the box itself actually being bound to the domain? If I do need to "bind" it; how is this done with OS X 10.6?

Yes you do. FMS will look in all the nodes set up in the Directory Utility for authentication.

Sounds like you already have the know-how in house if the IT people bind the workstations to the AD. Otherwise a google on "10.6 bind active directory" will get you some tutorials.

  • Like 1

Share this comment


Link to comment

Yes you do. FMS will look in all the nodes set up in the Directory Utility for authentication.Sounds like you already have the know-how in house if the IT people bind the workstations to the AD. Otherwise a google on "10.6 bind active directory" will get you some tutorials.

Thanks Wim, this is exactly the information I was searching for! I'm assuming I only need to bind the workstation running FMS -- since it's doing the authentication -- and not all the client OS X workstations? Pointing me in the direction of Directory Utility makes things MUCH clearer. I just needed that little push to get clarity.

Share this comment


Link to comment

The FileMaker Server machine must be a member of the domain. You would be better advised in this instance to be running a server with Windows Server and binding it to the domain. But if you want to use OS X Server, you can do that. It's just more trick, as you've discovered, to join the server to the domain.I believe that the Tech Brief on External Authentication covers this.Steven

Thanks Steven. OS X based FileMaker Servers are better suited to my solutions, as I leverage the UNIX underpinnings for a lot of automation. I also use Core Image, AppleScript, and other OS X specific technologies extensively for server automation tasks.

If the current version of the brief is "techbrief_fm8_server_auth.pdf", I have definitely been reading this (over and over). I guess my confusion was primarily caused by some of the changes that have occurred since this was written. It talks about a tool called "Directory Access", which I could not find. Apparently it is now called "Directory Utility" and has been moved from /Applications/Utilities to /System/Library/CoreServices. Once I understood this, things became much clearer.

Also, I was thrown a bit by the diagrams on page 51. It seems to imply in scenario 2 that BOTH the client and server must be a member of the domain. But the following page seems to clear this up by saying the client must only be a member of the domain if you require SSO. If the scenario 2 diagram had a dotted line for the client or some notation that it is optional, that would be clearer.

Thanks again for all the information and your contributions to the community. It is greatly appreciated!

Share this comment


Link to comment

Thanks Steven, 

 

If we go for external authentication, does it mean we rely on the OS administrator or network support people to help put the right group for the user?

 

I am just thinking that may introduce some management difficulties. As example, if one user access right changed, we need to ask the administrator to update or remove the group accordingly. It becomes less agile or flexible when the filemaker solution is not built or maintained by the IT people.

 

Am i right? Any other flexible way on maintaining the AD for external authentication?

 

Great if someone can give me some insights on this area.

Share this comment


Link to comment

For some odd reason, this comment just popped up today, although it appears to have been written about 2.5 weeks ago.

 

External Authentication can use either domain level Accounts and Groups or Local Accounts and Groups on the server.  The person in charge of either one would create the Groups initially and place Accounts into them.  Changes would be made by the same person or by others authorized to do so.

 

IT professionals are very accustomed to creating Accounts and placing them into groups.  FileMaker developers and FileMaker Server Administrators may be less acquainted.  That's why we provide these resources.

 

Steven

Share this comment


Link to comment
×

Important Information

By using this site, you agree to our Terms of Use.