External Server Authentication and [Full Access] Privileges… Life (or FileMaker) May Not Be What At First It Seems

[Steven H. Blackwell]

External Server Authentication and [Full Access] Privileges…

Life (or FileMaker) May Not Be What At First It Seems

-By-

Steven H. Blackwell

Someone recently advised me about a discussion on a FileMaker List that focused on the supposed ability of a user with an Account authenticated by External Server Authentication and attached to the [Full Access] Privilege Set to make changes in a hosted file’s security schema. (Technically this is a Group, not an Account, but we’ll call it an Account here for sake of simplicity.)

If someone has actually done this, we need to learn the circumstances under which it happened including the versions both of FileMaker Pro and of FileMaker Server as well as the OS of the machines running FileMaker Server and FileMaker Pro.  Such a capability would represent a significant security vulnerability.

I set out to investigate this report and whether such an action could actually have occurred, and whether I could duplicate the reported behavior.  Bottom line: the answer is No. But the scenarios I discovered were interesting and somewhat unexpected.

I want to thank long time FileMaker developer and technical expert Darren L. Terry of Pacific Data Management in San Jose, California, for his assistance in running this issue to ground.  Darren, who was once described on a FileMaker List as being “…worth [his] weight in rum…” hit on the first major important clue required to answer this question.

The report I got was that a user with a [Full Access] Account that was externally authenticated by FileMaker Server had been able to log onto a hosted file and change items in the security settings. I doubted that claim.

Here is what should happen, and is actually supposed to happen, in these circumstances.  If a user with an Account with [Full Access] privileges that was externally authenticated opens a hosted file, that user will have access to the Manage Security… functionality.  The user of this Account can view the names of other Accounts and of External Groups.  The user of this Account can also view the items in any of the Privilege Sets in the file.

When the user of the Account makes changes in any of the other Accounts or Groups or in any of the Privilege Sets, they may appear to be changed.  However, these changes are not committed until the user exits the Manage Security… area.

Upon exiting, the user will be presented with a credentials challenge similar to this one:

Now, if the user enters the [Full Access] Account credentials that were externally authenticated, an error message similar to this one should appear:

In other words, an externally authenticated Account with [Full Access] privileges should not be able to change and commit Security settings. To do otherwise would be a violation of several core Principles of Security including Segregation of Duties/Separation of Duties, Rule of Least Privileges, etc.

Here is an important caveat and warning: For a variety of reasons, externally authenticated Accounts ought not be assigned to the [Full Access] Privilege Set.  If a physical copy of a file were to be obtained, the External Groups could possibly be spoofed, granting unrestricted access to the file.

Nevertheless, if someone ignores that advice and does assign [Full Access] privileges to an external Account, attempts to make changes in the security schema should produce the results described above, namely the invalid password challenge.

Yet, the report was that a user had been able to change the security settings.  I considered one way this might have appeared to have happened.

If a user had entered the Manage Security… area and made some changes but then cancelled them before attempting to exit the Security area and commit them, such a user might understandably believe he or she had been able to make the changes.  So if the user did not want the apparent changes to take effect, the user would cancel out of the event.  This was a possible explanation.

Darren Terry then provided an important clue:  suppose there were duplicate Accounts, one internal and one external, with identical Account names and passwords.  What would happen then? FileMaker Pro blocks creation of identically named Accounts in the same file; Account names must be unique. (Interestingly, passwords do not have to be unique; however developers should work on an assumption that they are required to be so.) But in this instance, since one Account was internal and the other external, there is no way to flag identical items.

So, in testing this scenario on a hosted file with identical [Full Access] Accounts, one internal and the other external, I was able to log onto the file with the external Account.  I could identify that this was the external Account by placing it higher in the Authentication Order List than the identical internal Account.  I made changes in the Privilege Sets and then sought to exit the file.  I was presented with the Confirm Full Access Login credentials challenge (as shown above), entered the credentials, and exited the Security area successfully.

Thus it did appear that I had used the externally authenticated [Full Access] Account to change the security settings in the file.  But this appearance is deceptive; that is not what actually happened.

When FileMaker Pro sought to evaluate the credentials I supplied, it first examined the externally authenticated one that was higher in the Authentication Order List.  It rejected that Account, and moved to the next one in the list.  That was the internal [Full Access] Account; that Account was accepted.  I confirmed this behavior by disabling the internal Account.  That produced the error shown at the start of this BLOG post.  Re-enabling the internal Account produced a successful exit from the Manage Security… area of the file.

Positioning in the Authentication Order List is not a controlling factor for this scenario. Placing the internal Account higher in the list, logging in to the file, and then disabling that Account produced the same unsuccessful result.  That happened despite the presence of the identical external Account.

So, in summary, here are the key points to remember:

• Don’t use External Server Authentication for a [Full Access] Account (technically a Group) in a file.

• If you choose to ignore this advice, you cannot commit changes to the Security schema with that externally authenticated [Full Access] Account.  Such changes require an internally authenticated [Full Access] Account.

• Darren Terry is still worth his weight in rum.

View the full article