Troubleshooting Kerberos Authentication Issues
NOTE: Windows Integrated authentication, Windows NT Challenge/Response (NTCR), and Windows NT LAN Manager (NTLM) are the same and are used synonymously throughout this article.
This article details steps you can take if automated Kerberos authentication is not working and you are being prompted with a NTLM username and password prompt.
How NTLM Authentication
NTLM is the authentication protocol used in Windows NT and in Windows 2000 Server work -group environments and above. It is also employed in mixed Windows Active Directory domain environments that must authenticate Windows NT systems.
NTLM Authentication Mechanism
Figure 1 shows the NTLM protocol.
Figure 1. The NTLM challenge/response mechanism
The challenge/response mechanism is outlined below:
1. User requests access. The user tries to log on to the client by providing user credentials. Before logon, the client computer caches the password hash and discards the password. The client sends a request to the server, which includes the user name along with the request in plain text. 2. Server sends challenge message. The server generates a 16-byte random number called challenge, or nonce, and sends it to the client. 3. Client sends response message. The client uses a password hash generated from the user's password to encrypt the challenge sent by the server. It sends this encrypted challenge in the form of a response back to the server. 4. Server sends challenge and response to domain controller. The server sends the user name, the original challenge, and the response from the client computer to the domain controller. 5. Domain controller compares challenge and response to authenticate user. The domain controller obtains the password hash for the user, and then uses this hash to encrypt the original challenge. Next, the domain controller compares the encrypted challenge with the response from the client computer. If they match, the domain controller sends the server confirmation that the user is authenticated. 6. Server sends response to the client. Assuming valid credentials, the server grants the client access to the requested service or resource. How Kerberos Authentication Works
Kerberos authentication offers the following advantages over NTLM authentication:
Mutual authentication. When a client uses the Kerberos v5 protocol for authentication with a particular service on a particular server, Kerberos provides the client with an assurance that the service is not being impersonated by malicious code on the network. Delegation support. Servers that use Kerberos authentication to authenticate clients can impersonate those clients and use the client's security context to access network resources. Performance. Kerberos authentication offers improved performance over NTLM authentication. Simplified trust management. Networks with multiple domains no longer require a complex set of explicit, point-to-point trust relationships. Interoperability. Microsoft's implementation of the Kerberos protocol is based on standards-track specifications recommended to the Internet Engineering Task Force (IETF). As a result, the implementation of the protocol in Windows 2000 lays a foundation for interoperability with other networks where Kerberos version 5 is used for authentication.
Kerberos Authentication Mechanism
A simplified view of the Kerberos authentication protocol is shown in Figure 2.
Figure 2. Kerberos authentication
When a client authenticates against a network service, the Kerberos v5 protocol follows these steps:
1. Client requests TGT from KDC. The user tries to log on to the client by providing user credentials. The Kerberos service on the client computer sends a Kerberos authentication service request to the Key Distribution Center (KDC). The request contains the user name, the service information for which the ticket-granting ticket (TGT) is requested, and a time stamp that is encrypted using the user's long-term key, or password.
Note On Windows 2000 Server or Windows Server 2003 operating systems, a domain controller acts as a KDC, and Active Directory hosts the security account database.
2. Authentication service sends encrypted TGT and session key. The KDC gets the long-term key, or password, for the user from Active Directory, and then decrypts the time stamp that was passed along with the request. If the time stamp is valid, the user is genuine. The KDC authentication service creates a logon session key and encrypts the copy with the user's long-term key. The authentication service then creates a TGT, which includes user information and a logon session key. Finally, the authentication service encrypts the TGT with its own key and passes both the encrypted session key and the encrypted TGT to client. 3. 4. Client requests server access from TGT. The client decrypts the logon session key using its long-term key, or password, and caches it locally. Additionally, the client stores the encrypted TGT in its cache. When accessing a network service, the client sends a request to the KDC ticket-granting service (TGS) with information, including the user's name, an authenticator message encrypted using the user's logon session key, the TGT, and the name of the service (and server) that the user wants to access. 5. 6. TGS sends encrypted session key and ticket. The TGS on the KDC decrypts the TGT using its own key and extracts the logon session key. Using the logon session key, it decrypts the authenticator message (which is usually a time stamp). If the authenticator message is successfully decrypted, the TGS extracts user information from the TGT, and using the user information creates a service session key for accessing the service. It encrypts one copy of the service session key with the user's logon session key, creates a service ticket with the service session key and user information, and then encrypts the service ticket with the server's long term key (password). The TGS then sends the encrypted service session key and service ticket to the client. 7. Client sends service ticket. When a client accesses the service, it sends a request to the server. The request contains the authenticator message (time stamp), which is encrypted using the service session-key and the service ticket. 8. Server sends encrypted time stamp for client validation. The server decrypts the service ticket and extracts the service session-key. Using the service session-key, the server decrypts the authenticator message (time stamp) and evaluates it. If the authenticator passes the test, the server encrypts the authenticator (time stamp) using the service session-key and then passes the authenticator back to the client. The client decrypts the time stamp, and if it is the same as the original, the service is genuine and the client proceeds with the connection.
Service Principal Names (SPNs)
The Kerberos v5 authentication protocol uses service principal names (SPNs) for the following reasons:
To support mutual authentication. To enable a client to request tickets, which in turn, enables the client to communicate with a particular service.
For example, if a client needs to obtain a ticket and authenticate with a particular service (MyService), which is running on a computer (MyServer) that is listening on port 4766, then the client requests a ticket from the KDC by using a name constructed from that information, as shown here:
MyService/MyServer:4766
An SPN that is registered in Active Directory maintains a mapping between this name and the domain account under which the requested service is running. By using this mechanism, it becomes difficult for a malicious user to impersonate a service on the network. The malicious user must disable the actual service and remove the actual server from the network. Then the malicious user must add a new computer to the network with the same name and expose the duplicated service. Because the client uses the Kerberos v5 protocol with mutual authentication, the client will not be able to use the duplicated service unless it can provide the password for the domain account under which the actual service is configured to run.
ASP.NET Authentication
IIS passes to ASP.NET the token that represents the authenticated user or anonymous user account. This token is maintained inside an IIdentity object that is contained inside an IPrincipal object, which, in turn, is attached to the current Web request thread. The IPrincipal and IIdentity objects can be accessed through the HttpContext.User property. These objects and this property are set by authentication modules, which are implemented as HTTP modules and invoked as a standard part of the ASP.NET pipeline, which is shown in Figure 3.
Figure 3. ASP.NET pipeline
The ASP.NET pipeline model consists of an HttpApplication object, various HTTP module objects, and an HTTP handler object, along with their associated factory objects. An HttpRuntime object is used at the start of the processing sequence. Throughout the request life cycle, an HttpContext object is used to convey details about the request and response.
For more information about the ASP.NET request life cycle, see "ASP.NET Life Cycle" at http://msdn.microsoft.com/en-us/library/ms227435(VS.80).aspx.
Troubleshooting Kerberos Authentication Issues
Configuring Delegation
To use Kerberos delegation, appropriate Active Directory configuration is required. To grant the Web server the right to delegate client credentials, configure Active Directory as follows:
If you run your application under the NetworkService account, the Web server computer account must be marked in Active Directory as trusted for delegation. If you run your application under a custom domain account, this user account must be marked in Active Directory as trusted for delegation. If your application impersonates a user account, make sure that the user account your application impersonates is not marked as "Sensitive and cannot be delegated" in Active Directory.
Check Delegation & SPNs are Configured Correctly
A tool to identify problems with Kerberos authentication can be found here… http://www.iis.net/community/default.aspx?tabid=34&g=6&i=1434 You can read how to use and install this tool here. http://blogs.iis.net/bretb/archive/2008/03/27/How-to-Use-DelegConfig.aspx
This tool will help identify if your services have correctly configured service principal names (SPN) or if any duplicate SPNs exist. It will also highlight any pass through authentication issues. 401 when trying to authenticate
Review the sub status of the 401 error (401.1, 401.2 etc) and use the guidance to troubleshoot further… http://support.microsoft.com/kb/907273 Internet Explorer prompts for a password when you are using Windows Integrated authentication (Microsoft Windows NT Challenge/Response).
The following conditions must be met for Internet Explorer to automatically authenticate a user's logon and password and maintain security: Windows Integrated authentication, also known as Windows NT Challenge/Response, must be enabled in the Web site properties in IIS. Anonymous authentication is attempted first, followed by Windows Integrated authentication, Digest authentication (if applicable), and finally Basic (clear text) authentication.
Both the client and the Web server must be either in the same Microsoft Windows NT- based or Microsoft Windows 2000-based domain or in trusted Windows NT-based or Windows 2000-based domains in which the user's account can be granted permissions to resources on the IIS-based computer.
The user's browser must be Internet Explorer. Internet Explorer is the only browser that supports Windows Integrated authentication (NTCR).
Internet Explorer must consider the requested URL to be on the intranet (local). If the computer name portion of the requested URL contains periods (such as http://www.microsoft.com and http://10.0.0.1), Internet Explorer assumes that the requested address exists on the Internet and does not pass any credentials automatically. Addresses without periods (such as http://webserver) are considered to be on the intranet (local); Internet Explorer passes credentials automatically. The only exception is addresses included in the Intranet zone in Internet Explorer.
Internet Explorer's Intranet zone security setting must be set to Automatic logon only in Intranet zone. This is the default setting for Internet Explorer. For additional information about Internet Explorer security zones, click the article number below to view the article in the Microsoft Knowledge Base:
174360 How to Use Security Zones in Internet Explorer
The user requesting the Web page must have appropriate file system (NTFS) permissions to the Web page as well as all of the objects referenced in the Web page. For example, a user may have Full Control rights to a Web page, but is prompted for a password if the Web page refers to graphics that are in a secure folder.
Internet Explorer prompts for a password when you are using Basic (clear text) authentication or Digest authentication.
Internet Explorer does not pass your user name and password automatically when you are using Basic (clear text) authentication or Digest authentication. Therefore, you are always prompted for credentials when you are using these authentication methods.
Internet Explorer prompts for a password when you are using anonymous authentication.
Anonymous authentication never prompts you for a password because IIS already knows the user name and password of the anonymous account. You are prompted for a password because Internet Explorer has been forced to use an authentication method other than anonymous. This occurs because the anonymous user account (IUSR_computername by default) did not gain access to one or more of the following items: The requested file or Web page
Any of the requested objects embedded in the file or Web page (for example, images)
The ISAPI extensions associated with the requested file or web page (for example, and .shtml file) Check Your IE Internet Zones
One of the Zones is configured to auto-authenticate with current logged on user credentials and the other is not.
IE’s default behaviour is to auto-authenticate in Intranet Zone. “http://vsserver:1024” fits the pattern of an Intranet website. Meanwhile, “http://vsserver.north.root.domain.com:1024” fits the pattern of a dotted URL address, which is treated as the Internet Zone, which does not have auto-authenticate enabled.
Thus, IE does not auto-authenticate when you use the dotted URL address, meaning that when IIS requests your administrator credentials to access the application, you get the user login popup. Windows Authentication Providers
There are 3 providers for Windows Authentication (Negotiate, NTLM & Negotiate / Kerberos). By default, negotiate is on top which is why you may be getting an authentication prompt.
Within IIS click the WinLogin folder and then select Authentication within the center IIS pane. Right click Windows Authentication and go to properties. You should see a view like this…
The above seen grab is WRONG.
Add the “Negotiate / Kerberos” Provider
Please ensure…
1. Ensure the WinLogin folder is a web application 2. Click the WinLogin folder withn IIS then click Authentication in the middle 3. Ensure anonymous is disabled & forms & windows are enabled. 4. Right click on Windows Authentication and click Providers 5. Within the Available Providers drop down list select “Negotiate / Kerberos” and click add. 6. Ensure this provider once added appears at the very top of the list above Negotiate / NTLM 7. Open the WinLogin/Web.config and ensure the authentication mode is set to "Windows".
You can also open the application host config file located at <%SystemDrive%>/Windows/System32/inetsrv/config and change the below settings. default settings
Changed to this.
Proxy Server or Similar?
Some proxy services don’t understand NTLM.
When using Integrated Authentication over the Internet. Integrated Authentication (NTLM) is a connection-based authentication protocol, meaning that an authenticated connection between a client and server is the only proof of authenticity. This works fine in Intranet scenarios, but for Internet scenarios a lot of network devices in between the client and server can either not support or mishandle NTLM (such as Proxy Server connection pooling/multiplexing), causing unexpected 401 errors. Windows Extended Protection within IIS 7.5 https://www.iis.net/configreference/system.webserver/security/authentication/windowsau thentication/extendedprotection Configuring Kerberos within IIS
The below steps will take you through the setup of Kerberos for a site. Steps 1-8 should be sufficient when you want Kerberos for the site to be configured only for single HOP. The steps followed from Step 9 shows you the configuration when you want to configure double hop i.e delegate the logged in account to a backend server (for eg a sql service).
Configuration for single hop:
1) Click on the website, go to authentication and make sure that windows authentication is enabled.
2) Make sure that when you want to use windows authentication, anonymous authentication is not enabled, which is a common mistake I have observed. Because anonymous authentication takes more precedence than windows authentication. Below is the link which talks about precedence in authentication. http://msdn.microsoft.com/en-us/library/ee825205(v=cs.10).aspx
3) Enabling windows authentication doesn’t mean Kerberos protocol will be used. It might also use NTLM which is also a provider in windows authentication. In order to setup Kerberos for the site, make sure “Negotiate” is at the top of the list in providers section that you can see when you select windows authentication. Negotiate is a provider or container which supports Kerberos protocol and it also contains NTLM as a backup when Kerberos fails due to some reason. But one important thing to keep in mind over here is when we want to use Kerberos “Negotiate” should be at the top.
4) So above three steps should be sufficient when you want to browse your site with the machine name as http://machinename or http://FQDN of machine name and you need not create any SPN’s (concept of SPN is explained in my previous blog) as you will have a HOST SPN registered to your machine account by default when you join a machine to a domain. HOST SPN is similar to HTTP SPN’s and should be sufficient when you want to access a site over Kerberos.
For eg: If you have a machine with the name ‘illuminati’ a host SPN for illuminati will be present and it will be registered to your inbuilt machine account. You can confirm this through running the below command. Setspn –l machineaccount
Setspn –l illuminati : this will query for all the SPN’S registered to the machine account illuminati.
5) If you want to access the site with a custom hostname we need to create appropriate SPN for the hostname and we need to register it either to the machine account or to the domain account.
We usually don’t register the SPN to a machine account and choose domain accounts when we have a web farm scenario (same site hosted in multiple servers behind a load balancer) and the same ticket from AD should be accessible in all the machines in the farm.
6) Let’s consider the below scenario with imaginary hostname, machine name and a domain account.
FQDN Machine name: illuminatiserver.domain.com
Hostname: Kerberos.com
Domain account: domain\chiranth
Note: Be careful while choosing a hostname. The hostname shouldn’t have “www.” If we have www in the hostname Kerberos will fail, because when a client tries to access a site with hostname www in it, it will try to go over internet rather than intranet zone.
7) For the above requirements with a custom hostname we can create SPN’s in either one of the two ways. It can be chosen on your requirement and the policies you have.
Method 1: Registering a SPN to a machine account.
When you have a custom hostname and you want to register it to a machine account, you need to create an SPN as below.
Setspn –a HTTP/HOSTNAME machineaccount
Eg: setspn –a HTTP/Kerberos.com illuminatiserver
Method 2: Registering a SPN to a domain account.
When you have a custom hostname and you want to register it to a domain account, you need to create a SPN a below.
Setspn –a HTTP/HOSTNAME domainaccount
Eg: setspn –a HTTP/Kerberos.com domain\chiram
Note: These commands can be run on any machines within the domain but In order to create or delete SPN’s you need to be a domain admin privileges.
8) So once we have the proper SPN in place we need to modify the configuration of IIS such that we point IIS to the account to which we have the SPN registered and what account’s credentials IIS needs to use to decrypt the ticket forwarded by the client which obtained from AD. So again based on the above two variations, configuration settings will differ as below.
Method 1: Configuration when we have SPN registered to machine account. a) Click on the site and go to configuration editor and traverse to the path system.webServer/security/authentication/windowsAuthentication
b) Make sure that usekernel mode is set to true. Usekernel mode setting tells IIS that it needs to use its machine account to decrypt the Kerberos token/ticket which was obtained from AD and forwarded by the client to the server to authenticate the user. c) Also when have usekernel mode set to true the decryption of the ticket happens at the kernel level which is performance effective and a faster process.
Method 2: Configuration when we have SPN registered to the domain account. a) Go to advanced settings of your application pool under which your website is running and change the identity to the domain account. In our case it will be domain\chiranth
b) Now Click on the site and go to configuration editor and traverse to the pathsystem.webServer/security/authentication/windowsAuthentication
d) Make sure that you have “useAppPoolCredentials” set to true. When you have“useAppPoolCredentials” set to true you are telling IIS that it needs to use its application pool identity(which we have changed in the previous step to point to domain account) to decrypt the Kerberos token/ticket which was obtained from AD and forwarded by the client to the server to authenticate the user.
Note: If we have both useAppPoolCredentials and kernel mode set to true useAppPoolCredentialstakes precedence and application pool account is used for decryption of the ticket. Usekernelmodesetting was introduced from IIS 7 and higher versions. In IIS 6 and lower version always the application pool identity was used for decryption of the token/ticket.
Configuration for double hop:
9) The above steps should be sufficient if you expect your site to work over a single Hop. But if you want to delegate the logged in credentials to the backend server, For e.g. if you are passing the logged in credentials to the backend database server and have integrated security = true /SSPI you need to continue following the below steps.
10) Click on site and in authentication section make sure that you have ASP.NET impersonation enabled along with windows authentication.
11) Now you need to specify in AD that the account to which your HTTP service/SPN is registered (for the hostname) is authorized to delegate the user logged in credentials to any backend service (for eg: MSSQL service). This setting again varies on the type of SPN you have registered and might fall under any one of the below categories.
Method 1: When SPN is registered to machine account. a) Go to Active directory Users and Computers. b) Click on computers. c) Search for your computername (in our case illuminatiserver) and go to its properties. d) Select the delegation tab and choose the second option (unconstrained delegation) ‘Trust this computer for delegation to any service’ where you are authorizing the machine account “illuminatiserver” with the power to delegate the logged in credentials of an user to any backend service running on any machine.
Method 2: When SPN is registered to a domain account. a) Go to Active directory Users and Computers. b) Click on Users. c) Search for your domain user account (in our case domain\chiranth) and go to its properties. d) Select the delegation tab and choose the second option (unconstrained delegation) ‘Trust this account for delegation to any service’ where you are authorizing the domain account “illuminatiserver” with the power to delegate the logged in credentials of an user to any backend service running on any machine.
12) We might have policies where we don’t want to enable delegation to all the services i.e we don’t want to have unconstrained delegation setup due to some security policies in such cases we need to enable constrained delegation.
To enable constrained delegation on the delegation tab select the 3 rd option where it says “Trust this account for delegation to specified service” and in the bottom windows you can add the list of backend services (MSSQLSVC, CIFS service) specific to the machines to which your SPN account can delegate the login credentials.
For eg: I have registered my HTTP SPN to domain\chiranth and in the delagtion tab of chiranth I have selected the third option “Trust this account for delegation to specified service” and in the list of service I have specified MSSQLSvc/MySQLServer:1433.
The above setting specifies that domain\chiranth account will be able to delegate the logged in credentials in IIS server to only MSSQLSvc running MySQLServer on port 1433 and no other services or machines.
Additional Suggestions
Adsi edit
To set the Trust computer for delegation option 1. Click Start, point to Program Files, point to Administrative Tools, and then click Active Directory Users and Computers. 2. Navigate to the computer account that needs to be set, for example, Active Directory Users and Computers/
Ensure only 1 SPN for the IIS app pool system account using setspn https://technet.microsoft.com/en-us/library/cc731241(v=ws.11).aspx setspn -Q */*Win2k8r2* >>C:spn_recordswin2k8r2.txt
Powershell to show all AD SPNS
#Set Search cls $search = New-Object DirectoryServices.DirectorySearcher([ADSI]“”) $search.filter = “(servicePrincipalName=*)” $results = $search.Findall()
#list results foreach($result in $results) { $userEntry = $result.GetDirectoryEntry() Write-host "Object Name = " $userEntry.name -backgroundcolor "yellow" - foregroundcolor "black" Write-host "DN = " $userEntry.distinguishedName Write-host "Object Cat. = " $userEntry.objectCategory Write-host "servicePrincipalNames" $i=1 foreach($SPN in $userEntry.servicePrincipalName) { Write-host "SPN(" $i ") = " $SPN $i+=1 } Write-host ""
}
Further Considerations
Ensure domain controller and client are within 10 minutes of each other. Other Links of Interest
An unexpected 401.1 status is returned when using Pre-Authentication Headers with Internet Explorer and Internet Information Services https://www.youtube.com/watch?v=ztY1mqsBedE https://blogs.msdn.microsoft.com/friis/2009/12/31/things-to-check-when-kerberos- authentication-fails-using-iisie/ https://support.microsoft.com/en-gb/kb/2749007 https://support.microsoft.com/en-gb/kb/871179 https://support.microsoft.com/en-gb/kb/896861 https://www.iis.net/configreference/system.webserver/security/authentication/windowsau thentication http://blogs.iis.net/webtopics/unexpected-401-1-error-over-windows-integrated- authentication-on-iis-7-5-website http://www.adopenstatic.com/cs/blogs/ken/archive/2007/01/16/1054.aspx https://blogs.msdn.microsoft.com/friis/2009/12/31/things-to-check-when-kerberos- authentication-fails-using-iisie/ https://blogs.technet.microsoft.com/askds/2008/05/14/troubleshooting-kerberos- authentication-problems-name-resolution-issues/