LDAP Users are not used

Hy!

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:

  1. getent passwd shows the correct data:
    …local users…]
    +::0:0:::
    mtausig:x:10000:100:Mathias:/home/mtausig:/bin/bash
  2. 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.

cheers
Mathias

I think that line

+::0:0:::

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.

I assume that yast put it there.
BUt it didn’t matter. I removed the coresponding line from /etc/passwd, but the problem remains the same.

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.

Tried it, same problems.

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.

/etc/nsswitch.conf:


passwd: files ldap
group:  files ldap
hosts:  files dns
networks:       files dns
services:       files ldap
protocols:      files
rpc:    files
ethers: files
netmasks:       files
netgroup:       files ldap
publickey:      files
bootparams:     files
automount:      files #nis
aliases:        files ldap
passwd_compat:  files ldap
group_compat:   files ldap

But if the problem would be here, getent wouldn’t show the users.

/etc/pam.d/common-auth just usese pam_unix2

auth    required        pam_env.so
auth    required        pam_unix2.so

whose configuration file /etc/security/pam_unix2.conf contains

auth:           use_ldap  debug
account:        use_ldap debug
password:       use_ldap md5 debug
session:        none debug

But I have tried with a direct reference to pam_ldap in common-auth as well, but to no avail.

In the “User authentication sources” of the yast user management LDAP is enabled while nis, smb and kerberos are not.

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.

Maybe you’re using the wrong encryption method? If this has worked before, maybe ask your sysadmin what changed at the other end?

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.