#959 Provide a new option for different ways of dealing with multi-valued names not matching RDN
Closed: wontfix 3 years ago by pbrezina. Opened 12 years ago by jhrozek.

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)


Are there any suggestions how to handle this differently? For example the longest name or some kind of regular expression?

owner: somebody => jzeleny

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.

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.

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.

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.8.0

This is out of the scope of the 1.8 release.

milestone: SSSD 1.8.0 => SSSD 1.9.0

"Nice to have" for 1.9.

blockedby: =>
blocking: =>

Fields changed

feature_milestone: =>
milestone: SSSD 1.9.0 => SSSD Deferred

Fields changed

changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
mark: => 0
review: => 1
selected: =>
sensitive: => 0

Fields changed

review: 1 => 0

Metadata Update from @jhrozek:
- Issue assigned to jzeleny
- Issue set to the milestone: SSSD Patches welcome

7 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/2001

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