Debugging ASP.NET 1.1 as non-admin in VisualStudio.NET 2003 and IIS 5

Written on August 22, 2005

Imho it is the easiest way to debug ASP.NET 1.1 applications as non-admin using VisualStudio.NET 2003, when you're following these instructions:

Grant the following rights to your LUA (= Limited User account) for the directories listed below:

Directory Permissions

%WINDIR%\Temp Read / Write


%INSTALLROOT%\Temporary ASP.NET Files Read / Write

&INSTALLROOT% is of the form c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 and %WINDIR% is of the form C:\WINDOWS.

After this you have to add your LUA to the security groups 'Debugger Users' and 'VS Developers'

By default, with a restricted user login, you cannot debug Web applications because the user running the debugger is not a member of the proper group to debug other users' programs (Administrators), and the Web server started ASP.NET as the NETWORK_SERVICE account.

If you do not want to grant this login membership in the local Administrators group or run the debugger as the local Administrator, you need to change the account that ASP.NET is running as. On Windows XP Professional, edit machine.config as shown below and put in your username and password in clear text. This has the potential disadvantage of requiring all ASP.NET applications on the machine to run as your user account, but is the best method for IIS 5, and allows you to debug and build Web apps the same way you did in the past.

As an Administrator, edit the attributes of the file "%INSTALLROOT%\Config\machine.config" 'on the processModel tag, as shown:

If you do not set a restrictive ACL on the machine.config file, putting your userid and password in cleartext allows anyone to see your password. Even if you set a restrictive ACL, all users in the Administrators group will still be able to see it.

The resolution to the above security risk is the following: Use the aspnet_setreg.exe utility to put an encrypted version of the LUA's username and password in the registry by using the following command:

aspnet_setreg.exe -k:SOFTWARE\MY_SECURE_APP\processModel -u:"username" -p:"MyPassword"

Then modify the processModel as follows to point it to the registry:

By default the DACL on the "HKLM\SOFTWARE\MY_SECURE_APP" hive grants Full Control to only System, Administrators and Creator Owner. Since ASP.NET is running under my userid, the caveat here is to make sure that I gave my userid (ex. "username") Read access to this registry hive where the userid and password are now stored.

My machine needed to be rebooted after modifying all these settings - so it won't by a disprofit if you do it also ;-)