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