Re: Cross Realm HELP

[Jeremiah Martell <inlovewithgod@gmail.com>]

Buck,

   Thanks again.

   I will definitely try what you suggested. I do have a copy
of kinit and klist on my Linux box. However, I noticed that I can't
find the kinit and klist that is built by heimdal. I've looked in the
install directory I gave heimdal's configure, but it's not there. Am I
missing something?

   - Jeremiah :-)
   inlovewithGod@gmail.com

On 9/22/05, Buck Huppmann <buckh@pobox.com > wrote:

On Wed, Sep 21, 2005 at 08:45:17AM -0400, Jeremiah Martell wrote:
> Buck,
>
> Thanks for your reply.
>
> In my particular configuration, there is a realm called
> "PARENT.EXAMPLE.COM< http://PARENT.EXAMPLE.COM>",
> and two children realms called "CHILD1.EXAMPLE.COM<http://CHILD1.EXAMPLE.COM>",
> and "CHILD2.EXAMPLE.COM <http://CHILD2.EXAMPLE.COM>". Cross realm trusts
> exist so that if I authenticate into CHILD1, I can traverse to PARENT, and
> then to CHILD2, where the LDAP directory resides.
>
> My krb5.conf file is setup correctly because another application can
> successfully accomplish what I'm after. It logs into CHILD1, traverses
> realms until it gets to CHILD2, and binds to the LDAP Directory. So from
> this I'm assuming the krb5.conf and the necessary trusts are setup properly.

at this point, you need to probably take it to an LDAP guru list, since
it seems like things are correctly working for cross-realm authentication,
at least as demonstrated by the other application

for my part, not knowing LDAP and SASL API's, the most i can suggest is
to see if you can do the following. note that this uses GSSAPI and not
Kerberos 5 directly. (is there a Kerberos 5 SASL mechanism?)

kinit yourself@CHILD1.EXAMPLE.COM
ldapsearch -P 3 -H ldap://server.in.child2.example.com -Y GSSAPI \
        -b '' -s base '(objectclass=*)'
klist

and see if you get a cross-realm krbtgt and an
ldap/server.inchild2.example.com@CHILD2.EXAMPLE.COM ticket. if not, maybe
you need to find out how the other application is ``traversing realms'',
since this is normally the business of Kerberos and should be transparent
to the application. if the other application is jumping through some hoops
to do this, maybe you can save your application the trouble by setting up
a [capaths] section in your krb5.conf

http://www.pdc.kth.se/heimdal/heimdal.html#Transit-policy