Running ASP.NET on a Domain Controller
Topic Last Modified: 2006-06-20
By default, the worker process for Microsoft® ASP.NET (Aspnet_wp.exe) runs under the local machine account to restrict access to domain resources and provide a more secure environment. This will cause an error if you try to run or debug an ASP.NET application on a domain controller or a backup domain controller. On a domain controller, all user accounts are domain accounts and not local machine accounts, so Aspnet_wp.exe fails because it cannot find a local account named "localmachinename\ASPNET".
Workarounds
Create a weak account that has the permissions necessary for running the ASP.NET worker process, and then configure the <processModel> section of the Machine.config file to run the worker process under that account.
Configure the <processModel> section of the Machine.config file to run the ASP.NET worker process under the SYSTEM account or an Administrator account, instead of the machine account.
Note
This is not a recommended practice and has serious security implications. Allowing ASP.NET applications to run under the SYSTEM or an Administrator account allows code that is being run by the Aspnet_wp.exe process to have access to the domain controller and domain settings. Executables that are started by the Aspnet_wp.exe process also run in the same context and will have access to the domain controller and domain settings.
To create a weak account with the correct permissions
Create a user account on the computer and add this user account to the Users group.
Grant this user account the Log on as a batch job right.
a. Click Start, point to Programs, point to Administrative Tools, and then click Local Security Policy.
b. Expand Security Settings, expand Local Policies, and then click User Rights Assignment.
c. In the list of policies, right-click the Log on as a batch job policy and click Security.
d. If the new user account does not appear in the Assigned To list, click Add to add the new user account.
e. Select the Local Policy Setting check box next to the user account name and click OK.
f. Restart the server, if necessary.
Note
This process may need to be repeated for the Domain Controller Security and Domain Security policies.
Grant the new user account write access to the \WINNT\Microsoft.NET\Framework\V1.0.XXXX\Temporary ASP.NET Files\ directory. This will allow the Aspnet_wp.exe process to write temporary files and classes to this directory.
a. Navigate to the \WINNT\Microsoft.NET\Framework\V1.0.XXXX\ directory in Microsoft Windows® Explorer and right-click the Temporary ASP.NET Files icon.
b. Click Properties and then click the Security tab.
c. Select the user account from the list and select the Allow check box for Write permissions.
d. Click OK.
e. Make sure that the new user account has access to all other files and directories that are necessary to serve ASP.NET pages.Grant the new user account write access to the \WINNT\TEMP\ directory. If you are running XML Web services, this will allow the Aspnet_wp.exe process to write temporary files and classes to this directory.
a. Navigate to the \WINNT\TEMP\ directory in Windows Explorer and right-click the TEMP icon.
b. Click Properties and then click the Security tab.
c. Select the user account from the list and select the Allow check box for Write permissions.
d. Click OK.
e. Make sure that the new user account has access to all other files and directories that are necessary to serve ASP.NET pages.Specify that the ASP.NET worker process will run under the new user account.
a. Open the \WINNT\Microsoft.NET\Framework\V1.0.XXXX\Config\Machine.config file.
b. In the <processModel> section, change the userName and password attributes to the name and password of the new user account. For example: userName="DomainName\ASPNETUSER" password="ASPNETUSERpassword".
c. Save the changes to the Machine.config file.