2 How To: Create a Custom Account to Run ASP.NET

This How To describes how to create a least privileged local account to run the
ASP.NET worker process (aspnet_wp.exe) or for impersonated identities in virtual
directories. Although the procedures in this How To create a local account, the
same concepts apply to a domain account.

ASP.NET Worker Process Identity

The default account for running ASP.NET, created at installation time, is a least
privileged local account and is specified in machine.config as follows:
<processModel enable="true" userName="machine" password="AutoGenerate" />
This account is identified as ASPNET under Local Users and Groups, and has a
strong password secured in the Local System Authority (LSA).
When you need to access network resources, such as a database, using the ASP.NET
process identity, you can do one of the following:
Use a domain account.
Use �mirrored� local accounts (that is, accounts with matching usernames and
passwords on two computers). You need to use this approach when the computers
are in separate domains with no trust relationship or when the computers are
separated by a firewall and you cannot open the ports required for NTLM or
Kerberos authentication.

The simplest approach is to change the ASPNET account�s password to a known
value on the Web server and then create an account named ASPNET with the
same password on the target computer. On the Web server, you must first
change the ASPNET account password in Local Users and Groups and then
replace �AutoGenerate� with the new password in machine.config.
<processModel enable="true" userName="machine"
password="YourStrongPassword" />
You can use the steps presented in this How To to create a least privileged local
account.



Impersonating Fixed Identities

You can set fixed identities for specific virtual directories by using the following
setting in web.config.
<identity impersonate="true" userName="YourAccount"
password="YourStrongPassword" />
This approach is typically used when you have multiple Web sites on the same Web
server that need to run under different identities; for example, in application hosting
scenarios.
This How To describes how to create a least privileged local account. If administration
is your primary concern, you can use a least privileged, constrained domain
account with a strong password.

Notes

When considering the account used to run ASP.NET, remember the following:
ASP.NET does not impersonate by default. As a result, any resource access
performed by your Web application uses the ASP.NET process identity. In this
event, Windows resources must have an access control list (ACL) that grants
access to the ASP.NET process account.

If you enable impersonation, your application accesses resources using the
original caller’s security context, or the anonymous Internet user account (by
default IUSR_MACHINE), if IIS is configured for anonymous authentication.
In this event, resources must have ACLs based on the original caller identity
(or IUSR_MACHINE).

Always adhere to the principle of least privilege when creating a custom
account — give the minimum set of required privileges and permissions only.

Avoid running ASP.NET using the SYSTEM account.

Avoid granting the account the “Act as part of the operating system” privilege.

Summary

This How To includes the following procedures:
1. Create a New Local Account
2. Assign Minimum Privileges
3. Assign NTFS Permissions
4. Configure ASP.NET to Run Using the New Account


1. Create a New Local Account

This procedure creates a new local account. By default, it will be added to the local
Users group.

To create a new local account

1. Create a local account (for example, “CustomASPNET”).
Make sure you use a strong password for the account. Strong password should
include at least seven characters, and use a mixture of uppercase and lowercase
letters, numbers, and other characters such as *, ?, or $.
2. Clear the User must change password at next logon option.
3. Select the Password never expires option.

2. Assign Minimum Privileges

This procedure assigns the minimum set of privileges necessary to run ASP.NET.
To assign minimum privileges
1. From the Administrative Tools programs group, start the Local Security Policy
tool.
2. Expand Local Policies, and then select User Rights Assignment.
A list of privileges is displayed in the right pane.
3. Assign the following privileges to the new account:
Access this computer from the network
Deny logon locally
Log on as a batch job
Log on as a service

Note: To assign a privilege to an account, double-click the privilege, and then click Add to
select the required account.

4. Close the tool.

3. Assign NTFS Permissions

This procedure grants the custom ASP.NET account required NTFS permissions
within the local file system.
Note: The steps in this procedure apply to the file system on the Web server (and not on
a remote computer, where you may be duplicating the account, for network authentication
purposes).

To assign NTFS permissions

1. Start Windows Explorer and assign the appropriate permissions to the folders
specified in Table 1.
The fixed impersonation account referred to in Table 1 refers to the account that
can be optionally configured using the element in web.config as
shown below.
<identity impersonate="true" userName="YourImpersonatedIdentity"
password="YourStrongPassword" />


4. Configure ASP.NET to Run Using the New Account

This procedure edits machine.config to configure ASP.NET to run using the new
account.
To configure ASP.NET to run using the new account
1. Open machine.config using Visual Studio.NET or Notepad.
Machine.config is located in the following folder:
C:\WINNT\Microsoft.NET\Framework\v1.0.3705\CONFIG
2. Locate the element and set the user name and password attributes
to match your new custom account.
Default:
Becomes:
3. Save the changes to machine.config

Note: With the current release of the .NET Framework, there is no way to avoid storing the
password in clear text. While storing clear text credentials is not recommended, the
machine.config file is considered more secure because it is located outside the Web
space. You should secure machine.config against unnecessary access by using an appropriately
configured ACL.

In Windows .NET Server, the credentials will be encrypted for greater