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).
Cheers
Joe
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
