SSSD with rfc2307bis causes thousands of concurrent LDAP queries, triggering OpenLDAP flow control

[Christopher Paul]

Hello sssd-users,

I'm experiencing severe performance degradation with SSSD when using 
ldap_schema=rfc2307bis. User lookups with "id" can take several seconds, 
and I believe that I have identified the root cause.

## Symptoms:
- SSSD logs: "LDAP operation ... seems slow, took more than 80% of timeout"
- OpenLDAP logs: "deferring operation: pending operations"
- Simple "id username" commands taking 5-10+ seconds (when not cached)

## Root Cause:
When looking up a single user, SSSD appears to be sending individual 
LDAP queries for EVERY member of EVERY group the user belongs to. This 
results in thousands of near-simultaneous asynchronous LDAP searches.

OpenLDAP's conn_max_pending/conn_max_pending_auth parameters are 
correctly throttling these requests, causing the perceived slowness.

## Environment:
- SSSD version: 2.9.6
- OpenLDAP version: 2.5.20

## Questions:
1. Why does SSSD need to resolve all group members when looking up a 
single user? This should be unnecessary to id a single user.
2. Can SSSD be configured to return just the group names/GIDs for a user 
lookup without also fetching full details of every member in those groups?
3. Could SSSD batch these queries or use more efficient LDAP operations?

I've attached my sssd.conf. The key setting is ldap_schema=rfc2307bis.

This behavior effectively makes rfc2307bis unusable in environments with 
large groups. Any guidance would be appreciated.

Many thanks,

[Christian, Mark]

On Mon, 2025-07-21 at 17:17 -0700, Christopher Paul via sssd-users
wrote:
> Hello sssd-users,
>  
>  I'm experiencing severe performance degradation with SSSD when using
> ldap_schema=rfc2307bis. User lookups with "id" can take several
> seconds, and I believe that I have identified the root cause.
>  
>  ## Symptoms:
>  - SSSD logs: "LDAP operation ... seems slow, took more than 80% of
> timeout"
>  - OpenLDAP logs: "deferring operation: pending operations"
>  - Simple "id username" commands taking 5-10+ seconds (when not
> cached)
>
> ## Root Cause:
>  When looking up a single user, SSSD appears to be sending individual
> LDAP queries for EVERY member of EVERY group the user belongs to.
> This results in thousands of near-simultaneous asynchronous LDAP
> searches.
>  
>  OpenLDAP's conn_max_pending/conn_max_pending_auth parameters are
> correctly throttling these requests, causing the perceived slowness.
>  
>  ## Environment:
>  - SSSD version: 2.9.6
>  - OpenLDAP version: 2.5.20
>  
>  ## Questions:
>  1. Why does SSSD need to resolve all group members when looking up a
> single user? This should be unnecessary to id a single user.
>  2. Can SSSD be configured to return just the group names/GIDs for a
> user lookup without also fetching full details of every member in
> those groups?
>  3. Could SSSD batch these queries or use more efficient LDAP
> operations?
>  
>  I've attached my sssd.conf. The key setting is
> ldap_schema=rfc2307bis.
>  
>  This behavior effectively makes rfc2307bis unusable in environments
> with large groups. Any guidance would be appreciated.

This is a common topic covered throughout the sssd mail archives. 
Configure your client to not enumerate groups by adding the following
to your sssd.conf.

enumerate = false

from man sssd.conf:

enabling enumeration is not
           recommended, especially in large environments.

Consider it a win for confidentiality.

Mark

On 7/21/25 5:53 PM, "Christian, Mark via sssd-users"  wrote:
> This is a common topic covered throughout the sssd mail archives.
> Configure your client to not enumerate groups by adding the following
> to your sssd.conf.

Hi Mark,

Thanks very much for your suggestion, but that is not my problem. As you can see from the sssd.conf I attached to my original post, I already have "enumerate = false".

Chris

[John Hodrien]

ignore_group_members (bool)
           Do not return group members for group lookups.

If set to TRUE, the group membership attribute is not requested from the ldap server, and group members are not returned when processing group lookup calls, such as getgrnam(3) or
           getgrgid(3). As an effect, “getent group $groupname” would return the requested group as if it was empty.

Enabling this option can also make access provider checks for group membership significantly faster, especially for groups containing many members.

This option can be also set per subdomain or inherited via subdomain_inherit.

Default: FALSE

Regards,

John

--
John Hodrien (he/him)
Principal Teaching and Research Support Specialist, School of Computer Science
2.22 Bragg Building, University of Leeds
________________________________
From: None via sssd-users 
Sent: 22 July 2025 02:05
To: [e-mail] 
Cc: [e-mail] 
Subject: [SSSD-users]Re: SSSD with rfc2307bis causes thousands of concurrent LDAP queries, triggering OpenLDAP flow control

CAUTION: External Message. Use caution opening links and attachments.

On 7/21/25 5:53 PM, "Christian, Mark via sssd-users"  wrote:
> This is a common topic covered throughout the sssd mail archives.
> Configure your client to not enumerate groups by adding the following
> to your sssd.conf.

Hi Mark,

Thanks very much for your suggestion, but that is not my problem. As you can see from the sssd.conf I attached to my original post, I already have "enumerate = false".

Chris
--
_______________________________________________
sssd-users mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]
Fedora Code of Conduct: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedor...https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproj...https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedo...https://lists.fedorahosted.org/archives/list/[e-mail]
Do not reply to spam, report it: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%...https://pagure.io/fedora-infrastructure/new_issue

[Christopher Paul]

On 7/22/2025 12:25 AM, John Hodrien wrote:
> ignore_group_members (bool)
>        ...

Hey John,

Thank you! That solves my problem. I owe you a beverage of your choice 
next time I'm in London or you are in Oakland.

But I still wonder why, with "ignore_group_members false" a lookup for a 
single user must do LDAP lookups for all the person and posixAccount 
attribute values for EVERY member of a group to which a SINGLE user 
belongs to. That still seems like sort of a bug to me.

[John Hodrien]

No problem.

I think the answer is, lots of legacy functions that really were written on the assumption that resolving this sort of information was really cheap, often optimised for just ripping through a local passwd/group file.  Don't blame SSSD.  Rather than code querying who was a member of a group, it'd simply enumerate all of the groups a user was a member of, which creates this hideous case with recursive LDAP lookups, when you're then expected to fully populate objects for each of these groups, which contain membership information of them.

You can't know whether a member is a user or a group either, without looking them up, so it really is horrible, and hard to fix, if you're using those functions and expect them to return correct information.

SSSD nicely includes this tweak, which effectively lies when you ask who is a member of a group, by saying "nobody".  Which on one hand is odd, because the only reason I looked in the group was because I know the user I'm looking up is a member of it!  As long as codes look at which groups the user is a member of, rather than doing the inverse, everything ticks along fine.

That's my understanding anyway, but I'm not an expert.

John

--
John Hodrien (he/him)
Principal Teaching and Research Support Specialist, School of Computer Science
2.22 Bragg Building, University of Leeds
________________________________
From: Christopher Paul 
Sent: 22 July 2025 22:45
To: John Hodrien ; [e-mail] 
Subject: Re: [SSSD-users]Re: SSSD with rfc2307bis causes thousands of concurrent LDAP queries, triggering OpenLDAP flow control

CAUTION: External Message. Use caution opening links and attachments.

On 7/22/2025 12:25 AM, John Hodrien wrote:
       ignore_group_members (bool)
       ...

Hey John,

Thank you! That solves my problem. I owe you a beverage of your choice next time I'm in London or you are in Oakland.

But I still wonder why, with "ignore_group_members false" a lookup for a single user must do LDAP lookups for all the person and posixAccount attribute values for EVERY member of a group to which a SINGLE user belongs to. That still seems like sort of a bug to me.

--
Chris Paul | Rex Consulting | https://www.rexconsulting.nethttps://www.rexconsulting.net/

[Christopher Paul]

On 7/22/25 14:53, John Hodrien wrote:
> [...]
>
> That's my understanding anyway, but I'm not an expert.

You're probably right, but it would be nice if SSSD could retrieve 
groups for a user but not look up all the members attribute values for 
all the other members of each group to which one user belongs.

I notice that with "ignore_group_members = true", that the "groups 
<uid>" command still works.

Chris

[Christopher Paul]

On 7/22/25 16:48, Christopher Paul via sssd-users wrote:
> On 7/22/25 14:53, John Hodrien wrote:
> > [...]
> >
> > That's my understanding anyway, but I'm not an expert.
>
> You're probably right, but it would be nice if SSSD could retrieve 
> groups for a user but not look up all the members attribute values for 
> all the other members of each group to which one user belongs.
>
> I notice that with "ignore_group_members = true", that the "groups 
> <uid>" command still works.

Oh blast it. Actually with "ignore_group_members = true", "id <uid>" 
also works, and it does not look up all the members attribute values for 
all the other members of each group to which one user belongs. So this 
feature does exist and it's called "ignore_group_members = true".

But I guess it would be nice if "getent group <group name>" worked to 
list all members without looking up their user values. I see no reason 
why a group lookup should cause all members' attribute values to be 
looked up.

Chris

[John Hodrien]

Again, not the expert here and there's likely some wrongness in what I'm saying, but...

I think the problem is the legacy (and still very much used) functions for gathering group information work on the basis that a big sweep of the groups file gathering all the information is much more sensible than lots of targeted pokes for just what you need.  So you have things like this, directly quoting from the man pages:

The initgroups() function initializes the group access list by reading the group database /etc/group and using all groups of which user is a member.

The getgrouplist() function scans the group database (see
       group(5)) to obtain the list of groups that user belongs to.  Up
       to *ngroups of these groups are returned in the array groups.

struct group {
               char   *gr_name;        /* group name */
               char   *gr_passwd;      /* group password */
               gid_t   gr_gid;         /* group ID */
               char  **gr_mem;         /* NULL-terminated array of pointers
                                          to names of group members */
           };

So you use initgroups to find out about all the groups a user is a member of, and in doing that you find out about all those groups, which means you need to populate the group members of all those groups.  Bleurgh!  This is what leads to the performance fun.

Say I'm restricting access to a service on the basis of group membership.  I can either ask "Which groups is this user a member of?", then check that the group I want is there, or I can ask "Who is a member of this group?".  The former means full group enumeration of every group a user is a member of, whereas the latter involves just a single group, but it's not all positive.

Using the ignore_group_members option in SSSD works around this and makes things much faster, but there is a downside.  If I go the latter route, and we've used ignore_group_members, then when I query a group, it tells me that nobody is a member of it.

So "What groups is Sally a member of? People".  "Who is a member of People? Nobody".  That then can cause you some grief with ignore_group_members.  In the past I know newgrp would fail to work properly with this configuration.

But to be honest, these niggles are in my experience few and far between.  With a large LDAP setup, ignore_group_members is an essential performance boost.

John

--
John Hodrien (he/him)
Principal Teaching and Research Support Specialist, School of Computer Science
2.22 Bragg Building, University of Leeds
________________________________
From: Christopher Paul via sssd-users 
Sent: 23 July 2025 00:52
To: [e-mail] 
Cc: Christopher Paul 
Subject: [SSSD-users]Re: SSSD with rfc2307bis causes thousands of concurrent LDAP queries, triggering OpenLDAP flow control

CAUTION: External Message. Use caution opening links and attachments.

On 7/22/25 16:48, Christopher Paul via sssd-users wrote:

On 7/22/25 14:53, John Hodrien wrote:
[...]

That's my understanding anyway, but I'm not an expert.

You're probably right, but it would be nice if SSSD could retrieve groups for a user but not look up all the members attribute values for all the other members of each group to which one user belongs.

I notice that with "ignore_group_members = true", that the "groups <uid>" command still works.

Oh blast it. Actually with "ignore_group_members = true", "id <uid>" also works, and it does not look up all the members attribute values for all the other members of each group to which one user belongs. So this feature does exist and it's called "ignore_group_members = true".

But I guess it would be nice if "getent group <group name>" worked to list all members without looking up their user values. I see no reason why a group lookup should cause all members' attribute values to be looked up.

Chris

[Sumit Bose]

Am Wed, Jul 23, 2025 at 08:35:17AM +0000 schrieb John Hodrien via sssd-users:
> Again, not the expert here and there's likely some wrongness in what I'm saying, but...
>
> I think the problem is the legacy (and still very much used) functions for gathering group information work on the basis that a big sweep of the groups file gathering all the information is much more sensible than lots of targeted pokes for just what you need.  So you have things like this, directly quoting from the man pages:
>
> The initgroups() function initializes the group access list by reading the group database /etc/group and using all groups of which user is a member.
>
> The getgrouplist() function scans the group database (see
>        group(5)) to obtain the list of groups that user belongs to.  Up
>        to *ngroups of these groups are returned in the array groups.
>    struct group {
>            char   *gr_name;        /* group name */
>            char   *gr_passwd;      /* group password */
>            gid_t   gr_gid;         /* group ID */
>            char  **gr_mem;         /* NULL-terminated array of pointers
>                                       to names of group members */
>        };

Hi,

where did you get this information? The `getgrouplist()` function is
defined as

int getgrouplist(const char *user, gid_t group, gid_t *groups, int *ngroups);

and returns only a list of GIDs and not the full group structs.

Where possible we try to avoid to lookup group-members internally. But a
typical use case for the `getgrouplist()` call is the `id` command and
if you do not use `id` with the `-g` option `id` will call `getgrgid()`
for all GIDs returned and this has to return the group struct with all
members.

Btw, I think the original question was not about the large number of
requests in general but that SSSD is sending those in parallel (sending
the next request before a reply for the previous was received). This is
indeed unexpected and comes most probably from
`sdap_process_group_members_2307bis()`
https://github.com/SSSD/sssd/blob/master/src/providers/ldap/sdap_async_group...
As you can see there is a loop which calls
`sdap_process_missing_member_2307bis()` for every group missing in the
cache which sends an asynchronous LDAP search without waiting for a
reply. This should most probably be handled differently to not overload
and LDAP server. Can you open an issue on github for this?

bye,
Sumit
> So you use initgroups to find out about all the groups a user is a member of, and in doing that you find out about all those groups, which means you need to populate the group members of all those groups.  Bleurgh!  This is what leads to the performance fun.
>
> Say I'm restricting access to a service on the basis of group membership.  I can either ask "Which groups is this user a member of?", then check that the group I want is there, or I can ask "Who is a member of this group?".  The former means full group enumeration of every group a user is a member of, whereas the latter involves just a single group, but it's not all positive.
>
> Using the ignore_group_members option in SSSD works around this and makes things much faster, but there is a downside.  If I go the latter route, and we've used ignore_group_members, then when I query a group, it tells me that nobody is a member of it.
>
> So "What groups is Sally a member of? People".  "Who is a member of People? Nobody".  That then can cause you some grief with ignore_group_members.  In the past I know newgrp would fail to work properly with this configuration.
>
> But to be honest, these niggles are in my experience few and far between.  With a large LDAP setup, ignore_group_members is an essential performance boost.
>
> John
>
> --
> John Hodrien (he/him)
> Principal Teaching and Research Support Specialist, School of Computer Science
> 2.22 Bragg Building, University of Leeds
> ________________________________
> From: Christopher Paul via sssd-users 
> Sent: 23 July 2025 00:52
> To: [e-mail] 
> Cc: Christopher Paul 
> Subject: [SSSD-users]Re: SSSD with rfc2307bis causes thousands of concurrent LDAP queries, triggering OpenLDAP flow control
>
> CAUTION: External Message. Use caution opening links and attachments.
>
> On 7/22/25 16:48, Christopher Paul via sssd-users wrote:
>
> On 7/22/25 14:53, John Hodrien wrote:
> [...]
>
> That's my understanding anyway, but I'm not an expert.
>
> You're probably right, but it would be nice if SSSD could retrieve groups for a user but not look up all the members attribute values for all the other members of each group to which one user belongs.
>
> I notice that with "ignore_group_members = true", that the "groups <uid>" command still works.
>
> Oh blast it. Actually with "ignore_group_members = true", "id <uid>" also works, and it does not look up all the members attribute values for all the other members of each group to which one user belongs. So this feature does exist and it's called "ignore_group_members = true".
>
> But I guess it would be nice if "getent group <group name>" worked to list all members without looking up their user values. I see no reason why a group lookup should cause all members' attribute values to be looked up.
>
> Chris
> -- 
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[John Hodrien]

Hi Sumit,

See, I told you I'd get it wrong!

Yes, things like id are properly evil, and an easy way to see the difference in performance between ignore_group_members true/false.

I'll go back to hiding in my corner ;)

Thanks,

John

--
John Hodrien (he/him)
Principal Teaching and Research Support Specialist, School of Computer Science
2.22 Bragg Building, University of Leeds

________________________________
From: Sumit Bose 
Sent: 23 July 2025 10:44
To: End-user discussions about the System Security Services Daemon 
Cc: Christopher Paul ; John Hodrien 
Subject: Re: [SSSD-users]Re: SSSD with rfc2307bis causes thousands of concurrent LDAP queries, triggering OpenLDAP flow control

CAUTION: External Message. Use caution opening links and attachments.

Am Wed, Jul 23, 2025 at 08:35:17AM +0000 schrieb John Hodrien via sssd-users:
> Again, not the expert here and there's likely some wrongness in what I'm saying, but...
>
> I think the problem is the legacy (and still very much used) functions for gathering group information work on the basis that a big sweep of the groups file gathering all the information is much more sensible than lots of targeted pokes for just what you need.  So you have things like this, directly quoting from the man pages:
>
> The initgroups() function initializes the group access list by reading the group database /etc/group and using all groups of which user is a member.
>
> The getgrouplist() function scans the group database (see
>        group(5)) to obtain the list of groups that user belongs to.  Up
>        to *ngroups of these groups are returned in the array groups.
>    struct group {
>            char   *gr_name;        /* group name */
>            char   *gr_passwd;      /* group password */
>            gid_t   gr_gid;         /* group ID */
>            char  **gr_mem;         /* NULL-terminated array of pointers
>                                       to names of group members */
>        };

Hi,

where did you get this information? The `getgrouplist()` function is
defined as

int getgrouplist(const char *user, gid_t group, gid_t *groups, int *ngroups);

and returns only a list of GIDs and not the full group structs.

Where possible we try to avoid to lookup group-members internally. But a
typical use case for the `getgrouplist()` call is the `id` command and
if you do not use `id` with the `-g` option `id` will call `getgrgid()`
for all GIDs returned and this has to return the group struct with all
members.

Btw, I think the original question was not about the large number of
requests in general but that SSSD is sending those in parallel (sending
the next request before a reply for the previous was received). This is
indeed unexpected and comes most probably from
`sdap_process_group_members_2307bis()`
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com...https://github.com/SSSD/sssd/blob/master/src/providers/ldap/sdap_async_groups.c#L1382
As you can see there is a loop which calls
`sdap_process_missing_member_2307bis()` for every group missing in the
cache which sends an asynchronous LDAP search without waiting for a
reply. This should most probably be handled differently to not overload
and LDAP server. Can you open an issue on github for this?

bye,
Sumit
> So you use initgroups to find out about all the groups a user is a member of, and in doing that you find out about all those groups, which means you need to populate the group members of all those groups.  Bleurgh!  This is what leads to the performance fun.
>
> Say I'm restricting access to a service on the basis of group membership.  I can either ask "Which groups is this user a member of?", then check that the group I want is there, or I can ask "Who is a member of this group?".  The former means full group enumeration of every group a user is a member of, whereas the latter involves just a single group, but it's not all positive.
>
> Using the ignore_group_members option in SSSD works around this and makes things much faster, but there is a downside.  If I go the latter route, and we've used ignore_group_members, then when I query a group, it tells me that nobody is a member of it.
>
> So "What groups is Sally a member of? People".  "Who is a member of People? Nobody".  That then can cause you some grief with ignore_group_members.  In the past I know newgrp would fail to work properly with this configuration.
>
> But to be honest, these niggles are in my experience few and far between.  With a large LDAP setup, ignore_group_members is an essential performance boost.
>
> John
>
> --
> John Hodrien (he/him)
> Principal Teaching and Research Support Specialist, School of Computer Science
> 2.22 Bragg Building, University of Leeds
> ________________________________
> From: Christopher Paul via sssd-users 
> Sent: 23 July 2025 00:52
> To: [e-mail] 
> Cc: Christopher Paul 
> Subject: [SSSD-users]Re: SSSD with rfc2307bis causes thousands of concurrent LDAP queries, triggering OpenLDAP flow control
>
> CAUTION: External Message. Use caution opening links and attachments.
>
> On 7/22/25 16:48, Christopher Paul via sssd-users wrote:
>
> On 7/22/25 14:53, John Hodrien wrote:
> [...]
>
> That's my understanding anyway, but I'm not an expert.
>
> You're probably right, but it would be nice if SSSD could retrieve groups for a user but not look up all the members attribute values for all the other members of each group to which one user belongs.
>
> I notice that with "ignore_group_members = true", that the "groups <uid>" command still works.
>
> Oh blast it. Actually with "ignore_group_members = true", "id <uid>" also works, and it does not look up all the members attribute values for all the other members of each group to which one user belongs. So this feature does exist and it's called "ignore_group_members = true".
>
> But I guess it would be nice if "getent group <group name>" worked to list all members without looking up their user values. I see no reason why a group lookup should cause all members' attribute values to be looked up.
>
> Chris
> --
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.fedor...https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffedoraproj...https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.fedo...https://lists.fedorahosted.org/archives/list/[e-mail]
> Do not reply to spam, report it: https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpagure.io%...https://pagure.io/fedora-infrastructure/new_issue

[Christopher Paul]

On 7/23/2025 2:44 AM, Sumit Bose wrote:
> Btw, I think the original question was not about the large number of
> requests in general but that SSSD is sending those in parallel (sending
> the next request before a reply for the previous was received). This is
> indeed unexpected and comes most probably from
> `sdap_process_group_members_2307bis()`
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_SSSD_sssd_bl...
> As you can see there is a loop which calls
> `sdap_process_missing_member_2307bis()` for every group missing in the
> cache which sends an asynchronous LDAP search without waiting for a
> reply. This should most probably be handled differently to not overload
> and LDAP server. Can you open an issue on github for this?
>
> bye,
> Sumit

Hi Sumit,

Yes, and thank you. That is my concern. I have submitted 
https://github.com/SSSD/sssd/issues/8047. I have added to the problem 
report a suggestion to consider: "Instead of sending many hundreds or 
thousands of individual lookups for each user, why not send batched 
queries using OR filters for groups of users. There must be a sweet spot 
of batch size to reduce the number of round trips but also not exceed 
MTU or other limitations." I'm not sure that's possible or not in this 
situation, but it seems like it may be more efficient if possible.

Many thanks,

[Gregory Carter]

https://unofficialaciguide.com/2019/07/31/ldap-schemas-for-aci-administrator...
"In the RFC2307 compatibility layer, we have no memberOf or anything
similar to use for identifying group membership. But we do have the
“uid=ldapy” attribute. If we wanted to set ACI policy based on this
information, we would have to authenticate the user, grab the UID
attribute, then compare it to a specific group’s list of memberUIDs (or
search through all groups to find which one has the correct memberUID)."

Ironically, perhaps this is something SambaAD compensates for, which I
defined as RFC2307 for our schema, but I see memberOf definitions in my
users anyway so the above scenario may not apply.

So what is your directory server and if you could check your schema
definition and see if there are any memberOf definitions?  Or is it a
straight uid?

On Mon, Jul 21, 2025 at 5:35 PM Christopher Paul via sssd-users <
[e-mail]> wrote:
> Hello sssd-users,
>
> I'm experiencing severe performance degradation with SSSD when using
> ldap_schema=rfc2307bis. User lookups with "id" can take several seconds,
> and I believe that I have identified the root cause.
>
> ## Symptoms:
> SSSD logs: "LDAP operation ... seems slow, took more than 80% of timeout"
> OpenLDAP logs: "deferring operation: pending operations"
> Simple "id username" commands taking 5-10+ seconds (when not cached)
>
> ## Root Cause:
> When looking up a single user, SSSD appears to be sending individual LDAP
> queries for EVERY member of EVERY group the user belongs to. This results
> in thousands of near-simultaneous asynchronous LDAP searches.
>
> OpenLDAP's conn_max_pending/conn_max_pending_auth parameters are correctly
> throttling these requests, causing the perceived slowness.
>
> ## Environment:
> SSSD version: 2.9.6
> OpenLDAP version: 2.5.20
>
> ## Questions:
> Why does SSSD need to resolve all group members when looking up a
>
> single user? This should be unnecessary to id a single user.
> 2. Can SSSD be configured to return just the group names/GIDs for a user
> lookup without also fetching full details of every member in those groups?
> 3. Could SSSD batch these queries or use more efficient LDAP operations?
>
> I've attached my sssd.conf. The key setting is ldap_schema=rfc2307bis.
>
> This behavior effectively makes rfc2307bis unusable in environments with
> large groups. Any guidance would be appreciated.
>
> Many thanks,
>
> --
> Chris Paul | Rex Consulting | https://www.rexconsulting.net
>
> --
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Christopher Paul]

On 7/22/25 16:00, Gregory Carter via sssd-users wrote:
> https://unofficialaciguide.com/2019/07/31/ldap-schemas-for-aci-administrator... 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__unofficialaciguide.com_2019_07_31_ldap-2Dschemas-2Dfor-2Daci-2Dadministrators-2Drfc2307-2Dvs-2Drfc2307bis_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=kNfe78trlDa8qcpE6Krv-hqja3H7VlB9J4LBxzcpgL8&m=fghJVQYUm5Bpopzx-I3fjRWs7UzLCKrjRZjZsy8HplPDfN9gXM_f4F5y4lKS3YqG&s=_OVo7RDoglen8Nxd4pOic8TRxtAaB9p23oo1ojGMHY8&e=
> "In the RFC2307 compatibility layer, we have no memberOf or anything 
> similar to use for identifying group membership. But we do have the 
> “uid=ldapy” attribute. If we wanted to set ACI policy based on this 
> information, we would have to authenticate the user, grab the UID 
> attribute, then compare it to a specific group’s list of memberUIDs 
> (or search through all groups to find which one has the correct 
> memberUID)."
>
> Ironically, perhaps this is something SambaAD compensates for, which I 
> defined as RFC2307 for our schema, but I see memberOf definitions in 
> my users anyway so the above scenario may not apply.
>
> So what is your directory server and if you could check your schema 
> definition and see if there are any memberOf definitions?  Or is it a 
> straight uid?

OpenLDAP  2.5.20, using RFC2307bis schema, so there does exist memberOf 
values. Which brings up another very good question. Why must a 
"member=<userDN>" be used to fetch groups for RFC2307bis data when 
memberOf was specifically designed to alleviate the performance problems 
caused by "member=" lookups?

[Gregory Carter]

The RFC doesn't define how only what.

Maybe the SSSD maintainers can describe their approach to whether or not
SSSD looks for memberOf in a CN or if it automatically switches to search
mode to any groups in that CN context that it can find with a matching uid.

I suppose the White Elephant in this thread is why should we continue to
use OpenLDAP when Samba-AD is available now and it works?

On Tue, Jul 22, 2025 at 4:55 PM Christopher Paul via sssd-users <
[e-mail]> wrote:
> On 7/22/25 16:00, Gregory Carter via sssd-users wrote:
>
> https://unofficialaciguide.com/2019/07/31/ldap-schemas-for-aci-administrator...
> https://urldefense.proofpoint.com/v2/url?u=https-3A__unofficialaciguide.com_2019_07_31_ldap-2Dschemas-2Dfor-2Daci-2Dadministrators-2Drfc2307-2Dvs-2Drfc2307bis_&d=DwMFaQ&c=euGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM&r=kNfe78trlDa8qcpE6Krv-hqja3H7VlB9J4LBxzcpgL8&m=fghJVQYUm5Bpopzx-I3fjRWs7UzLCKrjRZjZsy8HplPDfN9gXM_f4F5y4lKS3YqG&s=_OVo7RDoglen8Nxd4pOic8TRxtAaB9p23oo1ojGMHY8&e=
> "In the RFC2307 compatibility layer, we have no memberOf or anything
> similar to use for identifying group membership. But we do have the
> “uid=ldapy” attribute. If we wanted to set ACI policy based on this
> information, we would have to authenticate the user, grab the UID
> attribute, then compare it to a specific group’s list of memberUIDs (or
> search through all groups to find which one has the correct memberUID)."
>
> Ironically, perhaps this is something SambaAD compensates for, which I
> defined as RFC2307 for our schema, but I see memberOf definitions in my
> users anyway so the above scenario may not apply.
>
> So what is your directory server and if you could check your schema
> definition and see if there are any memberOf definitions?  Or is it a
> straight uid?
>
> OpenLDAP  2.5.20, using RFC2307bis schema, so there does exist memberOf
> values. Which brings up another very good question. Why must a
> "member=<userDN>" be used to fetch groups for RFC2307bis data when memberOf
> was specifically designed to alleviate the performance problems caused by
> "member=" lookups?
>
> --
> Chris Paul | Rex Consulting | https://www.rexconsulting.net
>
> --
> _______________________________________________
> sssd-users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail].o...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Christopher Paul]

On 7/23/2025 10:12 PM, Gregory Carter wrote:
> The RFC doesn't define how only what.
>
> Maybe the SSSD maintainers can describe their approach to whether or 
> not SSSD looks for memberOf in a CN or if it automatically switches to 
> search mode to any groups in that CN context that it can find with a 
> matching uid.
>
> I suppose the White Elephant in this thread is why should we continue 
> to use OpenLDAP when Samba-AD is available now and it works?

Hi Gregory,

I really don't get why you would ask this question. But my answer is: 
One, OpenLDAP provides rock-solid, appliance-like reliability. Two, it 
has a proven track record for delivering excellent performance 
(~2500/searches/CPU core/second). The developer team very actively 
maintains OpenLDAP. This problem with SSSD performance has nothing to do 
with OpenLDAP, except that the rate limiting built into the product 
prevented an unintentional friendly denial of service.

I understand everyone likes and is more effective with the tools that 
they are familiar with, but wonder if there is another reason that 
you're implying people discontinue use of OpenLDAP?

And, doesn't SambaAD not use OpenLDAP under the hood for its directory 
server?

And, apologies to the list. I think we're off topic now. Does this even 
relate to the SSSD issues as discussed?

[Gregory Carter]

Maybe.  But depending on the Directory back end you pick for SSSD will
determine how much work you have to do, OpenLDAP, SAMBA-AD, FreeIPA...etc.

Don't get bent out of shape about it, its simply a comment.

On Thu, Jul 24, 2025 at 6:50 AM Christopher Paul <
[e-mail]> wrote:
> On 7/23/2025 10:12 PM, Gregory Carter wrote:
>
> The RFC doesn't define how only what.
>
> Maybe the SSSD maintainers can describe their approach to whether or not
> SSSD looks for memberOf in a CN or if it automatically switches to search
> mode to any groups in that CN context that it can find with a matching uid.
>
> I suppose the White Elephant in this thread is why should we continue to
> use OpenLDAP when Samba-AD is available now and it works?
>
> Hi Gregory,
>
> I really don't get why you would ask this question. But my answer is: One,
> OpenLDAP provides rock-solid, appliance-like reliability. Two, it has a
> proven track record for delivering excellent performance
> (~2500/searches/CPU core/second). The developer team very actively
> maintains OpenLDAP. This problem with SSSD performance has nothing to do
> with OpenLDAP, except that the rate limiting built into the product
> prevented an unintentional friendly denial of service.
>
> I understand everyone likes and is more effective with the tools that they
> are familiar with, but wonder if there is another reason that you're
> implying people discontinue use of OpenLDAP?
>
> And, doesn't SambaAD not use OpenLDAP under the hood for its directory
> server?
>
> And, apologies to the list. I think we're off topic now. Does this even
> relate to the SSSD issues as discussed?
>
> --
> Chris Paul | Rex Consulting | https://www.rexconsulting.net