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

Yeah.

[qoncept]

At my last 2 jobs developers have had security exceptions for local admin rights. The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management.

Re:Yeah.

[Aeros]

In my current position and also the last company I worked with we had this policy in place. What they ended up doing is giving us two user accounts, one was low-level which was our regular account then a high-level that we switch to when we needed local admin rights for doing installs. Seems to work out fine and I hear alot of companies operate this way. It is a pain to switch back and forth but it satisfies all parties and I am able to get my work done.

You damn well should

[QuoteMstr]

Any developer who can't competently administer his own machine is incompetent. The kind of rigorous thinking required is identical. I'd be highly reluctant to work at a place that didn't let me install and manage the software packages I needed to do my job. I've used hundreds of small programs to help me in my work, along with kernel debuggers and other tools that require administrative privileges. Having to ask for approval and installation assistance for each of them would have been impractical.

If you're worried about developers screwing up their boxes, why aren't you more worried about these developers screwing up the their code?!

Re:You damn well should

[TheRealFixer]

Any developer who can't competently administer his own machine is incompetent.

You'd think that would be the case but, in my experience, I've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops. Didn't understand basic networking principles or basic OS functions and dos and don'ts. That being said, I still would give them admin rights to their own workstations. Otherwise I'd be spending my whole day installing a billion apps for them that they need to test or develop with, and that also ends up being a waste of their time having to wait for me. But I also have the expectation that they're probably going to need some additional care when they mess something up.

But 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.

Re:You damn well should

[Deorus]

How can a competent developer not understand operating system concepts?

Re:You damn well should

[MightyMartian]

That's not an example of a developer who doesn't understand OS concepts. That's an example of a moron who should be shown the door with extreme prejudice.

Re:You damn well should

[bwcbwc]

WTF? It IS a developer's job to worry about system security from an application implementation perspective. It IS a developer's job to understand the operating system well enough to understand the best way to use the operating system's APIs and services. It IS a developer's job to understand what software is on their system, because that software could be interacting with the program they are developing. This knowledge alone makes them more competent to administer and manage their own PC than your typical COE support person. On top of that, they need the access to do their job.

1) Developers should have local admin rights on their machines
2) Apart from automated software updates for standard anti-malware and office tools, the developer should install and maintain the tools required to do their job.
3) The developer should not require access to the normal helpdesk support for issues local to their PC.

On the other hand, as posted below, there is no reason a development machine can't be isolated from the local network, or else the local admin rights can be granted to a local-only user that does not have access to the network. If your company doesn't want to provide developers with two separate computers, limit the network access to a non-admin user. Under *nix, Vista or Win 7 the developer can sudo or invoke the local admin user to install software and perform administrative tasks required for software development.

Heck you can even force developers to develop inside a virtualized environment in a VHD image, but they'll still need admin rights within the virtualized system. Your testers, even moreso.

Re:You damn well should

[Daishiman]

Because knowing OS theory doesn't make you an OS specialist dedicated to implementing good practices on production systems. Even a kernel dev might not know how to install and deploy a production system and implement all backup, user, and processing policies.

Re:You damn well should

[mcmonkey]

Wow. The scariest part of your story is people think this guy is a top performer.

Now, on the one hand, you can say he was very competent in operating his workstation. He knew how to install software. He knew how to configure said software the way he wanted. He knew how to change OS settings to make sure his software worked the way he wanted. He did all this without having to contact anyone else for support

Really? So 1) he owns the company? Or is the president or CEO? If not, why the fark should the world revolve around the way he wants his system to work?

2) Why is it a good thing he can get his system to work the way he wants, when he wants every hacker on the planet to get in to your company's systems through his laptop? And if that's not what he wants, then his software is not configured the way he wants.

Seriously, this guy is a menace. I can grab a chain saw and rip open someone's chest, that does not make me a competent heart surgeon. Yes, this guy made changes, but in no way should anyone say he is competent in operating his workstation.

"Standardization"

[Nerdfest]

Organizations that treat developers like standard "business" users are going to get systems developed as well and as fast as those created by standard "business" users. A developer needs at least elevated rights on a workstation.

What it REALLY comes down to

[Anonymous Coward]

Here's the thing... Why the **** does windows program installation basically require files be installed any place other than locally. That's the entire problem. The entire design of windows is to install **** under system32 or program files when it doesn't need to be there. I remember the old days when programs ran under one directory. Easy to maintain. You know where everything is. To uninstall is simply to delete. Don't get me started on the registry. REALLY? You're telling me it's "faster" than reading a text file config. Hardly. ARE YOU HEARING ME MICROSOFT? Why the **** do you even need admin rights? YOU DON"T!!!

Yes in DEV, No in TEST and PROD

[garyisabusyguy]

It is a huge pain in the ass to do development without local admin rights.

HOWEVER, it is a huge cluster fuck to implement in PROD because your permission levels all have to be reconfigured to fit any rational security model.

I have found that denying developers local admin in the TEST environment is a good way to shake out any implementation nightmares

Re:What?

[Javagator]

as an admin, I prefer to maintain control of what is installed on the systems

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.