Microsoft KB Archive/326985

From BetaArchive Wiki

Article ID: 326985

Article Last Modified on 4/23/2007


  • Microsoft Internet Information Services 5.0

This article was previously published under Q326985


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:

217098 Basic overview of Kerberos authentication in Windows 2000

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:

299838 Unable to negotiate Kerberos authentication after upgrading to Internet Explorer 6

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:

248350 Kerberos authentication fails after upgrading from IIS 4.0 to IIS 5.0

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:

cscript adsutil.vbs set w3svc/1/NTAuthenticationProviders "Negotiate,NTLM"

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, 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 but the server or servers are named, you must register 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.exe 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 ( to the Active Directory for the server, where webserver1 is the NetBIOS name of the server:

    Setspn -A HTTP/ webserver1

    You receive output that is similar to the following:

    Registering ServicePrincipalNames for CN=webserver1,OU=Domain Controllers,DC=microsoft,DC=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/ to perform an HTTP connection to the Web server on the server, but this SPN is not registered on the server, the Windows 2000 domain controller will automatically map it to HOST/ 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:

109626 Enabling debug logging for the Net Logon service

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:

Kerbtray.exe: Kerberos Tray

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
Computer:       CHERYL-LAPTOP
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
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

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
Computer:       DBSERVER
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:


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

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
Computer:       DBSERVER
The logon to account: Major
 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


For more information about Kerberos, click the following article numbers to view the articles in the Microsoft Knowledge Base:

266080 Answers to frequently asked Kerberos questions

244474 How to force Kerberos to use TCP instead of UDP in Windows Server 2003, in Windows XP, and in Windows 2000

262177 How to enable Kerberos event logging

287537 Using Basic authentication to generate Kerberos tokens

277741 Internet Explorer logon fails due to an insufficient buffer for Kerberos

269643 Internet Explorer Kerberos authentication does not work because of an insufficient buffer connecting to IIS

264921 How IIS authenticates browser clients

248350 Kerberos authentication fails after upgrading from IIS 4.0 to IIS 5.0

294382 Authentication may fail with "401.3" Error if Web site's "Host Header" differs from server's NetBIOS name

217098 Basic overview of Kerberos authentication in Windows 2000

283201 How to use delegation in Windows 2000 with COM+

299838 Unable to negotiate Kerberos authentication after upgrading to Internet Explorer 6

230476 Description of common Kerberos-related errors in Windows 2000

320903 Clients cannot log on by using Kerberos over TCP

235529 Kerberos support on Windows 2000-based server clusters

929650 How to use service principal names when you configure Web applications that are hosted on IIS 6

The Kerberos FAQ contains additional information about the Kerberos protocol:

back to the top

Keywords: kbhowtomaster KB326985