Developing with least privilege

I've always coded while logged in as Administrator, but after listening to a great discussion about developing with least privilege (DWLP) on dot net rocks I've been persuaded of the benefits and decided to give it a try. Developing, or doing anything for that matter, with least privilege is about making sure that for whatever task you're engaged in you only have the permissions necessary to carry it out. I guess the thing that persuaded me the most was thinking about the number of times I've worked on applications where everything worked fine on my machine (logged in as administrator), but then facing all kinds of problems at deployment. Not only that, but by developing as administrator you're hiding from yourself the permissions your application, or the tools you are using require since you're never forced to examine them. For example, I wasn't even aware of the VS Developer role until I started to do DWLP and the permissions used by ASP.NET were also somewhat misty in my mind. So what do you need to know to do .net development while not logged in as administrator? First your account must be a member of the following groups:

• Users
• Debugger Users
• VS Developers

ASP.NET applications run under the 'ASPNET' account by default. You would have thought that being a member of Debugger Users would mean that you could debug ASP.NET applications even though they are running under a different account, but according to MSDN, you're only allowed to debug if you are logged in as an administrator. So in order to debug ASP.NET applications we need to run the ASP.NET worker process (aspnet_wp) under our own loggin. To do this change the machine.config process model: You also need to grant read/write access to the windows directory and the framework directory to your account. On my machine these are at: C:\WINDOWSC:\WINDOWS\Microsoft.NET\Framework\v1.1.4322 It's a shame that the ASP.NET development model requires these changes. It makes it apparent that the development team assumed that developers would be developing as Administrators against all security best practices. Having to give a restricted user write access to the windows directory and puting the user's password in plain text in the machine.config file kinda defeats the object of the exercise. Now if I inadvertently access the windows directory programmatically from my application I'll be breaking the application for deployment under a restricted user account, but I wont discover this until the application is first deployed. There are plenty of tools you are going to need to use as a developer that have to be run as administrator. The trick is to only run those tools as administrator. You can run any program with a shortcut as another user by right-clicking the icon and selecting 'run as', and then choosing the username you want to run under. You can run any command line program (including cmd.exe) under a different username with the 'runas' utility. E.g: runas /user:admin cmd.exe Check out developing as non admin for a really good overview.