[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: GSSAPI Bind across trusted realms



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?

--
Dan White