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
(Disabling enumeration sounds quite painful; so useful for troubleshooting
On Mon, Sep 7, 2020 at 11:57 AM R Davies <rhodfoss(a)gmail.com> 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?
sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines