About Kerberos constrained delegation

[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]

Forefront TMG can publish Web servers and authenticate users to verify their identity before allowing them to access a published Web server. If a published Web server also needs to authenticate a user that sends a request to it, and if the Forefront TMG computer cannot delegate authentication to the published Web server by passing user credentials to the published Web server or impersonating the user, the published Web server will request the user to provide credentials for a second time. Forefront TMG can pass user credentials directly to a Web published server only when these credentials are received using Basic authentication or HTTP forms-based authentication. In particular, credentials supplied in a Secure Sockets Layer (SSL) certificate cannot be passed to a published server.

Forefront TMG provides support for Kerberos constrained delegation (often abbreviated as KCD) to enable published Web servers to authenticate users by Kerberos after verifies their identity by using a non-Kerberos authentication method. When used in this way, Kerberos constrained delegation eliminates the need for requiring users to provide credentials twice. For example, because it is unrealistic to perform Kerberos authentication over the Internet, SSL certificates might be used for authenticating users at the Forefront TMG computer. After Forefront TMG verifies the user's identity, Forefront TMG cannot pass the SSL client certificate provided by the user to a published server, but it can impersonate the user and obtain a Kerberos service ticket for authenticating the user (client) to a published Web server.

A Forefront TMG computer serving as a firewall that sits between the Internet and your organization's intranet must authenticate clients that send requests over the Internet to servers in your organization to prevent attacks from anonymous and unauthorized users. Every organization determines which authentication method can ensure that external clients are identified with sufficient confidence and that unauthorized clients cannot gain access to a published internal server. Many large organizations (including Microsoft) are moving toward the use of smart cards, which are actually just secured storage devices for an SSL client certificate, as a means to identify their users instead of relying on passwords. Smart cards enable two-factor authentication based on something that the user has (the smart card) and something that the user knows (the personal identification number (PIN) for the smart card), providing a more secure level of authentication than passwords.

Internal servers often need to authenticate users who send requests to them both from computers on the Internet and from computers on the intranet within the organization. For example, a mail server must verify the identity of users, including internal users, before allowing them access to the appropriate personal mailboxes. The authentication performed by an edge firewall clearly does not fully meet the needs of these servers.

If Forefront TMG can forward a user's credentials to an internal server, there is no need to prompt the user for a second time to obtain appropriate credentials. However, when SSL client certificates are used, Forefront TMG cannot delegate a user's credentials to an internal mail server, such as a Microsoft Exchange server, because Forefront TMG never receives a password that can be passed on to that server. There is also no way to forward an SSL client certificate to another server. This is an intended security feature of the SSL protocol.

Kerberos constrained delegation provides a way for Forefront TMG to impersonate a user sending a Web request and to authenticate to specific services running on specific, published Web servers, including Exchange Outlook Web Access servers, when Forefront TMG knows only the user name after it verifies the identity of the user.

For more information about the authentication methods supported by Forefront TMG, see Overview of client authentication.

This topic provides general background information that could help you implement Kerberos constrained delegation in diverse Web publishing scenarios.

How Kerberos constrained delegation works

A thorough description of the Kerberos authentication protocol, including Kerberos constrained delegation, is given in "How the Kerberos Version 5 Authentication Protocol Works" at the Microsoft TechNet Web site. This section summarizes the details of the Kerberos authentication protocol related to Kerberos constrained delegation as it is used by Forefront TMG.

The Kerberos authentication protocol is used to confirm the identity of users that are attempting to access resources on a network. Kerberos authentication uses tickets that are encrypted and decrypted by secret keys and do not contain user passwords. These tickets are requested and delivered in Kerberos messages. Two types of tickets are used: ticket-granting tickets (TGTs) and service tickets.

A Kerberos client (a user or a service) sends requests for tickets to the Key Distribution Center (KDC) in the domain. Requests for TGTs are sent to the authentication service of the KDC, and requests for service tickets are sent to the ticket-granting service of the KDC. When a client sends a request to the authentication service with credentials that can be validated, the KDC returns a TGT to the client. A TGT is a special service ticket for the authentication service and enables the authentication service to pass the client's credentials to the ticket-granting service in requests for service tickets for a specific service on a specific host computer. A TGT is issued for a specific client and can be reused by the client in requests for additional service tickets for the same service. A client must obtain a new TGT from the authentication service before it can obtain service tickets for another service. Each service ticket issued by the ticket-granting service is for a specific service on a specific host computer.

The Kerberos protocol includes a mechanism called delegation of authentication. When this mechanism is used, the client (the requesting service) delegates authentication to a second service by informing the KDC that the second service is authorized to act on behalf of a specified Kerberos security principal, such as a user that has an Active Directory directory service account. The second service can then delegate authentication to a third service.

This is accomplished using a proxy TGT or a forwarded TGT. When a proxy TGT is used, the requesting service obtains a TGT for the third service in the security context of a specific user and then passes the TGT to the second service, which uses it to request service tickets. In this case, the requesting service must know the name of the third service. When a forwarded TGT is used, the requesting service obtains a TGT that is marked forwardable for the second service in the security context of the user. The second service can use this TGT to request tickets for other services as needed.

Only forwardable TGTs can be used for constrained delegation. A TGT can be marked forwardable only if the account under which the requesting service is running has the ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION control flag set. For Forefront TMG, this is the Active Directory computer account of the Forefront TMG computer. This flag is automatically set when the account under which the requesting service is running is configured as trusted for Kerberos constrained delegation in Active Directory.

Kerberos constrained delegation is a feature that was introduced in Microsoft Windows Server 2003 and is provided by two extensions included in the implementation of the Kerberos V5 authentication protocol in Windows Server 2008:

• Protocol transition The protocol transition extension allows a service that uses Kerberos to obtain a Kerberos service ticket to itself on behalf of a Kerberos security principal (a user or a computer) without requiring the principal to initially authenticate to the KDC. Instead, a user sending a request to a service with credentials, such as an SSL client certificate, that are not acceptable for Kerberos authentication can be authenticated by any appropriate Windows authentication method. When authentication is completed, Windows creates a user token. Then, if the service has the necessary impersonation privileges in Windows, when the service uses this token to impersonate the user and request a Kerberos service ticket to another service, the service ticket issued, which is to the requesting service, is mapped to the user token. The service may use the service ticket obtained through protocol transition to obtain service tickets to other services and thereby delegate the credentials if the account under which the service is running is configured correctly to use the Kerberos constrained delegation extension.

• Constrained delegation The constrained delegation extension allows a service to obtain service tickets (under the delegated user's identity) to a restricted list of other services running on specific servers on the network after it has been presented with a service ticket, which may be a service ticket obtained through protocol transition.

Constrained delegation provides a way for domain administrators to limit the network resources that a service trusted for delegation can access to a restricted list of network resources. This is accomplished by configuring the account under which the service is running to be trusted for delegation to a specific instance of a service running on a specific computer or to a set of specific instances of services running on specific computers.

Each instance of a service running on a computer is specified by a unique identifier, called a service principal name (SPN). The syntax of an SPN is service_class/host_name:port:

• The service class is a string that identifies the service. Windows has built-in service classes for many services, but the service class can also be defined by the user. For example, the built-in Windows service class for Internet Information Services (IIS) is http.

• The host name is the name of the computer on which the instance of the service is running. This can be a fully qualified domain name (FQDN) or a NetBIOS name, but not an IP address. The host name is optional, but it must be included in the SPNs used by Forefront TMG.

• The port number is optional. It is used to differentiate between multiple instances of the same service on a single host computer. It can be omitted if the service uses the default port for its service class.

Each instance of a service that uses Kerberos authentication needs to have an SPN defined for it so that clients can identify that instance of the service on the network. The SPN is registered in the Active Directory Service-Principal-Name attribute of the Windows account under which the instance of the service is running. This way, the SPN is associated with the account under which the instance of the service specified by the SPN is running. When a service needs to authenticate to another service running on a specific computer, it uses that service's SPN to differentiate it from other services running on that computer.

Registration of an SPN in Active Directory maps the SPN to the Windows account under which the service specified in the SPN is running. Instances of services can automatically register their SPNs at startup. Administrators can use the Setspn.exe tool for Windows Server 2003 to manually register SPNs, as well as to read, modify, and delete the SPNs registered in a Windows account. The Setspn.exe tool can be especially useful for verifying that a specific SPN is registered in a specific Active Directory account. For information about obtaining and installing the Setspn.exe tool, see the Microsoft Knowledge Base article 892777, "Windows Server 2003 Service Pack 1 Support Tools."

To enforce constrained delegation, Active Directory maintains a list of the SPNs of the instances of services to which a service running under a specific account is allowed to delegate, that is, to obtain service tickets that can be used for constrained delegation. This list of SPNs is stored in the new Active Directory ms-DS-Allowed-to-Delegate-to attribute of computer and user accounts on computers that are running Windows Server 2008. When a Windows Server 2008 KDC processes a service ticket request by using the constrained delegation extension, the KDC verifies that the SPN of the target service is included in the list of SPNs in the ms-DS-Allowed-to-Delegate-to attribute.

Computers that are running Windows Server 2008 support two modes of delegation: Kerberos unconstrained delegation and Kerberos constrained delegation. Kerberos unconstrained delegation is supported if a user initially provides credentials for obtaining a TGT that can be forwarded to any service that is trusted for delegation. This behavior is the same as the Microsoft Windows 2000 Server behavior for Kerberos implementations. Constrained delegation can be used by a service if the service can obtain a Kerberos service ticket to itself on behalf of the user whose security context is to be delegated. With Kerberos constrained delegation, it does not matter whether the user obtained the service ticket directly by authenticating through Kerberos or whether the service obtained the service ticket on behalf of the user through the protocol transition extension.

For a service to use protocol transition in conjunction with Kerberos constrained delegation and obtain a Kerberos service ticket to a specific service on behalf of a user that was authenticated by a non-Kerberos authentication method, the account under which the service is running must be configured in Active Directory to allow Kerberos constrained delegation to any authentication protocol. In addition, the impersonated user account must not be marked as a sensitive account that cannot be delegated.

How Forefront TMG uses Kerberos constrained delegation

Without Kerberos constrained delegation, Forefront TMG can delegate credentials only when client credentials are received using Basic authentication or HTTP forms-based authentication. Credentials supplied in an SSL certificate cannot be delegated. With Kerberos constrained delegation, Forefront TMG can delegate client credentials that are supplied for the following types of authentication:

• Basic authentication

• Digest authentication

• Integrated authentication

• SSL client certificate authentication

• Forms-based authentication with user name/password credentials

• Forms-based authentication with user passcode

After verifying the identity of a user sending a Web request using a non-Kerberos authentication protocol, Forefront TMG can use Kerberos protocol transition to switch to the Kerberos protocol for authentication on behalf of the user and then send a Kerberos service ticket instead of the user's credentials to a published Web server that accepts Kerberos for authentication. This concept is implemented in the following steps:

1. In step 1, a user sending a Web request is authenticated by Forefront TMG through a non-Kerberos authentication method with the Windows (Active Directory) validation method.

2. In step 2, when the authentication is completed, a Windows user token is created for the authenticated user. Because the user was not authenticated by Kerberos, the user token is not associated with a Kerberos service ticket. Conversely, when a user is authenticated by the Kerberos protocol, the user token is indirectly linked to a Kerberos service ticket for the user.

3. In step 3, Forefront TMG uses the user token to impersonate the user and request a Kerberos service ticket for a specific service on the published Web server on behalf of the user.

4. In step 4, the Windows Server 2008 operating system on the Forefront TMG computer detects that there is no Kerberos service ticket in the user token and automatically initiates protocol transition by requesting a service ticket to Forefront TMG for the impersonated user.

5. In step 5, the service ticket issued through protocol transition is mapped to the user token, and Forefront TMG uses it to request a service ticket to the published service. When Kerberos constrained delegation is configured properly, the published Web server accepts this Kerberos service ticket instead of user name/password credentials, and the user is authenticated.

The Kerberos service ticket to the published service can be used by the Web server to obtain additional service tickets to other services on behalf of the same user. For example, if an Exchange front-end server that is published by Forefront TMG is configured in Active Directory to be trusted for delegation to an Exchange back-end server that accepts Kerberos authentication, the Exchange front-end server can obtain service tickets to the Exchange back-end server on behalf of users that have been authenticated by the Forefront TMG computer.

Additional technical details

Forefront TMG delegates authentication by requesting a forwardable TGT for a specific target service running on a specific host computer in the security context of an Active Directory user that has been authenticated by Forefront TMG. The KDC then creates a forwardable TGT for the computer that hosts the target service in the user's name and sends it back to Forefront TMG. Forefront TMG then forwards this TGT to the computer that hosts the target service, which can use it to request service tickets for the specified target service and to request new tickets for other services.

The KDC issues forwardable TGTs only if the account under which the requesting service is running has the ADS_UF_TRUSTED_TO_AUTHENTICATE_FOR_DELEGATION control flag set in Active Directory. This flag is automatically set when the account under which the requesting service is running is configured as trusted for delegation in Active Directory. For Forefront TMG, this account is the computer account of the Forefront TMG computer that requests forwardable TGTs.

Credentials are delegated to the published server for each request when Kerberos constrained delegation is used.

If authentication fails, Forefront TMG provides the server's failure notice to the client. If the server requires a different type of credentials, a Forefront TMG alert is triggered.

Setting up Kerberos constrained delegation

The following prerequisites must be met to use Kerberos constrained delegation for authenticating a user to a Web server published by Forefront TMG:

• The Forefront TMG computer, the published Web server or member of a published server farm, the domain controller that issues the Kerberos service tickets, and all other computers, such as back-end servers to which the Kerberos service tickets are passed, must be members of the same Active Directory domain. Forefront TMG does not support using cross-domain or cross-forest trusts to include additional Active Directory domains in a Kerberos constrained delegation scenario.

• This domain must be set to the Windows Server 2003 functional level or the Windows Server 2008 functional level.

  Note

  By default, a Windows Server 2003 domain is set to the Windows 2000 functional level.

• The user sending a Web request must have an Active Directory user account in this domain or another domain in the local forest. The possibility of including users from other forests is beyond the scope of this documentation.

• The SPN for the target service on the Web server must be registered in the Windows account under which the service runs. Services can automatically register their SPNs, or administrators can use the Setspn.exe tool for Windows Server 2003 to manually register SPNs.

• The computer account of the Forefront TMG computer must be configured in Active Directory as trusted for Kerberos constrained delegation, constrained to the SPN that specifies the target service on the published Web server. This is accomplished by selecting the Trust this computer for delegation to specified services only option and specifying the SPN of the target service on the published Web server as a service to which this account can present delegated credentials in the properties of the computer account in Active Directory Users and Computers.

  Note

  If a Forefront TMG computer is compromised when Kerberos constrained delegation is enabled, an attacker can impersonate any domain user and request service tickets to any service that is specified in Active Directory as a service to which delegated credentials can be presented. Therefore, SPNs should be defined only for servers that are published by Forefront TMG.

• To enable protocol transition, the computer account of the Forefront TMG computer must also be configured in Active Directory to allow Kerberos constrained delegation to any authentication protocol. This is accomplished by selecting the Use any authentication protocols option in the properties of the computer account in Active Directory Users and Computers.

• The Web server must be configured to support Integrated authentication, which includes Kerberos authentication, on the virtual directory to which the requests are sent.

• A Web listener that uses an authentication method with the Windows (Active Directory) validation method to authenticate users and a Web publishing rule that is configured to use Kerberos constrained delegation for authentication delegation to the published server must be created.

• Authentication using SSL client certificates requires deployment of a public key infrastructure (PKI) for issuing the client certificates and mapping them to the user accounts in Active Directory, installation of the root certificate of the certification authority that issues the SSL client certificates on the Forefront TMG computer, and installation of an SSL server certificate with the name that users use to access the published Web site on the Forefront TMG computer. For more information about deploying these certificates, see "Outlook Web Access Server Publishing in ISA Server 2004: Client Certificates and Forms-based Authentication" at the Microsoft TechNet Web site.

In Forefront TMG, the service principal name (SPN) is used for requesting a Kerberos service ticket when delegation using Kerberos constrained delegation is configured for a Web publishing rule. By default, the SPN specified in Forefront TMG Management on the Authentication Delegation tab in the properties of a Web publishing rule for an individual Web server is set to http/internal_site_name, and the SPN for a server farm is set to http/*. This SPN must match the SPN that is specified on the Delegation tab in the properties of the computer account of the Forefront TMG computer in Active Directory Users and Computers.

In Microsoft Exchange Server 2003, IIS runs under the Network Service account. For published Exchange servers, Forefront TMG uses an SPN consisting of the service class http and the internal site name of the published site for a single Exchange server or an asterisk for a server farm of Exchange servers.

By default, Microsoft Office SharePoint Portal Server 2003 disables Kerberos, so NTLM/Kerberos (Negotiate) and Kerberos constrained delegation will not work with Microsoft Windows SharePoint Services publishing. To enable Kerberos, follow the instructions in the Microsoft Knowledge Base article 832769, "How to configure a Windows SharePoint Services virtual server to use Kerberos authentication and how to switch from Kerberos authentication back to NTLM authentication."

Copyright © 2009 by Microsoft Corporation. All rights reserved.