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

[Grant Gossett]

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?

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?

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?

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)?


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?



Many thanks,


Grant