How to troubleshoot Kerberos-related issues in IIS

This article describes how to troubleshoot Kerberos authentication on Internet Information Services (IIS) servers. This is not a complete guide, but has many references that can help you to troubleshoot most Kerberos issues that you may experience.

By default, when you install IIS on a Microsoft Windows 2000 server, the NTAuthenticationProviders key in the metabase is set to Negotiate, NTLM. This means that when a Microsoft Internet Explorer 5.0 or later client connects to the Web site, IIS returns these two values in the WWW-Authenticate header. When this occurs, the client determines which authentication method it can connect with. If the client decides to connect by using the Negotiate method, the client negotiates with the server to determine whether to use Kerberos or NTLM for authentication. If the client does not support the Negotiate method, the client uses NTLM for authentication.

Note that this is a very general description of how this process works. Many other things that you may not notice also occur when Kerberos is involved.

If the Internet Explorer client can connect by using the Kerberos protocol, some additional security checks are performed. For example, the client may obtain a ticket from the Ticket Granting Service (TGS), and then use that ticket to authenticate.

For more information about how this process works, click the following article number to view the article in the Microsoft Knowledge Base: For more information, visit the following Microsoft Web site: You must be familiar with these references to troubleshoot Kerberos.

Note If you have recently upgraded to Internet Explorer 6.0, you may experience Kerberos problems because the Enable Integrated Windows Authentication check box is not selected by default. For more information about how to make sure that this option is set correctly, click the following article number to view the article in the Microsoft Knowledge Base:

Verify authentication methods

Make sure that the correct authentication methods are listed in the metabase for the IIS server or particular Web site. If your server was upgraded from Microsoft Windows NT 4.0 to Windows 2000, the Negotiate authentication method is not available, and you must add it manually. If you did not upgrade from Windows NT 4.0 to Windows 2000, make sure that the appropriate authentication methods are available. For more information about how to verify that the Negotiate authentication method is available and add the method if it is missing, click the following article number to view the article in the Microsoft Knowledge Base: Note that you can set this authentication method at the Web site level and not for the whole IIS server. To do this, use the Adsutil.vbs script to add the number of the Web site. For example, to set the authentication method for only the default Web site, use the following command:

The 1 after "w3svc" is the Web site number as listed in the Internet Services Manager (ISM).

Determine the server name

Next, determine whether you are connecting to the Web site by using the actual NetBIOS name of the server or by an alias name, such as a DNS name (for example, www.microsoft.com). If you are accessing the Web server by using a name other than the actual name of the server, a new service principal name (SPN) must have been registered by using the Setspn tool from the Windows 2000 Server Resource Kit. Because Active Directory does not know this service name, the TGS does not give you a ticket to authenticate the user. This forces the client to use the next available authentication method, which is NTLM, to renegotiate. If the Web server is responding to a Domain Name System (DNS) name of www.microsoft.com but the server or servers are named webserver1.development.microsoft.com, you must register www.microsoft.com in Active Directory on each IIS server. To do this, you must download the Setspn utility and install it on the IIS server.

For more information about how to download the Setspn utility, visit the following Microsoft Web site: Setspn.exehttp://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&DisplayLang=en (http://www.microsoft.com/downloads/details.aspx?FamilyID=5fd831fd-ab77-46a3-9cfe-ff01d29e5c46&DisplayLang=en) To determine whether you are connecting by using the actual name, try to connect to the server by using its actual name instead of the DNS name. If you cannot connect to the server, go to the Verify the Computer Is Trusted for Delegation section. If you can connect to the server, follow these steps to set an SPN for the DNS name that you are using to connect to the server:

1. Install the Setspn utility.
2. On the IIS server, open a command prompt, and then change to the C:\Program Files\Resource Kit directory.
3. Run the following command to add this new SPN (www.microsoft.com) to the Active Directory for the server, where webserver1 is the NetBIOS name of the server:
   
   Setspn -A HTTP/www.microsoft.com webserver1
   You receive output that is similar to the following:

   Registering ServicePrincipalNames for CN=webserver1,OU=Domain Controllers,DC=microsoft,DC=com
   HTTP/www.microsoft.com
   Updated object
   							

4. To view a listing of SPNs on the server to see this new value, type the following on the IIS server: Setspn -L webservername

Note that you do not have to register all services. Many service types, such as HTTP, W3SVC, WWW, RPC, CIFS (file access), WINS, and uninterruptible power supply (UPS), will map to a default service type named HOST. For example, if your client software uses an SPN of HTTP/webserver1.microsoft.com to perform an HTTP connection to the Web server on the webserver1.microsoft.com server, but this SPN is not registered on the server, the Windows 2000 domain controller will automatically map it to HOST/webserver1.microsoft.com. This mapping applies only if the Web service is running under the local System account.

Important If the SPN that you want to register is for the computer account (the Web site is running under the LocalSystem or NetworkService account), you must not change the existing SPNs of the computer. Instead, only add the new HTTP SPN. If the name of the Web site matches the host name, no change to the SPNs is required. If the standard names HOST/Server and HOST/ServerFQDN are missing, you must investigate the problems that the Netlogon service on the server has when it registers the required SPNs. You should receive error messages in the log file when you enable logging of the service. For more information, click the following article number to view the article in the Microsoft Knowledge Base: You should also receive events of Netlogon in the System eventlog about registration errors.

Verify that the computer is trusted for delegation

If this IIS server is a member of the domain but is not a domain controller, the computer must be trusted for delegation for Kerberos to work properly. To enable this, follow these steps:

1. On the domain controller, click Start, point to Settings, and then click Control Panel.
2. Double-click the Administrative Tools folder, and then double-click Active Directory Users and Computers.
3. Under your domain, click the Computers folder.
4. In the list, locate the IIS server. Right-click the server name, and then click Properties.
5. Click the General tab, click to select the Trusted for delegation check box, and then click OK.

Use Kerbtray

Another very useful utility for troubleshooting Kerberos issues is Kerbtray.exe, which is part of the Windows 2000 Resource Kit. By using Kerbtray, you can see Kerberos tickets that were granted out of the local cache. To download this utility, visit the following Microsoft Web site: For more information about this tool and tips about troubleshooting Kerberos, visit the following Microsoft Web site:

Enable security event logging

Security event logging can be invaluable when you troubleshoot Kerberos authentication failures. With this enabled, you can see logon failures when a user tries to authenticate through IIS. This provides an explanation of what may occur during the authentication process and why the authentication process is unsuccessful.

The rest of the information in this section is quoted directly fromDesiging Secure Web Based Applications for Windows 2000 by Michael Howard. Because connections in Windows 2000 are authenticated, you need to understand how to read logon events. The purpose of this section is to explain the different variables that make up a logon event.

Logon/Logoff audit settings

Microsoft Windows NT includes only one audit category for logon and logoff. Windows 2000 introduces a second. The two categories -- Logon/Logoff and Account Logon -- are explained in the following sections.

Audit account logon events (Logon/Logoff category)

This event category, available in all versions of Windows NT and Windows 2000, indicates that an account logged on or off or made a network connection to the computer. In other words, the audit event is triggered on the computer where the logon occurs. The Logon/Logoff category is important because it provides the most information when using IIS, SQL Server, and COM+.

The most significant events in the Logon/Logoff category are

• Logon/Logoff event 529 (logon failure)
• Logon/Logoff event 528 (logon success)
• Logon/Logoff event 540 (network logon success)

The following sections show these events, and Table 1 explains each of the fields in the events.

Logon/Logoff event 529 (logon failure)

Logon/Logoff event 528 (logon success) and Logon/Logoff event 540 (network logon success)

Audit account logon events (Account Logon category)

This event category indicates that an account logged on or off and that the computer was used to validate the account. In this case, the audit event is triggered on the computer where the account resides. Many Kerberos-related events, such as ticket issuing, are logged when this audit category is enabled.

The following sections show two often-seen account logon failure events.

Account Logon event 676 (logon failure): Authentication Ticket Request FailedNote What is the NT AUTHORITY\SYSTEM account? This account is usually referred to as LocalSystem; it's the account under which most services run. You'll see many references to this account in the Security Event Log.

Event 676 signifies that Major could not get an initial ticket granting ticket (TGT) from the Key Distribution Center (KDC). The most important part of the event is the failure code. These codes are the same as the MIT Kerberos codes. Table 2 describes some of the most common failure codes; a full list can be found in the main http://www.ietf.org/rfc/rfc1510.txt (http://www.ietf.org/rfc/rfc1510.txt) .

Table 2 - Some common Kerberos failure codes

Account Logon event 681 (logon failure) with a large number for the error code

You might sometimes see an error like the following. The problem is that the error code is virtually useless. Table 3 - Example account Logon error codes.


If you correlate the previous two security failure events -- Major's request for an initial TGT failing with error 6 (Client not found in the Kerberos database) when he attempted to log on and a generic logon failure occurring with error 3221225572 (The specified user does not exist) -- it's plain to see what the error is: Major isn't a valid account!

For more information about Kerberos, click the following article numbers to view the articles in the Microsoft Knowledge Base: The Kerberos FAQ contains additional information about the Kerberos protocol: