Windows Server 2003 Constrained Delegation (IIS 6.0)
Applies To: Windows 7, Windows Server 2008, Windows Server 2008 R2, Windows Vista
Windows 2000 supports delegation, but you cannot constrain the delegation to a specific set of services on a system, which makes it difficult to implement this capability securely. Windows Server 2003 native domains use constrained delegation (sometimes referred to as “Service4User2Proxy”), which entrusts IIS to give delegated credentials to a specified list of services on remote servers. The ability to implement constrained delegation on a network creates new possibilities for configuring a Windows Server 2003 file server running IIS; the credentials from a user are passed through to designated services on designated computers. This allows you to secure NTFS permissions on remote content using domain-based users and groups rather than a single, designated user for UNC access from the IIS server.
When delegation is enabled on a Windows Server 2003 file server, you can delegate a user’s credentials obtained with NTLM, Basic, Digest, Client Certificate, and Kerberos authentications to a remote server: Clients can authenticate to IIS using any of these authentication protocols and IIS delegates the credentials using the capabilities of Kerberos. This feature of Windows Server 2003 is known as protocol transition, sometimes referred to as ”Service4User2Self”, because IIS (the ”Service”) is able to obtain a service on behalf of the authenticated user to itself. This is perfectly reasonable because IIS has already authenticated the user and is in effect telling Kerberos that it trusts the user’s identity for use in operations to itself. Constrained delegation is related to protocol transition, and allows IIS (the ”Service”) to use the User’s service ticket in a request to the Kerberos Domain Controller (KDC) for a ticket to a specific remote server (the “Proxy”). The ticket can be delegated only to services on the remote server that are specified by the domain administrator, which is why this type of delegation is called constrained delegation. This gives you maximum flexibility in choosing how you authenticate users on IIS, while preserving the ability to securely connect to network resources with pass-through authentication.
Finally, the service ticket sent by IIS is used by the remote file server to authorize access to the requested shares, directories, and files, which are secured by ACLs. The service ticket represents a domain user’s identity, for example “MyWebSiteAnonymousUser”. The entire process of Authentication, Protocol Transition, Constrained Delegation, and Authorization is shown in Figure 7.
Figure 7: Authorization under constrained delegation
As an example of protocol transition, if your client authenticates to the Web server via Integrated Windows authentication using NTLM, the user’s token on IIS does not have sufficient permissions to access another server, such as a file or SQL server. Consequently, pass-through authentication for a user authenticated with NTLM (or any method other than Basic or Kerberos authentication) will fail. Windows Server 2003 allows you to configure Microsoft Active Directory® so that logons using NTLM can be authorized for delegation (see the instructions below). Once you have enabled this delegation, the token that the Web server receives is now a Kerberos ticket, which has permission to access another server. Basically, the NTLM-based token gets upgraded to a Kerberos-based ticket. See the Windows Server 2003 documentation for more details.
If you have upgraded from IIS 5.0 to IIS 6.0, by default IIS 6.0 runs in IIS 5.0 isolation mode. In IIS 5.0 isolation mode, out-of-process applications run as the local IWAM_ComputerName account, which prevents constrained delegation from working correctly. A process that runs as a local account cannot be used to obtain a Kerberos ticket on behalf of an authenticated user. Constrained delegation can be enabled, however, by switching IIS to run in worker process isolation mode. Worker processes running in worker process isolation mode will run as Network Service user accounts, a computer account with sufficient rights on the domain to delegate credentials.