401.1 and 401.2-Authentication Problems

Article
10/08/2009

Applies To: Windows Server 2003, Windows Server 2003 with SP1

Typically, HTTP 401.1 and 401.2 errors are encountered when the authentication process fails in some way — either because the mechanism that IIS used to obtain the credentials has failed or because the credentials themselves are invalid. This is an important distinction that is a critical to the problem isolation process. These errors tell you that, before performing any other function, IIS has failed to authenticate the user.

For a brief overview of the authentication options available in IIS, see Managing a Secure IIS 6.0 Solution.

Initial Isolation

When you know that authentication has failed, gather the following information:

The URL that is being requested
The authentication method that is configured for that node in the metabase

When you know the requested URL, you can use IIS Manager to verify the authentication methods that are enabled. Alternatively, you can use the Adsutil.vbs command-line script to check the AuthFlags metabase property. For information about the settings for this property, see AuthFlags Metabase Property.

Multiple Authentication Methods

Typically, initial HTTP requests to a server are anonymous. In most cases, a Web browser does not know to send authentication information, and, therefore, it issues a request without this information. If Anonymous authentication is enabled for the requested resource, IIS does not attempt to use other authentication protocols, but instead attempts to obtain a security token for the IUSR_ComputerName account by calling one of the Windows logon APIs. If this fails, then IIS looks to see if other authentication methods are enabled for the URL and sends back a 401.2 response to the browser that includes a list of WWW-Authenticate HTTP headers that specify the authentication schemes IIS is configured to accept for that URL.

At this stage, typically it is up to the HTTP client to choose to continue the HTTP transaction, to pick a protocol from the list, and to proceed to authenticate with that protocol. If this process is successful, IIS then calls a logon API and obtains a security token that it can use to associate a user context with the HTTP request.

LogonMethod Default Has Changed

The LogonMethod metabase property designates the kind of logon token that IIS asks for when calling the Windows logon APIs for Anonymous or Basic authentication. In earlier versions of IIS, the default was set to 0, which caused IIS to request an INTERACTIVE token. This sometimes caused problems when the IUSR_ComputerName, or, in the case of Basic authentication, the user credentials did not have the Log on locally user right. In such a case, IIS returns a 401.1 error.

In IIS 6.0, the default value of LogonMethod has changed to 3, which evaluates to a NETWORK_CLEARTEXT token. This token is very similar to an INTERACTIVE token; however, it does not allow the user to physically log on to the system console and does not require the Log on locally user right.

For more information, see Securing Sites with Web Site Permissions.

No Authentication Methods Selected (AuthFlags=0)

IIS returns a 401.2 error when no authentication methods are enabled. If you receive this error, ensure that an authentication method is enabled.

Anonymous Accounts (IUSR_ComputerName) Attempting Sub-authentication Logon Receive the 401.1 Error: Logon Failed

By default, the sub-authentication component, Iissuba.dll, is not enabled in IIS 6.0. In earlier versions, Iissuba.dll allowed IIS to manage passwords on anonymous accounts, which created a potential security risk. In IIS 6.0, you can use sub-authentication to manage passwords for anonymous accounts. To do so, your configuration must meet the following requirements:

For applications for which you grant anonymous access, the worker process must run as LocalSystem.
The sub-authentication component, Iissuba.dll, must be registered.
The AnonymousPasswordSync metabase property must be enabled (set to true).

The actions taken to meet these requirements are different for clean installations of IIS 6.0 and upgrades to IIS 6.0 than they are for installations of IIS with sub-authentication configured. For more information about configuring sub-authentication, see Anonymous Authentication in IIS 6.0.

Additionally, when you encounter a 401.1 error, ensure that the account configured for anonymous authentication has not expired or is not locked out.

Non-Anonymous authentication

Initially, a Web browser issues an anonymous request. If Anonymous authentication is not enabled or if Anonymous authentication fails, IIS sends a list of supported authentication protocols as a group of WWW-Authenticate HTTP headers. At this point, the browser chooses the protocol to use, and then continues processing the request.

Basic authentication

Basic authentication is the simplest authentication protocol. Because of its simplicity, it is a good authentication method to enable temporarily when you are troubleshooting authentication problems. Use this authentication protocol if you want to quickly verify that a password is correct or that communication with a domain controller is working.

If the user name is a domain account, IIS contacts a domain controller to verify the credentials. If this fails, IIS returns a 401.2 error. If communication with the domain controller is successful, but the user name or password is invalid, IIS returns a 401.1 error.

Internet Explorer — not IIS — allows the user three connection attempts before rejecting the connection request and reporting an error to the user. When the Web server verifies that the user name and password correspond to a valid Windows Server 2003 user account, a connection is established.

Integrated Windows authentication

Integrated Windows authentication actually encompasses two different authentication protocols: Kerberos and Windows NT Challenge/Response, also known as NTLM. When this authentication protocol is enabled, IIS sends the following HTTP headers to the browser:

WWW-Authenticate: Negotiate
WWW-Authenticate: NTLM

The Negotiate header indicates that IIS can negotiate which of the two Windows authentication protocols to use. Internet Explorer 5, or later, recognizes this authentication header and determines which of the two authentication protocols to use. The NTLM authentication header is used as a fallback for browsers that do not support the Negotiate authentication header.

Kerberos protocol authentication

Authentication with the Kerberos protocol occurs as follows:

IIS requests authentication.
If the Windows user has not logged on to a domain, a dialog box requesting credentials appears in Internet Explorer, and then IIS contacts the Ticket Granting Server or Key Distribution Center (KDC) to request and receive a Ticket Granting Ticket. It then sends the Ticket Granting Ticket along with information about the server running IIS to the KDC.
1. If the Windows user has already successfully logged on to the domain and received a Ticket Granting Ticket, IIS sends this ticket along with information about the IIS server to the KDC.
2. The KDC issues the client a Resource Ticket.
3. The client passes this ticket to the server running IIS.
  
  When troubleshooting Kerberos, ensure that the browser can make a trusted connection to the KDC by meeting the requirements listed in Microsoft Knowledge Base article 326985, How To: Troubleshoot Kerberos-related Issues in IIS.

Additionally, consider potential problems with the following:

Service Principal Names. Kerberos uses a service for authentication. When the client passes the Ticket Granting Ticket and the information about IIS to the KDC, part of this information includes the server name from the URL that the browser is attempting to reach. By default, upon installation a systems NetBIOS name is registered in Active Directory® directory service. This is the name that a KDC uses to recognize IIS. It is called the Service Principal Name (SPN). If the browser is accessing the Web server by using some other host name — either the FQDN or another host header name — that name must be registered with Active Directory. You can do this by using the Setspn.exe command-line utility. For more information about Setspn.exe, in Help and Support Center for Windows Server 2003, click Tools, and then click Windows Support Tools.
Kerberos authentication. If you suspect that you are having a problem with the SPN, test Kerberos authentication by using the NetBIOS computer name. If the test is successful, you probably need to use the Setspn.exe command-line utility.

To run Setspn.exe, at a command prompt, type the following:

**Setspn -A HOST/**ServicePrincipalNameServiceAccount

In the above syntax, ServicePrincipalName is the new host name that you want to register and ServiceAccount is the identity under which the process that is hosting the service will be running. For computer accounts, like NetworkService or LocalSystem, use the NetBIOS name of the computer.

Note

The LocalService account, along with any other local accounts on an IIS server, cannot be authenticated by a KDC. Therefore, you cannot use the Kerberos protocol for authentication if the worker process identity is set to LocalService or to another account on the local computer.

Trust for delegation configuration. When troubleshooting Kerberos authentication, also ensure that the IIS computer is configured to be trusted for delegation in Active Directory. If the server running IIS is a member of the domain and is not a domain controller, then it must be trusted for delegation in order for Kerberos to work properly.

To configure a computer to be trusted for delegation

On the Domain controller, click Start, point to Administrative Tools, and click Active Directory Users and Computers.
Under the domain, double-click the Computers folder, right-click the server that is running IIS, and then click Properties.
Click the General tab.
Select the Trusted for delegation check box.
Click OK.

The computer account is now trusted for delegation.
- Security auditing. By enabling security auditing on the server running IIS, you can use the events that are logged to discover whether problems are occurring.
  
  For information about using the security log to troubleshoot Kerberos, see article 326985, How To: Troubleshoot Kerberos-related Issues in IIS.

Windows NT Challenge/Response protocol

Windows NT Challenge/Response (NTCR) protocol differs from Kerberos in that the server presents the HTTP client with a "challenge" and the client responds with its response. This way, the client's password is never sent over the network. Authentication with the NTCR protocol occurs as follows:

Typically, the client issues an initial anonymous request. When the anonymous request is rejected, IIS returns a 401.2 error and the WWW-Authenticate headers.
If the client fails or does not support Kerberos, the Negotiate and NTLM header values initiate an NTCR authentication exchange. The client closes the TCP connection, opens a new one, and sends a request that includes an Authorization: NTLM header. This header also includes encoded text that represents the users UserName, ComputerName, and Domain. This text is used by the Windows Security Support Provider Interface (SSPI) to generate the challenge. If the user account is not a local Windows account on the IIS server, the data is passed on to an appropriate domain controller, which then generates the challenge.
The challenge is sent to the client and IIS returns another 401.2 error.
The client uses its password and the challenge to create a mathematical hash. The client sends the hash back to the server in another Authorization: NTLM header.
The server accepts the response, and the local security provider or the appropriate domain controller recreates the same hash and compares the two. If they match, the user is successfully authenticated.

When troubleshooting NTCR authentication, note the following:

Point-to-point connections. NTCR authentication requires point-to-point connection between the client and the server that is running IIS. Consequently, the NTRC protocol will not work with some European Organization for Nuclear Research (CERN) proxies and other Internet devices. As a result, NTCR is not suitable for use over the Internet. If a connection is broken during authentication, IIS returns a 401.2 error.
HTTP keep-alives. A connection must be maintained through the entire authentication sequence. Therefore, HTTP keep-alives must be enabled on the server running IIS. If they are not enabled, IIS continues to return 401.2 errors until the browser fails the authentication sequence.
Security privileges. The user account accessing the server must have the Access this computer from the network privilege. If this is not the case, IIS returns a 401.1 error.
Domain controller communication. As with Basic authentication, if the credentials presented by the client are for a domain user account, the server running IIS needs to contact a domain controller.

AuthPersistence Usage in IIS 6.0

In earlier versions of IIS, the AuthPersistence metabase property had three possible settings. Two of the settings allowed administrators to enhance performance by specifying persistence based on the existence of a proxy server. Administrators could use either of those AuthPersistence settings to force IIS to negotiate one-time-per-client connections and then use those credentials for subsequent requests over the same connections. These two settings have been removed from IIS 6.0 for security reasons.

In IIS 6.0, the only valid setting for the AuthPersistence metabase property is AuthPersistSingleRequest, and NTLM is the only IIS 6.0 authentication protocol that honors this setting. The setting for AuthPersistSingleRequest is honored only in the following circumstances:

Integrated Windows authentication is set to NTLM.
Integrated Windows authentication is set to Negotiate, and NTLM authentication is used.

In either of these cases, AuthPersistSingleRequest is False — that is, not set — for backward compatibility with earlier versions of IIS. A value of False means that authentication persists for subsequent requests over the same connection.

In IIS 6.0, all other authentication protocols assume that the value of AuthPersistSingleRequest is True — that is, set — so authentication persists only for a single request over a connection. IIS 6.0 automatically resets authentication at the end of a request and forces each subsequent request over the same connection to authenticate.

401.3-Unauthorized: Access Is Denied Due to an ACL Set on the Requested Resource

A 401.3 error is a catchall "access denied" error. To troubleshoot this error, first check the authentication method that is enabled on the requested URL. This will help you determine the security context under which the request is expected to execute: as an anonymous user or as an authenticated user. How you proceed depends on whether the user is authenticated or not.

Verify file and directory ACLs. When the requested URL is a directory, not a file, check the default document(s) that are configured for that URL. Sometimes, if the first document in the default document list is missing, the second document in the list might generate a 401.3 error.

After verifying the ACLs, you have a few options. You can enable security auditing for object access failures. This can be difficult, though, because you have to enable auditing on the individual objects (files, directories, and so on) that you want to monitor. Alternatively, you can use File Monitor and Registry Monitor to look for access denied problems in the registry or file system.

Simplified UNC authentication model

The Universal Naming Convention (UNC) authentication method, also called UNC Pass-through authentication, determines the credentials used for gaining access to a UNC share on a remote computer. Beginning with IIS 6.0, the UNC authentication method looks at the request user and the credentials stored in the UNCUserName and UNCPassword properties of the metabase to determine the credentials to pass through to the computer with the UNC share. This occurs in the following way:

If the UNCUserName is specified (not empty) and UNCPassword is valid, the requested user credentials are sent as the user identity for access to the remote share. If the UNCUserName is specified and the UNCPassword is not valid, a 500-Internal Server Error message is sent to the client. For information about troubleshooting this error, see HTTP 500.x -- Internal Server Error Codes.
If the UNCUserName is not specified, then the credentials of the request user (either an authenticated set of credentials for authenticated requests or IUSR_ComputerName credentials for anonymous requests) are sent as the user identity for access to the remote share.