AD Authentication with nested filemaker groups

[James Gill]

Hello,

I wanted to make a new topic that piggy backed off of this post in another thread (given that the post is over 3 years old I felt it better to make a new post rather then to continue posting to that thread):

jlazore,

It is my experience that it doesn't matter what organizational unit (aka folder) the Filemaker security groups reside in they work properly where ever.

What you may want to do is make a Windows account for a ficticious person that you can use for testing purposes. That way you can retain full access rights for yourself and will be able to log in as this other person for testing.

I created my AD groups and named like something like this:

FM-Administrator

FM-TypicalUser

FM-HumanResources

FM-AreaManager

FM-Guest

Then you have to create externally authenticated accounts named exactly the same within Filemaker Pro. You *must* set the authentication order of the groups because your people *may* be a member of more than one group and FM needs to know which account to use. For instance, if your phoney AD user was a member of both the FM-Administrator and the FM-Guest groups, he would be granted FM-Guest rights if FM-Guest appears higher in the authentication order than than FM-Administrator.

My question is this: Ted clearly states that he has users that will be part of multiple groups in his AD domain. I have recently run into a problem where I have created several externally authenticated groups and have users that are part of multiple groups. Here's my schema:

Database 1

FilemakerDeveloperAccess - [Full Access]

FilemakerFinanceAccess - [Data Entry Access]

FilemakerGeneralAccess - [Data Entry Access]

Database 2

FilemakerDeveloperAccess - [Full Access]

FilemakerFinanceAccess - [Data Entry Access]

FilemakerGeneralAccess - [Custom Permissions (Write Only Access to a certain table)]

Database 3

FilemakerDeveloperAccess - [Full Access]

FilemakerFinanceAccess - [Read Only Access]

FilemakerGeneralAccess - [Read Only Access]

I have ensured that across all of my databases the accounts are set up in the same authentication order across. While I was testing permissions, I was running across a problem where my user was part of the FilemakerDeveloperAccess and FilemakerGeneralAccess groups, but I was only authenticating as the FilemakerGeneralAccess group. After digging around and some general hair pulling, I looked at the order that AD was presenting the memberships to the Filemaker Server (via terminal and `id <username>) and discovered that the FilemakerGeneralAccess group was displayed before the FilemakerDeveloperAccess group.

My question is, in all of the docs I've run across for Externally authenticating users against AD, I've only seen it mentioned that the authentication order in FILEMAKER DATABASE ONLY determines the level of access the user is presented with. I read that as, users with Filemaker Developer Access are authenticated 1st, Finance access 2nd, and General access 3rd.

It seems as if this isn't entirely accurate, as for users that are part of multiple groups, not only does the server authentication order matter, but also the listing of the user group memberships as they are presented from AD. To my knowledge, there is no way to control the order that the group permissions are presented in AD.

Is this accurate? If so, this severely limits the way that I can structure complex groups and permissions across my server (or at least makes it extremely complex to manage.)

[Vaughan]

Do NOT, repeat, do NOT externally authenticate full access accounts. While it is convenient, it opens a huge security hole: I just have to get your file, host it on server and re-create your EA setup to gain full access, after which I can open the file and change all the passwords.

The AD/OD returns ALL the groups that the person is in. The working out of which privilege set to use happens inside each database file, based on the authentication order. So an "admin" might have delete access in one file but read-only in another file. So in each file, make sure the EA account with the most privileges is highest in the order. That way people open the file with the MOST privileges that have.

Let me give you an example I actually encountered. Two solutions share the same Contacts file: a solution called Research and another called Recoupment. Users of the Research solution need write access to the Contacts table but users of the Recoupment solution need read only to Contacts.

This part is easy to set up, the tricky bit is when people use BOTH solutions.

One person in Research (Alex) needs access to both the Recoupment system as well as the Research system. This too is relatively easy, except that every once in a while they have the problem where the Contacts file is read only to them (they should have write access). Hoewever it fixes itself if they close FMP and open everything again. It turns out that they the problem is caused by opening the Recoupment system FIRST which opens Contacts with RO access. They then open Recoupment, but Contacts is already open.

The correct operation of a database should not depend on the order in which the files are opened. The solution is to make sure that people have they MAXIMUM privileges that are entitled to. Do this using the authentication order: in the Contacts file, put the account with the highest privileges (in this case, Research) above the account for Recoupment. In the Recoupment file it would be the other way around: Recoupment would be above Research.

Each time Alex opens Contacts it recognises they have write access (from Research) and allows them that, even though they might be using the Recoupment database. Then when they open Research system the privileges are correct.

Please don't try to concoct a system to determine whether the file is already open and if so force a re-login using the new EA account etc... it is not necessary.

[Steven H. Blackwell]

When the user is authenticated by Active Directory that information is returned to FIleMaker Server along with a list of the Groups to which the user belongs. The first matching Group in the file is the one that determines the Privileges for that user.

I believe this is discussed in the External Authentication Tech Brief.

Steven

[Wim Decorte]

This is a strange one. I've never ever seen authentication order fail. It is NOT the order in which you see groups listed when you ask the OS that determines the authentication order, it is strictly the other as set up in the FM file.

Troubleshooting these issues remotely is close to impossible but I'm going to guess that something is not exactly configured in the AD groups than what you think it is...