On Fri, Nov 15, 2019 at 10:58:17AM -0000, Jamal Mahmoud wrote:
Hi Sumit,
Thank you for getting back to me.
Now it would be important to know if the group is defined in the same domain your client is joined to or if it is coming form a different domain.
In the latter case (group is coming from a different domain) the cache attributes 'isPosix: FALSE' and 'gidNumber: 0' are expected because SSSD will filter out those groups because they are not valid in the domain the client is joined to. My guess is that using the group as primary group for some users might use a code path that skips the filter so that it is added to the cache as proper group first but later on another lookup uses the filter and removes the gidNumber and sets isPosix to FALSE. To solve this you should switch the scope of the group to 'Global' or 'Universal'.
In the former case (group is from the domain the client is joined to) it would be good to know if you are using UIDs and GIDs stored in AD or if you use SSSD's id-mapping scheme (ldap_id_mapping = False / True respectively).
bye, Sumit
The group we are using is defined in the same domain and for the most part it does in fact return the correct GIDs for the group. We have set ldap_id_mapping to false as we are using POSIX attributes on our AD users and groups.
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
I noticed that whenever the backend fills the cache with the wrong data, any updates do not actually modify the cache entry, we get this:
[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
But occasionally, seemingly out of chance it does modify the entry, fixing the problem and setting the group to isPosix: TRUE when we get this:
[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.
Not sure if any of that means anything towards the issue, just trying to give as much information as I can!
Do let me know if there is anything more you need, Thanks, 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...