On Fri, Nov 15, 2019 at 04:57:27AM -0800, Jim Burwell wrote: > On 2019-11-15 04:25, 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, > > > > I'm just after checking and you are correct! the ldap search through the > > Global Catalog does not return any POSIX attributes, we're going to apply > > this patch and see if the errors stop occurring. If this is the solution I > > owe you a drink (or 5). > > > > Thanks, > > Jamal > > > Yep. The docs say that all those POSIX attributes should be marked as > being part of the GC, which they aren't by default. You need to use the > AD schema too to do that IIRC. > > I've also encountered issues with groups going missing, and in fact I'm > working such an issue now. In our case, all the POSIX stuff is > replicated to the GC. What happens is that the user's groups are fine > for a long time (8-10 hours), then either a single group vanishes, OR > all but their login group vanishes. The only thing that brings it back
Hi, are the group from the domain the client is joined to or from a different domain in the forest? > immediately is stopping SSSD, removing /var/lib/sssd/db/*, and > restarting it. Then the groups will be back for that semi-random period. > > I had another case of this issue a few weeks ago. But in this case it > turned out to be that there was an automated process on the AD that was > removing users from groups, then adding them back shortly after. It Are the groups being removed as well during this process and then added back with the same name? Can you share your sssd.conf? bye, Sumit > seems that SSSD would sometimes catch it at the right time, and remove > the user from the group, or sometimes bug out and remove all the users > group except the user entry's gidNumber group (primary login group). > > This appears to me to be some sort of bug with SSSD where once it > removes a group in the cache, it doesn't restore it when the user comes > back. Perhaps negative caching (intended, or not)? > > > - Jim > > _______________________________________________ > 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
