12 Replies Latest reply on Jul 10, 2013 5:02 PM by JohnDCCIU

    FM Server caching LDAP info?

    Yadin

      Title

      FM Server caching LDAP info?

      Your post

      Our setup is as follows:  Mac servers running 10.6.8 server.  Filemaker server is on a server that is joined to the open directory of the primary server.  All authentication behavior is working as expected with AFP shares.

      Filemaker is ignoring changes to group membership in the OD.  I add a user to a group, but that user is unable to see the databases using that group as external authentication.  This issue just started for unknown reasons, and is not possible from what I know.  Since I can verify there is no issue with the directory system on either system by working with AFP share access, the issue lies souly within the Filemaker server software.  The only way it can be completely ignoring the changes to the external accounts is to somehow have internally cached the group membership information from the OD.  This obviously would be very bad behavior and should not be possible.  I have restarted the database server with no effect.

      Does anyone know if Filemaker can in fact cache the OD data, where that is to clear it, and how to prevent this bad behavior?  If not, can anyone identify another reason for this that I'm somehow missing?  It seems clear that Filemaker is not checking with the OD in a live fashion, I just don't know what it's doing and how, and to what extent I should be worried if it's caching credentials.

        • 1. Re: FM Server caching LDAP info?
          demani

          I have seen the same basic issue, and am posting in hopes that someone else might see it. If I restart the server (the machine, not just FMS) then I am able to use the new permissions, but once I login I cannot make any changes. Obviously this is a pretty bad situation since restarting the server when testing permissions and moving users between groups is an extremely inelegant solution. I don't think it is caching credentials per se (I can disable a user in OD and not be able to get in, and changing a password in OD does force the user to enter the new one), so I think it is passing the login info correctly, but I think it may be caching the permissions for the user-so changing the groups in OD doesn't show up in the Filemaker Server until the server machine is restarted.

          • 2. Re: FM Server caching LDAP info?
            Yadin

            Unfortunately Filemaker will not be assiting with this as I've been told by them that they do not support OS X server.  I found it amazingly baffling news that a server product is not supported on a server OS.  Since I observed this change in behavior between 10.6.7 and 10.6.8, it's my guess that something in that update does not agree with FM 11 server, but despite them issuing the v4 update to work with 10.7, it's still not happy.  I'm moving over to a Windows 2008 server as that seems to work nicely and Mac has to be phased out anyway due to obsolecense of the server hardware.

            • 3. Re: FM Server caching LDAP info?
              mwilson

              I have started testing external authentication of Filemaker Server 11.4.404 running on osx server 10.7.2 externally authenticating to Open Directory running on osx server 10.6.7

              I added a user to one group, tested loggin in to the filemaker solution, and user was correctly assigned group/priveleges.

              I then assigned a different group to the same user, but the original group/priveleges persisted.

              I removed the user from all groups and the original permissions persisted, allowing a user without group access into the filemaker solution.

              Restarting the Filemaker server machine, and the user was no longer able to log in to the solution.

              Adding the user to a group, and the user was still unable to log in to the solution.

              Restarting the Filemaker Server machine and the user was then able to log in with new credentials.

              so it appears the Filemaker Server is caching the open directory user/pass and extended priveleges until it is restarted. not good

               

              • 4. Re: FM Server caching LDAP info?
                mwilson

                Solution located using the Gooracle:

                Checking the Open Directory Server, user permissions appeared correctly.

                Checking the Filemaker Server, user permissions were incorrect, checked as follows:

                Last login: Fri Dec 16 20:03:59 on console
                mini:~ admin$ sudo dsmemberutil checkmembership -u 336977 -g 1054
                Password:
                user is not a member of the group
                mini:~ admin$ sudo dsmemberutil flushcache
                mini:~ admin$ sudo dsmemberutil checkmembership -u 336977 -g 1054
                user is a member of the group
                mini:~ admin$

                Flushing the cache on the Filemaker Server, and then re-checking permissions resulted in the correct permissions, and correct behaviour from the Filemaker Client logging in. 

                Woot \0/

                Flushing the cache on the Filemaker Server 

                • 5. Re: FM Server caching LDAP info?
                  demani

                  Well, that solves the immediate problem, but what is the interaction between Filemaker Server and OD that causes the cache to not be updated in the first place? Clearly FMS is a factor, otherwise OD replicas would be broken in general (and both my replicas work fine). Would it be better to have the FMS server be an OD replica as well? I was unable to get the support line to clarify anything about their recommend setup, so I don't know about that one.

                  • 6. Re: FM Server caching LDAP info?
                    mwilson

                    Further investigation suggests this is an open directory (OSX client) behaviour, rather than a Filemaker Server behaviour.

                    The Open Directory cache has a TTL (3600 secs) or 1 hour.

                    We see similar issues with other services tied to OD credentials (file/mail services)

                    mini:~ admin$ sudo dsmemberutil dumpstate
                    mini:~ admin$ open /Library/Logs/membership_dump.log

                    0x7fb662c34c10: User - mwilson
                    id: 336977
                    state: online
                    timestamp: Wed Dec 21 14:56:57 2011
                    TTL: 3592 sec

                    this TTL counts down actively once the OD credentials are received from the OD server. After 1 hour, these credentials are invalid, and the OD server is queried for credentials and at that stage gains the new credentials. 

                    I have yet to locate a way to shorten the TTL for the OD cache, however this would appear to be outside of the scope of Filemaker Server, the cache is at OS level, and supporting the advice mentioned earlier from Filemaker.

                    The solution of flushing the credentials on the filemaker server machine ensures that new OD credentials are immediately implemented.

                    Should anyone determine a way to shorten TTL on OD cache I would love to hear about it :-)

                    Best Regards,

                    Marcus Wilson

                     

                    • 7. Re: FM Server caching LDAP info?
                      demani

                      I've seen it go overnight-longer than the TTL-I wonder if OSXS may have a differnt setup than the client? NIf the server machine was an OD replica then would that facilitate faster updates? How is your server configured? Mine is an Xserve with 10.6.8 server, set as a simple client joined to the OD running on a separate machine. 

                      • 8. Re: FM Server caching LDAP info?
                        Yadin

                        This is not an OS issue as originally posted.  No other service on the server is exibiting this caching behavior.  If this was an OS level caching behavior then AFP connections would behave the same as Filemaker authentications and that is not the case.  Additionally, this problem came to my attention because it was several days after adding a user access and they could not get it.  So, we're not talking about a simple 1 hour TTL issue here, we are talking about a cache being made by Filemaker at the time it's pointed to the OD for authentication and never updating it again.  No reboot, no days of time.  The only way to refresh this is to unjoin and rejoin the server as a directory member. 

                        Based on what Marcus is reporting behavior wise, I suspect something else at work in addition to the behavior I have seen.  I am using two 10.6.8 servers, one as ODM one as member of it.  I did not see this issue until the servers were updated to 10.6.8.  Since Marcus is using 10.6.7 (which did not have this issue) and 10.7.2 (untested in my shop as a server bound to anything), I would hazard to say we're actually seeing two different issues that have a similar end result.

                        • 9. Re: FM Server caching LDAP info?
                          demani

                          Next week I'm going to try a run with a machine at 10.6.7 Server and at 10.6.8 Server, and also with 10.7.2 Client (looking at migrating from the Xserve to a pair of Minis). Also, I am going to give it a shot with Windows 7, since getting a server to run it might be the priority over running OSX for ease of management.

                          • 10. Re: FM Server caching LDAP info?
                            mwilson

                            Hi Yadin, if possible please test the dsmemberutil cache on the machine you are talking about, to determine if the cache on that machine shows the correct membership, and that filemaker server is out of sync with that, as per

                            Last login: Fri Dec 16 20:03:59 on console

                            mini:~ admin$ sudo dsmemberutil checkmembership -u 336977 -g 1054
                            Password:
                            user is not a member of the group
                            mini:~ admin$ sudo dsmemberutil flushcache
                            mini:~ admin$ sudo dsmemberutil checkmembership -u 336977 -g 1054
                            user is a member of the group
                            mini:~ admin$

                            this would assist in confirming there is a second issue at play, if the cache has the correct information but the server still does not have the correct user permissions assigned thanks

                            • 11. Re: FM Server caching LDAP info?
                              mwilson

                              further to the previously observed behaviour, I have the following to add:

                              Server OSX 10.7.3 Filemaker 11.0.4.404

                              Authenticating to Active Directory (Windows server 2008 R2 Enterprise edition) instead of Open Directory.

                              changes made to users are also not available to the hosted solution until after calling dsmemberutil flushcache.

                              I have made it a step in updating user configuration to the directory to "dsmemberutil flushcache" on the filemaker server, to ensure the information is not retained, and this appears to be maintaining correct permissions as a part of the change process.

                              I am yet to see any confirmed case where the contents on dsmemberutil is out of step with the filemaker server's authentication policy, so would expect this is where the issue lies, rather than a specific Filemaker Server issue. thoughts?

                              • 12. Re: FM Server caching LDAP info?
                                JohnDCCIU

                                     I'm seeing this behavior with FileMaker Server Advanced v12.0.4 on OS X Server 10.7.4, bound to an ActiveDirectory server.

                                     If I put an AD user into an AD Group, then the FileMaker database with that group properly configured allows the user in.  But when I remove the AD user from the AD group, the FileMaker database continues to allow the user in for a very long time.  At this point I'm more than two hours after removing the user and it's still allowing access.

                                     I've tried "dscacheutil -flushcache" a number of times, but it's still allowing access.

                                     I verified that the OS X box knows that that AD user is no longer in the AD group manually by using dscl to drill down to the AD group and then using the "read" command, which shows that the AD user is not there.

                                     What gives?