Evaluating the Effects of Impersonation on Application Compatibility

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

Securing your Web sites and applications by isolating them into separate application pools with unique identities can cause application compatibility problems when you are using anything but anonymous access. The application compatibility problems arise from the complexities of impersonation.

Impersonation allows a worker process to run under security credentials that are different from its base identity. Because the two are commonly confused, it is important to understand how the worker process identity that is established by the application pool identity is related to the impersonated user.

When a worker process is created by the WWW service, it is created with a process token that is associated with the application pool identity. This establishes the process identity of the worker process. By default, all of the actions taken by the worker process are completed in the context of this worker process identity account. However, when a client request is processed, the thread that processes the request uses a token associated with the client, which is also known as the authenticated user's token, during the duration of the request.

Before IIS serves a URL, the authenticated user's token is verified against the access control list (ACL) of the resource that is being requested. Additionally, if the request is for an Internet Server API (ISAPI) extension, such as ASP, the worker process applies the authenticated user's token as an impersonation token to the thread that calls the ISAPI extension. When the ISAPI extension begins processing the request, this impersonation token applies to the actions it takes. Consequently, the actions taken by an ISAPI extension are associated with the authenticated user, not the process identity.

Evaluate the effects of impersonation behavior on compatibility for the following:

• ASP applications

• ASP.NET applications