A best practice for developer security (and end-user security, for that matter) is to develop and run software using the least privilege necessary to get the job done, and no more (see Writing Secure Code, 2nd Edition for more information on Least Privilege). This includes how you log into your workstation. Too many developers and users use an account with administrative privileges on a day-to-day basis, leading to increased exposure to security problems, as well as potentially difficult to track bugs in their programs.
A better solution is to run using a non-admin account for day-to-day use. This approach is more secure, but brings with it some additional challenges. One such challenge is debugging ASP.NET applications. If you’re logged in as an Administrator, this is easy…it just works. To debug ASP.NET applications using a low-privileged account, you need to do a little setup work. The steps provided here are detailed in an article in the MSDN Library (http://msdn.microsoft.com/library/en-us/vsdebug/html/vxgrfaspnetdebuggingsystemrequirements.asp).
In order to debug ASP.NET applications under Visual Studio 2003, you need to either be a member of the Administrators group (not a best practice) or be a member of the Debugger Users group, and have the ASP.NET worker process running under your user credentials.
Note that on Windows 2000 and Windows XP, running the ASP.NET worker process (aspnet_wp.exe) under your own account requires that you put your user credentials in the machine.config file for the machine where you’re debugging. As such, you should consider the security implications carefully and decide if they are appropriate for your environment. You could, for example, create an account whose sole purpose is developing and debugging your applications to prevent anyone who has access to machine.config from accessing your main user account. On Windows Server 2003 with IIS 6, you can use the IIS Manager to change the identity of the ASP.NET worker process (in this case, w3wp.exe), so you are not required to store the credentials for the desired account in a clear-text file.
To run the ASP.NET worker process under a user account on Windows 2000 or Windows XP:
Of course, you can avoid all of this configuration by moving to Visual Studio 2005, which allows you to debug local ASP.NET applications as a non-admin without any need for configuration, thanks to its built-in lightweight web server. And best of all, if you’re an MSDN subscriber, you can download the beta now, and get the final version as soon as it’s available.