#926 Multi-value names for users - Does not work anymore

Created 5 years ago by slydini
Modified a month ago

Hello,

We have a big problem with sssd from version 1.5.x (RHEL 6.1 & Fedora 15) and not with version 1.2.1 (RHEL 6.0).
We can no longer use sssd (1.5.x) with our LDAP directory, it does not work.

This is due to an addition, see the mail from Stephen Gallagher:

http://www.mail-archive.com/sssd-devel@lists.fedorahosted.org/msg05524.html (Patch 0003)

When searching the primary name of a username, it works well for a DN based on the style:

dn: uid=barras, ou=users, o=epfl, c=ch

but the DN for our organization is:

dn: cn=Benjamin Barras,ou=dit-sb,ou=p-dit,ou=p,o=epfl,c=ch

and as the attribute "uid" is multi-valued:

uid: barras
uid: barras @dit-sb (this one just for administrative raison)

this version of sssd wants to find a primary name. As our RDN uses the attribute "cn", it does not match (see log) but in fact, we doesn't want to use a primary name, but only the uid that we give (in this case uid=barras).

We have approximately 12000 entries in our ldap directory and it works from many years ago.

Actually, we modify ours configurations systems for do not use SSSD but nss-pam-pam_ldap and ldapd which work well from many years.

Best regards,
Benjamin Barras

/var/log/sssd/sssd_default.log
ldap-epfl.log

The "uid" attribute that holds the user name is multivalued, so SSSD needs some mechanism to pick the right value. Currently, we try to match the "uid" value (or whatever else holds the user name) against the RDN to choose the right name. In your case, that doesn't hold as the RDN contains a different attribute.

We can't just pick the first value as some other software does, because there is no guarantee on the order of attributes returned from LDAP (although in practice the attributes /tend/ to be returned in the same order as they are stored)

I would actually suggest to treat this directory configuration as not supportable.

If we want to support this configuration, we could reuse a similar hack as Samba did at one point and deterministically pick something like "alphabetically smallest" -- see smbldap_talloc_smallest_attribute() in Samba tree. This would be still a gross hack, but at least we wouldn't get different names for the same user..

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.7.0

Fields changed

owner: somebody => jhrozek
rhbz: =>

The scope of this ticket to just picking the first value if the RDN doesn't match.

A followup ticket for another methods of fallback is https://fedorahosted.org/sssd/ticket/959

Fields changed

patch: 0 => 1
status: new => assigned

Fields changed

milestone: SSSD 1.7.0 => SSSD 1.5.13
rhbz: => 733382

Fixed by:
- 690ae38fc14acac1e62cac52558eeb263404ceca (master)
- d214d6a5c22887a6a3b503183c3306cebf6074be (sssd-1-6)
- 4c707ab2cf86ea81808962ab31ff26fd896eab1f (sssd-1-5)

resolution: => fixed
status: assigned => closed

Reopening to address
https://bugzilla.redhat.com/show_bug.cgi?id=738629 and https://bugzilla.redhat.com/show_bug.cgi?id=738621

component: SSSD => LDAP Provider
milestone: SSSD 1.5.13 => SSSD 1.5.14
resolution: fixed =>
status: closed => reopened

The two RHBZs are fixed by:

- master:
    - 920b227ac810f1a1964bbecfdc4d871a1cfd07ac
    - fd61c807554d5a3ff74f065eb0438fe2524f4ba2
    - 033d1e3985288ec827db85882b052104485606ac
    - c98298029c51fdbc727536fec7a27795184d04e4

- sssd-1-6:
    - 2f0eb4434eab740b0cdb2e33f2a2f0d3fbe143b7
    - 9afbe1b2daef7783c7843cfffa1ba248b3bd2cf2
    - 3d8dca5099e09dc56f94c8126166c6f499b7ea62
    - d3bd2ce77633d06b8a27ac3773d46763e93342a3

- sssd-1-5:
    - 9dd3285d2c9c7d0915f639e9f197b07ea4f747fe
    - 538a5b65c09165ae9b3c27f52f56e7b29249d8ba
    - ba16e3e50555bbb58e86eb2346cd81abdbab9e14
    - b21db8aeb3b8ee2148e884fa5aa65fd477181669

resolution: => fixed
status: reopened => closed

Fields changed

rhbz: 733382 => 733382,738629,738621

a month ago

Metadata Update from @slydini:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.5.14

Login to comment on this ticket.

defect

LDAP Provider

1.5.7

0

1

https://bugzilla.redhat.com/show_bug.cgi?id=733382, https://bugzilla.redhat.com/show_bug.cgi?id=738629, https://bugzilla.redhat.com/show_bug.cgi?id=738621

cancel