Re: GSSAPI Bind across trusted realms

[Dan White <dwhite@olp.net>]

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