Things to check when Kerberos authentication fails using IIS/IE…

  • Article

Version Française

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:
 

  • 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-1.aspx (no Service Principal Name defined)

  • https://blogs.technet.com/askds/archive/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-2.aspx (Service Principal Name is not unique)

  • 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:

  • 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!

Emmanuel Boersma

Comments

  • Anonymous
    May 14, 2012
    very intense article, i would suggest to change the layout but surely this include LOTS of details which answered most of my global questions

  • Anonymous
    June 04, 2012
    This article is well written. This helped me in resolving two of my issues with one of our intranet site integrated with Kerberos. Thank you!

  • Anonymous
    July 09, 2012
    Thanks Emmanuel. This article helped me a lot.

  • Anonymous
    July 14, 2012
    Hi, 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 http://he3123/site1 http://he3123:2222/site2 Thanks

  • Anonymous
    August 12, 2012
    The comment has been removed

  • Anonymous
    April 11, 2013
    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)?

  • Anonymous
    April 28, 2013
    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 Domaincomputername$. " So Domaincomputername$ 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 :)

  • Anonymous
    April 28, 2013
    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?

  • Anonymous
    May 20, 2013
    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...

  • Anonymous
    May 26, 2013
    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."

  • Anonymous
    July 26, 2017
    I am in a serious trouble, If I launch IE 11 as an admin the Kerberos works for my website but if I donot launch it as an admin I get an Error Code: 0x19 KDC_ERR_PREAUTH_REQUIREDAll above IE setting checkedSPN checkedAny suggestions

  • Anonymous
    November 13, 2018
    The comment has been removed