MORE INFORMATION
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 or
Windows XP, 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:
- SeChangeNotifyPrivilege
- SeUndockPrivilege
- SeInteractiveLogonRight
- SeNetworkLogonRight
In addition to these rights,
the ASPNET account is also granted the following rights by default:
- SeServiceLogonRight
- SeBatchLogonRight
- SeDenyInteractiveLogonRight
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/Write
Account: Process account and
configured impersonation accounts
Description: This is the
location for application content.
- 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.
back
to the top
Using File Resources
To enable an
application that is running with 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
directory 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 permissions.
- On the File menu, click Properties.
- 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.
back
to the top
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"/>
back
to the top
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.
back
to the top
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.
back
to the top
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).
back
to the top
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.
back
to the top
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.
back
to the top
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.
back
to the top
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.
back
to the top
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.
back
to the top
Using ASP.NET on a Primary or a Backup Domain
Controller
For additional information, click the article number below to
view the article in the Microsoft Knowledge Base:
315158
BUG: ASP.NET Does Not Work with the Default ASPNET Account on a Domain
Controller
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.
back
to the top
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:
- Open the Computer Management Microsoft Management Console (MMC) snap-in.
- Expand Services and Applications, and then select
WMI Control.
- Right-click WMI Control, and then click
Properties.
- In the WMI Control Properties dialog box, click the
Security tab.
- Expand Root, select CIMV2, and then
click Security.
- In the Security dialog box, click
Advanced.
- In the Access Control Settings dialog box, click
Add. Select
localMachineName\ASPNET, and then click
OK.
- In the Permission Entry dialog box, make sure that
Apply Onto is set to This namespace and
subnamespaces.
- Make sure that the Allow 'Enable Account' and
Allow 'Remote Enable' check boxes are selected.
- Click OK in each dialog box until you return to the
WMI Control Properties dialog box.
- Repeat steps 5 through 10 for other WMI namespaces that your application
will access.
- 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.
back
to the top
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.
back
to the top
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.
back
to the top