Re: nss_ldap and OpenLDAP client version
- From: Joe Shevland <jshevland@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 13 Jun 2006 19:05:13 +1000
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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscribe@xxxxxxxxxxx"
- References:
- RE: nss_ldap and OpenLDAP client version
- From: Ansar Mohammed
- RE: nss_ldap and OpenLDAP client version
- Prev by Date: Re: installing openoffice by package
- Next by Date: Re: FreeBSD is #1
- Previous by thread: RE: nss_ldap and OpenLDAP client version
- Next by thread: dual boot; Linux, FreeBSD
- Index(es):
Relevant Pages
|
