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://firstname.lastname@example.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 @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.
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..
milestone: NEEDS_TRIAGE => SSSD 1.7.0
owner: somebody => jhrozek
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
patch: 0 => 1
status: new => assigned
milestone: SSSD 1.7.0 => SSSD 1.5.13
rhbz: => 733382
- 690ae38 (master)
- d214d6a (sssd-1-6)
- 4c707ab (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:
resolution: => fixed
status: reopened => closed
rhbz: 733382 => 733382,738629,738621
rhbz: 733382,738629,738621 => [https://bugzilla.redhat.com/show_bug.cgi?id=733382 733382], [https://bugzilla.redhat.com/show_bug.cgi?id=738629 738629], [https://bugzilla.redhat.com/show_bug.cgi?id=738621 738621]
Metadata Update from @slydini:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.5.14
to comment on this ticket.
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
Copyright © 2014-2017 Red Hat
3.10.1 — Documentation