How to troubleshoot Kerberos-related issues in IIS (326985)

SUMMARY

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: back to the top

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).

back to the top

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=4e3a58be-29f6-49f6-85be-e866af8e7a88&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 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 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.

back to the top

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.

back to the top

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: back to the top

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)

Event Type:     Failure Audit
Event Source:   Security
Event Category: Logon/Logoff 
Event ID:       529
Date:           9/3/1999
Time:           8:57:21 PM
User:           NT AUTHORITY\SYSTEM
Computer:       CHERYL-LAPTOP
Description:
Logon Failure:
   Reason:           Unknown user name or bad password
   User Name:        Administrator
   Domain:           CHERYL-LAPTOP
   Logon Type:       2
   Logon Process:    seclogon
   Authentication Package: Negotiate
   Workstation Name: CHERYL-LAPTOP

				

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

Event Type:     Success Audit
Event Source:   Security
Event Category: Logon/Logoff 
Event ID:       540
Date:           1/23/2000
Time:           5:41:39 PM
User:           EXAIR\Cheryl
Computer:       CHERYL-LAPTOP
Description:
Successful Network Logon:
   User Name:        cheryl
   Domain:           EXAIR
   Logon ID:         (0x0,0x17872A8)
   Logon Type:       3
   Logon Process:    Kerberos
   Authentication Package: Kerberos
   Workstation Name:

				

Field	Comments
Event Type, Source,Category,ID,Date,and Time	self-explanatory
User	The user account performing the logon. For example, this might be NT AUTHORITY\SYSTEM,which is the LocalSystem account used to start many Windows 2000 services.
Computer	The computer on which the event occurred
Reason	Applies to logon failures only; it's the reason the account failed to log on.
User Name	The name of the user account attempting to log on
Domain	The domain of the user account attempting to log on.
Logon Type	A numeric value indicating the type of logon attempted. Possible values are: 2 - Interactive (interactively logged on) 3 - Network (accessed system via network) 4 - Batch (started as a batch job) 5 - Service (a Windows service started by service controller) 6 - Proxy (proxy logon; not used in Windows NT or Windows 2000) 7 - Unlock (unlock workstation) 8 - NetworkCleartext (network logon with cleartext credentials) 9 - NewCredentials (used by RunAs when the /netonly option is used)
Logon Process	The process performing the logon. The following are some example logon processes: - Advapi (triggered by a call to LogonUser; LogonUser calls LsaLogonUser, and one of the arguments to LsaLogonUser, OriginName, identifies the origin of the logon attempt) - User32 (normal Windows 2000 logon using WinLogon) - SCMgr (Service Control Manager started a service) - KsecDD (network connections to the SMB server-for example, when you use a NET USE command) - Kerberos (the Kerberos Security Support Provider [SSP]) - NtlmSsp (the NTLM SSP) - Seclogon (Secondary Logon-that is, the RunAs command) - IIS (IIS performed the logon; generated when logging on the IUSR_machinename account or when using Digest or Basic authentication)
Authentication Package	The security package called to attempt to log on the account. An authentication package is a dynamic-link library (DLL) that analyzes logon data and determines whether to authenticate an account. Most common examples are Kerberos, Negotiate, NTLM, and MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 (also called MSV1_0; authenticates users in the SAM database, supports pass-through authentication to accounts in trusted domains, and supports subauthentication packages) Workstation Name Workstation name, if known, used by the principal during logon.

back to the top

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 Failed

Event Type:     Failure Audit
Event Source:   Security
Event Category: Account Logon 
Event ID:       676
Date:           5/11/2000
Time:           8:47:01 PM
User:           NT AUTHORITY\SYSTEM
Computer:       DBSERVER
Description:
Authentication Ticket Request Failed:
   User Name:  Major
   Supplied Realm Name:    EXPLORATIONAIR.COM
   Service Name:     krbtgt/EXPLORATIONAIR.COM
   Ticket Options:   0x40810010
   Failure Code:     6
   Client Address:   172.100.100.12

				

Note 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 Kerberos Request For Comments: RFC 1510.

Table 2 - Some common Kerberos failure codes

Failure Code	Comments
6	Client not found in the Kerberos database.
7	Server not found in the Kerberos database. This generally indicates a service principal name (SPN) has not been registered for the service.
23	Password has expired.
32	Ticket has expired.
33	Ticket not yet valid.
34	Request is a replay. Someone is trying to play back a Kerberos client's response; you are possibly being attacked.
37	Clock skew too great. Kerberos is time-critical; make sure all clocks are synchronized

back to the top

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.

Event Type:     Failure Audit
Event Source:   Security
Event Category: Account Logon 
Event ID:       681
Date:           5/11/2000
Time:           8:47:01 PM
User:           NT AUTHORITY\SYSTEM
Computer:       DBSERVER
Description:
The logon to account: Major
 by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
 from workstation: WEBSERVER
 failed. The error code was: 3221225572

				

Table 3 - Example account Logon error codes.

Error Code(Decimal)	Error Code(Hex)	Comments
3221225572	0xC0000064	The specified user does not exist.
3221225570	0xC0000062	The name provided is not a properly formed account name.
3221225569	0xC0000061	A required privilege is not held by the client.
3221225578	0xC000006A	When trying to update a password, this return status indicates that the value provided as the current password is not correct.
3221225580	0xC000006C	Password is not correct. When trying to update a password, this status indicates that some password update rule has been violated.For example, the password might not meet length criteria.
3221225585	0xC0000071	The user account's password has expired.
3221225586	0xC0000072	The referenced account is currently disabled.

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!

back to the top