Confusion about External Authentication and Authorization

[pbenware]

Greetings,

 

Although not an expert by any means, I've been using FMPRo for some time (back to the FMPro 4 days), mostly for building solutions needed by the HigherEd I work for. We've been using solutions hosted from FMPro server with external authentication for years, and generally speaking have no issues.  I've been sneaking around on the FMForums.com site for some time, and have gotten great information and ideas. This is the first time I've ever been so stumped as to need to post for assistance.

 

Today, I'm working on an FMPro 12 database, hosted from an FMPro 12 Server Advanced, and also hosting this via IWP (IWP is not part of this issue at the moment, just trying provide a complete picture of the environment).

Both server and client are using current release versions.

 

The issue I'm having is not one of authentication.  That part works.  The issue I'm having appears to be one of authorization, and I'm not certain if the problem is my understanding of how it's supposed to work, or something else.

 

 

Here's the environment

A single file, multiple table database hosted from FMPro12 Server Advanced, using External Authentication to Active Directory.

The database has 3 externally authenticated security groups with the following FMPro privilege sets, in the following order, top to bottom:

FM_CSG_FULL- FULL ACCESS

FM_CSG_RW- Data Entry Only

FM_ALL_RESTRICTED- A security group with a custom privilege set that allows access to a specific set of layouts for creating new records.

 

(I also have a local FMPro Full Access account for file maintenance)

 

In Active Directory, the same groups exist, albeit in a much different order.

FM_CSG_FULL- with limited members of my workgroup who have admin role in FMPro

FM_CSG_RW- My entire workgroup, with Data entry access to all layouts.

FM_ALL_RESTRICTED- the entire organization.

 

My directory account, Lets call it ABC1, exists in ALL 3 Active Directory Groups.

My workgroup has accounts in FM_CSG_RW and FM_ALL_RESTRICTED AD groups.

Everyone in the organization has accounts in the FM_ALL_RESTRICTED AD group.

 

* In the actual production environment, I can't remove myself from two of these groups.  They are auto populated by other means, and are used for other authentication needs.

 

I have a startup script that sets a global variable [ $$UserCurrentPrivSet; Value: Get ( AccountPrivilegeSetName ) ], and then switches the user to the appropriate layout based on the result.

The script uses a nested If statement to switch layouts according to the value of $$UserCurrentPrivSet.

 

 

 

My Problem:

 

My understanding is that when I login using my ABC1 account, I should have the privileges associated of the first group FileMaker encounters with my account in it, in this case FM_CSG_FULL.

What I actually get are the privileges for FM_ALL_RESTRICTED.

 

I've verified this behavior with another AD test account that I have access to, ABC100.

- When ABC100 exists ONLY in the FM_ALL_RESTRICTED AD group, I get the FM_ALL_RESTRICTED privileges, as expected.

- When ABC100 exists ONLY in the FM_CSG_FULL AD group, I get the FM_CSG_FULL privileges, also as expected.

- When ABC100 exists in both the FM_CSG_FULL and FM_ALL_RESTRICTED AD groups, I get the FM_ALL_RESTRICTED privileges, which I do not expect.

 

My Confusion

My understanding, perhaps incorrectly, was that FileMaker would authorize privileges based on the order of the FileMaker Security groups.  So if I log in with an account that exists in all 3 AD groups, I would get the privileges associated with the first FM Security group that had my account in it.  In the example shown, I should have FM_CSG_FULL.

 

It seems that the opposite is happening.  I've been struggling with this for a few days now, and am getting no where quickly.

As near as I can tell, my startup script works as expected.  I've used Script Debugger to evaluate the value of $$UserCurrentPrivSet.  The values that I see are, for want of a better word, appropriate to the result I'm seeing.  It's just that result I'm seeing is not what I'm expecting based on my understanding of how FMPro evaluates the order of the security groups.

And that's the crux of my problem.  I'm questioning whether or not my understanding is correct.  I've so far found several old documents (FM8?) that indicate my understanding is correct, yet things still aren't working as I expect them to.

 

 

 

Can someone help me understand what I'm missing here?

 

thanks

Phil

[Steven H. Blackwell]

Have you toggled the popup list to read "Authentication Order" and not Creation Order or Account Name?  That's the Controlling MEchanism here.

 

Steven

[pbenware]

Hi Steven, Yes.

That was one of the first things I verified. (and just checked again for about the 15th time in the last week or so.)

[Wim Decorte]

The way you describe it is how it works.  The documentation has not been updated since FM8 because the feature has not changed since then, it's rock solid, no known bugs.

 

So where does it go wrong for you?  Perhaps a typo / name mismatch between the AD groups and the accounts in FM?  Perhaps you have some testing accounts on the FMS box's OS that match your account?

 

Have you tested with RSOP and WHOAMI to very your group membership?

[pbenware]

Thanks Wim.

 

So, I spoke with our server admin (he manages both the FMPro servers and Oracle db environment) and with one of our AD guys this morning.  They looked into it, and said things looked ok, but made a change on the FMPro Server OS configuration, and it's now working.  I'm still not clear what change was made, but they did say they had to break the domain binding for the server, then re-add it to the domain.  I'm guessing something in the prior binding process may have gotten munged, but I don't know for sure.

 

Anyway, now it's working.  On one hand, I wish I had engaged them sooner, but on the other hand, we've never experienced this type of issue with any of the other versions of FMPro server we've used.  So I still learned from the experience.

 

Thanks for all your help.