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:
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:
By design, IIS executes code in the following way:
Now, how the ISAPI and CGI chooses to execute code afterwards, that behavior is completely arbitrary and outside of IIS control. For example:
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.