When Kerberos authentication fails, it is always a good idea to simplify the configuration to the minimum (one client/one server/one IIS site running on the default port). In addition, some basic troubleshooting steps can be followed like using a test page to confirm the authentication method being used. If you use ASP.NET, you can create a test page like this or use our team's ASP.NET Authentication test page. If you are using classic ASP, you may use the following page:
Testkerb.asp<% authType=UCase(Request.ServerVariables("AUTH_TYPE")) authHeader=Request.ServerVariables("HTTP_AUTHORIZATION") response.write " Authentication Method : " & authType & "<BR>" LenAuthHeader = len(authHeader) response.write " Protocol : " if Len(authType ) =0 then response.write " Anonymous" else if authType<>"NEGOTIATE" then response.write authType else if LenAuthHeader>1000 then response.write "Kerberos" else response.write "NTLM"%>
You can also check whether Kerberos is used (or not) with tools like Fiddler, STRACE/HTTPREPLAY, Network Monitor…etc When Kerberos is used, the request sent by the client is pretty large (generally more than 2000 bytes) since the HTTP_AUTHORIZATION header includes the Kerberos ticket:
If NTLM is used the request size will be much smaller:
At this stage, if you are making use of Kerberos and authentication fails, a couple of things need to be verified:
If you are running IIS 7.5 on Windows R2, make sure the following hotfix is installed : http://support.microsoft.com/kb/2545850. If you don't install this hotfix, you may hit random kerberos issues.
Usage of Kerberos requires a domain since a Kerberos ticket is delivered by the domain controller.
Note: even if this configuration is not frequent (because it requires the client to have access to a Domain Controller), Kerberos can be used for a URL in the Internet Zone. In this case, unless default settings are changed, the browser will always prompt the end user for credentials. Note also that Kerberos delegation won't work in the Internet Zone (Internet Explorer only allows Kerberos delegation for a URL in the « Intranet » and "Trusted sites" zones).
If IIS doesn't send this header, you'll need to use ADSUTIL to set the Negotiate header though the NTAuthenticationProviders metabase property (see http://support.microsoft.com/kb/215383).Note: by default, the NTAuthenticationProviders property is not set which causes IIS to send both Negotiate and NTLM headers:
Kerberos is not enabled in this configuration and a hard coded loopback check will always force usage of NTLM in this scenario. Note that NTLM may also not work in this configuration (see http://support.microsoft.com/kb/896861 for more details).
The KERBLIST tool (included in the Windows 2003 Server Resource Kit) can be used to confirm that the client box can obtain a Kerberos ticket for a given SPN (in this example http/MEMMANUBO1):
If the Kerberos ticket request fails, Kerberos authentication will not be used. NTLM fallback may occur if the Kerberos ticket request fails because the SPN requested is unknown to the Domain Controller (DC). It is also worth noting that if the DC is unreachable, no NTLM fallback will occur.
In order to declare a SPN, consult the following Knowledge Base article: http://support.microsoft.com/kb/929650
By default, Internet Explorer doesn't include the port number information in the SPN used to request a Kerberos ticket. This can be a problem you use IIS to host multiple sites under different ports and identities. In this configuration, Kerberos authentication may only work for specific sites even if all SPNs have been correctly declared in Active Directory. To resolve this issue, you'll need to set the FEATURE_INCLUDE_PORT_IN_SPN_KB908209 registry value (as per http://support.microsoft.com/kb/908209). This will force Internet Explorer to include the port number in the SPN used to request the Kerberos ticket.
You may also use other tools like KERBSPY (included in the KAPIMON tool) to check the SPN used by Internet Explorer:
When a Kerberos ticket is sent from Internet Explorer to an IIS server, the ticket is encrypted using a private key. The private key is a hash of the password used for the user account associated to the SPN. Therefore, only an application running under this account will be able to decode the ticket.
Here is a summary of the Kerberos authentication algorithm's steps:
If you do not explicitly declare SPN, Kerberos authentication will work only if the application pool identity is « Network Service ». In this case, the Kerberos ticket is built using a default SPN that is created in Active Directory when a computer (in this case the server that IIS is running on) is added in the domain. This « default SPN» is associated to the computer account which, under IIS, maps to « Network Service ».
If your application pool needs to use an identity other than « Network Service », you'll need to declare a SPN (using SETSPN) and associate it with the account used for your application pool identity. A common mistake is to create similar SPNs with different accounts. For example:
SETSPN http/mywebsite UserAppPool1SETSPN http/mywebsite UserAppPool2
Above configuration won't work since there is no deterministic way to know if the Kerberos ticket for the SPN http/mywebsite will be encrypted using password of USerAppPool1 or UserAppPool2. This configuration will typically produce KRB_AP_ERR_MODIFIED errors. To check if you are in this (bad) « duplicate SPNs » scenario, you can use tools documented in this article: http://support.microsoft.com/kb/321044. You may also use an updated version of SETSPN for Windows 2003 which allows the detection of duplicate SPNs using setspn –X (see http://support.microsoft.com/kb/970536).
We also recommend you to read the following blog articles:
One of the new features of IIS7 is to provide kernel mode authentication. Kernel mode authentication provides a couple of advantages:
This allows you to have multiple applications pools running under different identities without having to declare SPNs
caveat: if a SPN has been declared with a specific user account (also used as application pool identity), kernel mode authentication will not be able to decrypt the Kerberos ticket since it uses the machine account. This problem is typical to web farm scenario since this scenario generally imposes to declare a SPN for the (virtual) NLB hostname. To prevent this issue, you can either:
There is a known Kerberos ticket renewal issue using XP SP2. This issue is solved with XP SP3 or using the following hotfix: http://support.microsoft.com/KB/939850
There is a known issue with Internet Explorer described in the following article: http://support.microsoft.com/kb/899417 (to activate the fix, you'll need to create the following registry key: FEATURE_ENSURE_FQDN_FOR_NEGOTIATE_KB899417). This problem manifests itself through the loss of Kerberos authentication after a while. Note that Internet Explorer security update MS09-054 (released on 10.13.2009) does activate the fix by default (no need to create a registry key).
In this scenario, check the following:
If delegation still fails, you may consider using DELEGCONFIG. This tool allows to diagnose - and resolve - dozens of issues preventing Kerberos authentication from working correctly. Check the following link for more details: http://blogs.iis.net/bretb/archive/2008/03/27/How-to-Use-DelegConfig.aspx
By default, Kerberos authentication is « request based » contrary to NTLM which is « session based ». This means that every request will include the Kerberos ticket. You can change this behavior using the authPersistNonNTLM property if you are running under IIS7 or EnableKerbAuthPersist for IIS6. For more details, please see the following: http://support.microsoft.com/kb/954873Note also that it may not be a good idea to blindly use Kerberos authentication on all objects. Using Kerberos authentication to fetch hundred of images with conditional GET requests likely producing « 304 not modified » responses is similar to attempting to kill a fly with a hammer. Such approach will also not provide obvious security gains.
We hope that this « checklist » will help you to quickly identify the nature of Kerberos authentication issues. As you may have noticed it, the number of potential issues is almost as high as the number of tools to solve them!
very intense article, i would suggest to change the layout but surely this include LOTS of details which answered most of my global questions
This article is well written. This helped me in resolving two of my issues with one of our intranet site integrated with Kerberos.
Thanks Emmanuel. This article helped me a lot.
Can you help me out please regarding Kirbos authetication?
It is for intranet site.
I have one server he3123 which have iis6.
I have two web site running under domain name account.both have different acocunt.
How can i set spn for two different acocount on same machine ?Is it possible ?
Site URL is
I think this section in the article is answering a part of your question:
•Does the web server use another port than default (80)?
You can set a SPN with a port number however you need to configure IE to make it request the Kerberos ticket with the port informed in the address bar.
The easiest way to avoid a SPN issue in your scenario (even if it's not the best solution) is to set the same password on both accounts, declare only one SPN (HTTP\he3123) and all we be working perfectly.
Else, you'll surely have a duplicate SPN which will make the authentication fails. If you prefer (it's surely a better solution) you can also use a DNS alias to avoid using the same password on both accounts and avoid the duplicate SPN by declaring a SPN on the alias.
If you want a "cleaner" solution, don't hesitate to open a ticket to the Microsoft Support, they will have a look to your scenario and architecture to provide you the best solution.
This is one of (or maybe) the best article(s) on Kerberos troubleshooting with IIS. Thanks a lot! One open question - "...using a default SPN...": This refers to the HOST/<Hostname> - entries I assume? Why is this only working for Network Service and not also for Local System (which should also be able to authenticate over the network and decrypt the Kerberos ticket)?
Never thought about it checking myself. MS texts are misleading, e.g. "The Local System account does not have any rights to access the network. When network access is necessary, Local System uses the account Domain\computername$. " So Domain\computername$ always references the Network Service, I presume. Local System would be able to decrypt the Kerberos Ticket, but cannot request one, as it cannot contact the domain controllers and authenticate as the machine. Thanks a lot :)
And another one: "The LocalSystem account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function. It has extensive privileges on the local computer, and acts as the computer on the network" from msdn.microsoft.com/.../ms684190%28v=vs.85%29.aspx. How can an account, which has no access to the network, act as the computer on the network? Or does that actually mean something else?
Hello MMF, my comment regarding LocalSystem account was wrong and I deleted it. LocalSystem (like NetworkService) can travel over the network using the computer account. I did a few tests with PSEXEC running CMD under LocalSystem and, for example, a NET USE clearly causes share connection to be established using machine account. Regarding your Kerberos question with LocalSystem, I'm simply not able to request a Kerberos ticket using KERBLIST running under LocalSystem and I honestly don't know why...
Thanks for coming back at me with this one. As far as I know the computer account is able to use both Kerberos and NTLM (from Vista onwards with the policy "Network security: Allow Local System to use computer identity for NTLM" = Enabled). And use the Null Session Fallback, if the negotiation for Kerberos fails on older systems, or if the policy is disabled. Why kerblist is not working is strange, but I think there should be some explanation :)
Refer to technet.microsoft.com/.../jj852275%28v=ws.10%29.aspx
"When a service connects to computers running versions of Windows earlier than Windows Vista or Windows Server 2008, services that run as Local System and use SPNEGO (Negotiate) that revert to NTLM will use NULL session."