There are several articles in existence about safely running the aspnet_wp.exe as the ASPNET user, or any other custom user that is specified in the <processModel> section of the machine.config file.  However, when I attempted to run the ASP.NET worker process as "machine," or any other user that had the necessary permissions, I was unable to do so.  After countless hours of creating a user, granting permissions, and following the steps set fourth by Microsoft in their patterns and practices document, what I found was that the effective settings in our Active Directory group policy were overriding the local policy that I set on my machine.  While I'm sure that their directions were well and good for traditional settings, they covered nothing about being in Active Directory and what happens to the local user permissions once they are set. 

 

However, there is a workaround for this dilemma.  In the <processModel> element of the machine.config file, set the user name to "system" and the password to "AutoGenerate."  Create a local user on your machine.  The user will need permission to access all the necessary resources (GAC, Temporary ASP.NET Files directory, etc.).  The list of necessary permissions can be found at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnnetsec/html/SecNetHT01.asp.  Additionally, if you store any username/password information in the registry, or if you need to access any legacy COM objects in a separate place on the server, the user will need to have the necessary rights.

 

Now, in the machine.config file, locate the <identity> element.  The default setting for the <identity> element is:

 

<identity impersonate="false" userName="" password=""/>

 

If you set the identity impersonation to true, but do not specify a user name and password, then the worker process attempts to access files as the IUSR_machinename account.  Now, specify a user name and password in the <identity> element, such as

 

<identity impersonate="true" userName="myLocalUser" password="myUserPassword"/>

 

In this setup, it is true that the ASP.NET worker process still runs as system, but when the worker process tries to access files on the server (either in the virtual directory, or in the Temporary ASP.NET Files directory for just-in-time compilation), it does so as the user specified in the <identity> element, not as the system user.

Editor's Note:
Readers should be cautioned that although the workaround suggested in this article may mitigate the risks associated with errors in application code running with elevated privileges, it does not and cannot eliminate all the risks associated with running the ASP.NET worker process as SYSTEM.  One such risk is that if an attacker can find a vulnerability and execute malicious code in the context of the application, it is still possible for that code to force execution to revert to SYSTEM privileges, despite the use of the <identity> configuration element.  For this reason, it is advisable to avoid running the ASP.NET worker process as SYSTEM unless no other alternative is available.