Kerberos Constrained Delegation in ISA Server 2006

Kerberos Constrained Delegation in ...

Microsoft Internet Security and Acceleration Server 2006

Microsoft® Internet Security and Acceleration (ISA) Server 2006 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 ISA Server 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. ISA Server 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.

ISA Server 2006 introduces support for Kerberos constrained delegation to enable published Web servers to authenticate users by Kerberos after their identity has been verified by ISA Server 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 ISA Server computer. After ISA Server verifies the user's identity, ISA Server 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.

Bb794858.ebb1f8c8-9416-4cb0-b1c3-236aefe6556d(en-us,TechNet.10).gif

An ISA Server 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 ISA Server 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, ISA Server cannot delegate a user's credentials to an internal mail server, such as a Microsoft Exchange server, because ISA Server 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 ISA Server to impersonate a user sending a Web request and authenticate to specific services running on specific, published Web servers, including Exchange Outlook Web Access servers, when ISA Server knows only the user name after it verifies the identity of the user.

For more information about the authentication and delegation methods supported by ISA Server 2006, see "Authentication in ISA Server 2006" at the Microsoft TechNet Web site.

This document provides general background information that could help you implement Kerberos constrained delegation in diverse Web publishing scenarios as well as specific information, including step-by-step procedures, for implementing Kerberos constrained delegation for publishing Outlook Web Access in Exchange Server 2003 with smart card-only authentication. If you only want to implement this particular scenario, you can skip directly to the section describing it.

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 ISA Server 2006.

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 ISA Server, this is the Active Directory computer account of the ISA Server 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 new extensions included in the implementation of the Kerberos V5 authentication protocol in Windows Server 2003:

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 ISA Server.
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 2003. When a Windows Server 2003 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.

With the addition of constrained delegation, computers that are running Windows Server 2003 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.

Note:
ISA Server 2006 supports Kerberos constrained delegation only within the boundary of a domain.

How ISA Server uses Kerberos constrained delegation

Without Kerberos constrained delegation, ISA Server 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, ISA Server 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

Note:
Integrated authentication can use either the Kerberos V5 authentication protocol, the NTLM authentication protocol, or a challenge/response authentication protocol.

After verifying the identity of a user sending a Web request using a non-Kerberos authentication protocol, ISA Server 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:

In step 1, a user sending a Web request is authenticated by ISA Server through a non-Kerberos authentication method with the Windows (Active Directory) validation method.
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.
In step 3, ISA Server 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.
In step 4, the Windows Server 2003 operating system on the ISA Server computer detects that there is no Kerberos service ticket in the user token and automatically initiates protocol transition by requesting a service ticket to ISA Server for the impersonated user.
In step 5, the service ticket issued through protocol transition is mapped to the user token, and ISA Server 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 ISA Server 2006 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 ISA Server computer.

Additional technical details

ISA Server 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 ISA Server. 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 ISA Server. ISA Server 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 ISA Server, this account is the computer account of the ISA Server computer that requests forwardable TGTs.

Note:
The access of a service ticket to a target service is limited to the access granted to the user on behalf of whom the service ticket was issued.

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

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

Setting up Kerberos constrained delegation for ISA Server

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

The ISA Server 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. ISA Server 2006 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.

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

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

The computer account of the ISA Server 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 an ISA Server 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 ISA Server.

To enable protocol transition, the computer account of the ISA Server 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 ISA Server computer, and installation of an SSL server certificate with the name that users use to access the published Web site on the ISA Server 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 ISA Server 2006, 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 ISA Server 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 ISA Server computer in Active Directory Users and Computers.

In Microsoft Exchange Server 2003, IIS runs under the Network Service account. For published Exchange servers, ISA Server 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.

Note:
Kerberos authentication depends on User Datagram Protocol (UDP) packets, which are commonly fragmented. If your ISA Server computer (or array in ISA Server Enterprise Edition) is in a domain and the blocking of IP fragments is enabled, Kerberos authentication will fail. We recommend that you do not enable the blocking of packets containing IP fragments in scenarios where Kerberos authentication is used. By default, Microsoft 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 , "How to configure a Windows SharePoint Services virtual server to use Kerberos authentication and how to switch from Kerberos authentication back to NTLM authentication."

Note:

Kerberos authentication depends on User Datagram Protocol (UDP) packets, which are commonly fragmented. If your ISA Server computer (or array in ISA Server Enterprise Edition) is in a domain and the blocking of IP fragments is enabled, Kerberos authentication will fail. We recommend that you do not enable the blocking of packets containing IP fragments in scenarios where Kerberos authentication is used.
By default, Microsoft 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 , "How to configure a Windows SharePoint Services virtual server to use Kerberos authentication and how to switch from Kerberos authentication back to NTLM authentication."

Typical scenario: Publishing Outlook Web Access in Exchange Server 2003 with smart card-only authentication

In this scenario, you want to enable remote users who have smart cards with SSL client certificates that are mapped to Active Directory user accounts in the local domain of a mail server running Exchange Server 2003 to access their mailboxes by sending HTTPS requests over the Internet that include the public name of the Exchange server and specify the /Exchange virtual directory without being prompted twice for their credentials. These requests are directed to an ISA Server computer that publishes the Exchange server and belongs to the same domain as the Exchange server. The ISA Server computer must authenticate the remote users to protect the organization's network, and the Exchange server must also authenticate the users to ensure that only the appropriate user can access a mailbox.

The solution described in this section allows ISA Server to authenticate the users using the SSL client certificates installed on their smart cards, and then to authenticate on their behalf to the Exchange server using Kerberos constrained delegation without the need for a password. This solution requires installation of Exchange Server 2003 with Service Pack 2 (SP2) and the software update described in the Microsoft Knowledge Base article 920209, "Description of the new feature in Exchange Server 2003 that supports Smart Card authentication to Outlook Web Access" on the Exchange server (or servers) published by ISA Server. Without this software update, a user name and password are required to log on to Outlook Web Access.

This section also includes instructions for implementing the solution with multiple published Exchange servers in a server farm and for deployments with both Exchange front-end and back-end servers. If you publish multiple Exchange servers in a server farm, they should be configured as Exchange front-end servers that do not store mailboxes, and the mailboxes should be stored on Exchange back-end servers.

For more information about publishing Exchange Server 2003, see "Publishing Exchange Server 2003 with ISA Server 2006" at the Microsoft TechNet Web site.

Configuring Active Directory to enable Kerberos constrained delegation

In this scenario, the ISA Server computer and the published Exchange server (or servers in a server farm) are members of the same Active Directory domain that is set to the Windows Server 2003 functional level. Kerberos constrained delegation and protocol transition are used to enable ISA Server to impersonate users that want to access their e-mail, calendar, and other information in the Exchange Server store. To enable Kerberos constrained delegation, the Active Directory computer account of the ISA Server computer must be configured as trusted for delegation to the target service on the published Exchange server (or servers in a server farm), and the target service must also be configured as trusted for delegation. To enable protocol transition, the computer account of the ISA Server computer must also be configured to allow Kerberos constrained delegation to any authentication protocol.

Verifying the functional level of the local domain

The Active Directory domain in which the ISA Server computer, the published Exchange server (or servers in a server farm), and the domain controller that issues the Kerberos service tickets for constrained delegation reside must be set to the Windows Server 2003 functional level.

Note:
ISA Server 2006 does not support using cross-domain or cross-forest trusts to include more than one Active Directory domain in a Kerberos constrained delegation scenario.

To verify the functional level of a domain

Open Active Directory Users and Computers.
Right-click the name of the applicable domain, and then click Properties.
Verify that Windows Server 2003 is listed under Domain functional level.

If the functional level of the local domain is not set to the Windows Server 2003 functional level, you can raise its functional level by performing the following steps.

Note:
If you have any domain controllers running earlier versions of Windows in the domain, do not raise the functional level to Windows Server 2003. After the functional level of a domain is set to Windows Server 2003, it cannot be changed back.

To raise the functional level of a domain to Windows Server 2003

In the Active Directory Users and Computers console tree, right-click the name of the applicable domain, and then click Raise Domain Functional Level.
In Select an available functional level, click Windows Server 2003, and then click Raise.

Configuring Active Directory to recognize an ISA Server computer as trusted for delegation to a published Exchange server

To enable Kerberos constrained delegation from an ISA Server computer to a published Exchange server, the Active Directory computer account of the ISA Server computer must be configured as trusted for delegation to the target service on the published Exchange server (or servers in a server farm). In a deployment with Exchange front-end and back-end servers, the procedures described in this section apply to only the front-end servers.

To configure Active Directory to recognize an ISA Server computer as trusted for delegation to a published Exchange server

In the Active Directory Users and Computers console tree, expand the Domain_Name node and click Computers.
In the details pane, double-click the name of the applicable ISA Server computer.
On the Delegation tab, select Trust this computer for delegation to specified services only, and then select Use any authentication protocol.
Click Add.
In the Add Services dialog box, click Users or Computers.
In the Select Users or Computers dialog box, enter the NetBIOS name of the Exchange server (or names of the Exchange servers in a server farm). Click Check Names after you type each name, and then click OK.
In the Add Services dialog box, find http in the list of available services. Select the entry for the Exchange server (or hold down the CTRL key and select the entries for the servers in a server farm) and click OK.
On the Delegation tab, verify that http appears under Service Type and that the name of the Exchange server (or names of the Exchange servers in a server farm) appear under User or Computer, and then click OK.
In ISA Server Enterprise Edition, repeat Steps 2 through 8 for each array member.

Configuring ISA Server to enable Kerberos constrained delegation

In this scenario, ISA Server must be configured to use Kerberos constrained delegation and send Kerberos service tickets to a published Exchange Outlook Web Access server with each request. This is accomplished by creating a Web listener and a Web publishing rule to publish a single Exchange server or a server farm of Exchange servers and configuring the Web publishing rule to use Kerberos constrained delegation to authenticate to the published Exchange server (or servers in a Web farm).

Creating the Web listener

The Web publishing rule needed in this scenario uses a Web listener that listens on the IP address to which users send their requests, requires SSL client certificate authentication and SSL secured connections with the clients, and uses an SSL server certificate installed on the ISA Server computer.

The common name on the SSL server certificate must match the public name of your Outlook Web Access site. For information about obtaining and deploying SSL server certificates, see "Digital Certificates for ISA Server 2004" at the Microsoft TechNet Web site.

To create the Web listener

Open ISA Server Management.
In the console tree, click Firewall Policy:
- For ISA Server Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.
- For ISA Server Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
In the task pane, click the Toolbox tab.
On the Toolbox tab, click Network Objects, click New, and then select Web Listener.

Complete the New Web Listener Wizard as outlined in the following table.

Page	Field or property	Setting or action
Welcome to the New Web Listener Wizard	Web listener name	Type a name for the Web listener. For example, type Exchange Publishing Listener.
Client Connection Security		Select Require SSL secured connections with clients.
Web Listener IP Addresses	Listen for incoming Web requests on these networks	Select the External network. Click Select IP Addresses, and select Specified IP Addresses on the ISA Server computer in the selected network. Under Available IP Addresses, select the appropriate IP address, click Add, and then click OK. In an ISA Server Enterprise Edition array with multiple array members, select the same virtual IP address for each array member if Network Load Balancing is enabled. Otherwise, select an appropriate IP address for each array member.
Listener SSL Certificates		Select Assign a certificate for each IP address, click Select Certificate, select the IP address that you selected on the Web Listener IP Addresses page, click Select Certificate, select the server certificate whose name matches the public name of your Outlook Web Access site, and click Select. If you selected multiple IP addresses on the Web Listener IP Addresses page, repeat this step for each IP address.
Authentication Settings	Select how clients will provide credentials to ISA Server	Select SSL Client Certificate Authentication.
	Select how ISA Server will validate client credentials	Select Windows (Active Directory) (the only available option).
Single Sign On Settings		Single sign on is not available when SSL client certificate authentication is used.
Completing the New Web Listener Wizard		Review the settings and click Finish.

In the details pane, click the Apply button to save and update the configuration, and then click OK.

Creating a server farm of Exchange servers in ISA Server (optional)

If you want to publish a server farm of Exchange servers that are load balanced by ISA Server, you must create a server farm network object that defines the server farm, and then use this network object in the Web publishing rule that publishes your Exchange servers. The creation of a server farm in ISA Server eliminates the need for including the Exchange servers in a Network Load Balancing (NLB) cluster. The Exchange servers included in this server farm must belong to the same Active Directory domain as the ISA Server computer. Note that a server farm that is published in a Web publishing rule is sometimes called a Web farm.

Your can create your server farm before performing the other steps to configure ISA Server for Kerberos constrained delegation, or you can perform these steps when you run the New Exchange Publishing Rule Wizard to create the Web publishing rule.

Note:
The Exchange servers included in a server farm should be configured as front-end servers that do not store mailboxes. All mailboxes should be stored on Exchange back-end servers.

To create a server farm of Exchange servers

Open ISA Server Management.
In the console tree, click Firewall Policy:
- For ISA Server Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.
- For ISA Server Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
In the task pane, click the Toolbox tab.
On the Toolbox tab, click Network Objects, click New, and then select Server Farm.

Complete the New Server Farm Wizard as outlined in the following table.

Page	Field or property	Setting or action
Welcome to the New Server Farm Wizard	Server farm name	Type a name for the server farm. For example, type Exchange Server Farm.
Servers	Servers included in this farm	For each Exchange server that you want to include in the server farm, click Add. Then in Server Details, click Browse, in Enter the object name to select, type the NetBIOS name of the Exchange server, click Check Names, click OK, and click OK again.
Server Farm Connectivity Monitoring	Method used to monitor server farm connectivity	Select the method that ISA Server will use to verify connectivity with the Exchange servers in the server farm. If you select Send an HTTP/HTTPS GET request and you want to specify a URL that differs from the URL that will be set in the Web publishing rule for this server farm, or if you want to specify a custom Host header that differs from the Host header that will be sent based on the Web publishing rule, click Configure, type the URL and HOST header, and click OK.
Completing the New Server Farm Wizard		Review the settings and click Finish.

In the message box indicating the Allow HTTP/HTTPS requests from ISA Server to selected servers for connectivity verifiers system policy rule will be enabled, click OK.
In the details pane, click the Apply button to save and update the configuration, and then click OK.

Restricting the certificates that clients can present (optional)

When SSL client certificate authentication or forms-based authentication of clients that are required to present an SSL client certificate is used, you can restrict client access by configuring the Web listener to accept only client certificates issued by specific trusted certification authorities, which are specified by selecting the applicable certificates in the Trusted Root Certification Authorities and Intermediate Certification Authority stores in the Web listener properties. For example, you can restrict access to managed client computers by configuring the Web listener to trust only client certificates that were issued by the enterprise certification authority of your organization.

To enforce a client certificate trust list

In the ISA Server Management console tree, click Firewall Policy:
- For ISA Server Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.
- For ISA Server Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
In the task pane, click the Toolbox tab.
Select Network Objects.
Expand Web Listeners.
Select the Web listener that you created in the previous procedure.
Click Edit.
On the Authentication tab, click Advanced.
On the Client Certificate Trust List tab, select Only accept client certificates trusted by the Root Certification Authorities selected below.
Under Issued To, select one or more certification authorities that issue the SSL client certificates that ISA Server should accept, and then click OK.

Note:
If you created your own certification authority, its root certificate must be distributed to all of your users and installed on their computers.
In the details pane, click the Apply button to save and update the configuration, and then click OK.

Note:
If you created your own certification authority, its root certificate must be distributed to all of your users and installed on their computers.

Client access can also be restricted by configuring the Web listener to accept only certificates that match at least one of the SSL client certificate restrictions defined for it. A client certificate restriction may apply to one of the following fields:

Issuer
Subject
Enhanced Key Usage
Extensions

A restriction may include an object identifier (OID) and a value that must be present in the specified field. For example, a certificate restriction can limit the client certificates that a Web listener will accept to those whose Enhanced Key Usage field contains the Smart Card Logon object identifier 1.3.6.1.4.1.311.20.2.2.

To restrict the acceptable client certificates to SSL client certificates on smart cards

In the ISA Server Management console tree, click Firewall Policy:
- For ISA Server Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.
- For ISA Server Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
In the task pane, click the Toolbox tab.
Select Network Objects.
Expand Web Listeners.
Select the Web listener that you created.
Click Edit.
On the Authentication tab, click Advanced.
On the Client Certificate Restrictions tab, select Accept the client certificate only if it matches at least one defined restriction.
Click Add.
In Restriction name, type a name for the restriction. For example, type Smart Cards Only.
In Certificate field, select Enhanced Key Usage.
In Match this OID in the selected certificate field, type the Smart Card Logon object identifier 1.3.6.1.4.1.311.20.2.2, and then click OK.
Click OK.
In the details pane, click the Apply button to save and update the configuration, and then click OK.

Creating the Web publishing rule

To configure ISA Server to use Kerberos constrained delegation and send Kerberos service tickets to an Exchange server with each request, you must have an Exchange publishing rule that is configured to use Kerberos constrained delegation to authenticate to the published Exchange server (or servers in a Web farm). In ISA Server Enterprise Edition, the settings in this Web publishing rule apply to all ISA Server computers in the array.

To create an Exchange publishing rule for Kerberos constrained delegation

In the ISA Server Management console tree, click Firewall Policy:
- For ISA Server Enterprise Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Arrays, expand Array_Name, and then click Firewall Policy.
- For ISA Server Standard Edition, expand Microsoft Internet Security and Acceleration Server 2006, expand Server_Name, and then click Firewall Policy.
In the task pane, click the Tasks tab.
On the Tasks tab, click Publish Exchange Web Client Access to open the New Exchange Publishing Rule Wizard.

Complete the New Exchange Publishing Rule Wizard as outlined in the following table.

Page	Field or property	Setting or action
Welcome to the New Exchange Publishing Rule Wizard	Exchange Publishing rule name	Type a name for the rule. For example, type Exchange Publishing.
Select Services	Exchange version	Select Exchange Server 2003.
	Web client mail services	Select Outlook Web Access.
Publishing Type		Select Publish a single Web site or load balancer if you are publishing a single Exchange server. Or, select Publish a server farm of load balanced Web servers if you are publishing a server farm of Exchange servers.
Server Connection Security		Select Use SSL to connect to the published Web server or server farm. This option is the recommended best practice. SSL adds encryption and ensures that no one on the same network segment can read private mail. When this option is selected, an SSL server certificate with the applicable name must be installed on the published Exchange server (or servers in a server farm), and the root certification authority certificate of the certification authority that issued the server certificate must be installed on the ISA Server computer.
Internal Publishing Details	Internal site name	Type the host name that internal users supply in a URL to reach the Web site. If you are publishing a single Exchange server and the internal site name specified in this field is not resolvable and is not the computer name or IP address of the published server, select Use a computer name or IP address to connect to the published server, and type the resolvable computer name or IP address of the published server. If you are publishing a server farm of Exchange servers, the internal site name must be resolvable. The internal site name can be set to the DNS name of one of the servers in the server farm.
Specify Server Farm This page appears only if you selected Publish a server farm of load balanced Web servers on the Publishing Type page.	Select the Exchange server farm you want to publish	Select the applicable server farm. Then click Edit and verify that an FQDN or NetBIOS name is specified for each member of the server farm. If an IP address is specified for any member of the server farm, change the IP address to the applicable FQDN or NetBIOS name. This is important because these names must match the host names in the automatically registered SPNs for these servers.
Public Name Details	Accept requests for	Select This domain name (type below).
	Public name	Type the public FQDN or IP address that external users will use to access the published Web site.
Select Web Listener	Web listener	Select the Web listener previously created.
Authentication Delegation	Select the method used by ISA Server to authenticate to the published Web server	Select Kerberos constrained delegation.
	Type the Service Principle Name (SPN) used by ISA Server for Kerberos constrained delegation	Do not change the default http/internal_site_name for a single Exchange server or http/* for a server farm.
User Sets	This rule applies to requests from the following user sets	Do not change the default All Authenticated Users.
Completing the New Exchange Publishing Rule Wizard		Review the settings and click Finish.

In the message box indicating that you must configure Active Directory to allow ISA Server to delegate authentication to the selected SPNs for Kerberos constrained delegation to work, click OK.
In the details pane, click the Apply button to save and update the configuration, and then click OK.

This Web publishing rule specifies SSL bridging with encrypted communication channels from external clients to the ISA Server computer and from the ISA Server computer to the published Exchange server. With this type of SSL bridging, ISA Server protects against attacks that are hidden in SSL-encrypted connections and prevents anyone on the same network segment from reading private mail. After a client request arrives, the SSL connection with the client computer is terminated at the ISA Server computer, and ISA Server decrypts and inspects the traffic received from the client. Then ISA Server initiates a second SSL connection to forward the traffic to the published Exchange server.

When an SSL connection is established between the external client and the ISA Server computer, the ISA Server computer presents the SSL server certificate specified in the Web listener to confirm its identity to the external client. This certificate must have the name that users use to access the published Web site, and the root certification authority certificate of the certification authority that issued the server certificate must be installed on the client.

When an SSL connection is established between the ISA Server computer and the published Exchange server, the ISA Server computer is an SSL client and requires that the published Exchange server responds with an SSL server certificate. The root certification authority certificate of the certification authority that issued this server certificate must be installed on the ISA Server computer. For more information about deploying these certificates, see "Digital Certificates for ISA Server 2004" at the Microsoft TechNet Web site. For more information about deploying an SSL server certificate on an Exchange server published by ISA Server, see "Publishing Exchange Server 2003 with ISA Server 2006" at the Microsoft TechNet Web site.

Configuring Exchange Server for Kerberos constrained delegation

In this scenario, to use Kerberos constrained delegation, the virtual directory used for Outlook Web Access on all the Exchange servers in your deployment (the /Exchange virtual directory in this solution) must be configured to accept Kerberos authentication, and Kerberos constrained delegation must be enabled on your Exchange servers. If your deployment includes both Exchange front-end and back-end servers, your Exchange front-end servers must be configured as front-end servers that support Kerberos constrained delegation.

Configuring the /Exchange virtual directory to accept Kerberos authentication

In the solution described in this section, the /Exchange virtual directory is used for Outlook Web Access on the Exchange server. To enable Kerberos constrained delegation from ISA Server, this virtual directory must be configured to accept Kerberos authentication. This is accomplished by setting the authentication method allowed on the /Exchange virtual directory to Integrated authentication. With Integrated authentication, users are authenticated by using either the Kerberos V5 authentication protocol, the NTLM authentication protocol, or a challenge/response authentication protocol.

Important:
Before you perform these procedures on an Exchange server, you must install Exchange Server 2003 SP 2 and the software update described in the Microsoft Knowledge Base article 920209, "Description of the new feature in Exchange Server 2003 that supports Smart Card authentication to Outlook Web Access" on the Exchange server (or servers) published by ISA Server.

To set the authentication method for the /Exchange virtual directory on an Exchange server

Open System Manager for Exchange Server.
If administrative groups are displayed, expand the Administrative Groups node, and expand Administrative_Group_Name.
Expand Servers, and then expand Exchange_Server_Name.
Expand Protocols, expand HTTP, expand Exchange Virtual Server, right-click Exchange, and then click Properties.
On the Access tab, click Authentication.
Select the Integrated Windows Authentication check box and verify that the Basic Authentication check box is cleared.
Click OK, and then click OK again.
Repeat this procedure on each Exchange server in your deployment.

Enabling Kerberos constrained delegation on Exchange servers

Kerberos constrained delegation must be enabled on the Exchange servers in your deployment.

To enable Kerberos constrained delegation on Exchange servers

In System Manager, locate the administrative group that contains the Exchange servers on which you want to enable Kerberos constrained delegation.
Right-click Administrative_Group_Name, and then click Properties.
Select the Enable Kerberos Constrained Delegation check box, and then click Modify.

Type the credentials for the account under which the KCD Service runs.

Note:
The account under which the KCD Service runs must have the Enable computers and user accounts to be trusted for delegation attribute configured in the Domain Group Policy object (GPO).

Click Apply, and then click OK.

Configuring an Exchange front-end server to support Kerberos constrained delegation

If your deployment includes both Exchange front-end and back-end servers, each of your Exchange front-end servers must be configured as a front-end server that supports Kerberos constrained delegation.

To configure an Exchange front-end server as a front-end server that supports Kerberos constrained delegation

In System Manager, right-click the applicable server, and then click Properties.
On the General tab, verify that the This is a front-end server check box is selected to confirm that you are configuring a front-end server.
On the KCD-FE tab, click This server is a KCD-FE server for the organization.
Click Apply, click OK, and then restart the Exchange System Attendant service.
Repeat these steps on each front-end server that you want to enable as a front-end server that supports Kerberos constrained delegation.

After completing the preceding three procedures, restart Microsoft Internet Information Services (IIS) on all your Exchange servers to propagate the changes in the authentication mechanisms. To do this, type iisreset at a command prompt, and then press ENTER.

Requiring secure communications to the Web site

After an SSL server certificate is installed on the Exchange server, you need to require the Web site to accept communications only over a secure (SSL) channel.

Perform the following procedure to require an SSL channel for communication to the Web site.

To enable secure communications

Open IIS Manager.
Expand the local computer, and then expand the Web Sites folder.
Right-click the Web site where the Exchange front-end services have been installed, by default, the Default Web Site, and click Properties.
On the Directory Security tab, under Secure communications, click Edit.
Select Require secure channel (SSL) on the Secure Communication page, and then click OK. Click OK again to close the Web site properties dialog box.

Note:
If you have multiple Exchange front-end servers providing Exchange Web client access, perform this procedure on each front-end server.

Deployments with Exchange front-end and back-end servers

If your deployment includes Exchange servers that are configured as front-end and back-end servers, ISA Server can forward Web requests to an Exchange front-end server using Kerberos constrained delegation after authenticating the user just as it does to the Exchange servers in the preceding sections, and ISA Server computers can be configured for this by following the steps for configuring Exchange servers in the preceding sections. In addition, the /Exchange virtual directory on Exchange back-end servers can be configured to accept Kerberos authentication by performing the same steps that are performed for an Exchange front-end server. However, these steps do not configure Exchange front-end servers to be trusted for delegation or allow Exchange back-end servers to trust the Kerberos service tickets sent by an Exchange front-end server. This is accomplished by performing the following steps.

To configure Active Directory to recognize an Exchange front-end server as trusted for delegation and to allow an Exchange back-end server to trust Kerberos service tickets sent by the Exchange front-end server

In the Active Directory Users and Computers console tree, expand the Domain_Name node and click Computers.
In the details pane, double-click the name of an Exchange front-end server.
On the Delegation tab, select Trust this computer for delegation to specified services only, and then select Use any authentication protocol.
Click Add.
In the Add Services dialog box, click Users or Computers.
In the Select Users or Computers dialog box, enter the NetBIOS name of the Exchange back-end servers that serve the selected Exchange front-end server. Click Check Names after you type each name, and then click OK.
In the Add Services dialog box, find http in the list of available services. Select the entry for an Exchange back-end server (or hold down the CTRL key and select the entries for all the Exchange back-end servers that serve the selected front-end server) and click OK.
On the Delegation tab, verify that http appears under Service Type and that the names of the Exchange back-end servers appear under User or Computer, and then click OK.
Repeat this procedure for each Exchange front-end server in your deployment.

The computers specified in the list of SPNs created by this procedure must contain only back-end servers. The Exchange System Attendant service automatically maintains this list and ensures that it includes all the back-end servers in the domain after installation of the software update described in the Microsoft Knowledge Base article 920209, "Description of the new feature in Exchange Server 2003 that supports Smart Card authentication to Outlook Web Access."