Change the account that ASP.NET runs under
All applications must run inside a process. Under Internet Information
Services (IIS) 6.0, ASP.NET Web applications run inside the IIS Worker
Process (w3wp.exe). By default, this process runs as the Network Service
account. Similarly, under IIS 5.0 (and IIS 6.0 in IIS 5.0 isolation
mode), ASP.NET Web applications run inside the ASP.NET Worker Process
(aspnet_wp.exe). By default, this process runs as ASPNET. The architecture
of ASP.NET allows you to change this default functionality to run more secure
Application Domains and ASP.NET
Application domains are the common language runtime (CLR)-equivalent to process
boundaries. However, one or more application domains can be hosted in the same
process. Code running in one application domain cannot access the memory
locations used by code running in another application domain, even if the two
application domains are hosted in the same process.
In IIS 6.0, an IIS Worker Process is created for each application pool that is
configured. Each application pool contains zero or more Web applications. Each Web application
is hosted in its own application domain. The
advantage of the application domain and Web application mapping is that if a
critical failure occurs in a Web application in one application pool, Web
applications in other application pools will not be affected.
IIS and ASP.NET Identity
As stated earlier, the IIS Worker Process runs as Network Service and the
ASP.NET Worker Process runs as ASPNET by default. On Windows
Server 2003 computers, you can determine the account under which this process
runs by clicking the Identity tab of the Properties dialog box for the
application pool that hosts the ASP.NET Web application, as shown here:
On Windows 2000 and Windows XP computers, you can determine this account by
locating the <processModel> element in the machine.config file on the Web
server. The <processModel> element supports the following two most common
This attribute identifies the user account under which the ASP.NET Worker
Process runs. This can be any valid user account on the computer or in the
domain. However, you can also specify one of the following special values:
This value specifies that the ASP.NET Worker Process should run as the Local
System account. This is a very high-privileged account, so you should be
extremely cautious when specifying this value. The Local System account has
full adminsitrative privileges on the local computer. Therefore, if an attacker
is able to execute code on the computer by exploiting a security hole in IIS,
he or she can do so with administrative privileges.
This value specifies that the ASP.NET Worker Process should run as the ASP.NET
service account. This is the Network Service account under Windows Server 2003
and the ASPNET account under Windows XP.
This attribute identifies the password for the user account specified in the
userName attribute. If the userName attribute is
set to Machine, this value should be set to autogenerate.
When the IIS Worker Process or the ASP.NET Worker Process starts a Web
application, the Web application inherits the identity of the process if
impersonation is disabled. (Impersonation is the process of allowing a thread
to run under a different account from its process.) However, if impersonation
is enabled, each Web application runs under the user account that is
authenticated by IIS or the user account that is configured in the Web.config
file. Impersonation can be enabled in either of the following two ways in
This allows the Web application to run using the identity that was
authenticated by IIS.
This allows the Web application to run using a specific identity.
If only anonymous access is enabled in IIS, the identity that is passed to the
Web application will be <machine>\IUSR_<machine>, where
<machine> represents the computer where IIS is running. This account is
the anonymous account.
If only integrated Windows authentication is enabled in IIS, the identity that
is passed to the Web application will be the authenticated Windows user.
If both integrated Windows authentication and anonymous access are enabled,
the identity that is passed to the Web application will depend on the one that
was authenticated by IIS. IIS first attempts to use anonymous access to grant a
user access to a Web application or resource. If this attempt fails, it then
tries to use Windows authentication.
WindowsIdentity.GetCurrent().Name Versus User.Identity.Name
You can determine the identity of a user of an ASP.NET application using one of
two objects: WindowsIdentity.GetCurrent().Name or User.Identity.Name.
The WindowsIdentity.GetCurrent() method returns a WindowsIdentity instance that
represents the identity running the thread. The User.Identity object represents
the identity that was passed from IIS. If IIS allows a user to access a page
anonymously, the User.Identity.Name property will return an empty string.
Otherwise, it will return the account name of the user authenticated by IIS.
The following table compares the output of these two objects, assuming that
integrated Windows authentication is enabled in IIS, ASP.NET is configured to
run under the Network Service account, and a user named JamesH in the BVS
domain accesses an ASP.NET page:
||NT Authority\Network Service
||NT Authority\Network Service
The identity under which a Web application runs is always the identity that is
passed from IIS if impersonation is enabled. If not, the Web application runs
under the same account that is configured for either the ASP.NET Worker Process
in the <processModel> element of the machine.config file or the IIS
Worker Process on the Identity tab of the associated application pool's
Properties dialog box in IIS.
Back to Tips and Tricks