Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication

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

J.D. Meier, Alex Mackman, Michael Dunner, and Srinath Vasireddy
Microsoft Corporation

Published: November 2002

Last Revised: January 2006

Applies to:

• ASP.NET 1.1

See the "patterns & practices Security Guidance for Applications Index" for links to additional security resources.

See the Landing Page for a starting point and complete overview of Building Secure ASP.NET Applications.

Summary: ASP.NET Web applications usually run using the built-in ASPNET account. On occasion, you may want to use a custom account instead. This How To article shows you how to create a least privileged local account to run ASP.NET Web applications.

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.

Contents

ASP.NET Worker Process Identity
Impersonating Fixed Identities
Notes
Summary of Steps Step 1. Create a New Local Account Step 2. Assign Minimum Privileges Step 3. Assign NTFS Permissions Step 4. Configure ASP.NET to Run Using the New 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 of Steps

This How To includes the following steps:

• Step 1. Create a New Local Account
• Step 2. Assign Minimum Privileges
• Step 3. Assign NTFS Permissions
• Step 4. Configure ASP.NET to Run Using the New Account

Step 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. The strong password should include at least seven characters, and should 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.

Step 2. Assign Minimum Privileges

This procedure assigns the minimum set of privileges necessary to run ASP.NET.

To assign minimum privileges

1. From the AdministrativeTools programs group, start the Local Security Policy tool.

2. Expand LocalPolicies, and then select UserRightsAssignment.

   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.

Step 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 Microsoft 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 <identity> element in web.config as shown below.

   <identity impersonate="true" userName="YourImpersonatedIdentity"
             password="YourStrongPassword" />
   

Table 1. Required NTFS permissions

Step 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 Microsoft Visual Studio® .NET or Notepad.

   Machine.config is located in the following folder:

   C:\WINNT\Microsoft.NET\Framework\<versionNumber>\CONFIG
   

2. Locate the <processModel> element and set the user name and password attributes to match your new custom account as follows:

   Default: <processModel userName="machine" password="AutoGenerate" />
   Becomes: <processModel userName="CustomASPNET" password="YourStrongPassword" /> 
   

3. Encrypt the userName and password attributes by using aspnet_setreg.exe. To do this, type the following command at the command line:

   aspnet_setreg.exe -k:SOFTWARE\MY_SECURE_APP\ASPNET -u:"yourdomainname\username" -p:"password"
   

   This command encrypts the userName and password attributes, creates registry keys at any location that you specify, and then stores the attributes in those registry keys. This command also generates output that specifies how to change your Web.config or Machine.config file so that ASP.NET will use these keys to read that information from the registry.

4. Modify the configuration file to point to these registry keys as follows:

   <processModel userName= "registry:HKLM\SOFTWARE\MY_SECURE_APP\ASPNET\ASPNET_SETREG,userName" password="registry:HKLM\SOFTWARE\MY_SECURE_APP\ASPNET\ASPNET_SETREG,password"
   .....> 
   

Note: For more information on the aspnet_setreg.exe utility, see "How to use the ASP.NET utility to encrypt credentials and session state connection strings" (https://support.microsoft.com/kb/329290/).

© Microsoft Corporation. All rights reserved.