Share via

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

  • Article
Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

 

patterns & practices Developer Center

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

Folder Required permission Account Comments
C:\WINNT\Microsoft.NET\
Framework\ Temporary ASP.NET Files		 Full Control Process and fixed impersonation accounts This is the ASP.NET dynamic compilation location. Application code is generated in a discrete directory for each application beneath this folder.
The tempdir attribute on the <compilation> element can be used to change this default location.
C:\WINNT\temp Read/Write/Delete Process This is the location used by Web services to generate serialization proxies.
Note that the Delete permission is set using the Advanced button on the Security page of the Windows Explorer folder properties dialog box.
Application folder Read Process This is the location of your Web application files (that is, your application's virtual root directory: for example, c:\inetpub\wwwroot\webapp1).
By default, the Users group has the appropriate access rights.
%installroot% hierarchy
(C:\WINNT\Microsoft.Net\Framework\v1.0.3705)		 Read Process and fixed impersonation accounts ASP.NET must be able to access .NET Framework assemblies.
By default, the Users group has the appropriate access rights.
C:\WINNT\assembly Read Process and fixed impersonation accounts This is the global assembly cache. You cannot directly use Windows Explorer to edit ACLs for this folder. Instead, use a command prompt and run the following command:
cacls %windir%\assembly /e /t /p domain\useraccount:R
Alternatively, prior to using Windows Explorer, unregister shfusion.dll with the following command:
regsvr32–u shfusion.dll
After setting permissions with Windows Explorer, re-register shfusion.dll with the following command:
regsvr32 shfusion.dll
Web site root:
C:\inetpub\
wwwroot or the path that the
default Web site points to		 Read Process ASP.NET reads configuration files and monitors for file changes in this folder.
C:\WINNT\system32 Read Process This location is for system dynamic-link libraries (DLLs) loaded by the .NET Framework.
Parent directories of context List Folder/ Read Process This location is for file change notifications and the C# compiler.

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/).

patterns & practices Developer Center

Retired Content

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

© Microsoft Corporation. All rights reserved.