Configuring ASP.NET Process Identity
ASP.NET pages are executed within a process, or Windows program. All Windows programs run with a specific security identity. By default, the ASP.NET process runs under a predefined Windows identity. Alternatively, by configuring your application to use impersonation, you can set ASP.NET to run under a different identity or under the Windows identity of the user making the request.
To help improve the security of your ASP.NET applications, you should make sure that the ASP.NET process runs with an identity that has only the minimal permissions required to run your applications. This reduces the vulnerability of any resources that are exposed by ASP.NET, should a security breach occur.
On a Web server running Microsoft Windows Server 2003 and Internet Information Services (IIS) 6.0, the ASP.NET process runs in the application pool for the Web application. The application pool defines the identity that ASP.NET runs under (by default, the NETWORK SERVICE account). On earlier versions of IIS, (in Microsoft Windows 2000 and Windows XP Professional operating systems), ASP.NET runs in the ASP.NET worker process (Aspnet_wp.exe). The identity that ASP.NET runs under is defined by the identity of the Aspnet_wp.exe process (by default, the ASPNET account).
To specify the identity for your ASP.NET application on a server running Windows Server 2003, use IIS Manager to configure the identity of the application pool for your ASP.NET application. The application-pool identity must also be added to the IIS_WPG group on the server computer.
To run the ASP.NET worker process with its own account under Windows 2000 or Windows XP Professional, you can make settings in the Web server computer's Machine.config file. The file is located in the following folder:
In the Machine.config file, apply the following attributes to the <processModel> configuration element:
userName The name of the Windows account under which the process will run.
password The clear-text password for the account. There are security risks associated with storing clear-text passwords in a configuration file. If you store credentials in the configuration file, you should encrypt the contents of the <processModel> configuration element using the ASP.NET Set Registry console application (Aspnet_setreg.exe). For information about how to use the ASP.NET Set Registry console application, see article 329290, "How to use the ASP.NET utility to encrypt credentials and session state connection strings," in the Microsoft Knowledge Base at the Microsoft support Web site. For applications that are published on the Internet, use an alternative means of running the application under a specific identity, such as impersonating the anonymous identity supplied by IIS. For more information, see Using IIS Authentication with ASP.NET Impersonation.
The following example shows how to set these attributes, in the <processModel> element of a configuration file, to run the worker process under a local user account.
<system.web> <processModel enable="true" userName="LOCALMACHINE\IUSR_ProcessUser" password="%Hco94*#QW12"/> </system.web>
In addition to setting the userName attribute to the name of an existing Windows identity, you can set it to the predefined names System or Machine. The System account runs the worker process under the same identity as IIS itself (typically SYSTEM).
It is not recommended that you run your applications under the System account, because the account has elevated privileges and can therefore represent a security risk if the ASP.NET process is compromised.
The Machine account runs the worker process with a special account named ASPNET that has limited permissions. With either identity, the process does not have to supply credentials to the operating system.
In order for your ASP.NET applications to function properly, you must ensure that the process identity has access to the Access Control Lists (ACLs) that are listed in ASP.NET Required Access Control Lists (ACLs). Additionally, on servers running IIS 5.0, the process identity must be granted read access to the IIS metabase, which can be accomplished using the Aspnet_regiis.exe tool and specifying the -ga option (for example, aspnet_regiis -ga "UserDomain\ApplicationUser").