Jeffrey, Follow-on question. How does your sssd configuration ever bind to a nonlocal-domain global catalog server?
Are you relying on sssd's site-awareness to determine preferred AD DCs and global catalog servers? Or are you hard-coding global catalog servers in your sssd.conf file? If the former, then I'd beat up on your maintainer for AD site and services; they have defined non-local global catalog servers for your site. Spike On Thu, Dec 22, 2022 at 4:14 PM Spike White <[email protected]> wrote: > Jeffrey, > > Bear in mind I'm a Linux engineer. (I speak regularly to our AD team). > As I understand it, the domain-local memberships are housed in the local > domain, not the GC. > > If you look at the output of 'sssctl domain-status <domain>', you will see > it references two DCs that it's bound to. The local DC and the global > catalog server. > > So for domain-local groups, it would consult the first DC and get back the > proper membership. For universal groups, yes their membership is contained > in the GC, so it'd have to consult that second DC (the global catalog > server). > > That leaves only the global groups. and I think your reasoning is correct > for those. > > To be honest, when we were transitioning to sssd from our previous AD > integration tool, we were under a time crunch. So while we saw (same as > you) that not all global group memberships showed up, we didn't have time > to deep-dive into the actual culprit. (I suspect it's exactly as you > state, because at that time we were doing 'tokengroups = false'). > > Since we were under a severe time crunch, we just promoted any global > group that got called out by the users. We promoted that global group to > a univeral group. > > I haven't seen a global group getting called out for missing membership in > over a year. However, we have transitioned to 'tokengroups = true', so > that's likely why. > > Spike > > On Thu, Dec 22, 2022 at 2:53 PM Jeffrey Chung <[email protected]> wrote: > >> Thanks for the reply Spike. We will do some performance tests in our AD >> environment for this. >> >> There are situations where tokenGroups should be disabled to get >> consistent results like changing the search base for groups. >> >> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/windows_integration_guide/changing-the-ldap-search-base-for-users-and-groups-in-a-trusted-ad-domain >> >> In this scenario with tokenGroups disabled we would still hit the same >> issue in my original post. To me this seems to be a bug in sssd, it can't >> rely just on the GC to get back a complete list of groups a user is member >> of because you'll be missing other group scopes like Global and Domain >> Local. Am I thinking about this wrong? >> >> -Jeff >> _______________________________________________ >> 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] >> Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> >
_______________________________________________ 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] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
