Re: [nssldap] nss_ldap on SLES 10

[Iain Morgan <imorgan [at] nas.nasa.gov>]

Sometime ago, Ralf Haferkamp wrote:
> On Monday 29 January 2007 20:43, Iain Morgan wrote:
> > Hello,
> >
> > On SLES 9 (nscd 2.3.5, nss_ldap 215) it seems that it is sufficient to
> > set rootbinddn in /etc/ldap.conf to get reasonable behaviour. However,
> > on SLES 10 (nscd 2.4, nss_ldap 246) it appears to be necessary to set
> > binddn/bindpw instead.
> What do you mean by "reasonable behaviour". Please describe.
> 

By that I mean that with the group, passwd, and shadow entries in
/etc/nsswitch.conf set to query LDAP, the following things occur:

        - 'getent passwd <ldapaccount>' returns an entry when run by an
          unprivileged user.
        - Similar as above for 'getent group <ldapgroup>'
        - 'getent shadow <ldapaccount>' only returns a result when run as root
        - 'ls -l' on a file oned by an user with an account in LDAP
          returns the symbolic name for the owner and group associated
          with the file even when run as an unprivileged user.

> > With only rootbinddn set on SLES 10, commands such as 'getent shadow'
> > work when run as root, but 'getent passwd' does not - regardless of
> > whether it is run as root or not.
> Does "id <username>" work?

No. It works for local accounts, but not for LDAP accounts.

> You also might wanna check the LDAP Server logs. Probably you can see as what 
> user (rootbinddn/binddn/anonymous) nss_ldap is trying to authenticate against 
> the LDAP server.

Yeah, I forgot to include that in my original post. With SLES 10, it is
attempting to bind anonymously. The only exception to this is when I run
'getent shadow' as root. In that case it uses rootbinddn.

> 
> > Whereas the same configuration under 
> > SLES 9 works as you would expect for both 'getent shadow' and 'getent
> > passwd'.
> >
> > I'm assuming the issue is that nscd 2.4 drops privileges for all queries
> > except getsp*().
> Did you configure to run as a separate user?q If not, I think it does not 
> drop 
> privileges anywhere. But I must admit that my nscd-knowledge is pretty 
> limited.

No. The daemon itself appears to be running as root, at least according
to ps. But since rootbinddn is being ignored for most queries I'm
assuming that nscd or nss_ldap is dropping privileges. And I haven't
seen any indication of that in the nss_ldap code.

> 
> Additionally note that neither "getent passwd" (without any user name 
> supplied) nor "getent shadow" and the getsp*() calls make use of nscd.

They appear to under SLES 9. I should also note that I was abbreviating
when I referred to 'getent passwd' and 'getent shadow' in my original
post. I was implicitly meaning 'getent passwd <username>' and 'getent
shadow <username>'.

> 
> > Has anyone else observed this and is there an 
> > (secure) alternative to having to set both rootbinddn and binddn?
> 
> -- 
> Ralf Haferkamp
> SUSE LINUX Products GmbH, Maxfeldstrasse 5, D-90409 Nuernberg
> T: +49-911-74053-0
> F: +49-911-74053575 - Ralf.Haferkamp@suse.com
> 


--
Iain Morgan