IIS 6.0 Worker Process Isolation Mode
When you use Worker Process Isolation Mode in IIS 6.0, you can configure the default process identity for the worker process. For more information about the built-in Windows accounts and the default priviledges that are associated with each account, visit the following Microsoft Web site:
IIS 5 Isolation mode
In IIS 6, the built-in ASPNET user account is is used to run the ASP.NET worker process in IIS 5.0 Isolation mode.
You can configure the process identity in the processModel
section of the Machine.config file when IIS is running in IIS 5 Isolation mode. Note
When ASP.NET is running in IIS 6.0 Worker Process Isolation Mode, the settings in the processModel
section are ignored. To configure the process identity, recycling, or other process model values, use IIS Manager to configure the IIS worker process for your application.
The Machine.config file is located in the following folder:
represents the .NET Framework version.
attributeand the password
attribute control the identity of the process. The default values for these attributes are the following.
processModel userName="machine" password="AutoGenerate"/
value and the AutoGenerate
value instruct ASP.NET to use the built-in ASPNET account. Additionally, these values instruct ASP.NET to use a cryptographically strong, random password. This password is stored in the Local Security Authority (LSA) for the ASPNET account.
If you want to use a process that has more permissions and user rights, you can set the userName
attribute to System
. When you use the System account, the ASP.NET worker process runs by using the same identity as the Inetinfo.exe process.
By default, the Inetinfo.exe process runs as the System identity. When you configure the ASP.NET worker process to use the System identity, the ASP.NET worker process can access most of the resources on the local computer. On a computer that is running Windows Server 2003, the System account has the same permissions and user rights as the computer account. Therefore, the System account can access the same network resources as the computer account.
To configure the process to run as the System identity, change the userName
attribute in the processModel
section to the following.
processModel userName="SYSTEM" password="AutoGenerate"/
Default permissions for the ASPNET account
When you install ASP.NET, the ASPNET account is created as a local account. The ASPNET account only belongs to the Users group on that computer. The ASPNET account has all the permissions and user rights that are associated with the Users group. Therefore, the ASPNET account can access any resources to which the Users group is granted access.
For more information about default permissions and user rights on a newly installed application server that is running IIS 6.0, click the following article number to view the article in the Microsoft Knowledge Base:
Default permissions and user rights for IIS 6.0
By default, the ASPNET account does not have the correct permissions and user rights to do some of the tasks that are described in this article.
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 frequently 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.
To enable an application that is running under the ASPNET account to write to files, an administrator can grant write permissions for the ASPNET account. The administrator can grant write permissions for an individual file or for folder hierarchies.
To change the Access Control List for a file, follow these steps:
- Open Windows Explorer.
- Select the file or the folder for which you want to change the permissions.
- On the File menu, click Properties.
- Click the Security tab. Then, click to select the check boxes for the permissions that you want.
You can also use a script or the Cacls.exe command-line tool to change the permissions for a file.
With impersonation, the application runs in the security context of the request entity, either as an authenticated user or as an anonymous user. By default, impersonation is optional and is not enabled in ASP.NET. To enable impersonation at the level of the computer or at the level of the application, add the following configuration directive in the <system.web> section of the Machine.config file or the Web.config file.
Applications that use SQL Authentication to connect to a database are not generally affected by using the ASPNET account. Applications that use integrated authentication and impersonation are also not generally affected. However, if an application is not impersonating and is using Integrated 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 Authentication over named pipes. However, you can use the ASPNET account together with Integrated 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 change the file permissions to allow this use.
The Application log
Applications that must write to the Application log can do so when they are running under the ASPNET account. If an application must create a new event log category, the application must create a registry key under the
registry hive. By default, the ASPNET account cannot create a registry key under the
To create the category at run time, you must enable impersonation. Then, you must impersonate an account that has more permissions and user rights. Alternatively, an administrator can create the category. Then, the application can write to the category at run time.
If applications must create new event log categories, create the categories at installation. After you have created the category, the ASPNET account can write to the Application log.
The System.DirectoryServices namespace and the Active Directory directory service
If a Web application must access the Active Directory directory service, 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 the Active Directory directory service. If the application uses explicit credentials, the application should store the credentials appropriately by using a technique such as COM+ construction strings or by using the Windows data protection APIs.
The ASPNET account has sufficient permissions to write to performance counter data. However, the ASPNET account does not have sufficient permissions to read performance counter data. If the application must read performance counter data or must create performance counter categories, you must grant Administrator permissions or Power User permissions to the ASPNET account.
If an application must create new performance counter categories, create the categories at installation. After you have created the categories, 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. To monitor ASP.NET performance counters in Windows Server 2003, add the process identity to the IIS_WPG group.
Out-of-process COM servers
Applications that must start out-of-process COM servers when they run as the ASPNET account can specifically grant start permissions to the account by using the Dcomcnfg.exe tool.
By default, you cannot step into an XML Web service call from a client application. To step into an XML Web service call, you must add the ASPNET account to the Debugger Users group on the computer where the XML Web service is running.
In COM+ services, you can run code by using 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 the ServicedComponent
class. Then, you can run this class as a COM+ server application that has a configured identity.
Code-behind files on UNC shares
In ASP.NET, you can use several methods to develop application files. In the following methods, content is stored in code-behind files on Universal Naming Convention (UNC) shares:
- You can use HTML in an .aspx file. Then, you can store the code for the page in a precompiled assembly in the Bin folder. This method is the Microsoft Visual Studio .NET model.
- You can package all the code and the HTML content in a single source file that is compiled on demand.
- You can put the HTML presentation in an ASP.NET file. Then, you can dynamically compile any associated source code for that file by using an src attribute in the <%@ Assembly %> directive.
If application content is located on a network share, the compiler starts in the ASPNET account. Therefore, the compiler 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.
ASP.NET on a primary or 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
is the name of the computer where the IWM_ComputerName
account is located.
For more information, click the following article number to view the article in the Microsoft Knowledge Base:
FIX: ASP.NET does not work with the default ASPNET account on a domain controller
The IIS metabase
The ASPNET account cannot read the Microsoft Internet Information Services (IIS) metabase. If an application must access metabase settings, you can use the Metaacl.exe utility to selectively grant read permissions to metabase nodes.
If an application must use .disco files, you must grant read permissions to the metabase for the ASPNET account. The .disco files must read the IIS metabase to provide discovery services.
System management and WMI
You can use Windows Management Instrumentation (WMI) to manage and to monitor computers that are running Microsoft Windows operating systems. However, when applications that run on the Windows operating system run under the ASPNET account, the ASPNET account only has the same default permissions as the Everyone account. These permissions include reading WMI data, writing provider data, and running methods for providers on the local computer.
For more information about the WMI security mechanisms, see the WMI Platform SDK documentation or visit the following Microsoft Developer Network (MSDN) Web site:
By default, ASP.NET generates a cryptographically strong password for the ASPNET account. If the ASPNET account password is not shared between computers or is not reset to a value other than the default, this behavior helps protect the system after you grant additional permissions and user rights to the ASPNET account.
Interaction with the desktop
When IIS services are configured to enable interaction with the desktop, the ASPNET account cannot access the desktop. This behavior occurs when the Discretionary Access Control Lists (DACLs) on the default window station object and on the default desktop object are not configured to grant user rights to the ASPNET account. Administrators can change these DACLs. Or, you can run the process by using an account that has user rights for these objects.
When you remove ASP.NET, the ASPNET account is disabled. However, the account remains on the system. If you do not want to reinstall ASP.NET, you can delete the ASPNET account.
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). Therefore, any ACLs that referred to the previous ASPNET account no longer apply to the new ASPNET account.