FreePress Blog

Every software developer knows (or should know) the principle of “least privilege”. What it means basically is that a user should run applications on their computer using the most restrictive permissions possible. This helps guard against damage caused by running programs which (either by malice or unintentional bugs) can potentially corrupt your system by changing system settings, installing other programs, etc.

Unfortunately, it is very common for many developers to ignore this principle in the interest of getting their software out the door and on the shelves faster. This sometimes leads to their programs requiring Administrative privileges in order to run, when they could really get by with less if they thought it through. In turn, this leads to the security model that most consumer versions of Windows currently ship with, wherein the default (and in most cases the only) user account is configured as an administrator. They do this because it is too complicated to try to explain computer security to the average Joe who wants to install programs, etc. whenever they want.

All of this to say that developers who build ASP.NET web applications experience a similar issue when trying to debug their applications from within the MS Visual Studio environment. Because ASP.NET runs under a system (NETWORK_SERVICE) account, and the IDE debugger is running under the user’s account, the user’s process cannot access the ASP.NET process.

The quick fix for this is to set ASP.NET to run under the same user account credentials that the debugger (IDE) is run under. This does open up some other issues (which are out of the scope of this document), but assuming you have an otherwise secure configuration on your machine it won’t hurt anything.

The fast way to do this is to change the processModel in the machine.config file (located in %FRAMEWORK_ROOT%\CONFIG). By default, it is set to
<processModel userName="machine" password="AutoGenerate" ...... />
and you can change it to
<processModel userName="UserAccountName" password="UserAccountPassword" ...... />

The obvious problem with this is that then your username & password would be stored in cleartext in the machine.config file. Of course, this file should be locked down anyway, but it’s better to take the additional step and encrypt it.

Here is the outline of the process from start to finish (note that you will have to perform most of these actions as an administrator):

1. Add the user account you wish to use to the “Debugger Users” group
2. Download the aspnet_setreg.exe utility from Microsoft
3. Run the utility with the following syntax, to store the encrypted username/password combination in the registry:
   aspnet_setreg.exe -k:SOFTWARE\MY_SECURE_APP\processModel -u:"UserAccountName" -p:"UserAccountPassword"
4. Now edit the %FRAMEWORK_ROOT%\Config\machine.config file
   • Find the <processModel ... userName="machine" password="AutoGenerate" ...... /> line
   • Change the “userName” attribute value from “machine” to “registry:HKLM\SOFTWARE\MY_SECURE_APP\processModel\ASPNET_SETREG,userName”
   • Change the “password” attribute value from “machine” to “registry:HKLM\SOFTWARE\MY_SECURE_APP\processModel\ASPNET_SETREG,password”
5. Grant permissions to read the encrypted registry key to the “Debugger Users” group
• Run regedt32.exe and navigate to HKLM\SOFTWARE\MY_SECURE_APP hive.
• Right-click HKLM\SOFTWARE\MY_SECURE_APP and select “Permissions”
• Add the “Debugger Users” group and grant it “Read” permission
6. Set permissions on the %FRAMEWORK_ROOT% directory
• Give the “Debugger Users” group READ permission on %FRAMEWORK_ROOT%
• Give the “Debugger Users” group READ+WRITE permission on %FRAMEWORK_ROOT%\Temporary ASP.NET Files
7. Restart IIS

Now you should be able to debug your ASP.NET applications from within Visual Studio .NET, running as a regular (non-Admin) user.