I seem to have forgotten to describe how the following aspect of IIS functions in the prior post because I was concentrated on clarifying something else (that your Windows logon is NOT the same as logon via IIS). Thus, I got the following followup:

Question:

Answer:

Yes, you are describing one of many common misunderstanding about the user identity IIS uses to executes requests and run code like ISAPI and CGI.

Overall, the desired IIS behavior is to run user applications as the authenticated user identity, whatever it is.

Authentication controls the protocols that IIS will use to negotiate user identity with the client. At the end of Authentication, IIS expects to either reject with a 401 because the client failed to provide sufficient/correct user identification, or IIS will have a NT User Token that represents the user principle.

Then, IIS will use this NT User Token to perform all Authorization (access checks) against the requested resource.

Since anonymous authentication does not negotiate any user principle, it means that this authentication process MUST use some other pre-determined username/password. This is why IIS creates the IUSR_machine account and why you want to keep the username/password in sync within the metabase. If this username/password is incorrect, IIS will be unable to allow anonymous access because it cannot login the user identity to get a NT User Token to process the request, and it will return a 401.1.

After Authentication and Authorization finishes, IIS has two NT user tokens with which it can choose to execute this request with:

1. The NT User Token obtained through the Authentication process
2. The Process Identity

By design, IIS executes code in the following way:

1. For ISAPI Filter DLL, the code is executed using the process identity. IIS will not impersonate user identity prior to invoking its entrypoints. This makes a lot of sense because impersonation is expensive and ISAPI Filter runs during request processing itself - and IIS certainly does not impersonate unnecessarily.
2. For ISAPI Extension DLL, the code is executed by impersonating the NT User Token obtained through Authentication. This allows ISAPI applications like ASP and ASP.Net to offer security checks based on the remote user's identity - a powerful integration feature.
3. For CGI EXE, it depends on the value of the "CreateProcessAsUser" metabase property applicable to the URL. It defaults to TRUE and means to create the CGI process using the NT User Token obtained through Authentication. If FALSE, then the Process Identity is used instead.

Now, how the ISAPI and CGI chooses to execute code afterwards, that behavior is completely arbitrary and outside of IIS control. For example:

1. ASP chooses to keep the impersonated identity and use it to execute the page and access resources
2. ASP.Net allows configuration via the <identity> element. You can tell ASP.Net to keep the impersonated identity, strip it off and use the Process Identity, or impersonate a totally new username/password to execute code

Finally, ISAPIs like ASP and ASP.Net are application frameworks that allow arbitrary user code to run, so some of that user code CAN change the impersonation token of a thread (which subsequently changes the identity used to execute other code on that thread [until the thread token is reset, of course - but this is no longer documented nor reliable behavior]). Thus, it is also possible for some COM components instantiated in your ASP page or global.asa file, or Managed code classes calling RevertToSelf() or otherwise stripping/resetting the impersonation token, to change the effective user identity that executes code on the server.

//David