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 <jeff.chung(a)sig.com> 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/...
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 -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)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.fedorahoste...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue