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.