Xavier Ambrosioni wrote:
Hi,
thank you for your help.
I solved my problem. The /etc/krb5.keytab file was not readable by
openLDAP daemon. Now everything is ok in local but when I tried
ldapsearch command in remote from my client (iMac running leopard
10.5.6) I get the following error:
ldap_sasl_interactive_bind_s: Invalid credentials (49)
additional info: SASL(-13): authentication failure: GSSAPI
Failure: gss_accept_sec_context
In the openldap log's file I can see:
Feb 27 18:04:20 passrlsrv slapd[9861]: SASL [conn=16] Failure: GSSAPI
Error: Miscellaneous failure (see text) (Decrypt integrity check
failedxt))
If I run klist command on my client, I can see the following tickets:
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: xav@PASSRL
Valid Starting Expires Service Principal
02/27/09 18:04:17 02/28/09 04:04:17 krbtgt/PASSRL@PASSRL
renew until 03/06/09 18:04:17
02/27/09 18:04:20 02/28/09 04:04:17 ldap/passrlsrv.passrl@
renew until 03/06/09 18:04:17
I suspect that the problem is due to the ldap service ticket principal
that is "ldap/passrlsrv.passrl@" instead of
"ldap/passrlsrv.passrl@PASSRL". In my kdc log file I see that the
service ticket request is for "ldap/passrlsrv.passrl@PASSRL"
Any idea why the principal looks wrong in the client kerberos cache ?
I'm not as familiar with this error, but there is one possible
explanation here:
http://www.faqs.org/faqs/kerberos-faq/general/section-73.html
It may be that your /etc/krb5.keytab file contains old information,
where the principal may have been encrypted with an old key. I would
start by recreating both the ldap/passrlsrv.passrl@PASSRL principal, and
the xav@PASSRL principal, and reexporting your /etc/krb5.keytab.
Concerning the absent @PASSRL in your service ticket, I don't know that
that's necessarily an error. I've encountered that myself when talking
to a Windows 2003 AD/LDAP server:
https://lists.andrew.cmu.edu/mailman/private/cyrus-sasl/2008-November/001579.html
- Dan
