mac | pc 13.0.2 Upgrade breaks external authentication of openldap users

[kailou]

Issue: Update from FMS v13.0.1.224 to 13.0.2.295 breaks external authentication of openldap users in local groups on OSX Server 10.8.5

 

I should note upfront that my FMS is currently working again only because I've reverted to the previous version - 13.0.1.  I was unable to resolve the problem with 13.0.2.  I'm tossing this out to the community to see if anyone else has seen this issue and if they've found a fix.

 

My Environment:

OSX Server 10.8.5 running on a mini.

Current Installed Version FMS: 13.0.1.224

OSX is bound to an openldap server on our network.  This has been happily providing authentication for several services on the mini, including FileMaker Server since v11, and most recently with v13.0.1.224.

 

Users from the openldap directory are added to local groups on the mini.  The local groups are added to various FM databases for external authentication.  No problem, been working just fine ... until the v13.0.2.295 update.  This update breaks external authentication for the openldap users in the local groups.  I have isolated the problem to know that it is definitely something with the 13.0.2 update and not anything else on the system, I'm just not sure which new FMS component is the culprit.  Openldap users can still happily login to the server and other services hosted on the server, only FMS is effected.

 

Throughout this process there have been no errors what-so-ever thrown to any system logs.  I do see 661 warnings in the FMS Event.log, but I believe these to be red herrings.  All databases have been double checked that fmapp is set for the local groups in question; authentication order has also been double checked.  None of these were changed, anyway, from when it worked with 13.0.1.  I have no 'opener scripts', never have.

 

What I've tried:

- Upgrade was first done with the updater.  I did this twice, no joy.

- Uninstalled FMS completely and installed full version of 13.0.2.295 from scratch.  No joy.

- Created a new local user on the server and added that user to one of the local groups used by my FM databases.  This user has no problem authenticating and accessing the databases.  Openldap users in the same local group fail under v13.0.2

- I've compared files between the installations of v13.0.1 and v13.0.2 and so far have not found anything useful.  Many of these files are binary, though, so I can't really see the what they are doing internally.

- Spoke with FileMaker help line.  Friendly, but no solutions and no similar reports in their knowledge base.

 

Anyone else see this?  Thoughts?  Solutions?

 

Cheers,

Keith

 

[Wim Decorte]

Did you open a support ticket with FMI on this, to have it escalated passed the friendly guy on the phone?

[kailou]

Hey, don't knock the 'friendly guy'! ;-P  No, have not escalated the issue.  The friendly guy suggested the same, but that would be at a high rate for that support call and I'm too cheap for that call just yet.  I'm not yet convinced that I've exhausted the existing user group knowledge base on the subject.  I'm really hoping someone out there has come across something similar and can offer that one little nugget that would nudge me in the right direction. 

[Wim Decorte]

Too many variables involved for us to know what's going on.  EA issues are usually best trouble-shot when being at the site and testing various things.   You are not running the latest FMS version so do that first.

[kailou]

Thanks, Wim.  We can absorb small windows of downtime to test further if I had some additional things to try.  I've spent 2 full days already trying to troubleshoot 13.0.2 in various ways before reverting to 13.0.1.  If you have some ideas of things to poke at, I'm all ears.  One thing that would be helpful would be some way to get FMS to generate verbose debug logs that would show all the steps it is taking in the EA process - I see no way to tell FMS to do this, so the FMS logs are currently not helpful.  My system level logs are already verbose and they show nothing.  So, I've been troubleshooting in the blind so far.

[Wim Decorte]

FMS can't be more verbose than it is since EA is a strict hand-off to the OS, so only the OS logs will reveal any clues.

FMS does not do any authentication, only the OS does.

 

Your initial description is a bit confusing: you mention local accounts and openldap accounts in the same breath.  Which is it?  Do you have an OD server or only using local accounts on the FMS box?

[kailou]

OpenLDAP users in local groups. 'Local' meaning the group is a system level posix group, not Open Directory.  Open Directory is not running on the FMS machine.  Users are all kept in an openldap directory elsewhere on the network.  I add my users from openldap into the local groups on the FMS server machine.  I then add the appropriate group to my FM databases for EA.  The only time I've used a local posix user in a local posix group was as a troubleshooting measure to see if EA broke completely or if it broke only for the openldap users.  Only the openldap users fail EA under 13.0.2.

 

This is really similar to issues I had getting openldap to work with some other services (login,ssh,wiki etc) on the mini.  The fix in those cases had to do with modifying the PAM config.  So, it is certainly possible that has something to do with my 13.0.2 woes.  Perhaps something in the auth handshake changed between v13.0.1 and v13.0.2.  Nothing has changed with my PAM config for almost a year.  Perhaps 13.0.2 needs some additional, specific tweaks in the PAM config that 13.0.1 did not need.  Again, no log information what-so-ever, the EA fail is silent.

[Wim Decorte]

Is the FMS machine bound to the OD?

 

Since you have an OD, why would you want to create groups in the local OS of the FMS machine?  Why not create the groups in the OD itself?

 

When FMS asks the OS to authenticate a user it will traverse the authentication tree set up in the OS.  If the user does not exist in the local accounts it will check the OD it is bound to.  The OD will return the groups the user is a member of.

 

In your scenario you also expect it to return the non-OD groups the account is a member of; I'm not sure that it will or that it is designed to.  I'm pretty sure that if the account itself existed on the local system it would also return the local groups that this account belonged to but not the OD groups.

 

It seems like you are trying to mix and match OD accounts and local groups and that is going to produce some strange results.

[kailou]

Yes, FMS is bound (anonymous) to the OD.  I don't have access to modify the OD, thus the local groups.  I'm in a campus environment and the OD is hosted at the university level.  Very convenient for many local uses. 

 

Yes, in general the OS behaves just as you mention - it checks available auth methods and returns the necessary info to authenticate.  Ldap search does, in fact, return the local (non-OD) groups that OD users are a member of.  All the users for my FileMaker databases are OD users, none of them are local OS users.

 

Yep, the whole 'golden triangle' config is tricky, but I've had it working on OD and AD environments since v9.  You may be on the right track in that the OS just isn't returning the auth data the way FMS expects.  This may be the change in 13.0.2; 13.0.2 may be querying the OS differently from its predecessors.  I'm surprised that I would not see any errors at all in the system logs.

[kailou]

Ha!  OK, I now know why its failing, but I don't have the fix just yet.  My open directory logs weren't quite as verbose as I thought they were.  I set that to debug level and suddenly got a whole lot more information  Turns out that 13.0.2 has changed the way it hands off its authentication request to the OS, or in how it identifies itself to the OS, and as a result it attempts only a 'simple bind' to openldap with basic authentication; I need it to do GSSAPI.  13.0.1 actually properly followed the correct OS auth chain and would make the needed GSSAPI bind.  I just now need to figure out how/where to make the needed modification - either within the FileMaker config someplace, or maybe its within pam.d as I had suspected earlier.  If anyone has further insight I'd be grateful!

[kailou]

eh, not so quick, that was only part of the equation.  Got the GSSAPI thing resolved, but still not authenticating.  Ldap appears to be responding correctly, but FMS appears still not to be getting the info it needs…. *sigh* 

[Wim Decorte]

Just to be clear: we ARE talking about Apple's Open Directory that you are authenticating against, right?

You did mention OpenLDAP originally but then later talked about OD.  

Turns out that 13.0.2 has changed the way it hands off its authentication request to the OS, or in how it identifies itself to the OS

 

How did you establish that?

[kailou]

OpenLDAP as mentioned originally, not Apple's OD.  Its an openldap directory on Linux servers on our campus network.  I changed to OD because that was the way you seemed to be referring to the openldap directory in shorthand.  I'm sorry if that was confusing.  As mentioned above, I am not running Open Directory on any of my Apple machines.  I tried running Open Directory and it had issues in a 'golden triangle' sort of environment on our network.

 

How did I establish that things changed? First off, openldap auth worked under 13.0.1 and then fails under 13.0.2, with no other elements in the equation.  So, that alone tells us something changed in the way 13.0.2 requests or interprets auth info.  If nothing at all has changed on the system, then its more than logical to infer that it is a change in FMS 13.0.2.  Next, I can now see it in the system debug logs.  I've generated logs for the authentication process under 13.0.1 and then under 13.0.2 and I'm in the process of comparing them.  13.0.1 binds to ldap using GSSAPI, 13.0.2 out-of-the-box does a simple bind.  I've now resolved that portion of it by introducing a PAM config for the fmserver_helperd.  Now, when my FM openldap users attempt to login I can see in the logs that the auth process will sucessfully bind and authenticate to openldap under 13.0.2 just as it did under 13.0.1:

Module: ldap - successful GSSAPI authentication for authzid - 'dn:uid=myopenldapuser,cn=accounts,dc=stanford,dc=edu' authcid - 'myopenldapuser'

Module: ldap - Audit - success - Verify password for record type Users 'myopenldapuser' node '/LDAPv3/ldap.tld'

BUT even though the LDAP portion now appears to complete successfully, openldap users in FMS still cannot login to FM.  There is nothing further in the system logs;  the only other log piece I get anywhere is the 661 error in the FMS Event.log.  

[Wim Decorte]

FM EA is not designed to work with anything except Apple's Open Directory and Microsoft's Active Directory so I'm surprised you ever had it working against OpenLDAP, and apologies for adding to the confusion by not catching that earlier

[IanW]

Wim:

 

I've just been able to externally authenticate a FMS 13 database against a local system group and local (sharing only) user on Mavericks. Although my FileMaker machine is bound to an OD service on another Mac server, the user account and group do not exist in the OD.

 

When I remove the OD binding, the user is still able to use EA successfully. Is this an undocumented feature of FMS 13, or am I missing something?

 

Cheers

 

Ian

[Wim Decorte]

No, fully documented.  Local accounts and groups are supported, and have been since Server 7.  IIRC there is a subtle difference between OSX and Windows in this:

- on OSX, even though the machine may be bound to OD; FMS will still always look at the local accounts and groups first

- on Windows, when the machine is a member of the domain, local accounts and groups will be ignored

(It's been a few years since I have tested this though).

 

Using local accounts and groups is a great way to use EA when there is no AD or OD around.

[kailou]

Yeah, local groups with OD/AD/OpenLDAP accounts works great.  Never had an issue until 13.0.2.  I'm still trying to resolve this, though I've reverted to 13.0.1 and tabled my troubleshooting for the moment.

 

"- on Windows, when the machine is a member of the domain, local accounts and groups will be ignored"

Nah, I've got a mix of AD users and groups added to local groups, then its the local groups that are used for EA - FMS on Win machine.  Don't know about local users within those local groups, though I can't see why those wouldn't work as well.  

 

RE: FMS and OD-only.  I believe this is moot, IMO.  As long as the relevant LDAP schema is in place and mapped it really shouldn't matter the source (OD/AD/OpenLDAP), FMS doesn't know the difference.  This still may be my issue, though, if something changed in FMS 13.0.2 in the mapping - i.e., FMS is looking for the response in a different field than previously.  Hopefully I'll have some time to do more troubleshooting soon.