Things to check when Kerberos authentication fails using IIS/IE…
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:
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:
- Recommended hotfix
If you are running IIS 7.5 on Windows R2, make sure the following hotfix is installed : https://support.microsoft.com/kb/2545850. If you don't install this hotfix, you may hit random kerberos issues.
- Are the client and server in the same domain?
Usage of Kerberos requires a domain since a Kerberos ticket is delivered by the domain controller.
Is IIS configured to use integrated authentication?
Is integrated authentication enabled in Internet Explorer?
Does the URL used resolve to a security zone for which credentials can be sent?
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).
Is the IIS server configured to send the WWW-Authenticate: Negotiate header?
If IIS doesn't send this header, you'll need to use ADSUTIL to set the Negotiate header though the NTAuthenticationProviders metabase property (see https://support.microsoft.com/kb/215383).
Note: by default, the NTAuthenticationProviders property is not set which causes IIS to send both Negotiate and NTLM headers:
Are the client and server on the same box?
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 https://support.microsoft.com/kb/896861 for more details).
Can the client get a Kerberos ticket ?
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: https://support.microsoft.com/kb/929650
Does the web server use another port than default (80)?
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 https://support.microsoft.com/kb/908209). This will force Internet Explorer to include the port number in the SPN used to request the Kerberos ticket.
Does IE use the expected SPN?
If a web site is accessed using an alias name (CNAME), Internet Explorer will first use DNS resolution to resolve the alias name to a computer name (ANAME). The computer name will then be used to build the SPN and request a Kerberos ticket. So, even if the URL typed in IE's address bar is https://MYWEBSITE, IE will request a SPN for HTTP/MYSERVER if MYWEBSITE is an alias (CNAME) of MYSERVER (ANAME). You can change this behavior using the FEATURE_USE_CNAME_FOR_SPN_KB911149 registry key documented in this article: https://support.microsoft.com/kb/911149.
Getting a Network Monitor trace is always a good way to check the SPN associated to the Kerberos ticket:
You may also use other tools like KERBSPY (included in the KAPIMON tool) to check the SPN used by Internet Explorer:
Does the application pool identity match the account associated with the SPN?
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:
- Internet Explorer will use the URL typed in the address bar to compute a SPN
- The SPN is passed thought a SSPI API (InitializeSecurityContext) to the system component in charge of Windows security (LSASS process). At this stage, we can note that Internet Explorer code doesn't implement any code to construct the Kerberos ticket : IE just calls SSPI APIs
- Using the SPN that is passed in, LSASS requests a Kerberos ticket to a domain controller (DC). If the DC can serve the request (known SPN), it will create a Kerberos ticket, encrypt it using a key constructed from the hash of the user account's password for the account associated with the SPN. It will then proceed to send it to the client. As far as Internet Explorer is concerned, the ticket is an opaque blob.
- Internet Explorer encapsulates the Kerberos ticket provided by LSASS in the "Authorization : Negotiate" header and sends it to the IIS server
- IIS handles the request and routes it to the right application pool (using the host header specified)
- The application pool tries to decrypt the ticket using SSPI/LSASS APIs :
- If the ticket can be decrypted, Kerberos authentication succeeds and all services associated to the ticket are available (impersonation, delegation if ticket allows it…etc)
- If the ticket can't be decrypted, a Kerberos error (KRB_AP_ERR_MODIFIED) is returned. This error is a generic error indicating that the ticket has been altered in some way during its transport and could therefore not be decrypted. This error is also logged in the Windows Event Logs
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 UserAppPool1
SETSPN 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: https://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 https://support.microsoft.com/kb/970536).
We also recommend you to read the following blog articles:
https://blogs.technet.com/askds/archive/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-3.aspx (Service Principal Name is NOT added to the correct account)
Does Kerberos authentication fails in IIS7 when it worked fine in IIS6 ?
One of the new features of IIS7 is to provide kernel mode authentication. Kernel mode authentication provides a couple of advantages:
performance is increased since no more kernel mode to user mode transitions are made
decoding of the Kerberos ticket is made using machine account (not using application pool identity)
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:
- disable Kernel mode authentication
- set useAppPoolCredentials to true (this will keep you the performance benefit of kernel mode authentication while allowing to decode the Kerberos ticket under the application pool identity) – for more details, check out this blog : https://www.adopenstatic.com/cs/blogs/ken/archive/2008/02/12/16189.aspx
Why does Kerberos authentication work only for a limited amount of time under XP SP2 ?
There is a known Kerberos ticket renewal issue using XP SP2. This issue is solved with XP SP3 or using the following hotfix: https://support.microsoft.com/KB/939850
Why does Kerberos authentication work only for a limited amount of time
There is a known issue with Internet Explorer described in the following article: https://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).
Why does delegation fails when Kerberos authentication works ?
In this scenario, check the following:
- Internet Explorer Zone used for the URL. Kerberos delegation is only allowed for the « Intranet » and « Trusted Sites » zones (in other words, IE sets the ISC_REQ_DELEGATE flag when it calls InitializeSecurityContext only if the zone computed is « Intranet » or « Trusted Sites » )
- The account used for the application pool identity must have the « Trusted for delegation » flag set
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: https://blogs.iis.net/bretb/archive/2008/03/27/How-to-Use-DelegConfig.aspx
Why do I get bad performances using Kerberos authentication?
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: https://support.microsoft.com/kb/954873
Note 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!