Configuring Process Identity for ASP.NET
Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1
The ASP.NET worker process (Aspnet_wp.exe) should run with a different and less privileged identity than the Windows default System identity. This allows the process to run as a relatively untrusted user so that hosted Web applications do not have administrative privileges and cannot compromise the integrity of the server. If the security of the ASP.NET worker process were breached, only a relatively weak account would be compromised and the intruder would not have administrative access to the entire server.
To run the ASP.NET worker process with its own account under Windows 2000 and Windows Server, you can apply the following two attributes to the <processModel> configuration element:
userName
The name of the account under which the process will run.
password
The clear-text password for the account. There are risks associated with storing clear-text passwords in a configuration file. For applications published on the Internet, you should use alternative means of running the application with a specific identity, or you should store encrypted credentials in the registry. For more information about storing credentials in the registry, see "<processModel>" on MSDN.
The following example shows how to set these attributes in the <processModel> section of a configuration file to run the worker process under a local user account.
<system.web>
<processModel enable="true"
userName="LOCALMACHINE\IUSR_SomeUser"
password="password"/>
</system.web>
System and Machine are two predefined userName identity settings. The System account runs the worker process with the same identity as Internet Information Services (IIS) itself (typically System). The Machine account runs the worker process with a special unprivileged account named ASPNET. With either identity, the password is AutoGenerate, which means that the process does not have to supply credentials to the operating system.
To enable running the worker process with the special ASPNET account, add the following lines to the Machine.config file. If you change the process account in Machine.config, you must reset IIS or stop the Aspnet_wp.exe process.
<system.web>
<processModel enable="true"
userName="Machine"
password="AutoGenerate"/>
</system.web>
With the new process model enabled on Internet Information Services version 6, ASP.NET does not use its own process model. Its identity is inherited from the IIS worker process.
The following example is supported only if you explicitly add the appropriate account rights to the account under which the worker process runs. There are risks associated with storing clear-text passwords in a configuration file. For applications published on the Internet, you should use alternative means of running the application with a specific identity, or you should store encrypted credentials in the registry. For more information, see "<processModel>"on MSDN.
<system.web>
<identity impersonate="true"
userName="LOCAL\SomeUser"
password="password"/>
</system.web>
The technique described in the following paragraphs is commonly used by administrators hosting ASP sites and it will work in an ASP.NET environment with a weaker process identity.
The application grants access to an anonymous user (this assumes that the authentication scheme allows anonymous users), and the anonymous account is configured to be the desired account for the application. Also, the application uses per-request impersonation and the application code executes as the impersonated account. The process account still compiles and reads configuration because impersonation is used only with the request handler.
If you alternate between running the worker process with an account that has administrator privileges and a weaker account, the weaker account will not be able to read the Local Security Authority (LSA) secret used for Forms authentication, so all Forms authentication users must be reauthenticated. This does not apply when going from an account without administrative privileges to an account with administrative privileges. It does apply to applications with the following configuration.
<system.web>
<authentication mode="Forms"/>
<machineKey validationKey="AutoGenerate"
decryptionKey="AutoGenerate"/>
</system.web>