Jeffrey, I'm told that the alternative to tokengroups would be recursive LDAP queries. Which would be expensive for the clients, particularly with heavily-nested subgroups.
Prior to us using tokengroups, we tried to limit the cost of these LDAP queries by limiting the LDAP query depth to false. Interestingly, we also formerly used to have problems with global AD group memberships not being properly reflected. Our solution was to promote any such global groups up to universal groups and then the membership was seen. But for performance reasons, we started using tokengroups. We haven't seen this global group problem in a while. Interesting (and totally obscure!!) that it's related to use of tokengroups. BTW, if tokengroups is an expensive operation on AD DCs, seems like your AD team needs to size your AD DCs appropriately. Doesn't seem reasonable to throttle clients, due to some DC hardware. Spike On Wed, Dec 21, 2022 at 5:30 PM Jeffrey Chung <[email protected]> wrote: > The primary reason we disabled tokenGroups is because our sssd logs were > filling up with 'Unable to resolve SID S-1-5-21-XXX-XXX-XXX-XXX - will try > next sid.' entries. We found a work-around from this doc. > https://pagure.io/SSSD/sssd/issue/2914 > > In our environment not all of our AD groups are POSIX enabled, so I think > that's why we see a lot of those log entries. > > I just tested enabling tokenGroups and that seem to have solved the > issue. I'm seeing the LDAP query (port 389) going to a domain controller > from the same domain as the user. > > Is enabling tokenGroups the recommended configuration when using the AD > provider? The one thing I read is querying for tokenGroups is an expensive > operation on the domain controllers and care should be taken when scaling > this to larger environments. > https://learn.microsoft.com/en-us/windows/win32/adschema/a-tokengroups > Any insight into this? Is SSSD more efficient with tokenGroups enabled > versus not? > > -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
