Hello,
I’m just setting up a pc with sles 11.3 and ran into a problem with authentication over ldap:
[FONT=System]getent passwd[/FONT] works fine, it lists the users defined on the ldap-server, but when I want to su to one of them, it tells me, that the user doesn’t exist. Nothing is said in [FONT=System]/var/log/messages[/FONT]. I guess the ldap and nsswitch settings must be correct, because of the getent, so I thought maybe pam is not configured properly, but I have a similar machine with sles 11.2, where [FONT=System]/etc/pam.d/[/FONT] is configured exactly the same and everything works fine.
What I did after installation was:
Edit following files:
nss_base_passwd […] #i’m not sure, if those are needed
nss_base_shadow […]
nss_base_group […]
nss_base_hosts […]
nss_schema rfc2307
nss_map_attribute uniqueMember member
nss_connect_policy persist
nss_initgroups_ignoreusers […]
pam_password exop
pam_filter objectclass=posixAccount
pam_crypt local
binddn […]
bindpw […][/code]
[code]#/etc/openldap/ldap.conf
TLS_REQCERT allow
uri […]
base […]
scope sub
TLS_CACERT […][/code]
Then I copied the certificate, put hostname and ip of the machine in /etc/hosts and did:
zypper in nss_ldap
zypper in pam_ldap
pam-config -a --ldap
Can anybody tell me, what I forgot, or what the problem could be?
Nothing is said in [FONT=System]/var/log/messages[/FONT].
I’m a bit surprised by this - usually, “su” is rather verbose on both problems and success reports.
Can anybody tell me, what I forgot, or what the problem could be?
have you tried your tests with nscd stopped?
And just for clarification - you’re using “su” and not “sudo”, as these would use different setups?
Would running “strace su ” help you in debugging the problem? It’s quite verbose, but you might get a rough idea of what information sources are used by looking at the “open()” and “connect()” calls.
Ok, it seems to be nscd, thanks. When stopping it, su and ssh work.
I don’t know why I didn’t get this before (I grepped [FONT=System]/var/log/messages[/FONT] to make sure), but after restarting nscd I now get the entry:
#/var/log/messages
Feb 28 05:38:35 x nscd: nss-ldap: do_open: do_start_tls failed:stat=-1
Feb 28 05:38:35 x nscd: nss-ldap: do_open: do_start_tls failed:stat=-1
Feb 28 05:38:35 x nscd: nss_ldap: could not search LDAP server - Server is unavailable
[FONT=System]/etc/nscd.conf[/FONT] is the same on the working and the not working machine.
I will try and find the problem, but if you have suggestions please tell me.
Thanks again, Sven
I don’t understand why this occurs with su, but not getent - doesn’t getent use the cached results, too?
I can just disable the caching of passwd in nscd.conf and everything works and if it’s really just su, ssh (and probably other stuff, which uses the information for authentication), this probably doesn’t matter a bit…?
(google has not been very helpful, so far…[FONT=System]nscd -d[/FONT] just tells me, that it can’t find the username in the cache)
seems to be that nscd has trouble starting a trusted TLS session to the LDAP server.
I’ve had a look at the ldap.conf given in the initial post and saw that you have defined both tls_cacertdir and tls_cacertfile - I’d recommend to go for one, not both, to have predictable results.
Does running a test query via “ldapsearch -ZZ …” work from the machine in question?
[FONT=System]ldapsearch -D -b -H -W -ZZ[/FONT] works, yes. And I took the directory out of the conf-file (after testing), but it didn’t help with the su-problem.
Is there anything yast-specific I should have configured during installation? I e.g. choose, local files in the question-block, where people will be stored, because I have all conf-files from the working machines and thought, it would be easier, to just use those to configure the system…
while it doesn’t fit the picture, you might want to try to
stop nscd
move the current passwd cache db (/var/run/nscd/passwd) out of the way
restart nscd
retest
If that works, you can turn off persistent caching for passwd inside nscd - the idea behind these steps is that some old entry in the cache may be confusing the procedure.
