Hi,
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.
R.
So
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.)
Spike
On Mon, Sep 7, 2020 at 11:57 AM R Davies rhodfoss@gmail.com wrote:
Hi,
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.
R.
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o...
On Mon, Sep 07, 2020 at 05:57:13PM +0100, R Davies wrote:
Hi,
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).
Hi,
there is a fair change that the range handling is missing in a code-path used by enumeration. Please open a ticket at https://github.com/SSSD/sssd/issues/new for further investigations.
bye, Sumit
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.
R.
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o...
Thanks.
I've raised https://github.com/SSSD/sssd/issues/5310.
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?
It only applies to groups with > 1500 (AD's MaxValRange) member attributes.
- Are you using tokengroups? Or does this happen whether or not you use
tokengroups?
ldap_use_tokengroups is enabled by default for AD. I think I disabled tokengroups in one round of testing, but it either made no difference, or broke behaviour is some other way.
On Tue, 8 Sep 2020 at 07:10, Sumit Bose sbose@redhat.com wrote:
On Mon, Sep 07, 2020 at 05:57:13PM +0100, R Davies wrote:
Hi,
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).
Hi,
there is a fair change that the range handling is missing in a code-path used by enumeration. Please open a ticket at https://github.com/SSSD/sssd/issues/new for further investigations.
bye, Sumit
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.
R.
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o... _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o...
On Tue, 8 Sep 2020 at 09:28, R Davies rhodfoss@gmail.com wrote:
I've raised https://github.com/SSSD/sssd/issues/5310.
Just wondering if anyone had a chance to look at this issue?
This has the rather annoying property of being unable to trust group membership where enumeration is enabled.
Any thoughts, or potential workarounds would be much appreciated.
Thanks.
We are also running into same issue. Do we have any work around for this issue. Please let me know, if you need any addtional data,
On Tue, 2020-10-13 at 16:28 +0000, Sanjay Agrawal wrote:
We are also running into same issue. Do we have any work around for this issue. Please let me know, if you need any addtional data,
We too :) ATM we can avoid using enumeration though.
Jocke
Hi, Just following up and there is any update on this issue. Thanks Sanjay Agrawal
On Tuesday, October 13, 2020, 12:48:13 PM EDT, Joakim Tjernlund joakim.tjernlund@infinera.com wrote:
On Tue, 2020-10-13 at 16:28 +0000, Sanjay Agrawal wrote:
We are also running into same issue. Do we have any work around for this issue. Please let me know, if you need any addtional data,
We too :) ATM we can avoid using enumeration though.
Jocke _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org 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/sssd-users@lists.fedorahosted.o...
sssd-users@lists.fedorahosted.org
-
Joakim Tjernlund -
R Davies -
Sanjay Agrawal -
Spike White -
Sumit Bose