Article ID: 326985
Article Last Modified on 4/23/2007
APPLIES TO
- Microsoft Internet Information Services 5.0
This article was previously published under Q326985
IN THIS TASK
Verify authentication methods Determine the server name Verify that the computer is trusted for delegation Use Kerbtray Enable security event logging
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:
217098 Basic overview of Kerberos authentication in Windows 2000
For more information, visit the following Microsoft Web site:
Authenticationhttp://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/default.mspx?mfr=true
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
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, 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 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:
- Install the Setspn utility.
- On the IIS server, open a command prompt, and then change to the C:\Program Files\Resource Kit directory.
- 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 - 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:
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:
- On the domain controller, click Start, point to Settings, and then click Control Panel.
- Double-click the Administrative Tools folder, and then double-click Active Directory Users and Computers.
- Under your domain, click the Computers folder.
- In the list, locate the IIS server. Right-click the server name, and then click Properties.
- 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:
Kerbtray.exe: Kerberos Trayhttp://www.microsoft.com/downloads/details.aspx?FamilyID=4e3a58be-29f6-49f6-85be-e866af8e7a88&displaylang=en
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)
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) |
| 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) |
| 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. |
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 http://www.ietf.org/rfc/rfc1510.txt.
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
REFERENCES
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:
Keywords: kbhowtomaster KB326985
