Microsoft KB Archive/332142

= NTLM requests for content on UNC share may be returned with 401 error messages =

Article ID: 332142

Article Last Modified on 12/3/2007

-

APPLIES TO


 * Microsoft Internet Information Server 1.01
 * Microsoft Internet Information Services 6.0
 * Microsoft Internet Information Services 5.1
 * Microsoft Internet Information Services 5.0
 * Microsoft Internet Information Server 4.0

-



This article was previously published under Q332142



We strongly recommend that all users upgrade to Microsoft Internet Information Services (IIS) version 6.0 running on Microsoft Windows Server 2003. IIS 6.0 significantly increases Web infrastructure security. For more information about IIS security-related topics, visit the following Microsoft Web site:

http://www.microsoft.com/technet/security/prodtech/IIS.mspx





SYMPTOMS
When cached content or an ISAPI extension located on a UNC share and hosted on Internet Information Services (IIS) is requested with NTLM authentication, users may see inconsistent results. In some situations the content is served, but in other situations the user receives the following error message, even if the user is the same:

HTTP 401.3

Access denied by ACL on resource



CAUSE
When an IIS server contains content or an ISAPI extension that is located on a UNC share without delegation, an NTLM-authenticated request to that IIS server is unsuccessful on the first attempt. The request succeeds after a successful Basic-authenticated request. You may experience similar behavior for requests for other types of content.



STATUS
This behavior is by design.



MORE INFORMATION
The sequence of events that causes this behavior for an ISAPI extension is as follows:
 * 1) A request that uses NTLM authentication is made to the server. IIS tries to call the LoadLibraryW function. This call is unsuccessful because the NTLM credentials cannot be delegated.

NoteLoadLibraryW is the Unicode version of LoadLibrary. LoadLibrary maps the specified executable module into the address space of the calling process.
 * 1) The server receives another request that uses Basic authentication (for example, the request is received from a client that is using Microsoft Windows 98 or Netscape). In this case, because the token can be delegated, the LoadLibraryW call succeeds and returns a handle that is valid on the IIS server.
 * 2) The AccessCheck function is called on the handle to verify that the user has sufficient credentials to make the request. If the user has access, the request will succeed.

NoteAccessCheck determines whether a security descriptor grants a specified set of access rights to the client identified by an access token.
 * 1) A new request that uses NTLM authentication is received. A LoadLibraryW call is not required because a handle to the extension was loaded on the IIS server when the prior Basic authentication request succeeded. ( In the case of content on a UNC share, the content may be cached on the server from the successful Basic request.) AccessCheck is called on the handle. This can be done without delegation because all of the objects and tokens are now local. If AccessCheck succeeds, IIS allows the request.

ImportantAccessCheck is called on each request. If AccessCheck fails, IIS returns an HTTP 401 (unauthorized) error message. Because of this, no user is granted access without sufficient credentials. All three requests can be made by the same user, by different users, or any combination of the two. The important factor is whether IIS already has a handle or cached content for the request.

With Basic Authentication, we recommend that the data is encrypted by using SSL. This is because it is very easy to obtain credentials from a network trace. For more information about how to install SSL under IIS 5.0, click the following article number to view the article in the Microsoft Knowledge Base:

228836 Installing a new certificate with Certificate Wizard for use in SSL/TLS

