Re: [nssldap] id: cannot find name for user ID #

[Buchan Milne <bgmilne [at] mandriva.org>]

On Friday 25 January 2008 16:23:46 Adam Williams wrote:
> I'm trying to set up nss_ldap to work with my openldap 2.3.39
> installation on Fedora 8.  When I su -l adamtest (an account in
> openldap), I get the following error:
>
> [root@roark etc]# su -l adamtest
> id: cannot find name for user ID 773
> [I have no name!@roark ~]$ id
> uid=773 gid=100(users) groups=100(users)
>
>
> and I think its something with the nss_ldap id resolution, because here
> is the id command from me in /etc/passwd, notice the uid=511(awilliam)
> is shown correctly here versus adamtest in openldap.

Well, it seems non-root processes have no problem, but processes running as 
root do ...

[...]

> and my /etc/ldap.conf is:
[...]
> binddn cn=Manager,dc=mdah,dc=state,dc=ms,dc=us
> bindpw xxxxxxxx
> rootbinddn cn=Manager,dc=mdah,dc=state,dc=ms,dc=us

So, you have two DNs, and one password. Where is the other password? It needs 
to go in /etc/ldap.secret (yes, in the clear, but the permissions can be 
stricter than /etc/ldap.conf). The rootbinddn, if present, is used, in 
conjunction with the password from /etc/ldap.secret, when nss_ldap is invoked 
by a process running as root.

This is covered in the nss_ldap man page.

[...]
> and my slapd.conf is:

> database        bdb
> suffix          "dc=mdah,dc=state,dc=ms,dc=us"
> rootdn          "cn=Manager,dc=mdah,dc=state,dc=ms,dc=us"

Right, bad idea to use your rootdn in a world-readable config file. You may 
want to consider creating a dedicated DN (commonly referred to as a proxy 
DN), or use a method to provide each server with individual access to the 
LDAP server (e.g. SASL-GSSAPI - Kerberos) sufficient to search/list users.

It is not necessary to expose the majority of your directory contents (unless 
you want to save the most effort at the greatest risk and avoid using a 
binddn at all).

> rootpw          {SSHA}xxxxxxxxxxxxxxxxxxxxxxxxx


[...]

> access to dn="ou=People,dc=mdah,dc=state,dc=ms,dc=us"
>                     by self write
>                     by users auth
>                     by anonymous read

In OpenLDAP 2.2 or later (IIRC), you are probably missing the .subtree 
qualifier (to dn.subtree=), which would also have fixed your problem.

Regards,
Buchan