Cross realm authentication

[Mark Pröhl]

On 01/06/2011 05:02 AM, krbmit siso wrote:
> Hi Mark,
>
> Please find the attached capture for cross realm setup . I did not 
> understand why do you require
> 2 TGS-REQ going from client , please shed some light on the same .

the following sketch shows the principals involved in cross realm 
authentication:

    cient               realm-1 KDC
    client at REALM1  ->   krbtgt/REALM1 at REALM1

                              ^
                              |
                            TRUST
                      krbtgt/REALM2 at REALM1
                      krbtgt/REALM1 at REALM2
                              |
                              v

     service <-   realm-2KDC
     service at REALM2      krbtgt/REALM2 at REALM2


cross realm authentication usually works this way (scenario-1):

step 1: client requests a TGT in his realm: AS-REQ/AS-REP for 
krbtgt/REALM1 at REALM1
step 2: client decides that service belongs to REALM2 (by client 
configuration, dns topology or kdc referrals)
step 3: client request a cross-realm TGT for REALM2 by TGS-REQ to 
realm-1 KDC: krbtgt/REALM2 at REALM1
step 4: client request a service ticket for service at REALM2 by TGS-REQ to 
realm-2 KDC. clients presents krbtgt/REALM2 at REALM1

that is why two TGS request are sent from a client in a typical scenario.

your cross realm scenario (from wireshark capture) looks this way 
(scenario-2):

step 1: client request a cross-realm TGT for REALM2 by AS-REQ to realm-1 
KDC for krbtgt/REALM2 at REALM1
step 2: client request a service Ticket for service at REALM2 by TGS-REQ to 
realm-2 KDC. clients presents krbtgt/REALM2 at REALM1

that should work as well but is not the usual way.

The problem could be caused by your client or the trust setup between 
the two windows domains.
To test the trust setup you should simulate the client by using kinit 
and kvno from MIT Kerberos:

simulate scenario-1: kinit client at REALM1; kvno service at REALM2
simulate scenario-2: kinit -S krbtgt/REALM2 at REALM1 client at REALM1; kvno 
service at REALM2

your krb5.conf or DNS SRV records should provide the configuration for 
both realms.

if that works then your trust setup is ok.