Re-implement LDAP_MATCHING_RULE_IN_CHAIN for Active Directory

[archoversight]

Hello,

I am aware that in https://github.com/SSSD/sssd/commit/65bd6bf05d75c843e525f8bf89e9b75b02a2bfb7 this feature was dropped, but we are running into similar issues as what is seen in https://github.com/SSSD/sssd/issues/5030 where an id user takes longer and longer the more groups that the user is a member of.

We've implemented RBAC/Security groups using LDAP groups and are seeing issues with SSSD whereby it will fail to fetch the list of groups that a user is a member of in an appropriate time period due to it enumerating all the groups a user is a member of.

Even while setting ignore_group_members which does reduce the time somewhat it takes multiple seconds to fetch the group membership information. This radically slows down SSH logins and the like as that information is fetched.

Would it be possible to either re-implement LDAP_MATCHING_RULE_IN_CHAIN support in AD to avoid doing as many lookups and instead having Active Directory do that work, or is there a way I can force that to be used with the existing settings that are exposed?

Thanks, Bert

[sumit-bose]

Hi,

by default SSSD is currently using a search for tokenGroups which returns all groups the user is a member of in a single request. What typically takes the most time is to lookup the LDAP of each group the user is a member of which does not have a active cached entry in SSSD's cache. This will be the same if LDAP_MATCHING_RULE_IN_CHAIN is used.

When using the id command SSSD will not receive a single request but the id command does look up each group individually as well. Recently @alexey-tikhonov found that in this case each group is looked up twice from the AD DC. Optimizing this is currently work in progress.

So, to cut it short, I think re-adding LDAP_MATCHING_RULE_IN_CHAIN won't have considerable advantages especially since it might not return all group the user is a member of, domain local group might be missing when using a Global Catalog and cross-domain group memberships might be missing when using the LDAP port of an AD DC.

bye, Sumit

[archoversight]

Thanks for the response @sumit-bose, do you have a link to the bug report for the duplicate lookups so that we can follow that ticket and keep apprised of any updates happening there?

[alexey-tikhonov]

Thanks for the response @sumit-bose, do you have a link to the bug report for the duplicate lookups so that we can follow that ticket and keep apprised of any updates happening there?

I think this is https://bugzilla.redhat.com/show_bug.cgi?id=2133854

[marcohald]

for our use case it would be also a nice performance increase. We use ldap_group_search_base where we Filter for the CN of specific Groups. The Problem is that one of the Groups we filter for is a nested Group containing other Groups where a user can be a member. As workaround we list every group that is nested in the ldap_group_search_base which is working but not very convenient if a new group is added it needs to be changed.

[ibre5041]

Let me share some experience from large corporate environments:

• LDAP_MATCHING_RULE_IN_CHAIN is buggy as hell, most queries do die on timeout. Even if there are NO nested groups in place, the query times out.
• It is much faster to implement recursion on client side, than to rely on Microsoft's implementation
• Most likely you do not need to promote all AD user groups into Linux world.
• Store Posix attributes UID/GID in AD for relevant users/group, and promote only those groups which are relevant for Linux users.
• Everything is much more reliable if you're able to communicate with AD administrators

[andreboscatto]

Dear Contributor/User,

Recognizing the importance of addressing enhancements, bugs, and issues for the SSSD project's quality and reliability, we also need to consider our long-term goals and resource constraints.

After thoughtful consideration, regrettably, we are unable to address this request at this time. To avoid any misconception, we're closing it; however, we encourage continued collaboration and contributions from anyone interested.

We apologize for any inconvenience and appreciate your understanding of our resource limitations. While you're welcome to open a new issue (or reopen this one), immediate attention may not be guaranteed due to competing priorities.

Thank you once again for sharing your feedback. We look forward to ongoing collaboration to deliver the best possible solutions, supporting in any way we can.

Best regards, André Boscatto