Understanding cross-realm ticket flow - TGS-REQ to wrong(?) realm's KDC

[Douglas E. Engert]

Grant Gossett wrote:
> Hello there,
> 
> I'm currently trying to get cross-realm authentication working with a
> one-way active directory trust that involves a service principal in the
> trusting realm running apache with mod_auth_kerb. 
> 
> The setup uses 2 W2K3 R2 domain controllers which have a 1-way trust.
> Realm (domain) LABS.A.COM trusts realm (domain) CORP.A.COM - it is an
> external (non-transitive) trust. Inside of LABS.A.COM I have an apache
> server configured using mod_auth_kerb named support.labs.a.com with a
> service principal created for HTTP/support.labs.a.com at LABS.A.COM setup
> properly on the domain controller (at least I think it is). The
> reasoning behind my belief that it is set up properly is that kerberos
> authentication works for user principals that are in the LABS.A.COM
> realm. The web server is running CentOS 4.6 and apache was installed
> with mod_auth_kerb using the CentOS installer rather than being built
> afterward. In other words, "default CentOS distro options and versions"
> for apache and mod_auth_kerb.  
> 
> The problem I am seeing (or maybe misunderstanding) is that when user
> principals in the CORP.A.COM realm try to authenticate (using Internet
> Explorer 6) the AS-REQ and AS-RES seem to work out swimmingly. The
> TGS-REQ is where things seem to go bad. The TGS-REQ seems to be asking
> the TGS for a service ticket for the principal
> HTTP/support.labs.a.com at CORP.A.COM, rather than
> HTTP/support.labs.a.com at LABS.A.COM. This is where things are still a
> little fuzzy for me as I am new to kerberos, but I am assuming that this
> is where the problem lies. Naturally, the KDC for CORP.A.COM returns an
> error that the service principal is unknown and it all stops there. 
> 
> So I have a couple of questions that hopefully someone with more
> cross-realm authentication experience can help me with:
> 
> First, is it normal for a kerberized client (IE 6 in this case) to
> always ask its TGS in its realm for service tickets even if the service
> principal does not exist in its realm?

Microsoft introduced referrals to Kerberos where the client asks its
own KDC for information about where the service is located. So for IE
it would be normal. Its not standard, but other Kerberos implementations
are starting to add this feature.  See:

http://www.ietf.org/internet-drafts/draft-ietf-krb-wg-kerberos-referrals-10.txt

Traditionally the Kerberos client would use the krb5.conf [domain_realm]
to determine the realm of a server, then start to traverse the authentication
path. The referral lets the client ask its KDC for the information, and
thus simplifies the client management as it does not need to maintain the
[domain_realm] tables.

> 
> Second, its is my understanding that the client is responsible for
> traversing the authentication path. In other words, the TGS doesn't "do
> the work" of getting the client a service ticket for another realm's
> service principal, the client must do the work by getting a service
> ticket for the cross-realm service principal
> (krbtgt/corp.a.com at LABS.A.COM(?)), using that ticket to send a TGS-REQ
> to the next realm's TGS to actually get a ticket for the service
> principal in the next realm. Is that correct?

The client would ask CORP.A.COM for krbtgt/LABS.A.COM at CORP.A.COM
CORP.A.COM would issue it to the client, and it is usable at LABS.A.COM
to get service tickets. A result of setting up your one way trust.

> 
> Third, assuming that the answer to my first two questions is yes, how
> does the client learn from its TGS that it must ask a TGS further down
> the authentication path or that what it really needs to ask for is the
> trust's service principal?

Thats the referral vs the [domain_realms]
> 
> Fourth, and this may be beyond scope, how do clients normally identify
> what realm a network resource resides in (or in other words, which TGS
> to ask for a service ticket, assuming they can make a TGS-REQ to a
> different realm's TGS)?
> 

[domain_realms] and [capaths]  But the default, assume direct trust exists,
otherwise walk the path up then down the realm hierarchy.
CORP.A.COM->A.COM->LABS.A.COM  But with referrals on Windows, the client asks
the KDC what is next in the path.

> 
> It seems like there is a simple solution here, and that is to get IE to
> send the TGS-REQ for HTTP/support.labs.a.com at LABS.A.COM rather than
> HTTP/support.labs.a.com at CORP.A.COM. Is that correct? If so, does anyone
> have an inkling as to what I have set up incorrectly?
> 

Look at the netdom trust command and namesuffixes and addtln
on CORP.A.COM

Also look a the verify option to make sure it is set up correctly

http://technet2.microsoft.com/windowsserver/en/library/539c5381-db4f-445f-aac0-2df5448181c11033.mspx?mfr=true


> 
> 
> Many thanks,
> 
> 
> Grant 
> 
> 
> 
> 
> 
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444