This article outlines the access rights that are granted to the default process account and describes some situations in which these rights may be too restrictive for certain tasks.

In the default installation of ASP.NET on Microsoft Windows 2000 and Microsoft Windows XP, ASP.NET runs Web application code in a worker process. The identity of this process uses a local account named the ASPNET account (where the full name is the aspnet_wp account) by default. In beta releases of ASP.NET, the process identity is System, which is a powerful, administrative account that includes many access rights on the computer. To provide a less-privileged default installation, the release version of ASP.NET uses the weaker ASPNET account, which is suitable for most Web applications.

Note By default, if you are using Microsoft Internet Information Services (IIS) 6.0, your ASP.NET Web applications will run in the security context of the NetworkService account.

Back to the top

Configure the process identity

You can configure the process identity in the <processModel> section of the Machine.config file in the Config subdirectory of the installation root directory. The userName and the password attributes control the identity of the process. The default values for these attributes are as follows:

<processModel  userName="machine" password="AutoGenerate" />
				

The machine and the AutoGenerate values instruct ASP.NET to use the built-in ASPNET account and to use a cryptographically strong, random password that is stored in the Local Security Authority (LSA) for that account.

If you want to use a process that has more access rights, you can set the userName attribute to System, which causes the ASP.NET worker process to run with the same identity as the Inetinfo.exe process. The Inetinfo.exe process runs by default as the System identity. When you configure the ASP.NET worker process to use the System identity, the ASP.NET worker process can access almost all of the resources on the local computer. On computers that are running Windows 2000, Windows XP, or Microsoft Windows Server 2003, the System account also has network credentials and can access network resources as the machine account. To configure the process to run as the System identity, change the userName attribute in the <processModel> section as follows:

<processModel  userName="SYSTEM" password="AutoGenerate" />
				

Back to the top

Default permissions for the ASPNET account

The ASPNET account is created as a local account when you install ASP.NET. The ASPNET account belongs only to the Users group on that computer. Therefore, the ASPNET account has all of the rights that are associated with the Users group and can access any resources that the Users group is granted access to. The ASPNET account inherits the following user rights from the Users group.

User right	Explanation
SeChangeNotifyPrivilege	Bypass traverse checking.
SeUndockPrivilege	Remove the computer from the docking station.
SeInteractiveLogonRight	Log on locally.
SeNetworkLogonRight	Access this computer from the network.

In addition to these rights, the ASPNET account is also granted the following rights by default:

User right	Explanation
SeServiceLogonRight	Log on as a service.
SeBatchLogonRight	Log on as a batch job.
SeDenyInteractiveLogonRight	Deny log on locally.

ASP.NET grants specific, full-access permissions for the ASPNET account to the following folders:

•	Temporary ASP.NET Files
•	%windir%\temp

Additionally, ASP.NET grants Read permission to the Microsoft .NET Framework installation directory.

The following list outlines the Access Control Lists (ACLs) that are required for the ASPNET account. The default installations of Windows 2000 and the Microsoft .NET Framework include these ACLs.

•	Location: %installroot%\ASP.NET Temporary Files Access Type: Read/Write on the folder and List Folder Contents on the drive's root folder Account: Process account and configured impersonation accounts Description: This is the location for ASP.NET dynamic compilation. Beneath this location, application code is generated in a discrete directory for each application. You can use the tempDir attribute in the <compilation> section to configure the root location. Note If you change the machine.config to save the ASP.NET temporary files in a different location, the ASPNET account must have the List Folder Contents access type on the root level of the drive.
•	Location: %windir%\temp Access Type: Read/Write Account: Process account Description: This is the location that Extensible Markup Language (XML) Web services uses to generate serialization proxies.
•	Location: Application directory Access Type: Read Account: Process account and configured impersonation accounts Description: This is the location for application content (only Read access required). For more information, visit the following Microsoft Web site: http://msdn2.microsoft.com/en-us/library/aa302396.aspx (http://msdn2.microsoft.com/en-us/library/aa302396.aspx)
•	Location: Web site root (%systemdrive%\inetpub\wwwroot or the path that the default Web site points to) Access Type: Read Account: Process account and configured impersonation accounts Description: ASP.NET tries to read configuration files and monitor changes at drive:\inetpub\wwwroot\web.config.
•	Location: %installroot% hierarchy Access Type: Read Account: Process account and configured impersonation accounts Description: ASP.NET must be able to access .NET Framework assemblies on the Machine.config file (in the \Config subdirectory under %installroot%).
•	Location: %windir%\assembly Access Type: Read Account: Process account or configured impersonation accounts Description: This is the global assembly cache that contains shared assemblies.

For more information about default ACLs for Windows 2000-based computers, see the "Default Access Control Settings in Windows 2000" reference in the REFERENCES section.

Note By default, the ASPNET account generally does not have the correct access rights to do some of the tasks that are described in this article.

Back to the top

Accessing resources

The following sections describe how to use various resources. You can access many of these resources locally if you enable impersonation and if you grant the impersonated account access to the resource. However, impersonation often does not work when you try to access remote resources unless the application uses an authentication mechanism that can be delegated, such as Kerberos or Basic authentication. You can also use COM+ services to access resources, which is outlined in the Running code with a fixed identity section.

Using file resources

To enable an application that is running with the ASPNET account to write to files, you can impersonate a specific user in code before writting to files, or you can grant Write permissions for the ASPNET account. You can grant Write permissions for an individual file or for directory hierarchies.

Important When you grant Write permissions for an individual file or for directory hierarchies to the ASPNET account, all ASP.NET Web applications that are running under the ASPNET account on the server are also able to write to this file or the directory hierarchies. For more information about impersonating a specific user in code, click the following article number to view the article in the Microsoft Knowledge Base: To change the Access Control List for a file, follow these steps:

1.	Open Windows Explorer.
2.	Select the file or the folder for which you want to change permissions.
3.	On the File menu, click Properties.
4.	Click the Security tab. Click to select the check boxes for the ACL permissions.

You can also use script or the Cacls.exe command-line tool (which is included with Windows) to change the ACL for a file.

ASP.NET 1.1 uses the <DriveName>\Documents and Settings\<MachineName>\ASPNET folder to store the process files (where <DriveName> is the drive on your computer where ASP.NET is installed and <MachineName> is the name of your computer).

Enabling impersonation

With impersonation, you run in the security context of the request entity, either as an authenticated user or as an anonymous user. In ASP.NET, impersonation is optional and is not enabled by default. To enable impersonation at the level of the computer or the application, add the following configuration directive in the <system.web> section of the Machine.config or the Web.config file:

<identity impersonate="true"/>
				

Using databases

Applications that use SQL authentication to connect to a database are not generally affected by the switch to the ASPNET account. This is also true for applications that use integrated authentication and impersonation. However, if an application is not impersonating and is using Windows authentication, you must grant access to the database for the ASPNET account.

You cannot use the ASPNET account when you try to authenticate to Microsoft SQL Server by using Integrated Windows authentication over named pipes. However, you can use the ASPNET account successfully with Integrated Windows authentication over the Transmission Control Protocol (TCP) transport.

If an application must use a Microsoft Access database, the ASPNET account must be able to write to the database file. Administrators must adjust file permissions accordingly.

Using the event log

Applications that must write to the Application event log can do so while they are running as the ASPNET account. If an application must create a new event log category, the application must create a registry key under the HKEY_LOCAL_MACHINE registry hive, which the ASPNET account cannot do.

To create the category at run time, you must enable impersonation, and then you must impersonate an account that has more access rights. Alternatively, an administrator can create the category, and the application can write to the category at run time.

If applications must create new event log categories, create the categories at installation. After the category is created, the ASPNET account can write to the Application event log.

Using System.DirectoryServices and Active Directory

If a Web application must access Active Directory, the application can use impersonation in an environment that supports delegation. Alternatively, the application can supply explicit credentials to the DirectoryEntry constructor in the System.DirectoryServices namespace to access Active Directory. If the application uses explicit credentials, applications should store credentials appropriately by using a technique such as COM+ construction strings or by using the Windows data protection application programming interfaces (APIs).

Using performance counters

The ASPNET account has sufficient permission to write to (but not to read) performance counter data. If the application must read performance counter data or create performance counter categories, Administrator or Power User permissions are required.

If an application must create new performance counter categories, create the categories at installation. After the categories are created, the ASPNET account can write to the counters.

You can still use the Performance Monitor tool (Perfmon.exe) to monitor ASP.NET performance counters when you use the ASPNET account.

In Windows 2000, follow these steps:

1.	Run Registry Editor.
2.	Locate the following registry key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ASP.NET_1.1.4322\Names
3.	Click the Security tab.
4.	Add the worker process identity with the following permissions: • Query Value • Set Value • Create Subkey • Enumerate Subkeys • Notify Read Control

In Windows Server 2003, add the identity to the IIS_WPG group.

Starting out-of-process COM servers

Applications that must start out-of-process COM servers while running as the ASPNET account can specifically grant launch permissions to the account by using the Dcomcnfg.exe tool.

Debugging issues

By default, you cannot step into an XML Web service call from a client application. To step into XML Web services, you must add the ASPNET account to the Debugger Users group on the computer where the XML Web service is running.

Running code with a fixed identity

In COM+ services, you can run code with a fixed identity. You can use the ServicedComponent class of the System.EnterpriseServices namespace to write managed code components that use COM+ services. You can wrap privileged functionality in a class that is derived from ServicedComponent and then run this class as a COM+ server application with a configured identity.

Compiling code-behind files on UNC shares

In ASP.NET, you can use several methods to develop application files:

•	You can use Hypertext Markup Language (HTML) in an .aspx file, and then you can store the code for the page in a precompiled assembly in the Bin directory. This is the Microsoft Visual Studio .NET model.
•	You can package all of the code and the HTML content in a single source file that is compiled on demand.
•	You can place the HTML presentation in an ASP.NET file, and then you can dynamically compile any associated source code for that file by using an src attribute in the <%@ Assembly %> directive.

Note If application content is located on a network share, the compiler starts in the ASPNET account and does not have network credentials to access the file. If you use network shares, you cannot use the src attribute to point to a file. You must use one of the other methods instead.

Using ASP.NET on a primary or a backup domain controller

By default, if you are using ASP.NET 1.1 on a domain controller, your ASP.NET Web applications will run in the security context of the IWAM_<ComputerName> account (where <ComputerName> is the name of your computer).

For more information, click the following article number to view the article in the Microsoft Knowledge Base: back to the top

Reading the IIS metabase

The ASPNET account cannot read the Microsoft Internet Information Services (IIS) metabase. If an application must access metabase settings, you can selectively grant Read access to metabase nodes by using the Metaacl.exe utility.

If an application must use .disco files, which rely on the ability to read the IIS metabase to provide discovery services, you must grant Read access to the metabase for the ASPNET account.

Using System.Management and WMI

Windows Management Instrumentation (WMI) is a powerful, administrative functionality that you can use to manage and to monitor Windows-based computers. However, when ASP.NET applications run under the ASPNET account, this account only has the same default access permissions as Everyone. These permissions include reading WMI data, writing provider data, and executing methods for providers on the local computer. More information about the WMI security mechanisms can be found in the WMI Platform SDK documentation or on MSDN.

Note On Windows 2000 without service pack 3 (SP3) or later, or on Windows XP without service pack 1 (SP1) or later, ASP.NET Web applications that run under the ASPNET account may not work, and you may receive an "Access Denied (0x80041003)" error message. This occurs because the account does not have enough privileges to access certain WMI namespaces. To resolve the issue, install Windows XP SP1 or later, or Windows 2000 SP3 or later. To work around the issue, follow these steps:

1.	Open the Computer Management Microsoft Management Console (MMC) snap-in.
2.	Expand Services and Applications, and then select WMI Control.
3.	Right-click WMI Control, and then click Properties.
4.	In the WMI Control Properties dialog box, click the Security tab.
5.	Expand Root, select CIMV2, and then click Security.
6.	In the Security dialog box, click Advanced.
7.	In the Access Control Settings dialog box, click Add. Select localMachineName\ASPNET, and then click OK.
8.	In the Permission Entry dialog box, make sure that Apply Onto is set to This namespace and subnamespaces.
9.	Make sure that the Allow 'Enable Account' and Allow 'Remote Enable' check boxes are selected.
10.	Click OK in each dialog box until you return to the WMI Control Properties dialog box.
11.	Repeat steps 5 through 10 for other WMI namespaces that your application will access.
12.	Restart IIS. To do this, run IISRESET from the command line.

By default, ASP.NET generates a cryptographically strong password for the ASPNET account. Therefore, this workaround is safe provided that the ASPNET account password is not shared between computers or reset to a value other than the default.

Interacting with the desktop

When IIS services are configured to allow interaction with the desktop, the ASPNET account does not have the correct rights to access the desktop because of the Discretionary Access Control Lists (DACLs) on the default window station and desktop. Administrators can change these DACLs, or you can run the process with an account that has permission to access these objects.

Removing ASP.NET

When you remove ASP.NET, the ASPNET account is disabled and remains on the system. You can delete the ASPNET account if you do not intend to reinstall ASP.NET.

If you reinstall ASP.NET after you explicitly delete the ASPNET account, a new ASPNET account is created that has a new security identifier (SID). As a result, any ACLs that referred to the previous ASPNET account no longer apply to the new ASPNET account.

Using Windows Server 2003

ASP.NET 1.1 uses the <DriveName>\Documents and Settings\<MachineName>\ASPNET folder to store the process files. However, in IIS 6.0 and ASP.NET SP1, you may see these files in the <DriveName>:\Documents and Settings\Default User\Local Settings\Application Data folder. The path does appear to be a change.

Note<DriveName> is the drive on your computer where ASP.NET is installed. <MachineName> is the name of your computer.

The default user profile is used in Windows Server 2003. In this case, the default identity is NetworkService. You can configure NetworkService at the application pool level. NetworkService has permissions that are similar to the ASPNET account. Windows Server only uses the ASPNET account for IIS 5.0 Isolation mode. If you use Worker Process Isolation mode, all ASP.NET applications run in an IIS W3wp.exe worker process.

Back to the top

For more information about the default Access Control Lists in Windows 2000, see the following Microsoft white paper: For more information, click the following article number to view the article in the Microsoft Knowledge Base:

Back to the top