How to configure the process identity for the ASPNET account in ASP.NET 1.1 when you use IIS 5 Isolation mode in IIS 6.0 on Windows Server 2003

This article discusses how to configure the process identity for the ASPNET account in Microsoft ASP.NET 1.1 when you use Microsoft Internet Information Services (IIS) 5 Isolation mode in IIS 6.0 on a computer that is running Microsoft Windows Server 2003.

Notes

• Windows Server 2003 only uses the ASPNET account for IIS 5 Isolation mode.
• IIS 5 Isolation mode is a compatibility feature. By default, this feature is installed, but not enabled, when you install IIS 6.0.

In Microsoft Windows Server 2003, a default installation of ASP.NET runs Web application code in a worker process. If you use Worker Process Isolation mode, all Windows-based applications that are built on the Microsoft .NET Framework run in an IIS 6.0 W3wp.exe worker process.

Note When Windows applications run in the W3wp.exe worker process, the default process identity is NetworkService. You can configure the default process identity at the application pool level.

In IIS 5, the Aspnet_wp.exe worker process runs under the local ASPNET account. In beta releases of ASP.NET, the identity of the Aspnet_wp.exe worker process used the System account. The System account is an administrative account on the local computer. This account includes many permissions and user rights on the computer. By default, the worker process uses the ASPNET account in the release version of ASP.NET. This configuration creates a less-privileged default installation. The ASPNET account has fewer permissions and user rights. However, the ASPNET account is still suited for most Web applications.

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.

Process identity

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: Note Version represents the .NET Framework version.

The userName attribute and the password attribute control the identity of the process. The default values for these attributes are the following. The machine 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.

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: Note 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.

Resource access

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.

File resources

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:

1. Open Windows Explorer.
2. Select the file or the folder for which you want to change the permissions.
3. On the File menu, click Properties.
4. 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.

Impersonation

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.

Databases

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 HKEY_LOCAL_MACHINE registry hive. By default, the ASPNET account cannot create a registry key under the HKEY_LOCAL_MACHINE registry hive.

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.

Performance counters

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.

Debugger issues

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.

Fixed identity

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 account.

Note 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:

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.

Remove ASP.NET

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.

For more information about the default Access Control Lists in Windows 2000, see the following Microsoft white paper: For more information about how to encrypt credentials and connection strings, click the following article number to view the article in the Microsoft Knowledge Base: For more information about the ASPNET account, click the following article number to view the article in the Microsoft Knowledge Base: