Article ID: 895967 - View products that this article applies to.
This article discusses how to configure the process identity for the ASPNET account. You can use this configuration to run tasks that may not run as expected in a default installation.
This article describes how to do the following:
The article also discusses how to use performance counters, debuggers, and Microsoft technologies such as Windows Management Instrumentation (WMI) and the Active Directory directory service. Additionally, this article describes issue that you may experience if you uninstall or reinstall ASP.NET.
Although this article discusses how to configure the ASPNET account to have elevated permissions and user rights, the default permissions and user rights of the ASPNET account are suited for most Web applications.
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.
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 ModeWhen 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 modeIn 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 identityYou 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:
%systemroot%\WINDOWS\Microsoft.NET\Framework\Version\CONFIGNote 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 accountWhen 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:
812614Note 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.
(https://support.microsoft.com/kb/812614/ )Default permissions and user rights for IIS 6.0
Resource accessThe 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 resourcesTo 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:
ImpersonationWith 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.
DatabasesApplications 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 logApplications 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_MACHINEregistry 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 serviceIf 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 countersThe 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 serversApplications 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 issuesBy 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 identityIn 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 sharesIn 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:
ASP.NET on a primary or backup domain controllerBy 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:
(https://support.microsoft.com/kb/315158/ )FIX: ASP.NET does not work with the default ASPNET account on a domain controller
The IIS metabaseThe 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 WMIYou 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:
http://msdn2.microsoft.com/en-us/library/aa394582.aspxBy 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 desktopWhen 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.NETWhen 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:
http://technet.microsoft.com/en-us/library/bb742509.aspxFor more information about how to encrypt credentials and connection strings, click the following article number to view the article in the Microsoft Knowledge Base:
329290For more information about the ASPNET account, click the following article number to view the article in the Microsoft Knowledge Base:
(https://support.microsoft.com/kb/329290/ )How to use the ASP.NET utility to encrypt credentials and session state connection strings
(https://support.microsoft.com/kb/315158/ )FIX: ASP.NET does not work with the default ASPNET account on a domain controller
Article ID: 895967 - Last Review: December 28, 2006 - Revision: 2.7