#445 Support for rfc2307bis should also read the memberUid attribute.
Closed: wontfix 3 years ago by pbrezina. Opened 13 years ago by nalin.

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.


Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.3

Fields changed

doc: 0 => 1

Fields changed

milestone: SSSD 1.5.0 => SSSD 1.6.0

Fields changed

coverity: =>
milestone: SSSD 1.6.0 => SSSD 1.7.0
upgrade: => 0

Fields changed

milestone: SSSD 1.8.0 => SSSD 1.9.0
patch: => 0

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Deferred
rhbz: =>

Fields changed

rhbz: => 0

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: =>

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.

Replying to [comment:8 rabbitt]:

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.

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_member that 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_send request 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 be sdap_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

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

Replying to [comment:11 peterkirby]:

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.

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.

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.

Metadata Update from @nalin:
- Issue set to the milestone: SSSD Patches welcome

7 years ago

Metadata Update from @jhrozek:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1727082 (was: 0)

4 years ago

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.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

3 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/1487

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata