Reducing Kerberos requests when using KCD for web publishing.

1. Introduction

If you have read the article “Kerberos Constrained Delegation in ISA Server 2006” and followed the instructions how to publish a web server by using Kerberos Constrained Delegation, you might expect that the Kerberos authentication requests should be quite low as Kerberos uses tickets. You might also expect that those tickets will be stored somehow and will be reused by the subsequent GET requests on the same session. I can tell you you’re too trustful to think that this will happen without additional configuration on ISA server and the backend web server(s).

2. Symptoms

On one of my Onsite I had a look on some ISA daily reports and I saw that their ISA server array members have submitted more Kerberos requests than http(s) requests (Figure 1). This behavior was not expected at all as the customer intended to reduce the load to their Domain Controllers by using Kerberos as authentication protocol.

Figure 1 - Kerberos requests before ISA/IIS changes.

After analyzing the ISA traces with the help of a GTSC escalation engineers, we did find out that ISA server will pre-authenticate each http(s) request and not as you would have expected only the first request after the session to the web server has been established.

The Problem was that the issued Kerberos token, that was obtained from the S4U2Self call (Kerberos protocol transition extension), will not be cached on ISA. So after each http request this token will be flushed and ISA needs to obtain this ticket again and again. This behavior can have a huge impact concerning the authentication performance. As you can see in Figure 1 this ISA environment produces over 8 million authentication requests per day but got only ~4 million http(s) requests.

3. Solution

The first step is now to configure the backend IIS 6.0/7.x web servers not to re-authenticate each http request by enabling the Kerberos authentication persistence. This can be done as described in the following KB articles.

· IIS 7.x -

· IIS 6.0 -

The second step is to configure the ISA Server 2006 not the send the credentials for each subsequent http request by enabling the “CredentialsDelegationPersistence” web publishing property. This web publishing property is available per rule and will specify whether delegated credentials will be sent to the published server for each request or for only one request during a connection.

Save the following script as CredentialDelegationPersistence.vbs

If Not WScript.Arguments.Named.Exists("Rule") Then

WScript.Echo "Rule name not defined"


End If

Set fpcRoot = CreateObject("FPC.Root")

Set fpcArray = fpcRoot.GetContainingArray()

Set fpcPublishingRule = fpcArray.ArrayPolicy.PolicyRules(WScript.Arguments.Named("Rule"))

Set fpcWebPublishingProperties = fpcPublishingRule.WebPublishingProperties

WScript.Echo "CredentialsDelegationPersitence current setting: " & (fpcWebPublishingProperties.CredentialsDelegationPersistence)

fpcWebPublishingProperties.CredentialsDelegationPersistence = WScript.Arguments.Named("Value")


WScript.Echo "CredentialsDelegationPersistence set to : " & (fpcWebPublishingProperties.CredentialsDelegationPersistence)

To tell ISA 2006 to delegate the credentials only once during the connection setup execute the script on one of your ISA array members as follows and wait after the ISA array members are in snyc:

Cscript.exe credentialdelegationpersistence.vbs /Rule:<rulename> /Value:1

It is important to do the changes first on the IIS backend server (KerberosAuthPersistence) before switching the ISA not to delegate the Kerberos credentials for each request (CredentialsDelegationPersistence).

After implementing those changes the number of Kerberos requests has the approximate number of HTTP(s) requests ~6 million Kerberos and http(s) requests per day in my customer’s environment.

Figure 2 - Kerberos requests after ISA/IIS configuration changes.


Jan Tiedemann
Sr. Premier Field Engineer
Microsoft Customer and Service and Support Organization

Technical Reviewer

Thomas Detzner
Sr. Escalation Engineer
Microsoft FF Edge Customer Support and Services

Comments (2)
  1. This methodology also applies to TMG deployments.

    Jim Harrison, FF Edge CS

  2. Anonymous says:

    We experience the same symptoms in our environment and in certain situations the domain controllers suffer in performance due to the enormous amount of requests they must handle (for example after an outage and all users login again).

    We made an analysis of the number of requests before and after each step, but after each step there was no decrease in the number of requests.

    Is there anyway you can asist or explain why we do not see any improvmeents?

Comments are closed.

Skip to main content