January 2002
In its default installation on Windows 2000 and Windows XP, ASP.NET runs Web application code in a worker process. The identity of this process defaults to an unprivileged local account called the ASPNET account.
In beta releases of ASP.NET, the process identity was System, a powerful administrative account with many privileges on the machine. In order to provide a less-privileged default installation, the weaker account is now used and is suitable for use in most Web applications.
You can configure the process identity in the <processModel> section in the machine configuration file (the Machine.config file in the \config subdirectory of the installation root). The identity is controlled by the userName and password attributes. The default values for these attributes are machine and autogenerate, respectively. These values tell ASP.NET to use the built-in ASPNET account and to use a cryptographically strong random password stored in the Local Security Authority (LSA) for that account.
If you want a more privileged process, 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. This process runs by default as the System identity. When so configured, the ASP.NET worker process will have the right to access nearly all resources on the local machine. In Windows 2000, Windows XP, and Windows .NET Server family systems, the System account also has network credentials and can access network resources as the machine account.
To configure the process to run as System, change the userName attribute in the <processModel> section as follows:
<processModel userName="system" password="autogenerate" …/>
The ASPNET account is created as a local account on installation and belongs only to the Users group on that machine. It therefore has all privileges associated with the Users group and can access any resources that the group is granted access to. In addition, ASP.NET adds specific full-access permissions for the account to the Temporary ASP.NET Files directory and to %windir%\temp, and it adds read permissions to the Framework installation directory.
Default access control lists (ACLs) for a Windows 2000 system are documented in the white paper "Default Access Control Settings in Windows 2000," available at http://www.microsoft.com/windows2000/docs/SecDefs.doc.
The following table shows the required ACLs for the ASPNET account. A default installation of Windows 2000 and the .NET Framework includes these ACLs and requires no administrative changes.
|
Location |
Access Type |
Account |
Comments |
|
%installroot%\ASP.NET Temporary Files |
Read/Write |
Process and configured impersonation accounts. |
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 configure the root location using the tempDir attribute in the <compilation> configuration section. |
|
%windir%\temp |
Read/Write |
Process. |
Used by XML Web services to generate serialization proxies. |
|
Application directory |
Read/Write |
Process and configured impersonation accounts. |
This is the location for application content. |
|
Web site root (the path that the “Default Web site” points to). (%systemdrive%\inetpub\wwwroot) |
|
Process and configured impersonation accounts. |
ASP.NET will try to read configuration files at x:\inetpub\wwwroot\web.config and perform change monitoring on that directory. |
|
%installroot% hierarchy |
Read |
Process and configured impersonation accounts. |
ASP.NET must be able to access .NET Framework assemblies on Machine.config file (in the \config subdirectory under %installroot%). |
|
%windir%\assembly |
Read |
Process or configured impersonation accounts. |
This is the global assembly cache, which contains shared assemblies. |
By default, the ASPNET account generally does not have sufficient privileges to do some of the tasks described in the rest of this article.
The following sections describe some strategies for using some of these resources. Many can be accessed locally if impersonation is enabled and the impersonated account has access to the resource. However, impersonation often does not work for accessing remote resources unless the application uses a delegatable authentication mechanism, such as Kerberos or basic authentication. Another strategy for accessing resources is to use COM+ services as described in the Running Code with a Fixed Identity section later in this article.
In most cases, these resources can be accessed if the process is running as System. Whether or not this is the appropriate strategy depends on the application. The administrator should be aware that running code as System means that it runs as a member of the Administrators group and has access to all local resources on the machine.
An administrator can enable an application running with the ASPNET account to write to files by adding write access permissions for the account. This can be done either for an individual file or for directory hierarchies.
You can change file ACLs from the Windows Explorer by choosing Properties from the File menu and then selecting the Security tab. File ACL changes can also be automated using script or the cacls.exe command-line tool that ships with the operating system.
Impersonation is the process of running in the security context of the request entity, whether an authenticated user or an anonymous user. In ASP.NET, impersonation is optional and is not enabled by default. Impersonation can be enabled at the machine or application level by placing the following configuration directive into the machine or application configuration file inside the <system.web> section:
<identity impersonate="true"/>
Applications that connect to a database with SQL authentication generally are not impacted by the switch to the ASPNET account. This is also true for applications that use integrated authentication and impersonation. If an application is not impersonating and is using Windows authentication, access to the database must be granted to the ASPNET account.
However, the ASPNET account cannot be used when attempting to authenticate to Microsoft SQL server using Integrated Windows authentication over named pipes. The account can be used successfully with Integrated Windows authentication over the TCP transport.
If an application needs to use a Microsoft Access database, the account must be able to write to the database file. Administrators should adjust file permissions accordingly.
Applications that need to write to the Application event log can do so while running as the ASPNET account. If an application needs to create a new event log category, it must create a registry key under the HKLM hive, which the ASPNET account cannot do. If impersonation is enabled and a privileged account is impersonated, the category can be created at run time. Otherwise, an administrator can create the category and the application can write to it at run time.
Applications that need to create new event log categories should create the categories at installation. Once the category is created, the ASPNET account can write to the log.
If a Web application needs to access Active Directory, it can use impersonation in an environment that supports delegation, or it can supply explicit credentials to the DirectoryEntry constructor in the System.DirectoryServices namespace. If explicit credentials are used, applications should store credentials appropriately using a technique such as COM+ construction strings or using the Windows data protection APIs.
The ASPNET account has sufficient privileges to write to (but not read) performance counter data. If the application needs to read performance counter data or create performance counter categories, Administrator or Power User permissions are required. Applications that need to create new performance counter categories should create the categories at installation. Once the categories are created, the ASPNET account can write to the counters.
The System Monitor tool (Perfmon.exe) can still be used to monitor ASP.NET performance counters when the ASPNET account is used.
Applications that need to launch out-of-process COM servers while running as the ASPNET account can specifically grant launch permissions to the account using DCOMCNFG.exe.
By default, stepping into an XML Web service call from a client application does not work. To enable stepping into XML Web services, add the ASPNET account to the Debugger Users group on the machine where the XML Web service is running.
COM+ services provide an elegant way to run code with a fixed identity. The System.EnterpriseServices namespace contains a class called ServicedComponent that allows developers to easily write managed code components that use COM+ services. Developers can wrap privileged functionality inside a ServicedComponent-derived class and then run this class as a COM+ server application with a configured identity.
ASP.NET supports several modes of developing application files:
· HTML can reside in an .aspx file and the code for the page can be stored in a precompiled assembly in the \bin directory (this is the Visual Studio.NET model).
· All code and HTML content can be packaged in a single source file that is compiled on demand.
· HTML presentation can reside in an ASP.NET file and any associated source code for that file can be dynamically compiled using a src attribute on an <%@ Assembly %> directive.
If application content is located on a network share, the compiler will launch using the ASPNET account and will not have network credentials to access the file. If network shares are used, using the src attribute to point to a file will fail, and one of the other modes must be used in its place.
Running ASP.NET on a primary or backup domain controller with the ASPNET account is not supported. To enable this scenario, you must configure the worker process to run as System, as described at the beginning of this article.
The ASPNET account does not have the ability to read the Internet Information Services (IIS) metabase. If an application needs access to metabase settings, you can selectively add read access to metabase nodes using the metaacl utility.
To enable the use of .disco files, which rely on the ability to read the IIS metabase in order to provide discovery services, you must add read access to the metabase for the ASPNET account.
Windows Management Instrumentation (WMI) is a powerful administrative functionality that can be used to manage and monitor Windows machines. Using WMI functionality from an ASP.NET application will fail when the ASPNET account is used unless impersonation is enabled as described in the Enabling Impersonation section earlier in this article. This requires that a sufficiently privileged account be impersonated.
Another way to enable WMI access to the ASPNET account involves configuring the account rights so that the account is logged on interactively. By default, the ASPNET account is logged on using a Batch account. If an administrator so desires, he or she can remove the "Deny Interactive Logon" and the "Enable Batch Logon" rights from the account and add the "Enable Interactive Logon" right to the account so that ASP.NET will create the process with an interactive logon. This will provide some read-only access to WMI.
When the IIS services are configured to allow interaction with the desktop, the ASPNET account will not have sufficient privileges 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 the process can be run with a more privileged account that has the right to access these objects.
When ASP.NET is uninstalled, the ASPNET account is disabled and remains on the system. The account can be deleted if ASP.NET will not be reinstalled. If ASP.NET is later reinstalled after explicitly deleting the account, a new account is created, and will have a new security identifier (SID). Therefore, any ACLs that referred to the previous ASPNET account will no longer apply to the new account.
On Windows .NET Server, the ASPNET account is used only for IIS 5 Isolation mode. If Worker Process Isolation mode is used, all ASP.NET applications will run inside an IIS w3wp.exe worker process. In this case, the default identity is NetworkService and is configurable at the application pool level. NetworkService is similar to the ASPNET account with respect to permissions.