Ken Schaefer

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: 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

In previous versions of IIS, it has sometimes been difficult to isolate web application pools from each other. If multiple web application pools are configured to run as the same identity (e.g. Network Service) then code running inside one web application pool would be able to use File System objects to access configuration files, web pages and similar resources belonging to another web application pool. This was because it was impossible to allow one process running as Network Services access to a file, but prevent another process also running as Network Service access to the same file.

In IIS 7.0 it is possible, with some work, to prevent this from occurring. As part of IIS 7.0 inbuilt functionality, each web application pool has an application pool configuration file generated on-the-fly when that application pool is started. These are stored, by default, in the %systemdrive%\inetpub\temp\appPools folder. Each web application pool has an additional SID (Security Identifier) generated for it, and this in injected into the relevant w3wp.exe process. The application pool's configuration file is ACLed to allow only that SID access. Since each w3wp.exe process has it's own SID, each application pool's configuration file is ACLed to a different SID:

icacls.exe %systemdrive%\inetpub\temp\appPools\appPool.config /save output.txt

The actual SID always starts with the well-known identity prefix: S-1-5-8-82 followed by a hash of the Application Pool's name.

The retrieved SID can now be used to secure web site content in the same way. To do this:
Edit: Thomas Deml (from the IIS Product Group) has shown me an easier way to perform Step 4 below

1. Configure each website (or web application) to run in its own web application pool
2. Configure anonymous authentication to use the application pool identity rather than the IUSR account (this can be done by editing the Anonymous Authentication properties for the website in question)
3. Remove NTFS permissions for the IUSRS group and the IUSR account from the website's files and folders.
4. Use the icacls.exe tool to permit the App Pool's individual SID Read (and optionally Execute and Write) access to the web site's files and folders. You don't need to initially retrieve the SID using iCacls. Instead simply use: IIS APPPOOL\ApplicationPoolName as the user to grant read permissions to (see screenshot below for an example for the Default App Pool)

After configuring these NTFS permissions, only the SID that has been injected into a particular w3wp.exe process will be able to read the contents of the website in question. All code running in other w3wp.exe processes, even though the process identity may also be Network Service, will be unable to read this particular website's content. This technique may be most useful to web hosters or similar administrators, that need to accept content from various external or untrusted parties.

Edit #2: Here's a screenshot of the dynamic SID injection in action for the Default App Pool (using the excellent Process Explorer tool). The username highlighted can be used with icacls.exe to ACL your web content.

Hi,

For all those wondering what options you have post-Application Center 2000 for synchronisation (let alone load balancing etc), the IIS Product Group has released a technical preview of a new tool: msdeploy.exe. This tool can sync or migrate:

• IIS 7.0 configuration settings
• Web content
• Registry keys and values
• SSL certificates

The product group is planning to have Powershell cmdlet support by the final release. Read more and download the bits from the MSDeploy blog