Information
The topic you requested is included in another documentation set. For convenience, it's displayed below. Choose Switch to see the topic in its original location.

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 apply the following two attributes to the <processModel> configuration element of the Web server computer's Machine.config file:

  • 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 protected configuration. For more information, see Encrypting Configuration Information Using Protected Configuration. For applications published on the Internet, you should use an alternative means of running the application with 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).

Security noteSecurity Note

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.

NoteNote

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").

See Also

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback

Community Additions

Show:
© 2014 Microsoft