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-boun...@mit.edu [mailto:kerberos-boun...@mit.edu] On Behalf Of Jason D. McCormick Sent: Thursday, April 16, 2009 7:37 AM To: 'kerberos@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....@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 ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos