On 11/11/11 12:48 +0100, Raffael Sahli wrote:
Hi,
I'm so confused with the sasl passthrough implementation.
I set for the user test in my ldap tree the password {SASL}test@MY_REALM
Keytab: [test@ldap-master001 /]#--> ls /etc/krb5.keytab -l
-rw-r----- 1 root openldap 1078 2011-11-11 11:56 /etc/krb5.keytab
Happy 11-11-11 day.
SASL GSSAPI Auth: works well
[test@ldap-master001 /]#--> ldapwhoami
SASL/GSSAPI authentication started
SASL username: test@MY_REALM SASL SSF: 56
SASL data security layer installed.
dn:uid=test,cn=mycomany.net,cn=gssapi,cn=auth
SASL SLAPD Config: [root@ldap-master001 /]#---> cat /usr/lib/sasl2/slapd.conf
pwcheck_method: saslauthd
saslauthd_path: /var/run/saslauthd/mux
keytab: /etc/krb5.keytab
testsaslauthd works well: [root@ldap-master001 /]#---> testsaslauthd -u test -p MYPASSWORD -r MY_REALM -s ldap
0: OK "Success."
sasl debug log: saslauthd[26077] :do_auth : auth success: [user=test] [service=ldap] [realm=MY_REALM] [mech=kerberos5]
saslauthd[26077] :do_request : response: OK
But the ldapsearch simplebind command takes 7-10s...
[test@ldap-master001 /]#--> ldapsearch -D uid=test,ou=users,dc=my,dc=company -w MYPASSWORD -s base -b '' -x ldap_bind: Invalid credentials (49)
And the sasl debug log shows:
saslauthd[26076] :do_auth : auth failure: [user=test] [service=ldap] [realm=MY_REALM] [mech=kerberos5] [reason=saslauthd internal error]
For a more apples to apples comparison, try running testsaslauthd as the same user that your slapd process is running under. I can't see how this would be a permissions problem though.
Try running saslauthd in debug mode to see if you get any additional errors.
Do you see anything useful in your kdc logs?