Navigation

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:

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)

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)

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

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:

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: