Support for rfc2307bis should also read the memberUid attribute. #1487
Labels
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/445
One of the things the nss_ldap module does when examining groups in its 2307bis mode is to resolve both members by DN (the 'uniqueMember' attribute or its mapped equivalent) and by simple name (the 'memberUid' attribute or its mapped equivalent). This suggests that there are servers on which group membership is expressed as a mixture of user names and DNs (presumably, of the entries for other groups). I'd like for sssd to handle these cases, too.
In the longer-term, I'd love to not have to tell sssd which schema to use, and to instead have sssd just assume that I'm not being absolutely inconsistent in how I manage groups and such in my directory server.
Comments
Comment from dpal at 2010-04-06 15:03:12
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.3
Comment from dpal at 2010-04-13 15:20:19
Fields changed
doc: 0 => 1
Comment from dpal at 2010-07-20 15:05:40
Fields changed
milestone: SSSD 1.5.0 => SSSD 1.6.0
Comment from dpal at 2011-02-07 14:27:34
Fields changed
coverity: =>
milestone: SSSD 1.6.0 => SSSD 1.7.0
upgrade: => 0
Comment from dpal at 2011-07-22 21:54:34
Fields changed
milestone: SSSD 1.8.0 => SSSD 1.9.0
patch: => 0
Comment from dpal at 2012-01-16 16:33:29
Fields changed
blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Deferred
rhbz: =>
Comment from dpal at 2012-01-19 03:18:37
Fields changed
rhbz: => 0
Comment from rabbitt at 2014-09-01 04:51:08
Is this still something planned for in the near or long-term? My company definitely makes use of a mixed-mode 2307bis, using memberUid+member for *nix clients and member for AD clients - so having this "hybrid" functionality would be great.
P.s. If someone wanted to give me some pointers on touch points and areas of the code I should look at, I could maybe try my hand at whipping up a patch.
changelog: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
review: => 0
selected: =>
Comment from dpal at 2014-09-01 07:41:01
It is currently not planned for any specific milestone and waiting for someone to pick it up so you are welcome to give it a try. As for the specific code areas I will leave it to others to provide the pointers.
Comment from jhrozek at 2014-09-01 08:29:24
Replying to [comment:8 rabbitt]:
Off the top of my head...I would add a new option to src/providers/ldap/ldap_opts.h, to rfc2307bis_group_map, that enables the mixed mode. Maybe something like
ldap_rfc2307bis_flat_memberthat would default to memberUid. This option would be NULL by default.Then you'd need to amend the group lookup and initgroups. RFC2307bis group lookups are implemented in src/providers/ldap/sdap_async_nested_groups.c. When this option is set, the group lookup should automagically fetch the attribute value. From then on, it should be only about modifying the
sdap_nested_group_process_sendrequest so that all memberUid values are treated as users and not nested groups.The initgroups code is located in
src/providers/ldap/sdap_async_initgroups.c. The request to modify would besdap_initgr_rfc2307bis_send. The base_filter should be amended to OR a member=$user_dn with memberUid=$username if the new option is enabled.I don't think this option should be honored in the AD or IPA schemas.
If you're interested in submitting a patch, you can check out the [Internals documentation] and the https://fedorahosted.org/sssd/wiki/DevelTutorials devel tutorials
Comment from peterkirby at 2016-07-13 23:14:33
Is anyone currently working on this ticket? Or is there now a different way to do this?
My goal is to be able to list local system users in an ldap group (via memberuid attribute) as well as ldap user DNs (via member attribute). My understanding is, this is the way to do that. If that's not the case, I'd appreciate it someone could point me in the right direction.
If this is stil the way to do that, I'd be willing to try my hand at a patch. But, I don't want to reproduce work someone else is already doing.
Thank you.
mark: => 0
sensitive: => 0
Comment from dpal at 2016-07-14 03:35:15
Replying to [comment:11 peterkirby]:
I think this ticket is a dup of #1020 at least based on what you describe you are looking for #1020 and it is implemented since 1.9.
Comment from jhrozek at 2016-07-14 10:53:18
No, this one is different. What #1020 implemented was that memberUid can reference a local (/etc/passwd) user. What this ticket asks for is that a group can contain both username in memberUid and DN in member.
And no, nobody is working on this ticket. Feel free to send a patch or ask on sssd-devel for assistance.
Comment from nalin at 2017-02-24 14:33:32
Metadata Update from @nalin:
Comment from jhrozek at 2019-07-04 14:19:48
Metadata Update from @jhrozek:
Comment from jhrozek at 2019-07-04 14:19:48
Issue linked to Bugzilla: Bug 1727082
Comment from jhrozek at 2019-07-04 14:19:54
Metadata Update from @jhrozek:
Comment from jhrozek at 2019-07-04 14:19:54
Issue linked to Bugzilla: Bug 1727082
Comment from pbrezina at 2020-03-24 14:23:16
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:23:17
Metadata Update from @pbrezina:
The text was updated successfully, but these errors were encountered: