On Tuesday 04 March 2008 12:45:18 Guennadi Liakhovetski wrote:
Hi all
I'm new to LDAP, and I must say it took me a LONG time to set it up under Debian etch on both server and client at all to do anything useful.
Now I can do "ldapsearch -x -v -L" type requests from remote a host and locally. I then tried switching the remote host to using LDAP for user authentication. I'd like users not registered locally to be able to login using ldap, and for locally-known users nothing should change.
I did manage to get logins to use ldap by configuring all /etc/pam.d/common-* files to first try pam_unix and then, if that fails to use ldap:
- sufficient pam_unix
- sufficient pam_ldap (should this be "required?)
where * is "account", "auth", "password" and "session". In "auth" and "password" I also had to put
- required pam_deny
after ldap, because otherwise wrong passwords were accepted. In nsswitch.conf I put
*: files ldap
for "passwd", "group", "shadow". Now I would expect that with sequences ("pam_unix" before "pam_ldap" and "files" before "ldap") indeed locally known users wouldn't be authenticated using ldap.
If it were all just about users, then yes. However, users (either local or in LDAP) can be members of groups in LDAP (or, of course local). So, any function that lists the groups a user is a member of will invoke nss_ldap.
Unfortunately, this doesn't seem to be the case. Now _all_ nss / pam requests go to the LDAP server. Including calls from udevd, avahi-daemon, and others, which causes them to fail in various ways.
If you just want to prevent this from delaying bootup, the solution here may just be to add:
bind_policy soft
to nss_ldap's ldap.conf (/etc/libnss_ldap.conf on Debian I think).
Regards, Buchan