Home / Blog / AD FS – FM Cloud vs. FileMaker Server on Linux vs. FileMaker Server on macOS/Windows

AD FS – FM Cloud vs. FileMaker Server on Linux vs. FileMaker Server on macOS/Windows

We are big fans of using modern authentication to let users into FileMaker solutions. Our consultants have written extensively on using various OAuth identity providers and presented on the topic at various DevCons, including at last year’s Engage 2020.

Active Directory Federation Services (AD FS) is one of these identity providers (IdPs) and a very interesting one. With it, you can use your on-premise Active Directory (AD) without having to make the FileMaker Server machine a member server in that AD domain. That makes AD FS ideal for blended on-prem + cloud strategies. You can host FileMaker Server in the cloud and still use your own in-house AD to authenticate users.

Using AD FS is supported on all FileMaker Servers, whether you:

  1. Use Claris’ FM Cloud hosting
  2. Run your own on-premise server on Linux, macOS, or Windows
  3. Self-host on the cloud
  4. Host in the cloud via a third party

But there are some important differences.

You will see AD FS mentioned in the FileMaker Server settings and the official documentation only for FileMaker Cloud and the Linux version of FileMaker Server:

  • On FileMaker Cloud, you have the ability to add an external IdP in your Customer Console. A process we described in this blog post.
  • In FileMaker Server for Linux, AD FS is a fourth External Authentication option next to the three that are also available on Windows and macOS: Azure AD, Google, and Amazon accounts.
Photo of the FileMaker Customer Cloud Console highlighting the External iDP Accounts section
FileMaker Cloud Customer Console
Photo of the AD FS for FileMaker Server on Linux
AD FS for FileMaker Server on Linux

You can, however, also use AD FS if you deploy FileMaker Server on Windows or on macOS. On those, you need to add AD FS as a custom OAuth identity provider. We describe this process in our series of white papers on adding OAuth IdPs to FileMaker Server.

Using AD FS then works across all versions of FileMaker Server and all operating systems. But not quite in the same way; the main difference is in how you have to set up the AD accounts in your FileMaker file.

For the scenario we discuss below, we will work with the following AD setup: an AD group named Devs whose members need access to the FileMaker solution.

Photo highlighting the AD group needing access to the FileMaker solution
AD group needing access to the FileMaker solution

AD FS in FileMaker Cloud

When you use FileMaker Cloud, you add the user’s individual account (in this case, their AD email address) to a group that you create in your FileMaker Cloud customer console:

Photo highlighting the AD group to which the user's individual account is being added
Adding the user’s individual account to the AD group

And you then add that group (Devs in this example) in the Claris ID section of your FileMaker file:

Photo highlighting 'Claris ID - Soliant Consulting Inc. in the 'Authenticate via
Adding the AD group to the Claris ID section

The AD groups to which the user belongs play no role. You can only choose from the groups you set up in your FileMaker Cloud customer console. You will need to invite each individual member of your AD Devs group through their Claris ID and manually add them to your FileMaker Cloud Devs group.

You also cannot take a file from FileMaker Cloud and host it on your own server without modifying the accounts setup. Claris ID authentication is not available when the file is not hosted on FileMaker Cloud. This is true in general for all files hosted on FileMaker Cloud and not dependent on whether you use AD FS as your identity provider. It is just something to be aware of.

But there are other and more subtle differences between the Linux and the Windows / macOS deployment options.

FileMaker Server on Linux

AD FS on Linux is largely presented as a feature to work around the fact that the Linux version of FileMaker Server does not support binding to an AD domain, nor does it support the use of local accounts and groups in the OS itself. These features are available in the Windows and macOS versions of FileMaker Server.

AD FS on Linux is meant to be a replacement for that classic External Authentication through AD; it is not really meant to be “the fourth OAuth provider.”

After you set up your server’s connection to AD FS in the FileMaker Server admin console, add the AD groups for your users in the same area as you would do for that classic (non-OAuth) authentication, under FileMaker File or External Server:

Photo highlighting 'FileMaker File or External Server' on the 'Authenticate via
Add the AD group under ‘FileMaker File or External Server’

One could have expected AD FS to be the fourth choice in the Amazon / Google / Microsoft Azure AD section of the dropdown, but it is not. It is meant to work like regular AD authentication.

With this setup, every member of the AD Devs group will be allowed into the solution.

FileMaker Server on Windows and macOS

AD FS cannot be configured directly in the FileMaker Server admin console. Like all custom OAuth identity providers, when you want to use AD FS for your Windows or macOS server, you have to refactor the section that is normally reserved for Azure AD authentication. The setup is done by modifying the underlying dbs_config.xml file, as explained in the first white paper in the OAuth series.

And because we are re-using the Azure AD section of the FileMaker Server configuration, the AD groups in your FileMaker file need to be set up in that Microsoft Azure AD section:

Photo highlighting 'Microsoft Azure ID' on the 'Authenticate via' drop to which the Dev AD group will be added
Add the AD group to the Authenticate via ‘Microsoft Azure ID’ section

With this setup, every member of the AD Devs group will be allowed into the solution, same as on Linux.

Practical Implications of the Difference

The main difference between using AD FS on Linux vs. on macOS / Windows is that the Devs group account in the FileMaker file is in another location: on Linux, the group is under FileMaker File or External Server; on Windows / macOS, the group is under Microsoft Azure AD.

And you cannot have two accounts named Devs in your file. You cannot add it in the FileMaker File or External Server section and at the same time, add it to the Microsoft Azure AD section. Trying to do so will result in this error:

Photo of alert dialog that appears when the account name is already in use
FileMaker alert appears when account name is already in use

This limitation basically prevents you from switching the file easily between FileMaker Server on Linux, macOS, and Windows.

Say that you have a dev server on Linux and a production server on Windows or macOS; this behavior would require that you change your FileMaker accounts’ setup when you move files between your servers. Or you would have to create two different AD groups so that you can add two AD group accounts to FileMaker without name collision. Fortunately, FileMaker does support AD group-in-group. This involves very limited overhead on the AD side, but it may not be something that the AD admins are very comfortable with.

In this blog post, we have focused on what is different between using AD FS for different versions of FileMaker Server. As always, feel free to reach out to us for any assistance we can provide on setting up a safe and secure deployment.

Leave a Comment

Your email address will not be published. Required fields are marked *