Do Your Developers Have Local Admin Rights?

plover writes "I work as a developer for a Very Large American Corporation. We are not an IT company, but have a large IT organization that does a lot of internal development. In my area, we do Windows development, which includes writing and maintaining code for various services and executables. A few years ago the Info Security group removed local administrator rights from most accounts and machines, but our area was granted exceptions for developers. My question is: do other developers in other large companies have local admin rights to their development environment? If not, how do you handle tasks like debugging, testing installations, or installing updated development tools that aren't a part of the standard corporate workstation?"

Comments

Re:What?

[unixguy43]

As an admin, I've supported both types of environment. Depending on what the development project is, sometimes it's just better to allow the developers to have full admin rights in order to add compilers and other development tools required for project completion. The developers were responsible for all O/S issues related to installation of non-standard development tools, but would rely on the sysadmins for hardware support, as the service contracts were part of the corporate global service contracts. There's no easy answer on this one, and it pretty much depends on company policy around allowing admin access to non-admins. Personally, as an admin, I prefer to maintain control of what is installed on the systems under my umbrella, as it makes patching and upgrading easier when I know what's already there, and what dependencies are required.

Re:You damn well should

[AnodeCathode]

We allowed our developers to have local admin access. In exchange, their machines were located on a separate VLAN and all communication routed through an internal firewall. This allowed these uncontrolled machines to do what the developers wanted, but allowed us to easily shut them down in an outbreak. It also gave the developers easy access to logging their traffic and understanding exactly what would be required to have applications run in a restricted environment.

For production systems, the developers had separate admin accounts that would be granted the required access to a system with a logged change request, time limited.

It works reasonably well. Of course the developers could just plug into a non-restricted port, but of course, this is better managed through policy than technology.

Re:You damn well should

[Savage-Rabbit]

...admin access to production servers, absolutely not. I've seen way too many scary, scary things happen when developers are given unrestricted access to production systems.

IMHO:

• Development should be done using dedicated development systems that replicate the production environment. I have seen way to many problems and delays arise because the developer's setup on his personal laptops didn't exactly replicate the productions deployment environment.
• The development machine-pool should have it's own admin who's **only** role it is to service those development machines along with the version control/collaboration suite/bug tracking/etc... servers and development should never be done on live systems if it can be avoided. You need dedicated admins for the development machines because otherwise dozens of developers with root access will turn them into a godawful mess in no time flat.
• Developers should have root access to their own personal workstations/laptops.
• Developers should not have root access to development systems.
• Developers should never, ever, ever have root access to production systems.

I have worked in various places that had strategies ragning from what I just described and to developing-on/deploying-to live productions systems (with all the irate customers due to regular downtime caused by unexpected bugs which that entails). One place I worked at didn't allow developers admin rights on what development systems they had, they were too cheap to cough up for enough development machines and whenever (rarely) they did overcome their sense of thrift it took a week (if you were lucky) to get the machine up and working. The work had to be requested through proper channels, approved by a management committee and then performed by a bunch of overworked IT gnomes that also had to service several hundred workstations and a huge productions server-pool. We didn't even get to be Admin on our own Windows (by management mandate) laptops. Getting a port opened in the firewall on your own Windows workstation had to be approved by a security committee at management level. You can imagine how long that took. Needless to say most people solved these problems by setting up their own development environments. The result was a whole fleet of rogue machines. Every desk had 3-4 computers under it and workstations were regularly taken off the Windows domain by developers or Windows it self was simply quietly replaced with Linux. It was the only way to get things done and even then the pace of work was glacial.

Compromise

[Slashdot Parent]

That's the way it always is. The admins want to limit control to make their jobs easier, and the developers want full control to make their jobs easier, and never the twain shall meet.

About the best compromise I've ever seen is where admins say to the developers, "You can have local admin rights. However, don't keep anything important on your local disk (use network shares and source control), because we're not going to even attempt to support your unsupported software. If you bring your machine in with a problem, it's getting imaged, and that's that."

That usually makes the admins happy, because they don't have to increase their workload, and makes developers less likely to bork their machines, because no developer wants to lose a day reinstalling IDEs, etc.