Care, Share and Grow! : Kerberos

New features in SETSPN.EXE on Windows Server 2008

Saurabh Singh — Fri, 09 Jan 2009 03:05:00 GMT

The version of Setspn.exe that came with Microsoft Windows Server 2000/2003 Support Tools did not have features to detect duplicate SPNs. The new version of Setspn.exe that comes bundled with Windows Server 2008 utilities has some really cool features. For someone dealing with the dreaded Kerberos authentication failure issues on a daily basis like me it's a sigh of relief.

If you try the following command on the Windows Server 2008 you will see the various new options (or switches) available.

Notice the modifiers/switches:

-F = perform the duplicate checking on forestwide level

-S = add arbitrary SPN after verifying no duplicates exist

-Q = query for existence of SPN

-X = search for duplicate SPNs

Searching for duplicate SPNs using Setspn.exe:

D:\>setspn -X http/www.test.com
Processing entry 0
http/www.test.com is registered on these accounts:
    CN=mstest,CN=Users,DC=<some-DC-primary>,DC=<some-DC-secondary>
    CN=<IIS-servername>,OU=Domain Controllers,DC=<some-DC-primary>,DC=<some-DC-secondary> 

found 1 group of duplicate SPNs.

Searching for the existence of an SPN in the domain:

D:\>setspn -Q http/www.test.com
CN=<IIS-servername>,OU=Domain Controllers,DC=<some-DC-primary>,DC=<some-DC-secondary>
    http/www.test.com
    ldap/2334590-45566-113f....
    HOST/<IIS-servername>
    HOST/<IIS-servername.<some-DC-primary>.<some-DC-secondary>
    .......
    .......
CN=mstest,CN=Users,DC=<some-DC-primary>,DC=<some-DC-secondary>
    http/www.test.com 

Existing SPN found!

Adding an arbitrary SPN after verifying no duplicates exist in the domain:

D:\>setspn -S http/www.test.com <IIS-servername>
CN=mstest,CN=Users,.<some-DC-primary>.<some-DC-secondary>
    http/www.test.com 

Duplicate SPN found, aborting operation!

Adding an arbitrary SPN after verifying no duplicates exist in the forest:

D:\>setspn -F -S http/www.test.com <IIS-servername>
Operation will be performed forestwide, it might take a while.
CN=mstest,CN=Users,DC=<some-DC-primary>,DC=<some-DC-secondary>
    http/www.test.com
CN=mstest1,CN=Users,DC=<some-DC-primary>,DC=<some-DC-secondary>
    http/www.test.com 

Duplicate SPN found, aborting operation!

So what does this mean? It means you no longer have to depend upon boggling commands using LDIFDE or your own custom scripts to find out the duplicate SPNs. This is a good news indeed!

*Prior to this using Windows Server 2000/2003 Support Tools we could use commands using LDIFDE to find duplicate SPNs as below:

Syntax:

ldifde -f <filename> -d "<dc=domain-netbiosname,dc=primary-domain>" -l serviceprincipalname -r "(serviceprincipalname=<serviceprincipalname-to-check-for-duplicates>)" -p subtree

For example, if the domain name is test.abcd.com and the site URL is http//test.abcd.com command should be as shown below:

ldifde –f C:\log.txt -d "dc=test, dc=abcd, dc=com"-l serviceprincipalname –r "(serviceprinicpalname=http/test.abcd.com)" -p subtree

With the newer version of Setspn hopefully the dependency on the above command should reduce drastically.

Till next time,

Cheers!

Service Principal Name (SPN) checklist for Kerberos authentication with IIS 7.0

Saurabh Singh — Thu, 25 Dec 2008 04:01:15 GMT

In continuation to one of my earlier posts which focused on IIS 6.0 this post is more about the confusion that may arise around SPNs for setting up Kerberos authentication in IIS 7.0. IIS 7.0 has a new Kernel-mode authentication feature using which the ticket for the requested service is decrypted using Machine account (Local system) of the IIS server. It no longer depends upon the application pool Identity for this purpose by default and in turn improves the performance.

Here is how it looks like.

So what does this mean?

You no longer need to worry about the correlation between HTTP SPNs and the Application pool Identity that was required in the earlier version i.e. IIS 6.0. But that's not blindly true. There has been some confusion whether we don't have to care at all about SPNs or may have to depending upon the settings. Here is a checklist to give more clarity for different scenarios that you may fall under:

SCENARIO 1a

IIS 7.0 Web Site/Application
Authentication	Integrated Windows authentication
Application Pool Identity	NETWORK SERVICE
Kernel-Mode authentication	Enabled (<attribute name="useKernelMode" type="bool" defaultValue="true" /> in the ApplicationHost.config file)
Site URL	Accessed with the NetBIOS name, like http://<myIISserver-NetBIOS-name>/Default.aspx

SPNs will be required ONLY for the IIS machine account:

HOST/<myIISserver-NetBIOS-name>

HOST/<myIISserver-NetBIOS-name.fully-qualified-domainname> for e.g. HOST/myIISserver.mydomain.com

***Note: By default HOST/<myIISserver-NetBIOS-name> and HOST/<myIISserver-NetBIOS-name.fully-qualified-name> is already added for the machine account when a machine is added to a domain and HTTP forms a part of HOST. So you may not have to do anything special here for SPNs. Everything should be set by default.

You can check the set of existing SPNs for the machine account by running the following command:

> Setspn.exe -L <myIISserver-NetBIOS-name> or directly using a Snap-in like Adsiedit.msc.

SCENARIO 1b

IIS 7.0 Web Site/Application
Authentication	Integrated Windows authentication
Application Pool Identity	Custom account for e.g. Domain1\Username1
Kernel-Mode authentication	Enabled (<attribute name="useKernelMode" type="bool" defaultValue="true" /> in the ApplicationHost.config file)
Site URL	Accessed with the NetBIOS name, like http://<myIISserver-NetBIOS-name>/Default.aspx

The SPN requirements remain the same as above. You don't have to add SPNs like http/<myIISserver-NetBIOS-name> for the Domain1\Username1 unlike in IIS 6.0 (where we had to add an SPN of the form http/<myIISserver-NetBIOS-name> for the Application Pool identity).

SPNs will be required ONLY for the IIS machine account:

HOST/<myIISserver-NetBIOS-name>

HOST/<myIISserver-NetBIOS-name.fully-qualified-domainname> for e.g. HOST/myIISserver.mydomain.com

You can check the set of existing SPNs for the machine account by running the following command:

> Setspn.exe -L <myIISserver-NetBIOS-name> or directly using Snap-in like Adsiedit.msc.

SCENARIO 2a

IIS 7.0 Web Site/Application
Authentication	Integrated Windows authentication
Application Pool Identity	NETWORK SERVICE
Kernel-Mode authentication	Enabled (<attribute name="useKernelMode" type="bool" defaultValue="true" /> in the ApplicationHost.config file)
Site URL	Accessed with a Custom Host name, like http://www.mysite.com

SPNs will be required ONLY for the IIS machine account in the following format:

HTTP/<site-custom-name> for e.g. HTTP/www.mysite.com

You can add an SPN using Setspn.exe like

> Setspn -a http/<site-custom-name> <myIISserver-NetBIOS-name>

where <myIISserver-NetBIOS-name> is the IIS machine account and <site-custom-name> is the custom host/host header name for the Web Site URL.

e.g. > Setspn -a http/www.mysite.com <myIISserver-NetBIOS-name>
*The command is NOT case sensitive

You can check the existing set of SPNs for the machine account by running the following command:

> Setspn.exe -L <myIISserver-NetBIOS-name>

SCENARIO 2b

IIS 7.0 Web Site/Application
Authentication	Integrated Windows authentication
Application Pool Identity	Custom account for e.g. Domain1\Username1
Kernel-Mode authentication	Enabled (<attribute name="useKernelMode" type="bool" defaultValue="true" /> in the ApplicationHost.config file)
Site URL	Accessed with a Custom host/Host header name, like http://www.mysite.com

SPNs will be required ONLY for the IIS machine account and NOT for Domain1\Username1 account unlike in IIS 6.0.

HTTP/<site-custom-name> for e.g. HTTP/www.mysite.com

You can add an SPN using Setspn.exe like

> Setspn -a http/<site-custom-name> <myIISserver-NetBIOS-name> where <myIISserver-NetBIOS-name> is the IIS machine account and <site-custom-name> is the custom host/host header name for the Web Site URL.

e.g. > Setspn -a http/www.mysite.com <myIISserver-NetBIOS-name>
*The command is NOT case sensitive

You can check the existing set of SPNs for the machine account by running the following command:

> Setspn.exe -L <myIISserver-NetBIOS-name>

Special case of running IIS 7.0 in a WEB FARM

If you are running IIS 7.0 server in a Web farm the KDC will not know in advance which individual server the request may go to and hence ticket decryption may fail. Hence in such a scenario instead of registering SPNs under a specific machine account use a domain account. I am not a SharePoint guy but based on what I have read on the Web this scenario is also applicable to a single SharePoint server configuration.

There are two ways to go:

Either

Disable Kernel mode authentication and follow the general steps for Kerberos as in the previous IIS 6.0 version. Refer this.

Or,

[Recommended for Performance reasons]

Let Kernel mode authentication be enabled and the Application pool's identity be used for Kerberos ticket decryption. The only thing you need to do here is:

1. Run the Application pool under a common custom domain account.

2. Add this attribute "useAppPoolCredentials" in the ApplicationHost.config file.

<system.webServer>
   <security>
      <authentication>
         <windowsAuthentication enabled="true" useKernelMode="true" useAppPoolCredentials="true" />
      </authentication>
   </security>
</system.webServer>

Remember there is no GUI setting for this. You need to modify the ApplicationHost.config file from

<%SystemDrive%>/Windows/System32/inetsrv/config folder on the IIS 7.0 machine.

3. Add the SPNs in the form:

http/<virtualhost-name> and

http/<virtualhost-name.fully-qualified-name> for the Application Pool Identity.

Ensure that we don't have such an entry for SPNs for any other account including IIS server machine account.

***If we have the same SPN mapped to multiple accounts (be it a machine or an user account) it leads to Duplicate SPNs and will break Kerberos.

Hope this helps!

Who knows! You may be missing these points for Kerberos authentication failures for Web applications...

Saurabh Singh — Sun, 16 Nov 2008 13:11:00 GMT

I am sharing here some of the general + elusive + ignored + must-have info that you may want to recheck when you are troubleshooting a kerberos cum delegation failure scenario and feel like reaching nowhere near the end of the tunnel (resolution!). These are my personal checklists based on experiences of troubleshooting kerberos related gotchas. I had also posted my first article on troubleshooting kerberos issues way back in January 2007. This article is a kind of continuation to it since I still see a lot of people missing some finer points here and there. Please check this post for the general kerberos checklist.

So here I go...

Kerberos was designed and is supported in Intranet scenarios. If you are trying to make it work over an Internet environment you may want to recheck other options (unless you are going ahead with Protocol transition for e.g. from Basic/NTLM to kerberos). Remember that for kerberos to work, the client (e.g. client browser) should be able to connect to the Domain Controller(KDC) to acquire the tickets. If your clients are coming over the Internet they may not be having access to the Domain Controller. Most security conscious organizations keep their DC away from Internet facing network in order to reduce the likelihood of it getting compromised. You may have to check with the firewall/proxy settings etc. and more...to make this work which I personally feel is not a good idea.

Kerberos will work for resources (client-IIS-Backend DB etc.) in the same domain or in trusted domains within the same forest. Either have mutual trust (preferable) between the domains in the forest or at least have the IIS domain trust the client's domain. If your clients are coming from a domain across the forest with an external trust we need to do extra work. Refer to this article. I am not an AD guy .

Here is an excerpt from the same article:

The Windows Server 2003 family supports domain trusts and forest trusts. We know what domain trusts are: they allow a user to authenticate to resources in another domain. Like always, all domain trust relationships have only two domains in the relationship: the trusting domain and the trusted domain. There are one-way trusts (unidirectional) and two-way trusts (bi-directional) and a Windows Server 2003 domain can establish a trust among other Windows 2000/2003 domains in the same or different forest, Windows NT 4.0 domains and Kerberos V5 realms. In Windows 2000, if users in one forest needed access to resources in a second forest, an administrator could create an external trust relationship between the two domains, which is one-way and non-transitive. This meant that in order to extend your trust to other domains in the forests you had to explicitly configure each and every one of them.
Windows Server 2003 offers a forest trust: two-way Kerberos-based transitive trust between Windows Server 2003 forests, enabling a transitive trust between all the domains in the two forests. Forest trusts are established between the root domain of both forests and can be either one way or two way. A Few things to remember are to make sure all domain controllers in both forests are running Windows Server 2003, with a correctly configured DNS infrastructure and forest functionality level set to Windows Server 2003 mode in both forests.

Many a times you will see something as shown below when connecting to a web site over Windows integrated authentication. You may have checked all the basic settings for kerberos and things look okay, yet somehow mysteriously this is failing to work with kerberos. After three attempts it will fail with 401.

You typed in http://www.test.com in the browser and it seems to be connecting to some other machine name as shown below in the picture.

Look at the IE prompt which shows that we are trying to connect to testkrb.saurabh1.com although web site URL in the browser's address box shows we are trying to reach the site www.test.com. Ideally we should have seen "Connecting to www.test.com" and not "connecting to testkrb.saurabh1.com". Equivalently try a ping to www.test.com and see what it resolves to.

If you see such a scenario it's time to check whether the web site URL is an Alias(CNAME) or a DNS Host (A) Record. There is a known issue with using Alias for a site which may not allow kerberos to work. There are some details which I don't want to get into at this point, probably some other day. In short, it tries to look into the KDC based on the SPN http/testkrb.saurabh1.com and not an SPN of the form http/www.test.com.

Solution:

Server side: Either go ahead and change the DNS entry to add www.test.com as a DNS Host (A) Record and not CNAME.

or,

Client side: Apply this hotfix to IE browser on the client(s) (I don't see this as a good option).

I would recommended to use a host name instead of an IP address to access a web site meant for a kerberos based authentication. You may see it working just fine even with IP address in some scenarios but then it may pose problems when we have client and servers in different domains etc. You may get into an issue wherein domain2 will not give any referral back to to the client to look into domain1 for the SPN. This can occur if IP address is being used to look for a service. In such a case even after adding SPN's for IP addresses, Kerberos won't work and will fall back to NTLM.

If your web site is configured to use a non-default HTTP port like 81 instead of 80, users will access the site as http://www.test.com:81 and not http://www.test.com (browsers append ':80' as the default port if none specified). Here lies the confusion when you add SPNs for the web site. Don't have an SPN with the port number appended even if you are running your site on a non-default port.

If the site is accessed as http://www.test.com:8080 SPN will still be of the form http/www.test.com and not http/www.test.com:8080.

Refer to this article. It confuses me further but I would suggest go ahead with the default as above.

Consider a scenario wherein two applications http://servername/app1 and http://servername/app2 are running under a NETWORK SERVICE & a domain user Application Pool identities respectively .
The SPNs requested will be http/servername in both the cases, and since we can’t have duplicate SPNs; kerberos may not work for either of the applications. We need to then either use the same Application Pool identity or separate host headers for the web sites and set SPNs accordingly. NOTE: This issue is taken care of in IIS 7.0 with Kernal mode authentication.
Again,if you are using two web sites with same name but different ports like http://servername:81 and http://servername:82; by default IE will request a ticket for the same SPN HTTP/servername.
We would then need an hotfix for the client machines, Refer to this.
When do we have Duplicate SPNs leading to kerberos not working?

Duplicate SPN arises from the fact that the same SPN is mapped to multiple accounts, it may be a machine or an user account. Doesn't matter. Mapping to multiple accounts will lead to duplicate SPNs!

*Remember: You can have multiple different SPNs registered under the same account but not vice-versa, i.e. you should *not* have the same SPN registered under multiple accounts.

IIS uses NTLM credentials when accessing a resource for a local request coming to it (i.e. client say IE, and IIS are on the same box). It may use Kerberos or NTLM from a separate client machine depending on the setup.The best way to check if delegation is working is from a client machine which is not same as the IIS server. NTLM doesn't support delegation. Kerberos does!

At times making sure all the settings on the client, IIS, AD, back-end (if any) to make kerberos work properly doesn't help, and in such cases make sure that we purge all the kerberos tickets using Klist or Kerbtray on the client. In fact if possible logoff and re-login to the client machine from where you are testing the web application for kerberos authentication so that the client is issued a fresh ticket.

*Check the following link for my other posts related to Kerberos.

Till next time...

Kerberos troubleshooting from IIS perspective

Saurabh Singh — Mon, 29 Jan 2007 09:47:00 GMT

Hi All,

This is my first posting in the blog.

I really had to take enough courage to start blogging, but with some help from one of my mentors in MS, I am finally here.

I hope people really get benefitted from the articles that I post in here.

Today, I am going to talk about how to implement Kerberos authentication for IIS. I have chosen this topic after a lot of consideration. This topic has always evoked a state of anxiety and fear among Web administrators and MS PSS support engineers alike. Also this has been a pain for us since a lot of calls that we receive are related to Kerberos authentication failure and causes a lot of labor and revenue loss to MS and customers.

So here it goes...

So what exactly is this Kerberos, first time when I heard of it I thought it must be some mystical word related to enchantment and what not. I went and looked into the dictionary and found something similar. It meant a fierce three-headed dog figure from Greek mythology that guarded the gates of the underworld. Kerberos protocol, similar to the dog figure has three main sections: client, server and an intermediary called Key distribution centre (KDC).

So how exactly is this Kerberos protocol work:

There are numerous articles that you can find which will give you an insight as to how Kerberos protocol works, so instead of explaining some redundant stuffs here which might confuse you a bit more (like the way it did to meJ), I will be very lucid and straight in my explanation, and concentrate more on troubleshooting than getting into various jargons associated with it. Let me know if you need articles on the topic and I can post it here.

Simply speaking, a client requests a ticket (or token) from an Intermediary called Key Distribution centre (KDC) for accessing any service registered with it. In our case to access a web service, it looks for an authenticated token to access the web services, and once getting a unique short-term session key from the KDC, directly contacts the IIS server hosting the web service. IIS in turn receives the token its own session key and since it is authenticated by the KDC with which the IIS service has been registered authenticates the client to access the application running on it. Remember authentication and authorization are two different terms. A client might be authenticated still might not be able to access the resource because of lack of authorization to access it.

To understand the details of how a Kerberos protocol works, I recommend reading MS knowledge base or Technet.

Before you configure Kerberos authentication for your site, I recommend having these tools handy:

SETSPN (For adding, listing, deleting SPN entries for a domain)

KERBTRAY (For checking the Kerberos ticket used by the client to access a web server. It gives you information as to which ticket is being used by the client to access the IIS server, and whether the ticket is capable of delegation).

I will take up a scenario where you want to implement Kerberos delegation to work in this architecture. It is also called double-hop since client's credentials are hopped twice from the client to the IIS web server to the backend SQL server to access a resource. I suggest there are very good articles present elsewhere on Microsoft site where you can get in depth information on how Kerberos authentication works. I have concentrated more on troubleshooting, so you can skip to the next section J.

We assume client, IIS server and the backend SQL server in the same domain. The same scenario will also work if you have the components in different domains but they are mutually trusted both ways.

As a troubleshooting process, start with only Basic authentication enabled on IIS server and then test from a client machine to see if that works successfully. If it works, we are good to proceed further with Windows integrated authentication as the only enabled authentication on IIS (make sure that we do not have Anonymous authentication selected in the IIS mmc console).

The following checklist gives you an insight of the basic configuration required for Kerberos to work in double hop scenario from IIS perspective.

Non-NLB Scenario

IE : IIS : SQL Server
===============================
IE-IIS-Share
{All using default accounts, for eg. In IIS 6.0, app pool running under Network service or Local system.}
--------------------------------------------------------
IE:
- Add the URL to "Local Intranet Zone"
- Enable Windows Integrated Authentication
- Automatic logon with current username and password or, Automatic logon only in Intranet Zone
--------------------------------------------------------
IIS:
- Only "Windows Integrated Authentication" is checked.
Type in > cscript adsutil.vbs get w3svc/ntauthenticationproviders (You need to run this from <system drive>/inetpub/adminscripts)
- Make sure that this command shows > Negotiate, NTLM; or there is no value set.
Else type in > cscript adsutil.vbs set w3svc/ntauthenticationproviders Negotiate, NTLM
- Make sure to cross check the same at individual website/virtual directory level by using the command > cscript adsutil.vbs find ntauthenticationproviders.
SPN:
-          http/<computer-name>~~:<port>~~ <iis-computer-name>
            http/<FQDN> <iis computer-name>
~~CAUTION: Putting the <port> has been dicey. At times it works and at times it doesn't (only my own experienceJ).~~ I will recommend not using it when you set the SPN.
Domain Controller (DC):
-    Under Active Directory Users and Computers -> <Domain> -> Computers, Select the IIS server, right click ->Properties->Delegation tab
     Make sure that "Trust this Computer for delegation to any service (Kerberos only) is selected, or else "Trust this computer for delegation to specified services only" is selected.
    (You will get this option if the Domain functional level is Windows Server 2003 only).
    The 1st option is more generic and is good while you are implementing it for testing the first time.
    When the 2nd option is checked, you can go ahead with any of the options: "Use Kerberos only" or "Use any authentication protocol". In such a case make sure that you are selecting the right service Type running on the backend service for which you need delegation. Let's say if you have SQL server running at the backend to which you want the IIS to delegate the credentials, we need to add service type as "MSSQLSVC" and default port as 1433.
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
IE-IIS-Share
{App Pool running under Domain account}
--------------------------------------------------------
Domain account configuration:
- Account is trusted for delegation
- Is a member of IIS_WPG group on the local IIS computer
- Has "Act as a part of Operating System"/"Impersonate a client after authentication" privileges.
IE:
- Add the URL to "Local Intranet Zone"
- Enable Windows Integrated Authentication
- Automatic logon with current username and password or, Automatic logon only in Intranet Zone.
IIS:
- Only "Windows Integrated Authentication" is checked.
Type in > cscript adsutil.vbs get w3svc/ntauthenticationproviders (You need to run this from <system drive>/inetpub/adminscripts)
- Make sure that this command shows > Negotiate, NTLM; or there is no value set.
Else type in > cscript adsutil.vbs set w3svc/ntauthenticationproviders Negotiate, NTLM
- Make sure to cross check the same at individual website/virtual directory level by using the command > cscript adsutil.vbs find ntauthenticationproviders.
SPN:
-          Add the following:
                        http/<computer-name>~~:<port>~~ <domain user account>
                        http/<FQDN> <domain user account>
            Remove the following:
                        http/<computer-name>~~:<port>~~ <iis-computer-name>
                        http/<FQDN> <iis-computer-name>
~~CAUTION: Putting the <port> has been dicey. At times it works and at times it doesn't.~~ I will recommend not using it when you set the SPN.
Domain Controller (DC):
-    Under Active Directory Users and Computers -> <Domain> -> Computers , Select the IIS server, right click ->Properties->Delegation tab
    Make sure that "Trust this Computer for delegation to any service (Kerberos only) is selected, or else "Trust this computer for delegation to specified services only" is selected.
    (You will get this option if the Domain functional level is Windows Server 2003 only).
    The 1st option is more generic and is good while you are implementing it for the first time.
    When the 2nd option is checked, you can go ahead with any of the options: "Use Kerberos only" or "Use any authentication protocol". In such a case make sure that you are selecting the right service Type running on the backend service for which you need delegation. Let's say if you have SQL server running at the backend to which you want the IIS to delegate the credentials, we need to add service type as "MSSQLSVC" and default port as 1433.
If you still encounter problems try checking for duplicate SPNs.
- To find duplicate SPNs
Use command prompt to execute this command on dc:
       ldifde -f <filename> -d "<dc=domain-netbiosname,dc=primary-domain>" -l serviceprincipalname -r "(serviceprincipalname=<serviceprincipalname-to-check-for-duplicates>)" -p subtree
e.g. if the domain name is test.abcd.com:
       ldifde –f C:\log.txt -d "dc=test, dc=abcd, dc=com"-l serviceprincipalname –r "(serviceprinicpalname=http/test.abcd.com)" -p subtree

NLB Scenario
--------------------------------------------------------
Now we will talk about a scenario where IIS server is a part of Network load balancer (NLB). First thing, make sure that Kerberos is supported by your NLB (hardware or software). The settings for Kerberos are a bit different when you configure it for IIS servers running as NLB nodes. Here you don't have to set SPNs for individual IIS nodes; rather you need to set an SPN entry for the Virtual IP or alias of the Load balancer. It can be hardware or software.

IE-IIS-Share
--------------------------------------------------------
{All using default accounts}
--------------------------------------------------------
IE:
- Add the URL (here the URL is the NLB's virtual URL or alias) to "Local Intranet Zone"
- Enable Windows Integrated Authentication (Internet Options->Advanced->Security)
- "Automatic logon with current username and password" or "Automatic Logon only in Intranet Zone"

IIS:
Type in > cscript adsutil.vbs get w3svc/ntauthenticationproviders (You need to run this from <system drive>/inetpub/adminscripts)
- Make sure that this command shows > Negotiate, NTLM; or there is no value set.
Else type in > cscript adsutil.vbs set w3svc/ntauthenticationproviders Negotiate, NTLM
- Make sure to cross check the same at individual website/virtual directory level by using the command > cscript adsutil.vbs find ntauthenticationproviders.
- Setup the IIS Servers for delegation as mentioned in the above steps.
- Only "Windows Integrated Authentication" is used in IIS.
- If it's an NLB environment, we need to run the IIS application under an App pool running with domain user account.
- The domain user account should be trusted for delegation in the Active Directory.
From Active Directory Users and Computers, go to the properties of the IIS User (Domain user account). On the Delegation Tab, select "Trust this user for delegation to any service (Kerberos only)"
- The domain user account should be a part of IIS node's IIS_WPG group.
- We need to set the above settings for all the IIS nodes in the NLB.
- Also add the same host header entry for the NLB URL in all the IIS nodes in the IIS manager console -><website>->Properties->Web Site-> Advanced tab.

SPN:
- For IIS:
             http/<Netbios name of the NLB> <Domain user account>
             http/<FQDN of the NLB> <Domain user account> (If we are running the site on port 80, otherwise http/<FQDN of the NLB>~~:<Port>~~ <Domain user account>
    ~~CAUTION: Putting the <port> has been dicey. At times it works and at times it doesn't.~~ I will recommend not using it when you set the SPN even when your site is running under a different port other than the default 80.

We need to make sure that we do NOT have SPN entries set for http/<FQDN> <iis computer-name> for any of the IIS nodes.

Command: >Setspn –A http/<FQDN of the NLB> <Domain user account>
When we are using Constrained delegation make sure that the backend service is listed in list of services, for e.g. in case we are connecting to SQL server at the backend add MSSQLSVC in the Machine/user properties->Delegation tab.
Note: When we are accessing the web application from a client machine, I suggest installing Kerbtray on the client machine and checking for the "OK as Delegate" option in the attributes section for the corresponding SPN. If it is selected it means the ticket can be used for delegating credentials from the IIS server to the backend server. If it is not then it means there are some issues with the settings in IIS or somewhere else. Using Netmon trace is always a good idea to figure out what tickets are being used or looked for by the Client when accessing the Web application.

In case you face any issues related to Kerberos authentication failure, do the following to understand more from the event logs
- Make sure that we have enabled Kerberos logging according to http://support.microsoft.com/default.aspx?scid=kb;EN-US;262177 on all the IIS nodes.
- Apart from that, you also need to make sure that on all the IIS servers, these two settings are enabled.

Start->Programs->Administrative tools->Local security Policy->Security settings->Local Policies->Audit Policy->Audit account logon events->"Success, Failure".

Start->Programs->Administrative tools->Local security Policy->Security settings->Local Policies->Audit Policy->Audit logon events->"Success, Failure".

NOTE:

At times making sure all the above changes are done properly doesn't help, and in such cases make sure that we purge all the kerberos tickets using Klist or Kerbtray. In fact if possible logoff and re-login to the client machine from where you are testing the web application for kerberos authentication so that the client is issued a fresh ticket.

Additional Info:
================

You might see this error in the event logs in DC:
Event Type: Error
Event Source: KDC
Event Category: None
Event ID: 11
Date: 4/1/2002
Time: 1:40:14 PM
User: N/A
Computer: ComputerName Description:
There are multiple accounts with name host/mycomputer.mydomain.com of type 10.

This might be because of Duplicate SPNs. There are two or more computer accounts that have the same service principal names (SPNs) registered. Please refer to KB 321044 for further info. Remember, you can use Ldifde to check for duplicate SPNs as mentioned above.
Few Links:
For configuring backend SQL server to accept Kerberos authentication go through this link: http://support.microsoft.com/kb/319723/en-us
Also a good article on IIS Kerberos authentication http://support.microsoft.com/kb/907272/en-us and http://support.microsoft.com/?id=929650
How to configure an Asp.Net application for a delegation scenario: http://support.microsoft.com/kb/810572/
PS: Remember to test whether delegation is working fine, you need to access the website URL from a workstation (client) browser and not from IIS server itself.

Reason: IIS uses NTLM credentials when accessing the backend when request reaches it from the local server if, Kerberos fails and there is only single hop involved. NTLM will work with single hop and hence if you access a site locally from the IIS web server it is a single hop and not a double hop scenario.

One simple mantra to be remembered always: You can have multiple different SPNs registered under an account but not the other way, i.e. you should not have the same SPN registered under multiple accounts because it leads to duplicate SPN issue.

***************************************************** Addition to the blog

Think about a scenario where http://server/app1 and http://server/app2 are running inside a network service & a domain user identity respectively .
The SPNs requested will be http/server in both the cases, and since we can’t have duplicated SPNs it won’t work. We need to then either use the same server process identity or dedicated host headers.

Again,if you are using two websites with same name but different ports like http://server:80 and http://server:81; by default IE will request a ticket for the same SPN HTTP/server.

We would then need an hotfix for the client machines, http://support.microsoft.com/kb/908209.

If you have two websites http://application1 and http://application2 that are both DNS aliases (CNAMEs) of say myserver DNS host, IE will request the ticket for SPN HTTP/myserver for both the above websites. By default IE does't use port for sending the ticket and just the SPN name like, http/mysite:99, It ignores the port part of it.
Then you would need client fix http://support.microsoft.com/kb/911149, or use a different DNS HOSTs rather than CNAMEs.You might well go ahead with using a host headers for the websites.

[Something to add here with regard to using IP Addresses to access a site...

There is another confusion that people have while dealing with Kerberos authentication. At times you may want to use IP addresses to access a website and still want Kerberos authentication to work. Now in a general scenario this will not work because Kerberos requires SPN's to recognize a service like HTTP etc. You can however make it work by adding SPN's in the form: http/10.0.1.25 (website's IP) etc. This may or may not work.

However we do not recommend the above way to make Kerberos work for your site using IP addresses. The reason being that SPN's should ideally be names like http/<somename> and not http/<some IP address>.

Let's consider a scenario wherein users belong to domain2 and the Web server is part of domain1. Also let's assume we have mutual trust between domain1 and domain 2. When using IP addresses, client will look for SPN HTTP/10.0.1.25 (assuming this is website's IP on domain1) in domain2 (client's local domain).

Now you may get into an issue wherein domain2 will not give any referral back to to the client to look into domain1 for the SPN. This can occur if IP address is being used to look for a service. In such a case even after adding SPN's for IP addresses, Kerberos won't work and will fall back to NTLM.

]

***Update: Regarding confusion around Port entry in SPNs, check this http://technet.microsoft.com/en-us/library/cc263449.aspx#section4

Happy troubleshooting…and in case you still face issues, Microsoft Product Support Services (PSS) is always there to help you!

Feel free to shoot me a question if you have any confusion or need some assistance.

*Check the following link for my other posts related to Kerberos.