Another Look at Kerberos Constrained Delegation on ISA Server 2006 – OWA Publishing Scenario

A really nice feature that was added in ISA Server 2006 is support for Kerberos Constrained Delegation (KCD). Kerberos Constrained Delegation allows ISA Server 2006 to verify the identity of a client using a non-Kerberos authentication method (in this case SSL Client Certificates). ISA Server is then able to request a Kerberos ticket on behalf of the client instead of requiring the client to provide an additional set of credentials. For more detailed information on ISA Server and KCD please review the article Kerberos Constrained Delegation in ISA Server 2006.

Consider a scenario where you have an Exchange Server 2003, ISA Server 2006, an internal PKI infrastructure and you want to publish Outlook Web Access. Rather than have your external laptop users have to enter credentials you would like them to use SSL Client Certificates. For the purpose of this post we are going to use the test domain

In the test environment we issued a User Certificate to the user called Administrator. The machine is assumed to be a laptop that is already a member of the domain and, by default, would have the Trusted Root CA already installed. If this is not the case this would need to be imported in addition to the User Certificate.


Figure 1 – Example of a client certificate.

The next step is publishing OWA using ISA Server 2006. The external FQDN used to publish Outlook Web Access will be

Since SSL Certificates and KCD add additional complexity to the publishing scenario we want to start off with something simpler to make sure that publishing OWA works. Initially we use HTTP Authentication on the Web Listener and Basic Delegation in the publishing rule.


Figure 2 – Web Listener Properties


Figure 3 – Delegation used in the publishing rule.

After creating the rule, you can go to the external client and try to access the website. The result is that you should be prompted for authentication as shown below (Figure 4).


Figure 4 – Client receiving the authentication request while accessing the OWA page.

After entering the proper credentials I am able to see my mail and life is good.


Figure 5 – OWA Page after successful logon.

This confirms that we can get to the internal Exchange Server from an external location.

Now let’s try publishing with our original objective using SSL Client Certificates and Kerberos Constrained Delegation. In order for the ISA Server to request a Kerberos ticket on behalf of the client you need to set this up in Active Directory Users and Computers.


Figure 6 – Changing ISA Server’s computer properties to allow trust for delegation.

Once this has been done we can change the Web Listener and Publishing Rule in the ISA Server Management console to reflect our objective.

Figure 7 – Web listener properties.

Figure 8 – OWA Publishing rule under the Authentication Delegation tab.

After applying the changes to the ISA Server we test with the external client. We are asked to choose the certificate to use.

Figure 9 – Client being asked to choose a digital certificate to present

After choosing the certificate we receive an error as show below:

Figure 10 – 403 Error encountered by client trying to access OWA


To troubleshoot this type of error one thing that we can do is get a network trace from the internal interface of the ISA Server. This test might reveal what the problem is to us. Let’s see what we have in this case:

Figure 11 – The network trace taken from internal adapter of ISA Server

As you can see in the figure above on Frame 15 is the initial Kerberos Request and then in Frame 17 we see KRB Error: KRB5KDC_ERR_BADOPTION NT Status

We can see that the Server Name that ISA is trying to request the Kerberos Ticket from is http/

Although this is the published external name and is used for the public name on the rule it is not the correct Service Principal Name (SPN) to use in the rule.

We quickly change this in the rule and apply

Figure 12 – Changing the SPN on the Authentication Delegation tab

A quick test using the external client and we find that now we are able to get to OWA.

Another network trace on the internal interface of the ISA Server and we see the expected Kerberos Request and Reply.

Figure 17 – Network trace showing the Kerberos Response

Life is good!


I hope that I have shown in this article that troubleshooting OWA and KCD is not as intimidating as it first may appear.



Keith Abluton

Microsoft CSS Forefront (ISA/TMG) Team


Technical Reviewers:


Billy Price, Yuri Diogenes and Dan Watson from Microsoft CSS Forefront (ISA/TMG) Team



Comments (5)

  1. agentsmith says:

    Hi Keith,

    KCD for http only is more secure than all services – I Agree 😉 – What i meant was the "*" within "http/*" standing for all Ex2k7-FE-Servers – It has to be a "Any" since no one can tell the target-FQDN since it´s a Farm, right ? No dedicated lists possible here like "http/,http/" or "http/*" for the SPN, but maybe that would not really make it more secure since the rule limits the target anyway, right ?



  2. Anonymous says:

    Thanks for the question. If I understand it correctly then, yes, this is the most secure setup. You are "constraining" this to only 1 service which is HTTP rather than ALL services.

  3. agentsmith says:

    Hello Keith,

    thx for the article. – I´ve got a question to KCD.

    We´ve got KCD setup for OWA2k7 up and running flawlessly with a ISA2k6EE & 2 Ex2k7-FE-Servers.

    Since the two hosts building the Ex2k7-FE-Farm have different FQDN used for delegation this only works when setting "http/*" for the SPN in the Auth-Delegation Tab of the publishing rule. Everything works, but is this the most secure setup possible in this scenario ?



    P.S.: Thx again for the blog and all the valuable real-world-articles published ! Keep up the good work !

  4. Anonymous says:

    I believe the star gets replaced with the FQDN of the actual farm member used. Hence the star doesn’t actually mean any, but means ‘replace with the farm member FQDN being published’. This way the SPN sent would be http/farm-member1.fqdn or http/farm-member2.fqdn where farm-member1 and 2 are defined as servers in the farm.

  5. johnredd says:

    NEAT…. Although I trapped the issue when I saw the SPN initially 🙂

    This is good stuff!!

Skip to main content