On Mon, Nov 18, 2019 at 03:12:35PM -0000, Jamal Mahmoud wrote: > > On Fri, Nov 15, 2019 at 10:58:17AM -0000, Jamal Mahmoud wrote: > > > > Ok, do you know if the LDAP attributes uidNumber and gidNumber are > > replicated to the Global Catalog in your environment? By default they > > are not. > > > > You can check this manually as well with ldapsearch on the Global > > Catalog port 3268: > > > > ldapsearch -H ldap://your-ad-dc.your.ad.domain:3268 -b > > 'DC=your,DC=ad,DC=domain' samAccountName=groupname > > > > If gidNumber is missing in the Global Catalog object please try if > > setting > > > > ad_enable_gc = False > > > > in the [domain/...] section of sssd.conf makes the group lookup more > > reliable. > > > > bye, > > Sumit > Hi Sumit, > > After adding in the ad_enable_gc=false, it doesn't seem to stop the errors we > are getting, the last problem we got (today) was a logged in user had only > his uid and the primary GID, not sure if this is a different issue but i'm > starting to get the feeling that there is something misconfigured on our SSSD > client setup. > > Although, since I rolled this out, the machines with the new config did not > get the "non-POSIX POSIX group in the cache" problem we've been discussing, > so it may be solved, or coincedentally the specific error hasn't come up > again. > > As an aside, I've noticed that when the backend fetches new data for the > cache, sometimes it will just update the ts_cache and sometimes it will > update both the cache and the ts_cache. What determines this behaviour? I'm > asking because when the cache fetches and updates, it actually fixes the > problem when it updates the cache but when it only changes the ts_cache the > issue remains, i've added a couple of examples to explain: > > Updates both cache and ts_cache > [sdap_save_group] (0x0400): Storing info for group [email protected] > [sysdb_set_entry_attr] (0x0200): Entry > [[email protected],cn=groups,cn=domain.com,cn=sysdb] has set [cache, > ts_cache] attrs. > > Updates only the ts_cache: > [sdap_save_group] (0x0400): Storing info for group [email protected] > [sysdb_store_group] (0x1000): The group record of [email protected] did not > change, only updated the timestamp cache > > Realistically it should see that the incoming data is different to the cached > data no?
Hi, we use the timestamp LDAP attribute which stored the last modification time to decide if it is sufficient to just update the timestamp cache or if the data cache should be updated as well. In AD this attribute is called 'whenChanged' and the comparison between stored in new value is just a comparison of the strings, if they differ the data cache will be updated as well. What you describe might have two reason. If you add a member to a group on a Domain Controller (DC) A but SSSD is connected to DC B it might refresh the group after the new member is added but before the new data is replicated to DC B. This is somewhat expected and if the data is finally replicated to DC B and the cached group is expired again the data cache will be updated. The second reason might be that 'whenChanged' is handled even more differently then we thought. 'whenChanged' itself will not be replicated from DC A to DC B but DC B should update 'whenChanged' when the new data from DC A is added to the DC B with the current time. So it is expected that 'whenChanged' for the same object is different on every DC but is should change whenever the data is updated. That's e.g. the reason we just do a string comparison, 'whenChanged' should just be different to update the data cache and we do not care if the numerical values are larger or smaller. > > Sorry for the heavy message, please let me know if you need any specifics and > I'll be glad to provide. Really appreciate the time you're giving to help us > out. I wonder if you can try to monitor the replication in your environment by adding a new member to a group on a Domain Controller and check the group object on another Domain Controller in regular intervals (e.g. every 2s) with ldapsearch, especially the 'member' and the 'whenChanged' attributes. This should help to understand if replication just takes long or if 'member' and 'whenChanged' are no updated together on the other DC. Thanks bye, Sumit > > Kind Regards, > Jamal > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/[email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/[email protected]
