Every process running on a Windows NT/2000 server (or Windows.NET Server, when it ships) has a username associated with it. The username, in conjunction with ACLs (described earlier in Section 19.2), determines what resources the process will have access to.
By default, ASP.NET processes run with a username of SYSTEM. This gives these processes full access to all resources. If there is a security breach, then a malicious user may also be able to run processes with full access to all resources.
To guard against this and provide another layer of security, ASP.NET supports impersonation. Using impersonation, the ASP.NET process assumes, and executes with, the identity of the client making the request. For example, if user Dan requests a web page, and this web page requests access to a resource on the server, then when ASP.NET requests that resource, it will be as though Dan made the request, not SYSTEM. The permissions assigned to Dan in the ACLs will govern the request.
Impersonation is not enabled by default, since it consumes additional
server resources. Impersonation is enabled with an
<identity>
section in a configuration file. The default
<identity> section in
machine.config looks like the following:
<identity impersonate="false" />
To enable impersonation for an application, add a similar line to the
web.configfile in the
application virtual root directory, changing the
impersonate attribute value to
true.
If impersonation is enabled and the request is from an authenticated
user, then the ASP.NET process will run as though it were the
authenticated user. If the request if from an anonymous user, the
process will run as though it were
IUSR_
MachineName, where
MachineName is the name of the web server.
It is also possible to configure ASP.NET to always impersonate using
a specific identity. The following
<identity> section configures ASP.NET to
always run as Dan with a password of
pwd:
<identity impersonate="true" name="Dan" password="pwd" />
If the username is part of a different domain from the web server,
the domain name can be part of the username, as in
StersolDan.
If the application resides on a UNC (Universal Naming Convention) share, then the ASP.NET process will execute as the IIS UNC token whether impersonation is enabled or disabled. The only exception is that if impersonation is enabled with a specific username, then that username will be used for the UNC share, and access to the share will be dependent on that username’s access rights.
As stated earlier, the default identity
for ASP.NET is SYSTEM. This is controlled by the
<processModel>
section in the machine.config
configuration file. The default
<processModel> section looks like the
following:
<processModel
enable="true"
timeout="Infinite"
idleTimeout="Infinite"
shutdownTimeout="0:00:05"
requestLimit="Infinite"
requestQueueLimit="5000"
restartQueueLimit="10"
memoryLimit="60"
webGarden="false"
cpuMask="0xffffffff"
userName="SYSTEM"
password="AutoGenerate"
logLevel="Errors"
clientConnectedCheck="0:00:05"
comAuthenticationLevel="Connect"
comImpersonationLevel="Impersonate"
/>The relevant attributes here are
userName
and
password
. There
are two special values for userName:
SYSTEM and MACHINE. The default
is SYSTEM. In either case the value for
password needs to be
AutoGenerate
, which forces the system
to create its own password. As described above, when ASP.NET assumes
the username SYSTEM, it has full access to all resources.
In some cases, it may be desirable to change
userName to MACHINE, which will
then cause the process to run using a special account, installed
automatically when ASP.NET is installed, which begins with the prefix
ASPNET. This account is a member of the Guests group, and so has far
fewer privileges.
You can also set userName and
password to a specific domain or Active Directory
user account, which will then become the default user for all ASP.NET
processes. If you do this, the user account specified must have the
following rights:
Read/write access to %installroot%ASP.NETTemporaryASP.NETFiles. Typically this is a subdirectory of c:ProgramFiles. Subdirectories here are used for dynamically compiled output.
Read/write access to the %temp% directory. This is used by the compilers during dynamic compilation.
Read access to the application directory.
Read access to the %installroot% hierarchy of directories to allow access to system assemblies.