Ken Schaefer

As an extension of the previous article on Cross Forest (or Cross Domain) Kerberos Authentication this article examines how to configure cross forest authentication and delegation when users are accessing an arbitrary website URL.

In this scenario we have the same two Forests as in Part 8. Forest A (domainA.local) contains our resource servers (web server and SQL server). Forest B (domainB.local) contains our users and client PC.

Users are going to access a web site at www.myCompany.com, a domain that has no direct relationship between either the resource domain or user domain. Companies might need to implement this type of setup when they wish to have a single URL that users on either the internal network or externally can access. Alternatively I have seen scenarios where companies what to have a portal address (e.g. intranet.company.com) that then reverse proxies a number of internal web applications, and Kerberos authentication and transparent delegation to the proxied web applications makes for a simplified user experience.

A diagram of the process involved:

Wireshark/Ethereal packet captures of the actual traffic are available for download (rename to .pcap).  I’ll explain the packets to look for a bit further down in the blog post.

The configuration steps required for this setup are:

1. Determine some mechanism so that the users can resolve www.myCompany.com (DNS is a given, but if you are using a split-brain DNS then your internal DNS will need to have an appropriate zone as well as your public DNS)
   
2. Create an additional UPN (user principal name) suffix in your resource Forest (domainA.local). To do this:
   • Open the Active Directory Domains and Trusts Administrative Tool
   • Right-click on the top level "Domains and Trusts" node
   • On the UPN suffixes tab add www.myCompany.com and click Add. Note: you can add myCompany.com and this will add all hosts under myCompany.com. Adding www.myCompany.com will also work (but will also permit hosts under www.myCompany.com such as www.www.myCompany.com)
     
3. Configure Name Suffix Routing across the Forest Trust. To do this:
• Open the Active Directory Domains and Trusts Administrative Tool in DomainB.local (the user domain)
• Right-click on your domain (domainB.local) and choose Properties
• On the Trusts tab select DomainA.local under either options (Domains trusted by this domain or Domains that trust this domain) – it doesn’t matter which one. Click the Properties button
• On the Name Suffix Routing tab select *.www.myCompany.com and click Enable
  
• Click OK to exit all the dialogues
4. Steps 4 & 5 are generic Kerberos configuration steps that aren’t specific to cross-Forest scenarios: Add the requisite SPN (Service Principal Name). To learn about SPNs review Part 2 in this series. In this case we need to add an SPN for http/www.myCompany.com in domainA.local. If the web application pool is running under Network Service, Local Service or LocalSystem the SPN should be added under the computer account of the web server. If the web application pool is running under a custom user account, the SPN should be added under that user account in domainA.local. NOTE: if you are running IIS 7.0 and using kernel mode authentication (the default) then you should add the SPN under the machine account. See Part 6 on new features in IIS 7.0
   
   
   After adding the SPN, you should see the following in Active Directory:
   
   
5. Add the website www.myCompany.com to the Intranet Security Zone of the user’s computer. Recall from Part 3 that IE will not attempt Kerberos authentication unless the website is in the Intranet Security Zone. This can be done manually, via the IEAK, or using Group Policy.

After this is all configured and replicated around the environment then the following should be observable in the packet capture. Note that this exchange is similar to that seen in the previous packet capture (some stuff is actually missing from this packet capture as the machines already have name resolution and some referals already established. It is worth reviewing Part 8 packet capture with more detailed descriptions if you are seeing this for the first time). The only real difference is that we can see the routing required for http/www.myCompany.com service ticket:

1. Packet 6 – HTTP request by client
2. Packet 9 – Initial 401 response from web server
3. Packet 18 – DomainA.local DC returns service ticket for http/www.myCompany.com to client
4. Packet 21 – new HTTP request by client including Kerberos ticket
5. Packets 47-50 – tickets granted to access backend SQL Server
6. Packet 59 – HTTP 200 response to client with data from backend SQL Server

For reference the machines in question are: