In this part we extend, slightly, upon the previous scenario, by adding delegation. Now we need to allow IIS, in our resource Forest (or domain) to delegate the end user’s credentials, to a backend service (SQL Server in this case):

The machines this case are:

MachineDomainIP addressRole
svr03-r2-dc-1DomainA192.168.132.10DC
svr03-r2-dc-2DomainB192.168.132.11DC
svr03-r2-web-1DomainA192.168.132.20Web Server
svr03-r2-sql-1DomainA192.168.132.21SQL Server
cltxp-pro-1DomainB192.168.132.50Client

A packet capture is available for download (taken from the IIS server).

Opening the capture in Wireshark you should see the following (the bullet point numbers correspond to the numbers in the image below):

  1. XP client makes a request to IIS server (Packet 14) and IIS server responds with 401 Access Denied (Packet 17)
  2. XP client contacts DomainB Domain Controller for Kerberos ticket (Packet 19 – note the request for http/svr03-r2-web-1)
  3. DomainB DC returns a referral to DomainA DC (packet 20)
  4. XP client looks up the necessary service records for DomainA (packets 21-24) before requesting a service ticket from the DomainA DC (packet 33)
  5. The DomainA DC returns a service ticket to the XP client (packet 34)
  6. XP client makes a new request to IIS, supplying it’s Kerberos authentication data (packet 37)
  7. IIS contacts its local DomainA DC seeking a referral to DomainB (packets 52-55)
  8. DomainA DC refers IIS to DomainB DC
  9. IIS requests a Kerberos ticket, on behalf of the end user, from DomainB DC (packet 61)
  10. DomainB DC returns the necessary ticket (packet 62)
  11. IIS now connects to SQL Server (packet 65), and gets the results of the query. The resulting webpage is returned to the client (packet 87)

Cross Forest Delegation

The requirements to configure this scenario aren’t significantly beyond that to configure a basic cross-Forest/cross-Domain scenario featured in the previous part:

  • A two-way trust is required. This can use Selective Authentication. However Forest-Wide authentication may be administratively simpler to configure
  • An appropriate SPN needs to be registered for the backend SQL Server (similar to a single domain delegation scenario)

In the next part I will discuss publishing an arbitrary FQDN for the IIS host (e.g. a public facing internet site) and UPN suffix routing.

NOTE (Feb 2009): I finally got around to publishing promised part - see Part 9

Note: A listing of parts is available in the FAQ