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

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

On Monday 28 January 2008 21:48:43 Adam Williams wrote:
> Buchan Milne wrote:
> > 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.
> >
> >
> > 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).
> >
> >
> > In OpenLDAP 2.2 or later (IIRC), you are probably missing the .subtree
> > qualifier (to dn.subtree=), which would also have fixed your problem.
> >


> Yes I have manager's password in /etc/ldap.secret with permission 600.

Then you should check whether nss_ldap was failing to bind to the 
directory ... the file is sensitive to white space, blank lines etc.

> ok so if I set up a proxy user named proxy, that user will need an
> account in openldap like any other linux shell user?  so if I create
> proxy, my ACL would be?

This depends on what you want other DNs (e.g. real users) to be able to see. 
Since they would most likely be able to run 'getent passwd' to retrieve this 
information, I don't think it makes sense to prevent them from seeing it via 
LDAP.

So, the proxy user shouldn't need any specific ACL, since authentication does 
not rely upon being able to read any password attributes. Authentication is 
typically done with pam_ldap, which performs a bind as the DN of the user 
that is "logging in" (pam_ldap may require the proxy DN to be able to 
determine the DN of the user from their username, and nss_ldap needs to 
determine all the info for 'getent passwd user' and 'id user' with the proxy 
DN).

> access to dn.subtree="ou=People,dc=mdah,dc=state,dc=ms,dc=us"
> attrs=uid,uidNumber,gidNumber,gecos,homeDirectory,loginShell,memberUid,user
>Password,sambaLMPassword,sambaNTPassword by self write
>     by dn="uid=proxy,ou=People,dc=mdah,dc=ms,dc=us" read
>     by anonymous auth
>     by * none

There's no need to expose the passwords to the proxy DN, and I don't see much 
utility in hiding attributes that are easily visible on any of your servers. 
I also wouldn't give users write access to their uidNumber or gidNumer. So, 
something like this would be more sensible as a start:

access to attrs=userPassword,sambaLMPassword,sambaNTPassword
        by self write
        by * auth

(auth access to sambaLMPassword and sambaNTPassword does't make sense, but I 
prefer to group password attributes together rather than risk exposing them 
by mistake)

# let users write to "safe" attributes they might want to have control over

access to attrs=gecos,loginShell,....
        by self write
        by users read
        by * none

access to *
        by users read
        by * none

Although I typically have more complex ones that provide for a group of 
replicator DNs, and a group for samba Domain Controllers which have access to 
create accounts. You may want to look at the design Mandriva uses: 
http://wiki.mandriva.com/en/Projects/OpenLDAP_DIT

> and of course, uid=proxy,ou=People,dc=mdah,dc=ms,dc=us becomes by binddn
> and its bindpw in /etc/ldap.conf

Yes, and then remove rootbinddn and empty /etc/ldap.secret, unless you have a 
very specific reason to use it.

Regards,
Buchan