On 09/09/10 13:35 +0930, Indexer wrote:
I have REALM.A and REALM.B in my KDC setup. There is a two way trust between REALM.A and REALM.B.
I have a client computer on REALM.A, and can correctly kinit to get tickets from both realms via this trust pathway.
I also have an OpenLDAP server on the server with REALM.B, and it is identified by ldap/ldap.realm.b@REALM.B
When i obtain a ticket on REALM.A via this , and try to execute a SASL bind to the ldap server, i get an error of
SASL/GSSAPI authentication started ldap_err2string ldap_sasl_interactive_bind_s: Local error (-2)
It says that Minor code may provide more information (Server ldap/ldap.realm.b@REALM.B not found in Kerberos database).
My understanding and memory of the flow of tickets in this case (Wireshark is very helpful here) is that your client should be requesting and receiving a TGT from the KDC for REALM.A, and another one from the KDC for REALM.B, *then* a ticket for ldap/ldap.realm.b@REALM.B, directly from the KDC for REALM.B.
After receiving the ldap/ldap.realm.b@REALM.B ticket, it would then present it to the ldap server during GSSAPI exchange.
Note that if one of the KDCs is a Microsoft AD server, then it handles cross realm ticket requests differently, where the client is expected to obtain REALM.B tickets proxied from the KDC for REALM.A (or something like that).
I'd set up a wireshark capture and see which KDC is returning the error. You should see the Kerberos error codes transmitted over the wire.
A user from REALM.B can access the LDAP server correctly with GSSAPI
klist shows that i am getting a TGT for both REALM.A and REALM.B on my user@REALM.A.
Is this an issue with kerberos being unable to find the ticket across the realm trust for ldap to be verified? What steps can i follow to help fix this issue? Are there principal flags that i am forgetting to add to my LDAP principal for this to work?