Windows Permissions for Developers?

Question

I work at a Fortune 500 company as a Windows software developer in R&D. Corporate IT is currently gearing up for a company-wide Win7 deployment and as a part of it they are looking to completely lock down admin rights on all boxes (including our dev workstations).

I've been tasked to work with them to make the transition as smooth as possible... Lucky me...

I'd like to know if there are any published or other highly respected resources out there that I can use to:

1. Figure out where to draw a line in the sand
2. Back up my position.

Personally, my take is that we're R&D and our job is to do things that are 'out of the box'. Thus we need admin rights. However, having started my career as a Windows Admin, I'm aware of their goals and what they need to achieve. What I need to figure out and back up is a way to build the environment in a way that both IT and R&D can live with it and continue to perform their jobs productively.

Development VMs with local admin rights will definitely help a lot, but not in all cases since we interface with lots of custom hardware.

The CIO pushing these changes is definitely a 'pure IT' kind of guy with limited knowledge of the development process so I need some references that would be appropriate to share with someone like that.

I'm not looking to gather a lot of personal opinions (a lot of which have already been shared here: Should dev be admin on their computer?), I really need whitepapers, magazine articles, scholarly works, etc to use to make a strong case to upper management.
Thanks!

P.S. This is a semi-crosspost with this: Windows Permissions for Developers? on Stack Overflow, but since the answer probably lies in the interactions between the two communities, I think it is appropriate.

Answer 1

I've seen a couple good compromises here:

• Let IT have their way on the core physical machine, but make their department foot the bill for better developer hardware with lots of RAM (6GB minimum, more than 8 is better) and a few extra OS licenses (or good MSDN subscriptions) so you can have the power you need to do most of your work inside virtual machines.

  You want hardware powerful enough that it's not painful to have your dev, db, web, and test client roles all running simultaneously in their own VM, each with 2GB of RAM on average (ie: db might need more, test client might need less). If you're already doing most of your work in virtual machines, this is a no-brainer. Now you can have all the administrative rights you want, but it's just inside the VMs. The physical host is otherwise locked down to IT specifications.

  About the only time this doesn't work is if you're doing really low-level hardware engineering and development, or when you work for one of those companies that still have developers running Visual Studio 2003 and eight years later still won't foot the bill for upgrades (and it is mainly about the bill).

  I like this option because it turns the conversation into one about cost. IT's complaint about running as admin boils down more to support costs than security of business systems elsewhere; users who run as admin locally can break things, but it's still just locally. Security concerns do exist (say your account is compromised and you have access to sensitive data), but most of the time for them the repair is still just a matter or re-imaging your machine.

  The main thing is that if you can show the no-admin option has additional cost also, then the obvious solution is to run the numbers and see what costs more (hint: IT almost always wins that round. They have to get good at things like massaging ROI numbers ;) ). Fast machines also tend to make developers happy; they get something in return for giving up admin access, and you get more productive, happier (less turn over) staff.

• Give developers two accounts, one with admin access and one without. Their exchange e-mail and other integrated authentication systems only work on the account without admin access, and so they will need to be logged in without admin access by default. To use the additional privileges, they must log out and log back in on the other account. IT can set up authentication auditing, so they'll know when and how long you spent logged in as administrator, and spot abuse later.

  This doesn't work quite as well imo, because there will be times when you do need to spend pretty much all day or all week as admin to do things like troubleshoot some specific difficult issue. It also means additional management for IT as they have to deal with two accounts per developer.

At the end of the day, running as administrator on your core system by default is just a bad idea, even under Win7 w/UAC and even for developers. Running as a standard user is also good for developers, as it makes it less likely for a bug to creep through that only effects non-admin users. But there are times when administrator access can be important to developers. A scheme that recognizes both sides of this issue is important.

Answer 2

This was a good enough idea that I'm posting it as an answer. It's not the only answer, but I think it can be valid one for a decently-wide set of circumstances.

For the issue of testing custom hardware, get a small physical test lab, with no network access (or limited/locked down as needed for testing). Everyone has local admin, and re-imaging the machines to a known standard is done every night. Unless every one of your developers is simultaneously testing hardware, a shared lab ought to work nicely.