Ken Schaefer

Protocol Transition is a new feature in Windows Server 2003. The Kerberos implementation in Windows Active Directory domains provides the robustness of Kerberos whilst also obviating a number of the technical issues with non-Windows Kerberos implementations (platform infrastructure, ticket renewal, ticket proxy). However Kerberos has a downside – the need to get tickets from a KDC. In the IIS world, contacting a KDC simply isn’t a possible for many internet facing scenarios. Either the KDC is not exposed to internet facing clients (blocked by a firewall), or (more commonly) a KDC is simply not locatable because the necessary SRV (service records) are only located on internal DNS servers not available to the public:

In the diagram above '1' shows a typical problem with a non-Domain (i.e. public) client attempting to locate a KDC for a domain that a web server is in. Typically public DNS servers do not contain the necessary service records that tell a client where the KDC can be located.

Even if the client is able to locate a KDC, the '2' indicates the next hurdle - clients on the internet can not connect to the KDC to get the necessary tickets to use Kerberos Authentication to authenticate to the web server because a firewall or similar edge device blocks internet clients from directly contacting domain controllers.

Aside from an internet connection client establishing a VPN to your internal network, there are any number of technologies that allow such clients to authenticate to a web server, from Digest Authentication through to Client Authentication Certificates. However after a client has authenticated to a web server using such a technology, it can then become difficult to pass those credentials through to a backend server (Basic Authentication is an exception because it provides the web server with the user's username and password, allowing direct impersonation via LogonUser however a compromised web server in this case would allow a malicious attacker to harvest a rich database of users and their passwords).

Windows Server 2003 introduces two new technologies and two new services (not Windows Services in the sense of daemons, but services that can be leveraged) that address some of the authentication issues mentioned.

Windows Server 2003 introduces:

·         Protocol Transition – this allows a non-Kerberos Authentication mechanism to be used to authenticate to IIS, whilst IIS can use Kerberos to connect to a backend server.

·         Constrained Delegation – this allows Administrators to constrain what backend services IIS can connect to.

To facilitate these two pieces of functionality, Windows Server 2003 introduces two services that can be leveraged by your applications and by IIS:

·         Services For User to Self (S4U2S)

·         Services for User to Proxy (S4U2P)

Firstly let's address the necessary steps to configure Protocol Transition and Constrained Delegation in an IIS situation, and then we'll look through the actual implementation details that show how this all hangs together.

If you missed the previous parts in the series or need a refresher then you can find them at:

IIS and Kerberos Part 1 - What is Kerberos and how does it work?

IIS and Kerberos Part 2 - What are Service Principal Names?

IIS and Kerberos Part 3 -  A simple scenario

IIS and Kerberos Part 4 - A simple delegation scenario

Configuring Active Directory

To support Protocol Transition you need to be running Windows Server 2003 for your IIS server and you need to have a Windows Server 2003 functional level domain (this requires all DCs in your domain to be running Windows Server 2003. To raise the Domain Functional level, use Active Directory Domains and Trusts MMC Snapin).

To configure Active Directory using the GUI (how to configure this all programmatically is explained later) open Active Directory Users and Computers MMC Snapin.

Assuming that you are not using a custom user account for your web application pool, locate your IIS server’s computer object and bring up that machine’s properties. On the delegation tab choose both:

·         Trust this computer for delegation to specified services only  and

·         Use any authentication protocol

You will now need to specify the backend services that the IIS machine is permitted to delegate to. Click the "add" button and then the "users and computers" button. Enter the computer or user account that the backend service is running under (for example, if you are running SQL Server under a LocalSystem account on a remote server, enter the SQL Server's computer account. If you are running SQL Server under a custom user account, enter that user's account). A list of Service Principal Names (SPNs) registered under that account is displayed. Select the SPN that you wish IIS to be able to connect to. If you are not familiar with SPNs, or need to configure an additional SPN, then see Part 1 (Kerberos fundamentals) and Part 2 (Service Principal Names) in this series.

If you are running your web application pool under a custom user account, then perform the above steps for the user account, not the IIS server’s computer account.

Configuring IIS

There isn’t much to configure on the IIS box beyond what needs to be configured for straight Kerberos Delegation (see Part 3 in the series). The main difference is that the user account running the web application pool for your website needs to have SeTCBPrivilege (Act as Part of the Operating System) and SeImpersonateUser (Impersonate a User After Authentication). Your options involve either running your web application pool as LocalSystem, or granting a custom account these NT User Rights. These use rights can be assigned by editing the local security policy (start -> Run -> secpol.msc). Alternatively Group Policy can also be used.

Note: running a web application pool with any account that has SeTCBPrivilege is a security risk. Any potential compromise of your web application will result in the attacker having full privileges over your IIS server.

And that's the entire configuration that's required to support Protocol Transition natively on IIS to a backend server. Now you can authenticate to IIS using alternate authentication mechanisms, and still delegate to a backend service similar to how we configured IIS and SQL Server in Part 4 – A simple delegation scenario.

For more information on how this is actually implemented in Windows Server 2003, read on.

Services For User to Self

Services For User to Self (S4U2S) provides the ability for a service running on a server to get a Kerberos ticket for an end client, even if the end client did not authenticate using Kerberos. Instead of the service providing the end user’s TGT (Ticket Granting Ticket) or end user’s credentials (username/password) to the KDC, the service provides its own credentials.

The resulting token that is returned depends on what NT User Rights the service account has. If the service has SeTCBPrivilege (Act as Part of the Operating System) then the token returned is an Impersonation token. If the service does not have this privilege, the token is an Identification token.  (TCB in SeTCBPrivilege stands for Trusted Computing Base a.k.a. the trusted kernel of the operating system). An Identification token can be used to determine a user’s group membership and validate the user’s access to resources. An Impersonation token further allows access to kernel mode objects using the end user’s identity.

 In order to actually use an Impersonation token to impersonate an end user, the service must also have the SeImpersonatePrivilege (Impersonate a Client After Authentication). Attempting to impersonate an end user without this user right results in the Impersonation token being downgraded to an Identification token.

If the service has both SeTCBPrivilege and SeImpersonatePrivilege then the service can use the token to directly impersonate the end user (on the local system) without having the end user’s TGT or credentials. A service can do this by either directly calling LsaLogonUser (or the constructor for the .NET WindowsIdentity class that wraps LsaLogonUser), or by relying on the Kerberos SSP provided by Windows Server 2003.

Services for User to Self (S4U2S) help provide for Protocol Transition – the ability to perform Kerberos Authentication even though the end user has authenticated to our IIS server using some other protocol.

Services for User to Proxy

Services for User To Proxy (S4UTP) provides the ability for a service to obtain a Kerberos ticket on behalf of an end user that can be used to authenticate to a remote service. Whilst S4U2S discussed above allows a service to obtain a Kerberos Ticket, the Forwardable flag is not set, which does not permit the service to authenticate to remote services (e.g. a backend database) on behalf of the end user.

In order for the Kerberos ticket to be forwardable (i.e. used by the service to connect to a backend service such as a database), delegation must be enabled in Active Directory.

The actual series of events looks like the following:

In order for the service to be able to get forwardable tickets on an end user's behalf, a flag needs to be set on the service account’s userAccountControl property in Active Directory: TrustedToAuthenticateForDelegation (T2A4D). This flag has the value 0x1000000 (or 16777216 in decimal).

Note: if the end user had authenticated initially using Kerberos, then this particular flag doesn’t need to be set. We use it only when we are using Protocol Transition and we need to get forwardable tickets.

The T2A4D is new in Windows Server 2003 Active Directory domains. In a Windows 2000 functional level domain, a different flag: TrustedForDelegation (with a value of 0x80000 or 524288 in decimal) is set. This corresponds to the "Trust this computer for delegation to any service (Kerberos Only)" option in a Windows Server 2003 domain (see below). This was the only way to configure delegation in a Windows Server 2000 domain, and is known as "unconstrained delegation".

To set the T2A4D flag we choose the “Trust this computer for delegation to specific services only -> Use Any Authentication Protocol”. This means that a client can use any Authentication protocol to authenticate to our service, but then we’ll be using Protocol Transition and S4U2P to get Kerberos tickets to authenticate to these backend services.

The other Active Directory property we need to be aware of is the msAllowedToDelegateTo property. When we add a list of remote services that the service account is permitted to delegate to we populate the msAllowedToDelegateTo property of the service account.  The msAllowedToDelegateTo property is populated whenever we use Constrained Delegation. If we choose the "Keberos Only" option, then only this property is populated. If we choose the "Use Any Authentication Protocol" then both the T2A4D userAccountControl flag is set and the msAllowedToDelegateTo field is set.

Now, some gotchas that you need to be aware of. As mentioned earlier but worth repeating;

• Protocol Transition relies on using constrained delegation. You can’t use Protocol Transition in conjunction with unconstrained delegation.
• Once you have used constrained delegation to hop to a server, all subsequent hops must also use constrained delegation. In the following example, connecting from IIS to SQL Server used Constrained Delegation. In order for SQL Server to connect to additional backend servers the msDS-AllowedToDelegateTo property in Active Directory must be explicitly configured to allow SQL Server to do so.
• When using constrained delegation all servers in the delegation chain must be in the same domain. It is not sufficient that a domain or forest trust exists between the servers.

And that concludes this rather long Part 5. If you’re still reading this: thankyou. Please feel free to leave a comment if you feel that something was unclear or incomplete. If you feel something was incorrect, then please email me so I can avoid public embarrassment :-)

In Part 6 we’ll look at using Kerberos authentication across more than a single Active Directory forest. Subsequent parts will look at configuring additional services (such as ISA Server and Sharepoint). If there are specific scenarios you’d like me to cover, please drop me a line.

Edit: Due to blog spam - comments are disabled. Contact me through the contact form