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. 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.
What am I doing wrong?
I know SASL is not configured in my setup, but that shouldn't be a problem? At least not for the cases when LDAP shouldn't be attempted at all.
Thanks Guennadi --- Guennadi Liakhovetski
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
On Wed, 5 Mar 2008, Buchan Milne wrote:
On Tuesday 04 March 2008 12:45:18 Guennadi Liakhovetski wrote:
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).
So far my main problem is not delays in the bootup but failing services. like avahi-daemon, NetworkManager, gpm, etc. Are they failing because SASL is not configured? Can I configure LDAP access grobally to not use it? I've set up TLS, so, SASL shouldn't be needed? Or how do I fix it?
Thanks Guennadi --- Guennadi Liakhovetski
On Wednesday 05 March 2008 19:54:03 Guennadi Liakhovetski wrote:
On Wed, 5 Mar 2008, Buchan Milne wrote:
On Tuesday 04 March 2008 12:45:18 Guennadi Liakhovetski wrote:
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).
So far my main problem is not delays in the bootup but failing services. like avahi-daemon, NetworkManager, gpm, etc.
I've never seen this, although my laptop has no real local user accounts (system accounts are local, but my user is not), and runs its only ldap server locally (which starts after all the usual problematic services such as udev, haldaemon etc.).
Are you running nscd ? Does nscd start before LDAP is accessible?
Do you have an error message that occurs in this case?
Are they failing because SASL is not configured?
This has nothing to do with SASL.
Regards, Buchan
On Wed, 5 Mar 2008, Buchan Milne wrote:
On Wednesday 05 March 2008 19:54:03 Guennadi Liakhovetski wrote:
So far my main problem is not delays in the bootup but failing services. like avahi-daemon, NetworkManager, gpm, etc.
I've never seen this, although my laptop has no real local user accounts (system accounts are local, but my user is not), and runs its only ldap server locally (which starts after all the usual problematic services such as udev, haldaemon etc.).
Are you running nscd ? Does nscd start before LDAP is accessible?
No, no nscd. And the LDAP server is accessible from the start.
Do you have an error message that occurs in this case?
Here are some:
avahi-daemon[2220]: dbus_bus_get(): Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. avahi-daemon[2220]: WARNING: Failed to contact D-Bus daemon. NetworkManager: <information>^IDevice 'eth0' DHCP transaction took too long (>45s), stopping it. NetworkManager: <information>^IActivation (eth0) Stage 4 of 5 (IP Configure Timeout) scheduled... NetworkManager: <information>^IActivation (eth0) Stage 4 of 5 (IP Configure Timeout) started... NetworkManager: <information>^INo DHCP reply received. Automatically obtaining IP via Zeroconf. NetworkManager: <information>^Iautoip: Sending probe #0 for IP address 169.254.240.235. NetworkManager: <information>^Iautoip: Waiting for reply... NetworkManager: <information>^Iautoip: Sending probe #1 for IP address 169.254.240.235. NetworkManager: <information>^Iautoip: Waiting for reply... NetworkManager: <information>^Iautoip: Sending probe #2 for IP address 169.254.240.235. NetworkManager: <information>^Iautoip: Waiting for reply... NetworkManager: <information>^Iautoip: Sending announce #0 for IP address 169.254.240.235. NetworkManager: <information>^Iautoip: Waiting for reply... NetworkManager: <information>^Iautoip: Sending announce #1 for IP address 169.254.240.235. NetworkManager: <information>^Iautoip: Waiting for reply... NetworkManager: <information>^Iautoip: Sending announce #2 for IP address 169.254.240.235. NetworkManager: <information>^Iautoip: Waiting for reply... NetworkManager: <information>^IActivation (eth0) Stage 5 of 5 (IP Configure Commit) scheduled... NetworkManager: <information>^IActivation (eth0) Stage 4 of 5 (IP Configure Timeout) complete.
Are they failing because SASL is not configured?
This has nothing to do with SASL.
Good to know!
How should it work? Should all those services indeed contact the LDAP server? and get replies from it? Like what - user avahi unknown or what?
Thanks for the help so far! Guennadi --- Guennadi Liakhovetski
openldap-technical@openldap.org
-
Buchan Milne -
Guennadi Liakhovetski