18.2 Configuring the ASP.NET Worker Process Identity

ASP.NET uses a pool of worker processes to handle ASP.NET application requests. By default, each worker process executes in the context of a special Windows account named ASPNET. The ASPNET account is created when the .NET Framework and ASP.NET are installed, and is assigned a limited set of Windows privileges and permissions. Running ASP.NET applications with reduced permissions ensures that the applications cannot access system resources that they should not and reduces the risks posed by an application whose security has been compromised. See the .NET Framework SDK documentation for specific details of the permissions and privileges assigned to the ASPNET account.

You can configure ASP.NET applications to run in the context of the authenticated user making the request. See Section 18.5 later in this chapter for details.

You can change the account under which ASP.NET worker processes run by configuring the userName and password attributes of the <processModel> element, which is located in the machine.config file. This change affects all ASP.NET applications running on the machine; it is not possible to change the process identity for select applications.

Unlike changes to the Web.config files, ASP.NET does not detect and implement changes made to the machine.config file automatically. You must restart both the IIS Admin Service and the World Wide Web Publishing Service in order for changes to the <processModel> element to take effect. You can restart these services by running Control Panel Administration Tools Services.

ASP.NET provides two preconfigured values that you can assign to the userName attribute to control the worker process identity:

Machine

This is the default value and runs the ASP.NET application as the ASPNET account.

System

This value causes the ASP.NET worker process to run as the same account under which IIS is running; by default this will be the built-in Windows System account.

When using either of these settings, the value of the password attribute should be set to AutoGenerate to avoid the necessity of specifying the true password. For example, the following extract from the machine.config file configures the ASP.NET worker process to run as the same account used by IIS:

<configuration>   <processModel userName="System" password="AutoGenerate"/> </configuration>

Alternately, you can specify the name of an account under which the worker process should run. The userName attribute specifies the account name, and the password attribute contains the account's password in clear text. The following extract from the machine.config file configures the ASP.NET application process to run as the account "SomeUser," which has the password "secret":

<configuration>   <processModel userName="SomeUser" password="secret"/> </configuration>

The obvious downside of this approach is the presence of the plaintext username and password in the configuration file. Although by default IIS and ASP.NET are configured not to serve .config files in response to client requests, it is never good practice to list such information in plaintext.

To avoid the need to store plaintext usernames and passwords in your configuration files, store encrypted versions of them in the Windows registry. In the configuration file, provide a reference to the registry keys where the encrypted information is located, as shown in the following example:

<configuration>   <processModel userName="registry:HKLM\Software\OReilly\AspNet,Name"      password="registry:HKLM\Software\OReilly\AspNet,Password"/> </configuration>

The registry: keyword signals to the configuration system that it should refer to the Windows registry to obtain the necessary username and password details. Following the colon is the registry key path, which must be part of the local machine (HKLM) hive. The final element (following the comma) gives the name of the registry value where the information is located.

Microsoft provides a utility named Aspnet_setreg.exe that encrypts the username and password values, and places them into the registry. Full details of how to obtain and use this tool are available from MSDN by searching for Microsoft Knowledge Base Article number 329290.