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

[Jason D. McCormick]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6321 bytes
Desc: not available
Url : http://mailman.mit.edu/pipermail/kerberos/attachments/20090416/649c4af8/attachment.bin