401.1 and 401.2-Authentication Problems (IIS 6.0)
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.
When you know that authentication has failed, gather the following information:
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:
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.
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 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:
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:
Additionally, consider potential problems with the following:
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.
To configure a computer to be trusted for delegation
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:
When troubleshooting NTCR authentication, note the following:
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:
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:
The UNCAuthenticationPassthrough metabase property is no longer used for UNC authentication.
For more Information about authentication and authorization, see the following articles in the Microsoft Knowledge Base: