Bug #12240
closednss_ldap does not properly look up group members by distinguished name
100%
Description
RFC2307 / RFC2307bis allows for supplementary group members to be enumerated in LDAP using both the 'memberUid' and 'member' attributes. The 'memberUID' is a multi-valued attribute listing uids (i.e. the UNIX login values), while 'member' is a multi-valued attribute contains the LDAP distinguished names of each member. Prior to #10990, the nss_ldap code naively assumed all values of the member attribute would contain distinguished names (DNs) of the form 'uid=XXX,.....' and would merely strip off the first relatively distinguished name (RDN), and return the attribute value.
For directory servers with users that used a naming attribute other than uid (e.g. active directory almost always uses the commonName / cn attribute to name users, resulting in DNs of the form 'cn=xxxxx,.....'), listing group membership via the 'member' attribute of the group object would not work. #10990 fixed this by performing a lookup on each value of the 'member' attribute and the returning the 'uid' attribute (if present, otherwise the entry was skipped). The lookup was performed by searching all of the 'passwd' (i.e. user) base DNs using the search filter (&(objectclass=posixAccount)(distinguishedName=%s))
.
Unfortunately, many common directory servers (including openldap) do not allow you to search based on the 'distinguishedName' (or the alias 'dn') attribute, preventing group members enumerated with the 'member' attribute from being recognized by the OS (as the search will not return any entries). The generally accepted method of looking up an entry by DN is to perform an ldap search with the base DN being the DN you want and a search scope of 'base' (which should be compatible with all LDAP servers). The __ns_ldap_dn2uid
function should be modified to lookup DNs in this manner.
Files
Related issues