MIT Kerberos + Windows 2K3 AD Kerberos Cross-Realm TGT Issue usingSSPI

[Wilper, Ross A]

I will comment on two things.

"Empty" root domains in an Active Directory forest - They are worthless
and will cause you headaches down the line if you implement them. Use
other controls to protect your EA accounts.

On the trust problem, by default, Windows clients rely on the Active
Directory to do the host-to-realm mappings. Do you have a top-level-name
forward configured on the two-way external trust in AD? These are done
automatically for Windows forest trusts, but not always for external
trusts.

(Trust needs to be forest transitive)
Netdom trust AD.EXAMPLE2.COM /domain:EXAMPLE1.COM /AddTLN:EXAMPLE1.COM

-Ross

-----Original Message-----
From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
Behalf Of Jason D. McCormick
Sent: Thursday, April 16, 2009 7:37 AM
To: 'kerberos at mit.edu'
Subject: MIT Kerberos + Windows 2K3 AD Kerberos Cross-Realm TGT Issue
usingSSPI

Hello all,

Haven't found the answer to this one on Google or in mailing list
archives.
If someone has a ready-made answer for me, just point the way....

I'm working on a project that is consolidating two different
authentication
domains, their users and their services.  There is a long-standing MIT
Kerberos realm that for this question I'll call EXAMPLE1.COM.  There is
also
a new Windows 2003R2 Active Directory Forest comprising of two domains,
a
top-level "empty" forest root AD-ROOT.EXAMPLE2.COM and the populated
general
domain AD.EXAMPLE2.COM.  We've established a bi-directional trust
between
EXAMPLE1.COM and AD.EXAMPLE2.COM (but not between AD-ROOT.EXAMPLE2.COM
and
EXAMPLE1.COM).  There is appropriate Kerberos-related DNS records
published
for both domains example1.com and example2.com.  

Users in either domain/realm using Linux have no problems getting and
using
Kerberos tickets, TGTs and subsequent service tickets in either
direction -
EXAMPLE1.COM users -> AD.EXAMPLE2.COM services and AD.EXAMPLE2.COM users
->
EXAMPLE1.COM services.   Additionally, users on Windows XP using
Kerberos
for Windows/Network Identity Manager *and* using services/applications
that
reply on the "API" credential cache have no problems working in either
direction.  An example is OpenAFS or Firefox with
network.auth.use-sspi=false set.  This all works fine and seamlessly as
one
would expect.

However we are having problems with users of Windows XP who are logging
in
to AD.EXAMPLE2.COM acquiring the cross-realm TGTs (i.e.
ktbtgt/EXAMPLE1.COM at AD.EXAMPLE2.COM) and service tickets to use
EXAMPLE1.COM
for any application that uses the MSLSA/SSPI credential cache (e.g.
Internet
Explorer, Outlook, Firefox with network.auth.use-sspi=true).  From our
investigation, Windows never appears to be making any DNS-based
domain/realm
lookups (based on wireshark and DNS query logging) nor does there appear
to
be any way to hard-code domain-realm mappings into the registry to tell
the
SSPI cache how to act.  We do have hard-coded domain-realm mappings in
Network ID Manager, but SSPI (rightfully I believe) ignored this.  Any
GSSAPI or SPNEGO authentication attempt fails with a general error about
lacking authorized credentials.

We've explored various netdom.exe settings (many of which require the
trust
to be at the forest root level), some registry settings, user mapping
changes and other items all with no effect.  We've contemplated adding a
trust between AD-ROOT.EXAMPLE2.COM and EXAMPLE1.COM but there's no
documentation that we can find that indicates that'll be helpful.  

I guess my question is how do we either force domain-realm DNS lookups
to
happen or otherwise force the SSPI credential cache to get a TGT for the
cross-realm trust?  Can anyone point me to our configuration error or
help
out?

Thanks in advance.

- Jason