On Tue, 26 Jan 2010 16:37:37 +0100, mark wrote: > did you check if the credential cache can be accessed by nscd. E.g., if > nscd is running as nobody and /tmp/krb5cc_0 belongs to root it will not > work.
Hi Mark, Thanks for your reply! On my client system (Debian lenny), k5start creates the Kerberos credential cache (/tmp/krb5cc_0) based on the Kerberos host principal key and makes it accessible only to root. I know that libnss-ldap needs to access it, since it's mentioned in my /etc/ libnss-ldap.conf: krb5_ccname FILE:/tmp/krb5cc_0 However, nscd is also running as root, so it should be able to access it. In the mean time, I discovered the libsasl2-modules-gssapi-mit package was missing and have also added "SASL_MECH GSSAPI" to my LDAP Defaults config file (/etc/ldap/ldap.conf). My PAM config looks like this: auth sufficient pam_unix.so nullok_secure auth required pam_krb5.so use_first_pass account sufficient pam_unix.so account required pam_krb5.so password sufficient pam_unix.so nullok obscure md5 password required pam_krb5.so use_first_pass session required pam_unix.so session required pam_mkhomedir.so session optional pam_krb5.so Also, this is my current libnss-ldap.conf: base dc=example,dc=com uri ldap://ldapks1.example.com/ ldap_version 3 bind_policy soft krb5_ccname FILE:/tmp/krb5cc_0 Incidentally, the default for krb5_ccname is "/etc/.ldapcache" -- any idea what that's supposed to be about? ... Well, it looks like I'm in luck today, because I've just solved my own problem! These lines in my LDAP server's slapd.conf were the culprit: access to dn.children="ou=users,dc=example,dc=com" attrs=cn,uid by * auth I had added them in a desperate attempt to solve an earlier problem, but then stupidly forgot about them once that problem was solved. As soon as these lines were removed, my client was able to log in! Thanks again, Jaap ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
