Ken Schaefer

Note: I have created a list of all the IIS and Kerberos parts 

I'm finally getting around to writing this section on IIS and Kerberos. This initial post will cover the basics of a cross-Forest Kerberos authentication scenario. In the next few posts we'll cover more complex situations including delegation and ISA Server publishing.

The basics of cross-domain Kerberos authentication (in the same Forest) are the same as a cross-Forest scenario, so I've covered the cross-Forest scenario in these posts, and steps that are unnecessary for a cross-domain scenario can be omitted.

Our setup involves a resource Forest (domainA.local) and a user Forest (domainB.local). A network packet capture is included (it can be opened using Wireshark/Ethereal - rename the extension back to .cap), and to help decipher the capture the machines involved are:

In the scenario the client in DomainB.local attempts to connect to svr03-r2-web-1 in DomainA.local. The sequence of packets are:

1. Client connects to web server and gets 401 (Packets 4 and 6)
2. Client connects to DC in local Domain asking to a ticket to http/svr03-r2-web-1.domainA.local (Packet 8)
3. The DC in DomainB.local provides a referral to DomainA.local (Packet 9)
4. The client connects to a DC in DomainA.local asking for a ticket (Packet 12)
5. The DC in DomainA.local provides a Kerberos ticket to the client (Packet 13)
6. The client again connects to the web server, presenting its Kerberos ticket (Packet 15)
7. The server responds with a 200 OK (Packet 21)

And the user successfully authenticates using Kerberos:

Things to be aware of in this simple scenario:

• Typically a client will be connecting using the FQDN (fully qualified domain name) of the web server. Since Kerberos is only attempted if the website is in Internet Explorer's Intranet security zone, the website will need to be added to that security zone either using a GPO or manually
• Clients must be able to contact domain controllers in the resource Forest in order to get appropriate Kerberos tickets. If there are some DCs in the resource domain that are unreachable (e.g. due to firewalls ec) then you need to ensure that clients in the user Forest only get referrals to reachable DCs
• EDIT: Forest trusts can only be created when using a Windows 2003 functional level Forest. The Forest functional level can be raised using the Active Directory Domains and Trusts Admin MMC tool. Before you can raise the Forest functional level, you need to raise the Domain functional level of all Domains within the Forest to Windows Server 2003. If your Forest functional level is Windows 2000, only an external trust can be created, which does not permit Kerberos authentication.
• EDIT: Only a one-way trust (the resource Forest trusts the User forest) is required for this scenario. In future scenarios (e.g. when we introduce delegation) a two-way trust will be required. However we can limit the access the Resource forest has to the User forest using Selective Authentication
• EDIT: If you need guidance on creating a Forest Trust, then Microsoft's TechNet has a good guide