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:

It's been a long time between blog posts. Between a couple of Tech.Eds, being sick with the flu, and a large enterprise System Center Operations Manager 2007 deployment, it's been pretty busy the past month. In addition, handling bathroom and kitchen renovations is consuming pretty much all of the spare time on weekends.

This year I was privileged to deliver a few presentations at Tech.Ed South East Asia 2008 - one on IIS 7.0 for IT Pros, and a second on Web Farm Scenarios and IIS 7.0. Both of the session decks are available for download from the Tech.Ed SEA website (download the Server track ZIP file).

I also delivered the IIS 7.0 Security and Performance Tuning session at Tech.Ed Australia. My apologies if the session was quite up to scratch - I was suffering from the flu - but it's still the top rated Server track session, so thanks to all that filled in feedback. Click the session title link to download the session deck (1.2MB). Thanks to Wade Hilmo and Pete Harris from the IIS product group for helping me pull that session together.

Some random photos from Tech.Ed 2008:

Tech.Ed SEA 2008 presenter badge

The closing locknote at Tech.Ed Australia 2008. I didn't snap the slide that showed I was beating Steve Riley in the Presenter scores :-)

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:

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)

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

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

I was just trying to install SCVMM 2008 Beta 1 today. When installing the SCVMM 2008 Server, it failed installing the WAIK prerequisite asking me to instead install this manually.

Attempting to run the WAIK msi directly from the prerequisites folder (\prerequisites\WAIK\1033) failed asking me to "Insert the WAIK setup CD". I think this problem might be caused because I'm install SCVMM 2008 from a DVD. I copied the files from that folder onto the hard disk of the machine, and then attempted to run the MSI again, and WAIK installed successfully.

Last week I was in Seattle attending the Microsoft MVP Summit for 2008. Certainly this year's summit was much better organised than some previous summits in terms of interaction with the IIS product group.

Whilst we've seen a bunch of interesting stuff coming out from the product group over the past few months (WebDAV, MSDeploy, Powershell Provider, Bitrate Throttling, Admin Pack - including the Config Editor). However over the next few months expect to see a number of significant additional releases. Whilst I'm probably not at liberty to disclose what these are, think about the major market that IIS 7.0 has gone after (e.g. hosting with Apache) and some of the major features and modules that the competing platform has that IIS 7.0 doesn't currently, and you'll probably be pretty close to the mark in terms of upcoming features.

In addition to getting the inside scope from the product group, the MVP Summit also offers opportunities to talk and network with other MVPs, as well as an executive briefing. This year Ray Ozzie and Steve Ballmer came by to talk to us. Whilst I've had the opportunity to listen to many of Micosoft's senior executives in other forums (Tech.Eds, Partner events etc), what is refreshing about the MVP Summit is that these executives will spend half an hour (or more) taking questions, without notice, from the floor. Whilst they are naturally guarded about the answers they can give (if press are present), we're still above to canvas a range of topics. And more than once a product has changed somewhat due to the questions or feedback given during these sessions.

I, for one, am looking forward to the next MVP Summit in 2009 (assuming I'm reawarded of course!). As a small bonus, whilst browsing Barnes and Noble in downtown Seattle, I came across a most excellent book that everyone should have a copy of :-)

As some of you may be aware, Cesar Cerrudo of Argeniss presented a session at the just completed Hack in a Box conference where exploit code was demonstrated that allows certain code running with restricted privileges (e.g. Network Service) to gain high privileges (e.g. LocalSystem). The exploit appears to rely on the fact that certain other processes running as network service have SeImpersonatePrivilege, and the malicious code can use this to gain additional privileges on the system.

Microsoft has released an advisory on this potential vulnerability, and if you are running IIS 6 or IIS 7, you are urged to examine the potential implications and workarounds posted.

Edit: 19/04/2008 - the slides from Cesar's presentation have been posted on the Argeniss website

This Easter weekend, having a bit of downtime, I decided to convert my virtual infrastructure at home from VMWare Server to Hyper-V. The major blocking issue was a lack of RAID controller drivers from 3Ware for their 9650SE-series cards, but thanks to Justin Ho it seemed like I was good to go. The timely release of Hyper-V RC0 meant that I could use an updated version of Hyper-V, and also install my Windows Server 2008 machine using my local en-au settings rather than en-us.

The servers that I had running where:

• Server1 - Windows Home Server
• Server2 - Exchange 2007 (Windows Server 2003 x64)
• Server3 - Operations Manager 2007 + WSUS (Windows Server 2003 x86)
• Server4 - ISA Server 2006 (Windows Server 2003)
• Server5 - Domain Controller 1 (Windows Server 2003)
• Server6 - Domain Controller 2 (Windows Server 2003 x64)

To speed up the conversion time, I removed DC2 from the domain (and recreated it as a brand new VM at the end of the process. It is now my first Windows Server 2008 DC). I also removed the Operations Manager 2007 machine (and recreated this on Windows Server 2008)

The steps I used to convert these VMs:

1. Made a backup of all my virtual machines before I started!
2. DCPromo DC2, and remove it from the domain
3. Uninstall Operations Manager clients from all managed servers, then remove Server3 from the domain
4. Uninstall the VMWare Tools from each remaining virtual machine
5. Shutdown all remaining machines and make a backup of the VMDK files (again)
6. Convert the VDMK files to VHD files. You can use System Center Virtual Machine Manager (SCVMM) to do this. Alternatively I used the free VDMKtoVHD tool from VMToolKit. Note that if your VMDK files are pre-allocated fixed sized disks, they will become dynamically expanding VHD disks after the conversion (empty space isn't converted)
7. Configure my 3Ware 9650SE RAID controller BIOS per Justin Ho's instructions (see earlier)
8. Format my arrays, and install a brand new copy of Windows Server 2008 x64
9. Install the Hyper-V RC0 update
10. Install the Hyper-V role, as well as desired features (Backup and PowerShell)
11. Create the necessary virtual networks in Hyper-V
12. Create new virtual machines using the newly converted VHD files and boot the machines

Some issues that I discovered:

• My VMWare machines were using SCSI disks connected to a SCSI controller. Unfortunately booting Hyper-V machines requires IDE disks at the moment. Since the IDE mass storage controller wasn’t set to start in my VMs, they Blue Screened with STOP 0x7B (Inaccessible_Boot_Device). I fixed this issue by inserting the OS setup CD and doing a repair on the OS.
  EDIT: Steen has a great tip below for how to get around this issue. It requires you to add a dummy IDE disk to your VMWare VM prior to do the conversion (to get the IDE mass storage controller into a started state)
• There appears to be an issue with guest OSes talking to a virtualised ISA Server when all the machines are using the new VMBus NICs and the NICs are connected to a Private or Internal Hyper-V network (the issue doesn't appear to manifest if the NICs are bridged to a physical NIC). Networking doesn't work to well, and when running ISA's monitoring tools, packets are missing. To fix this issue, I changed the NICs on my ISA Server that were connected to Private or Internal networks to using the Legacy (Intel 21140) NIC. Since ISA Server 2006 only runs on Windows Server x86, there are supplied Intel 21140 drivers on the Hyper-V Integration Services disc.

So this was the picture beforehand:

and this is the picture aftewards:

Performance appears to be much snappier under Hyper-V compared to VMWare Server, especially with respect to Disk I/O. Additionally, I can now backup my virtual machines when running (well, I hope I can) using my new RD1000 device.

Here's a useful little module I didn't know even existed, but it appears to have been added to the Microsoft download site in the past couple of days. It allows for bit rate throttling of common, supported, media files when served by IIS 7.0. IIS first sends the first twenty or so seconds of data at the fastest possible rate, and then streams the rest slowly.

Full information on configuring this module is available on the http://learn.iis.net/ website. You can download the module from the Microsoft download site for x86 and x64.

Today Microsoft released to the Microsoft download site WebDAV modules for Windows Server 2008 / IIS 7.0 in both x86 and x64 versions. These are also available from the www.iis.net website.

Robert McMurray has written a page explaining how to configure the new WebDAV module.

Well, the book is finally a reality. I received my copies today - yay!

You can buy a copy from Amazon.com or your favourite bookstore now.

Note: previous articles

Windows Server 2008 and IIS 7.0 introduce some changes to the way that you need to implement Kerberos support. The three major changes that I'm aware of are:

1. Service Principal Names (SPNs) no longer need to be registered under the account that the web application pool is running under. Instead, in a default configuration you can run the web application pool under any account (custom user account, or LocalSystem, Local Service or Network Service) and register the SPN under the machine account in Active Directory. See this post for more details.
2. Your web application pool does not need LocalSystem privileges to be able to perform protocol transition. You can do this using Network Service.
3. If you want to use <identity impersonate="true" /> in web.config for your ASP.NET pages, you need to disable validateIntegratedModeConfiguration if you are using the Integrated Mode Pipeline. Otherwise you'll get a 500.24 error. You can either set validateIntegratedModeConfiguration to False or you can run in Classic Mode Pipeline

If I find any more things, I'll add them to the list.

Hi all,

There are two security patches out this month for IIS.

The first (MS08-005) affects Windows XP x86 (IIS 5.1), Windows XP x64 (IIS 6.0), Windows Server 2003 (IIS 6.0) and Vista RTM (IIS 7.0). Vista SP1 and Windows Server 2008 are not affected. This is a local escalation of privilege vulnerability, and requires that the attacker be able to access a server locally, or be able to somehow execute code locally (e.g. by placing a file that contains the necessary code on the server, and then have the server run that code from a remote location)

The second (MS08-006) affects Windows XP (x86/x64) and Windows Server 2003, and is a remote code exploitation. It does require that the ASP web service extension be enabled on Windows Server 2003.

Whilst it's always disappointing to see new bugs in IIS, I think the overall record of IIS 6.0 has been very good. Since it's release in early 2003, we've seen only a handful of bugs that are directly IIS' fault (e.g. the previous ASP issue), and handful of bugs that can be exploited via IIS (e.g. the previous WebDAV issue). Overall, there are less than 5 bugs exploitable via IIS 6.0 - which is a great record especially when compared with IIS 5.0 and with its major competitors.

Windows Server 2003 SP1 introduces kernel mode SSL. Windows Server 2008 takes this one step further and introduces kernel mode authentication. This can be utilised by IIS 7.0 applications to improve performance. It also has implications for Kerberos authentication and management of SPNs.

Consider the following scenario:

Ensuring Kerberos AuthN for App1 wouldn’t be possible in IIS 6/5 (earlier versions were pre-Windows 2000 so didn’t support Kerberos). This was because SPNs are based on a FQDN and the SPN for http/website1.domain.com could only be registered under a single account (and not under the two different accounts that App Pool 1 and App Pool 2 are using).

In Windows Server 2008 there is support for a new kernel mode authentication. I am supposing that this is implemented in ksecdd.sys, but it may be implemented elsewhere. When using kernel mode authentication, the service ticket is decrypted by the server (aka machine account), not by the user account that the web app pool is running under.

Because of this, it’s possible to:

• Register every SPN for each application hosted webserver under the machine account in Active Directory, regardless of the identity of the web app pool that the application is being hosted in
• Run multiple web applications hosted at the same FQDN under web app pools that are, in turn, running under multiple Windows identities.

Edit: Anil from the IIS Product Group pointed out an error in my advice below (it's not necessary to actually disable Kernel Mode Authentication). I have updated the section below: 

There is a caveat. This is because the service ticket decryption takes place using the server’s AD machine account. If you are using a web farm, then the KDC doesn’t know in advance which individual server will be servicing the request. In that case, it's impossible to deterministically register the SPN under a single machine account. Instead, you will need to:

• Disable kernel mode authentication Configure IIS to use the web application pool's identity for Kerberos service ticket decryption
• Run the web app pool under a common domain user account
• Be restricted to running all web application accessible at that FQDN under web app pools that are using the same domain user account above

If you are in this situation, then you can disable kernel mode authentication enable the use of the web app pool's identity for Kerberos service ticket decryption by setting the property useAppPoolCredentials to true for the web application or web site in question. An example would be:

<system.webServer>
   <security>
      <authentication>
         <windowsAuthentication enabled="true" useAppPoolCredentials="true" />
      </authentication>
   </security>
</system.webServer>

If you're not sure how SPNs and Keberos work, then check out the earlier posts