I run a LDAP Server on a SLES10 box which holds some user’s data. It worked great, until I had to reboot the machine yesterday. Since then, I can’t use the login data from the LDAP server anymore on that machine.
Here are the symptoms:
getent passwd shows the correct data:
…local users…]
+::0:0:::
mtausig:x:10000:100:Mathias:/home/mtausig:/bin/bash
su into a ldap account doesn’t work:
su mtausig
su: user mtausig does not exist
3) Logging into the machine with telnet doesn’t work either
The outputs from slapd look fine, but after I entered the password corectly, I get the line
login[11658]: FAILED LOGIN 2 FROM 192.168.1.78 FOR UNKNOWN, User not known to the underlying authentication module
in syslog.
4) Searching for the user and binding to it with ldapsearch works.
I can still use the LDAP server users on a remote machine, so it is obviously not a ldap issue. But it used to work on both hosts, and, to my knowledge, I didn’t change any settings before the reboot.
ought not to be there. IIRC this is Sun YP syntax meaning don’t look any further down the passwd file but take the rest of the entries from a YP database. I don’t know how you got that in there, but if you don’t use YP, you shouldn’t have it there.
You may have to restart the nscd service in case it is caching lookups. Also check these places: /etc/nsswitch.conf to make sure LDAP is specified for passwd and also /etc/pam.d/common-auth (I think, I don’t know SLE*). In fact it looks like you may have selected YP instead of LDAP as an authentication source in YaST somewhere.
Also check these places: /etc/nsswitch.conf to make sure LDAP is specified for passwd and also /etc/pam.d/common-auth (I think, I don’t know SLE*). In fact it looks like you may have selected YP instead of LDAP as an authentication source in YaST somewhere.
I think the problem is in the pam config, you’ll just have to figure out whether ldap is being called at all and whether the call is correct (add debug to the options).
Here is the syslog entries that are created during a login attempt:
==> /var/log/messages <==
Oct 17 11:41:22 ada3 login[21940]: pam_unix2(login:auth): pam_sm_authenticate() called
Oct 17 11:41:22 ada3 login[21940]: pam_unix2(login:auth): username=[ad60095910]
==> /var/log/slapd <==
Oct 17 11:41:22 ada3 slapd[19670]: conn=63 fd=14 ACCEPT from IP=127.0.0.2:55748 (IP=0.0.0.0:389)
Oct 17 11:41:22 ada3 slapd[19670]: conn=63 fd=14 closed
==> /var/log/messages <==
Oct 17 11:41:25 ada3 login[21940]: pam_unix2(login:auth): pam_ldap/pam_sm_authenticate() returned 0
Oct 17 11:41:25 ada3 login[21940]: FAILED LOGIN 1 FROM 192.168.10.78 FOR UNKNOWN, User not known to the underlying authentication module
==> /var/log/slapd <==
Oct 17 11:41:25 ada3 slapd[19670]: conn=64 fd=14 ACCEPT from IP=127.0.0.2:55750 (IP=0.0.0.0:389)
Oct 17 11:41:25 ada3 slapd[19670]: conn=64 op=1 BIND dn="" method=128
Oct 17 11:41:25 ada3 slapd[19670]: conn=64 op=1 RESULT tag=97 err=0 text=
Oct 17 11:41:25 ada3 slapd[19670]: conn=64 op=2 SRCH base="ou=Mitarbeiter,ou=argedaten,dc=argedaten-intern,dc=at" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=ad60095910))"
Oct 17 11:41:25 ada3 slapd[19670]: conn=64 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
Oct 17 11:41:25 ada3 slapd[19670]: conn=64 op=3 BIND dn="uid=ad60095910,ou=Mitarbeiter,ou=Argedaten,dc=argedaten-intern,dc=at" method=128
Oct 17 11:41:25 ada3 slapd[19670]: conn=64 op=3 BIND dn="uid=ad60095910,ou=Mitarbeiter,ou=Argedaten,dc=argedaten-intern,dc=at" mech=SIMPLE ssf=0
Oct 17 11:41:25 ada3 slapd[19670]: conn=64 op=3 RESULT tag=97 err=0 text=
Oct 17 11:41:25 ada3 slapd[19670]: conn=64 op=4 BIND anonymous mech=implicit ssf=0
Oct 17 11:41:25 ada3 slapd[19670]: conn=64 op=4 BIND dn="" method=128
Oct 17 11:41:25 ada3 slapd[19670]: conn=64 op=4 RESULT tag=97 err=0 text=
Ldap is beeing called, and produces no error (visible to me). But pam_ldap says nothing.
“stat /lib64/security/pam_ldap.so” tells me, that pam_ldap.so is accessed when I try to login.
Hey: Your second guess was almost correct. I just realized that it works, as long as I turn nscd off. If I satrt it again, I’m back to the old troubles. Which means, that this is some kind of nscd configuration problem.