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
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]
WTF, why works testsaslauthd well but failed with ldap auth? The kerberos server works well in both commands.....
root@ldap-master001:/usr/local/etc/openldap# /usr/local/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.21 (Nov 10 2011 11:20:35) $ root@ldap-master001:/usr/local/src/openldap-2.4.21/servers/slapd
root@ldap-master001:/usr/local/etc/openldap# saslauthd -v saslauthd: /usr/local/lib/liblber-2.4.so.2: no version information available (required by saslauthd) saslauthd: /usr/local/lib/libldap_r-2.4.so.2: no version information available (required by saslauthd) saslauthd 2.1.23 authentication mechanisms: sasldb getpwent kerberos5 pam rimap shadow ldap
Thank you
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?
Date: Fri, 11 Nov 2011 08:41:21 -0600 From: dwhite@olp.net To: raffi.sahli@hotmail.com CC: openldap-technical@openldap.org Subject: Re: OpenLDAP SASL Passthrough
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.
Nop, same problem (or same success message ^^ ) with the slapd running user "openldap". saslauthd works with sasl user "test" running with user openldap or root, and ldapsearch with user "test" doesn't.....
Try running saslauthd in debug mode to see if you get any additional errors.
Nop, just a success message with testsaslauthd:
saslauthd[26077] :do_auth : auth success: [user=test] [service=ldap] [realm=MY_REALM] [mech=kerberos5]
saslauthd[26077] :do_request : response: OK
and with ldap simple auth an error:
saslauthd[26076] :do_auth : auth failure: [user=test] [service=ldap] [realm=MY_REALM] [mech=kerberos5] [reason=saslauthd internal error]
Do you see anything useful in your kdc logs?
Yes, but I think everything is fine... I became this message on the kdc syslog with ldapsearch (simple bind + sasl pass..)
Nov 15 11:48:03 kerberos001 krb5kdc[25110]: AS_REQ (4 etypes {18 17 16 23}) 192.168.20.54: ISSUE: authtime 1321354083, etypes {rep=18 tkt=18 ses=18}, test@REALM for krbtgt/REALM@REALM Nov 15 11:48:20 kerberos001 krb5kdc[25110]: DISPATCH: repeated (retransmitted?) request from 192.168.20.54, resending previous response
And with testsaslauthd (success), there are no no syslog entries on the kdc master..
On 15/11/11 12:00 +0100, Raffael Sahli wrote:
Date: Fri, 11 Nov 2011 08:41:21 -0600 From: dwhite@olp.net To: raffi.sahli@hotmail.com CC: openldap-technical@openldap.org Subject: Re: OpenLDAP SASL Passthrough
On 11/11/11 12:48 +0100, Raffael Sahli wrote:
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
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.
Nop, same problem (or same success message ^^ ) with the slapd running user "openldap". saslauthd works with sasl user "test" running with user openldap or root, and ldapsearch with user "test" doesn't.....
For mech=kerberos5, there are several possible reasons for 'saslauthd internal error'. Each of them should log an explanation to syslog (to auth.err). You should see one of:
auth_krb5: could not generate ccache name auth_krb5: krb5_cc_resolve auth_krb5: krb5_kt_resolve auth_krb5: NULL password or username? auth_krb5: krb5_init_context auth_krb5: krb5_parse_name auth_krb5: could not generate ticket file name auth_krb5: krb5_cc_resolve auth_krb5: krb5_cc_initialize auth_krb5: krb5_get_init_creds_password: %d auth_krb5: krb5_cc_store_cred auth_krb5: k5support_verify_tgt
Hi,
Date: Tue, 15 Nov 2011 09:57:25 -0600 From: dwhite@olp.net To: raffi.sahli@hotmail.com CC: openldap-technical@openldap.org Subject: Re: OpenLDAP SASL Passthrough
On 15/11/11 12:00 +0100, Raffael Sahli wrote:
Date: Fri, 11 Nov 2011 08:41:21 -0600 From: dwhite@olp.net To: raffi.sahli@hotmail.com CC: openldap-technical@openldap.org Subject: Re: OpenLDAP SASL Passthrough
On 11/11/11 12:48 +0100, Raffael Sahli wrote:
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
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.
Nop, same problem (or same success message ^^ ) with the slapd running user "openldap". saslauthd works with sasl user "test" running with user openldap or root, and ldapsearch with user "test" doesn't.....
For mech=kerberos5, there are several possible reasons for 'saslauthd internal error'. Each of them should log an explanation to syslog (to auth.err). You should see one of:
auth_krb5: could not generate ccache name auth_krb5: krb5_cc_resolve auth_krb5: krb5_kt_resolve auth_krb5: NULL password or username? auth_krb5: krb5_init_context auth_krb5: krb5_parse_name auth_krb5: could not generate ticket file name auth_krb5: krb5_cc_resolve auth_krb5: krb5_cc_initialize auth_krb5: krb5_get_init_creds_password: %d auth_krb5: krb5_cc_store_cred auth_krb5: k5support_verify_tgt
I'm pretty sure the problem is not kerberos!
If I try ldapsearch (This step takes 10 seconds): ldapsearch -xD uid=test,ou=users,dc=my,dc=company -W -d-1
On Kerberos: Nov 18 11:38:43 kerberos001 krb5kdc[25110]: AS_REQ (4 etypes {18 17 16 23}) 192.168.20.54: ISSUE: authtime 1321612723, etypes {rep=18 tkt=18 ses=18}, test@REALM for krbtgt/REALM@REALM
ldapsearch with a wrong password: Nov 18 11:40:29 kerberos001 krb5kdc[25110]: AS_REQ (4 etypes {18 17 16 23}) 192.168.20.54: PREAUTH_FAILED: test@REALM for krbtgt/REALM@REALM, Decrypt integrity check failed
Actually the command testsaslauthd works with user test on kerberos5 mechanism so the problem can't be my MIT kerberos.
The problem is somewhere between OpenLDAP and SASLauthd....
Maybe that is the problem, but testsaslauthd works, so i'm not sure....
[root@ldap-master001 /]#---> saslauthd -v saslauthd: /usr/local/lib/liblber-2.4.so.2: no version information available (required by saslauthd) saslauthd: /usr/local/lib/libldap_r-2.4.so.2: no version information available (required by saslauthd) saslauthd 2.1.23 authentication mechanisms: sasldb getpwent kerberos5 pam rimap shadow ldap
Or on slapd start up (auth.log), but I think that isn't the problem... Nov 18 11:33:33 ldap-master001 slapd[12562]: auxpropfunc error invalid parameter supplied Nov 18 11:33:33 ldap-master001 slapd[12562]: _sasl_plugin_load failed on sasl_auxprop_plug_init for plugin: ldapdb
If I change the sasl mechanism to pam (PAM with pam_krb5) results with the same f.. problem. testsaslauthd works but ldap* with simplebind failed.
[root@ldap-master001 /]#---> cat /usr/lib/sasl2/slapd.conf pwcheck_method: saslauthd mech_list: plain login gssapi external #auto_transition: yes #log_level: 7 #auxprop_plugin: slapd #mech_list: plain #kerberos5 gssapi #pwcheck_method: saslauthd #saslauthd_path: /var/run/saslauthd/mux #keytab: /etc/krb5.keytab #_list: digest-md5 external gssapi
Thanks
On 18/11/11 12:03, Raffael Sahli wrote:
I'm pretty sure the problem is not kerberos!
Hi,
I just had virtually the same problem with virtually the same error messages and symptoms on an authentication server based on MIT Kerberos, OpenLDAP and SASL. I was banging my head against the wall because everything was configured exactly right, identical to two other systems I set up recently that work just fine.
Keytab entries were correct, DNS resolution worked forwards and reverse, permissions and group memberships were correct as well, testsaslauth never complained, etc. There was no reason for SASL pass-through not to work.
Turns out the problem was DNS-related after all. When creating the realm, various internal principals are added, one of those is (or should be) "kadmin/auth01.example.com@REALM" (auth01.example.com being the FQDN of the Kerberos server). For some reason--probably a rogue entry in /etc/hosts--this principal was created as "kadmin/auth01@REALM", i.e. containing only the hostname, not the FQDN. Took me a whole week to figure that out.
You might want to check your Kerberos principal names and see if you might have ran into a similar problem.
HTH
Andreas
Hi,
Thanks for you input, but the kadmin princ wasn't the problem. The kadmin entry is correct.
Date: Fri, 18 Nov 2011 15:27:04 +0100 From: daff@pseudoterminal.org To: raffi.sahli@hotmail.com Subject: Re: OpenLDAP SASL Passthrough CC: openldap-technical@openldap.org
On 18/11/11 12:03, Raffael Sahli wrote:
I'm pretty sure the problem is not kerberos!
Hi,
I just had virtually the same problem with virtually the same error messages and symptoms on an authentication server based on MIT Kerberos, OpenLDAP and SASL. I was banging my head against the wall because everything was configured exactly right, identical to two other systems I set up recently that work just fine.
Keytab entries were correct, DNS resolution worked forwards and reverse, permissions and group memberships were correct as well, testsaslauth never complained, etc. There was no reason for SASL pass-through not to work.
Turns out the problem was DNS-related after all. When creating the realm, various internal principals are added, one of those is (or should be) "kadmin/auth01.example.com@REALM" (auth01.example.com being the FQDN of the Kerberos server). For some reason--probably a rogue entry in /etc/hosts--this principal was created as "kadmin/auth01@REALM", i.e. containing only the hostname, not the FQDN. Took me a whole week to figure that out.
You might want to check your Kerberos principal names and see if you might have ran into a similar problem.
HTH
Andreas
openldap-technical@openldap.org
-
Andreas Ntaflos -
Dan White -
Raffael Sahli