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.
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 the credentials on the <processModel> element in machine.config. You should not store encrypted passwords in the registry. For more details, see Chapter 8.
<processModel enable="true"
userName="registry:HKLMSOFTWAREYourSecureAppprocessModel
ASPNET_SETREG,userName"
password="registry:HKLMSOFTWAREYourSecureAppprocessModel
ASPNET_SETREG,password" . . ./>You can use the steps presented in this How To to create a least privileged local account.
You can set fixed identities for specific virtual directories by using the following setting in web.config. Use aspnet_setreg.exe to store encrypted credentials in the registry.
<identity impersonate="true"
userName="registry:HKLMSOFTWAREYourSecureApp
identityASPNET_SETREG,userName"
password="registry:HKLMSOFTWAREYourSecureApp
identityASPNET_SETREG,password" />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.
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.
This procedure creates a new local account. By default, it will be added to the local Users group.
▸ To create a new local account
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 $.
Clear the User must change password at next logon option.
Select the Password never expires option.
This procedure assigns the minimum set of privileges necessary to run ASP.NET.
▸ To assign minimum privileges
From the Administrative Tools programs group, start the Local Security Policy tool.
Expand Local Policies, and then select User Rights Assignment.
A list of privileges is displayed in the right pane.
Assign the following privileges to the new account:
Access this computer from the network
Log on as a batch job
Log on as a service
Deny logon locally
Deny logon through Terminal Services
Close the tool.
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
Start Windows Explorer and assign the appropriate permissions to the folders specified in Table 1.
Table 1. Required NTFS permissions
Location
Required Permission
Account
Comments
Temporary ASP.NET Files: C:WINNTMicrosoft.NET Framework<version> 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.
Temporary Folder: C:WINNT emp
Read/Write/ Delete
Process
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 Virtual Directory: C:inetpubwwwrootwebapp1
Read
Process
The location of your Web application files (that is, your application’s virtual root directory). By default, the Users group has the appropriate access rights.
Installation (%installroot) Hierarchy: (C:WINNTMicrosoft.Net Frameworkv1.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.
Global Assembly Cache: C:WINNTassembly
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 Windows and run the following command: cacls %windir%assembly /e /t /p domainuseraccount: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:inetpubwwwroot 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.
System Root: C:WINNTsystem32
Read
Process
For system DLLs loaded by the Framework.
Application Folder Hierarchy C: C:inetpub C:inetpubwwwroot C:inetpubwwwroot mywebapp1
List Folder/ Read
Process
For file change notifications and the C# compiler (for file canonicalization reasons), the process account needs list folder and read data permissions to the application folder hierarchy. That is all parent folders all the way back to the root.
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.
userName="registry:HKLMSOFTWAREYourSecureApp identityASPNET_SETREG,userName" password="registry:HKLMSOFTWAREYourSecureApp identityASPNET_SETREG,password" />
In this example, aspnet_setreg.exe has been used to store the custom account credentials in encrypted format in the registry.
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
At a command prompt, run aspnet_setreg.exe to add an encrypted version of your custom account’s user name and password to the registry. For details about this utility and to download it, see article Q329290, "HOWTO: Use the ASP.NET Utility to Encrypt Credentials and Session State Connection Strings" in the Microsoft Knowledge Base.
aspnet_setreg -k:SOFTWAREYourSecureAppprocessModel -u:"CustomASPNET" -p:"YourStrongPassword"Open machine.config using Visual Studio.NET or Notepad.
Machine.config is located in the following folder:
C:WINNTMicrosoft.NETFrameworkv1.0.3705CONFIG
Locate the <processModel> element and set the userName and password attributes to contain the following strings which point to the encrypted credential details.
Default: <processModel userName="machine" password="AutoGenerate" . . ./> Becomes: <processModel userName="registry:HKLMSOFTWAREYourSecureAppprocessModel ASPNET_SETREG,userName" password="registry:HKLMSOFTWAREYourSecureAppprocessmodel ASPNET_SETREG,password" . . . />Save the changes to machine.config