On Thu, Nov 14, 2019 at 03:54:35PM -0000, Jamal Mahmoud wrote: > Hi, > > Can I ask why there is a lack of willingness to help us out on this issue? I > would have thought that it is in the sssd's best interest to resolve issues > users are having. Is there anybody on the dev team that can provide > assistance on this issue? Looking forward to any response.
Hi, I'm sorry for the delay in response. I silenced this thread originally since Jakub was handling it, but unfortunately Jakub has other responsibilities nowadays and I forgot the look at this thread. Some time ago you said: > I've managed to catch the error again on my machine by forcing the cache to > update much more often. I've compared the group entry in the cache both before > and after the corruption occurs and have found some interesting > differences: > the entryUSN is different, not sure if that matters, > the isPosix flag is set to FALSE on the corrupted entry > the gidNumber is set to 0, > All the users and ghost members, SID number uniqueID are all the same. I > managed > to pull an "AD group type flag set" 0x80000004 if that means anything at all > to > you. The '4' at the end of the groupType attribute indicates that the given group is a group with 'Domain Local' scope, i.e. it is only valid in its parent domain. 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 > > Thanks, > Jamal > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@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.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@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.org
