1. group lookups are inaccurate for groups with > 1500 members.  Once that condition hits, is it inaccurate for all memberships of all groups, or only the specific groups with > 1500 members?

2. Are you using tokengroups?  Or does this happen whether or not you use tokengroups?

(Disabling enumeration sounds quite painful; so useful for troubleshooting membership problems.)


On Mon, Sep 7, 2020 at 11:57 AM R Davies <> wrote:

When enumeration is enabled (required due to legacy application), and where a group has > 1500 members, and AD's MaxValRange is at the default 1500, then sssd fails to show more than 1500 group members.  Group lookups are no longer accurate.

A further interesting aspect is that if the sssd cache is expired (sssctl cache-expiry -E), then the correct group membership is shown until such time as enumeration is processed again (i.e. at most ldap_enumeration_refresh_timeout + memcache_timeout)

src/providers/ldap/sdap.c's sdap_parse_entry() states:

/* This attribute contained range values and needs more to
* be retrieved
/* TODO: return the set of attributes that need additional retrieval
* For now, we'll continue below and treat it as regular values.

As enumeration is enabled the subsequent ASQ/deref work is never undertaken.  As such sssd only ever processes the initial range retrieved members (0-1499) (NB that nested groups members are evaluated).

We have looked at the relevant source code, but can't find a way to trigger Attribute Scope Queries (ASQ)/deref.  Indeed, no manner of sssd configuration settings (other than disabling enumeration - which we sadly cannot do) appears to change this behaviour.  Increasing MaxValRange on AD defeats the purpose of having MaxValRange.

Has anyone run into this before?  Or, should I raise a new issue?

Many Thanks.


sssd-users mailing list --
To unsubscribe send an email to
Fedora Code of Conduct:
List Guidelines:
List Archives: