Performance issue in LDAP connector when user has lot of nested groups

[as428y]

Preflight Checklist

• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.
• I am not looking for support or already pursued the available support channels without success.

Version

master

Storage Type

etcd

Installation Type

Official container image

Expected Behavior

I have tried the feature "#4113,
to configure hierarchical groups

Expected that login based on hierarchy will be done in some logical time (a few seconds)

Actual Behavior

I have tried the feature "#4113,
to configure hierarchical groups

As soon as I have a lot of groups, the performance is not as good as expected.
For me, it took ~60 seconds to iterate over all groups I'm in

Maybe the following points will help

Replaced O(n²) duplicate detection with O(1) map lookup
Multiple string comparisons
query batching

Having multi-threading will improve it

Steps To Reproduce

No response

Additional Information

No response

Configuration

Logs

[yrro]

With LDAP, doing repeated searches to resolve all group memberships is generally a bad idea on larger installations.

The only efficient way to resolve all of a user's groups that I'm aware of with Active Directory is to look up the tokenGroups attribute. This gives the group SIDs, and you then have to do one or more searches to resolve those to entries so you can get the group names.

[nabokihms]

@yrro it seems like an Active Directory-specific thing? There is no guarantee other LDAP providers follow the same semantics, right?

[yrro]

Unfortunately yes. It's the price we pay for the ability to have a forest of multiple domains where users in one domain can be a member of a group in a second domain that is itself a member of a group in a third domain, etc. That said, from the point of view of a client, it's not too different from looking up the memberOf attribute on a user entry on FreeIPA-managed LDAP server; it's just that whereas memberOf gives you a full DN, tokenGroups gives you a SID.