'''Edit:'''
Forgot to mention that I had to make the file ''/etc/default/useradd'' world-readable. Otherwise, I would get:

{{{
Error initializing libuser: could not open configuration file `/etc/default/useradd': Permission denied.
}}}

'''Update''': Originally, I added the LDAP user to the database using an LDIF file similar to:

{{{
dn: cn=LDAP User,ou=Users,o=Group
ou: Users
o: Group
cn: LDAP User
uid: ldapuser
}}}

And to reiterate the problem, I could then log into a machine set up as an LDAP client as ''ldapuser'', but I could not run the ''lchfn'' program (because behind the scenes I was not authenticating as ''cn=...'' but rather as ''uid=...'' which did not work).

I decided to try changing how my LDAP user is added, so I deleted the user, and added him again, using an LDIF file similar to:

{{{
dn: uid=ldapuser,ou=Users,o=Group
ou: Users
o: Group
cn: ldapuser
uid: ldapuser
}}}

I could then log in as ''ldapuser'' AND run the ''lchfn'' program successfully. So now I wonder, isn't there a way for the cn to be equated to the uid, in the database, for running commands like ''lchfn''? I thought that indexing the uid in ''slapd.conf'' would do this for me, but maybe I don't have the syntax right:

{{{

Indices to maintain

index objectClass,uidNumber,gidNumber eq
index cn,uid,displayname,sn,st eq,pres,sub
}}}

Thanks for the update, I haven't noticed the cn/uid mismatch in the original report.

Ordinarily, it doesn't matter which attribute is used in the DN because libuser performs a search to determine the exact DN. When connecting to the LDAP server, however, the exact DN must be known because a search is not possible until a connection is successfully established.

libuser.conf.5 documents the exact form of the DN used by default as uid=//user//,//userBranch//,//basedn// ; this matches the suggestion in RFC 2307 section 5.3. I don't think it makes sense to add more automatically used values, and cn is particularly a bad match because it usually contains user's real name, not the login name known to system (and a real name is much more likely to be ambiguous).

As for treating two different attributes as equal, I don't think search indexes can be used for that - indexes are only used to make the search more efficient, not to change its semantics. Generally speaking, such a feature has semantic problems (what if there are two different objects, one with DN uid=ldapuser,..., the other with DN cn=ldapuser,... ?).

Perhaps server-specific plugins, if supported, could be used to modify the search semantics in the desired way, however that's not my area of expertise.

If it is still possible, changing the LDAP naming convention would probably be the simplest solution. An alternative option is to write a script that prepares an appropriate user-specific libuser.conf file and invokes lchfn with $LIBUSER_CONF pointing to the user-specific configuration file, and instructing users to use this script instead of directly using lchfn.

Replying to [comment:4 mitr]:

Thanks for the update, I haven't noticed the cn/uid mismatch in the original report.

Ordinarily, it doesn't matter which attribute is used in the DN because libuser performs a search to determine the exact DN. When connecting to the LDAP server, however, the exact DN must be known because a search is not possible until a connection is successfully established.

libuser.conf.5 documents the exact form of the DN used by default as uid=//user//,//userBranch//,//basedn// ; this matches the suggestion in RFC 2307 section 5.3. I don't think it makes sense to add more automatically used values, and cn is particularly a bad match because it usually contains user's real name, not the login name known to system (and a real name is much more likely to be ambiguous).

As for treating two different attributes as equal, I don't think search indexes can be used for that - indexes are only used to make the search more efficient, not to change its semantics. Generally speaking, such a feature has semantic problems (what if there are two different objects, one with DN uid=ldapuser,..., the other with DN cn=ldapuser,... ?).

Perhaps server-specific plugins, if supported, could be used to modify the search semantics in the desired way, however that's not my area of expertise.

If it is still possible, changing the LDAP naming convention would probably be the simplest solution. An alternative option is to write a script that prepares an appropriate user-specific libuser.conf file and invokes lchfn with $LIBUSER_CONF pointing to the user-specific configuration file, and instructing users to use this script instead of directly using lchfn.

Thanks for the explanation. That helps a bit. Yes, changing the way I insert the users is perfectly acceptable. I had also thought about using the LIBUSER_CONF variable, if push came to shove.