19.3 Impersonation

Every process running on a Windows 2000/2003 server 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 machine (note all lowercase). This causes the processes to run under a special low privilege user account named "ASPNET", which is created when the ASP.NET is installed. It is also possible to change the value of userName to SYSTEM, which gives the processes full access to all resources, or to any valid username which is a member of a domain which has sufficient access rights to the web server. If there is a security breach, then a malicious user may be able to run processes with the same access to resources provided by the userName assigned to the ASP.NET processes.

To provide more flexibility, 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 machine. 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.config file 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" username="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 Stersol\Dan.

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.

19.3.1 Application Identity

As stated earlier, the default identity for ASP.NET is machine. This is controlled by setting the username attribute to machine in the <processModel> section of 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="machine"     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 (note all lowercase). The default is machine. In either case, the value for password needs to be AutoGenerate, which forces the system to create its own password. As mentioned previously, when ASP.NET assumes the username SYSTEM, it has full access to all resources. The default value of userName, machine, will cause the process to run using a special account, installed automatically when ASP.NET is installed, called ASPNET. This account is a member of the Users group, which is prevented from making system-wide changes.

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.NET\TemporaryASP.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.