Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/1286
- Created at 2012-04-03 23:24:11 by sgallagh
- Closed at 2020-03-24 14:21:23 as wontfix
- Assigned to nobody
More and more, we are seeing LDAP servers using the 'uniqueMember' attribute instead of the 'member' attribute when using RFC2307bis schemas. It might be simplest on our users if we added an option {{{ldap_group_unique_member}}} defaulting to 'uniqueMember' and then processed both for group lookups.
The downside to this would be needing to perform two ASQ/DEREF searches to get {{{initgroups()}}}.
Comments
Comment from jhrozek at 2012-04-04 05:14:21
IIRC at least OpenLDAP's deref supports dereferencing multiple attributes at the same time. The only constraint is that all dereferenced attributes must be in the form of a DN. For example, you can dereference both "member" and "memberof" of a nested group with ldapsearch like this:
ldapsearch -H ldap://ldap.example.com -b 'cn=foo,ou=groups,dc=example,dc=com' -E 'deref=member:cn;memberof:cn'
Internally, ldapsearch seems to be just passing multiple dereference controls to the search function. I haven't tested Active Directory's ASQ search yet, though, but worst case we implement multiple searches (concurrent?) under the hood of the asynchronous dereference request.
Comment from dpal at 2012-04-05 15:01:43
Fields changed
milestone: NEEDS_TRIAGE => SSSD Deferred
Comment from dpal at 2012-04-05 15:02:06
Fields changed
rhbz: => todo
Comment from sgallagh at 2017-02-24 14:51:07
Metadata Update from @sgallagh:
- Issue set to the milestone: SSSD Patches welcome
Comment from pbrezina at 2020-03-24 14:21:22
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Thank you for understanding.
Comment from pbrezina at 2020-03-24 14:21:24
Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/1286
More and more, we are seeing LDAP servers using the 'uniqueMember' attribute instead of the 'member' attribute when using RFC2307bis schemas. It might be simplest on our users if we added an option {{{ldap_group_unique_member}}} defaulting to 'uniqueMember' and then processed both for group lookups.
The downside to this would be needing to perform two ASQ/DEREF searches to get {{{initgroups()}}}.
Comments
Comment from jhrozek at 2012-04-04 05:14:21
IIRC at least OpenLDAP's deref supports dereferencing multiple attributes at the same time. The only constraint is that all dereferenced attributes must be in the form of a DN. For example, you can dereference both "member" and "memberof" of a nested group with ldapsearch like this:
Internally, ldapsearch seems to be just passing multiple dereference controls to the search function. I haven't tested Active Directory's ASQ search yet, though, but worst case we implement multiple searches (concurrent?) under the hood of the asynchronous dereference request.
Comment from dpal at 2012-04-05 15:01:43
Fields changed
milestone: NEEDS_TRIAGE => SSSD Deferred
Comment from dpal at 2012-04-05 15:02:06
Fields changed
rhbz: => todo
Comment from sgallagh at 2017-02-24 14:51:07
Metadata Update from @sgallagh:
Comment from pbrezina at 2020-03-24 14:21:22
Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.
Given that we are unable to fulfill this request I am closing the issue as wontfix.
If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.
Thank you for understanding.
Comment from pbrezina at 2020-03-24 14:21:24
Metadata Update from @pbrezina: