nss_ldap and OpenLDAP client version

Joe Shevland jshevland at rowantreesoftware.com.au
Tue Jun 13 09:06:18 UTC 2006

Ansar Mohammed wrote:
> One of the more "undocumented" things here is to make sure that in your
> /usr/local/etc/nss_ldap.conf to make sure that your bind_polcy is soft. 
> If not, you will have no end of problems if you ldap server goes down. 
> Basically if you have in your nsswitch.conf:
> Passwd: files ldap
> Group: files ldap
> If your ldap server is down; nss_ldap keeps trying to reconnect and allot of
> apps just hang; (like top, ls -la etc)

Luckily I haven't had the problem of OpenLDAP going down much so I 
haven't tweaked this option yet (all clients are currently on the same 
machine). The [fail=continue] switches (can't recall the exact terms) 
might alleviate that for NSS stuff? When I first read about the 
parameter my initial reaction was that 'soft' and 'hard' weren't all 
that intuitive, but maybe thats just me (fail_immediately/retry_on_fail 
or similar make more sense to me).

One area I wasn't too sure of at first is the permissions on 
/usr/local/etc/ldap.conf (and nss_ldap.conf)... because of the issues I 
was having, I figured I needed to configure the 'binddn' and 'bindpw' 
settings to get a proxy user account to bind to LDAP (I was thinking of 
Solaris' proxy account and Directory Server). But those params require 
an unhashed password in the file, so I tried to set it only to be 
readable by root, which doesn't work - it needs to be world-readable.

 From what I've gleaned you can do away with these settings, if the 
directory is setup to allow anonymous binds and reading of the required 
information via an anonymous bind, or otherwise you need to setup an 
account with very limited read-only privileges on the required entries. 
One thing I'm still not clear on with the pam_ldap interaction (not so 
much the name service switch stuff) - a limited user to read 
username/group name/hostname information etc is fine for NSS, but what 
about authentication attempts? I'm guessing pam_ldap doesn't use the 
'binddn' proxy to compare the hashed passwords, or otherwise you'd be 
stuck in a situation where you have to have a world readable 
account/password, and that account can read all password information. 
I'll up the debugging on slapd and try it for myself, but I think when I 
last checked it wasn't using the 'rootbinddn' account I'd supplied for 
authentication attempts (might've been trying to bind anonymously and 
then as the user's DN directly with the supplied credentials, can't 
recall, though the latter would make sense to me).


More information about the freebsd-questions mailing list