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 group@domain.com [sysdb_set_entry_attr] (0x0200): Entry [name=group@domain.com,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 group@domain.com [sysdb_store_group] (0x1000): The group record of group@domain.com 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 -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o...