Provide a new option for different ways of dealing with multi-valued names not matching RDN #2001
Description
Cloned from Pagure issue: https://pagure.io/SSSD/sssd/issue/959
- Created at 2011-08-12 13:25:24 by jhrozek
- Closed at 2020-03-24 14:22:20 as wontfix
- Assigned to jzeleny
- Associated bugzillas
Some arguably broken LDAP configurations use multi-valued names that don't match the RDN. We need a way to handle with such configurations.
We reduced the scope of #926 to fall back to just picking the first value. This tickets is a RFE for a new option that could be used to pick the name in a different way, perhaps by picking the alphabetically smallest (see https://fedorahosted.org/sssd/ticket/926#comment:1)
Comments
Comment from jzeleny at 2011-08-17 08:35:22
Are there any suggestions how to handle this differently? For example the longest name or some kind of regular expression?
owner: somebody => jzeleny
Comment from jhrozek at 2011-08-17 08:53:09
Replying to [comment:1 jzeleny]:
Are there any suggestions how to handle this differently? For example the longest name or some kind of regular expression?
Longest, shortest, alphabetical sort..it does not matter as long as the result is both unique and consistent.
Comment from dpal at 2011-08-17 17:40:44
Would it also make sense to have it match a value of another single-value attribute is such attribute present in the record? However you would have to have a default method for those entries that do not have such attribute.
Comment from jhrozek at 2011-08-17 18:05:08
Replying to [comment:3 dpal]:
Would it also make sense to have it match a value of another single-value attribute is such attribute present in the record? However you would have to have a default method for those entries that do not have such attribute.
That might be an option as well although the logic would probably get too complex. I was thinking the configuration directive (something like ldap_multivalue_handling?) should allow several values:
- strict - just punt when multiple names are detected and cannot be matched against RDN. This is what we have in 1.6 and would be the default.
- first - return the firt value just like nss-ldap does. This is the unsafe-but-backwards-compatible behaviour we fall back to in 1.7.
- alphabetical - what Samba does
- ...any other methods
The reason for the 'strict' default is that I still think that such directory configuration should not be considered OK. We should allow operation, but only when the admin explicitly takes an action and turns an option on.
Comment from dpal at 2011-08-18 15:03:59
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.8.0
Comment from dpal at 2011-12-10 18:58:37
This is out of the scope of the 1.8 release.
milestone: SSSD 1.8.0 => SSSD 1.9.0
Comment from dpal at 2012-01-16 16:41:30
"Nice to have" for 1.9.
blockedby: =>
blocking: =>
Comment from dpal at 2012-02-09 15:31:13
Fields changed
feature_milestone: =>
milestone: SSSD 1.9.0 => SSSD Deferred
Comment from dpal at 2012-02-10 21:59:58
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=789478
rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=789478 789478]
Comment from jhrozek at 2016-11-17 11:13:29
Fields changed
changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
mark: => 0
review: => 1
selected: =>
sensitive: => 0
Comment from jhrozek at 2016-11-17 11:13:42
Fields changed
review: 1 => 0
Comment from jhrozek at 2017-02-24 14:54:07
Metadata Update from @jhrozek:
- Issue assigned to jzeleny
- Issue set to the milestone: SSSD Patches welcome
Comment from pbrezina at 2020-03-24 14:22:19
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:22:21
Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)