Do Your Developers Have Local Admin Rights? 605
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?"
What? (Score:1, Informative)
Re:What? (Score:5, Informative)
Re:Yes (Score:3, Informative)
Pretty much the same experience here. Even the "maximum security" bank auditing company I used to work (and develop) for gave their devs local admin rights. At least after their admins complained that they don't get anything accomplished because they had to do something for the devs every other minute.
Instead, we got a tight rule set put in place that pretty much said that, while we do have local admin, any kind of change in the software setup of the machine (i.e. new software or new security rules, etc) required a written permission. And behold, it worked.
You needn't cast every rule in silicium. It's one of the very, very few situations where a legal system can actually do something for security.
Re:You damn well should (Score:1, Informative)
Any developer who can't competently administer his own machine is incompetent. The kind of rigorous thinking required is identical.
I agree that developers should have local admin privileges, but I think this relies on them knowing their limits, and I don't believe that they need to be competent at administering their machines.
As an example, most of the code I develop runs on Solaris (with which I'm pretty intimately familiar) but I do most of my day-to-day work in Windows. I recently had problems VPN-ing into work (on Windows) and just about tracked it down to Kerio, the software firewall that we use. I was completely happy troubleshooting this far, because I understand our VPN's network flows, but troubleshooting Kerio was beyond me - I don't even know what diagnostics I can get. I passed it to our IT Support team and they investigated.
Does the fact that I can't troubleshoot obscure bits of software that I don't develop make me an incompetent developer? Isn't troubleshooting these types of problems what we have an IT Support team for?
Information Security 101 (Score:3, Informative)
Heck, with Visual Studio, its nearly required! (Score:1, Informative)
Here's a quick link with just a few of the examples:
msdn.microsoft.com [microsoft.com]
Re:You damn well should (Score:1, Informative)
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.
My last job's developer policy was: you have root access on your machine and you can install whatever you need to help get your work done, but if you mess up your machine, IT's solution is going to be to re-image it. (You won't lose work, because all of your work is checked in, right? And any un-checked-in in-development code can be backed up to the network first.) That way the developers get the freedom they need, and IT doesn't have to try to diagnose incompatibilities between hundreds of little third-party apps.
Huh? (Score:1, Informative)
I'm not even sure why this has to be asked. If a developer doesn't have local admin rights in at least some environment where testing can be done, then the developer simply can't do his or her job. This just seems obvious to me.
Where I work, employees in IT related groups have local admin rights to their workstation. Additionally, we have multiple test environments. We have a development test environment where developers, as well as QA, can do their testing. Then we have a staging environment, which mimics production, where only administrators have admin rights, just like in production, so that the software being developed can be verified to work in such an environment before being moved to production.
I do work in a very large corporation.
Yes... well almost... (Score:2, Informative)
Developers have near admin privileges. Everything is locked down via GPO, and developers are in our own OU.
We are admins on Development and Production servers so that can we handle application deployment, maintenance etc.
There are still some functions that we don't have access to, things like the virus scan, HIPS, Desktop validator, Smart card interface etc.
We can install/uninstall applications etc, but there is a finite list of software we can use, and if we get caught with unapproved software on a computer on the network, we will have a lot of explaining to do... to people with sidearms.
Re:You damn well should (Score:3, Informative)
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 (Score:5, Informative)
...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:
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.
Re:Yes (Score:3, Informative)
You just need to be a member of the Debugger Users group, and VStudio works fine without being Admin.
It's not impossible to not be an administrator. I install all my services as an ordinary user and make sure things work OK.
It's a lot more comfortable to just be the administrator, sure, no question - but it's not impossible.
Compromise (Score:5, Informative)
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.
Re:What? (Score:2, Informative)
# LS
LS-not found
Yeah, I should have root.
We have renamed LS to listthedirectory to make it harder on hackers, please make a mental note, but not a damn yellow sticky.
Also root is now called ~!ExtremeAdminAccount!~ (case sensitive, please use this when logging in via telnet from home.)
Re:What? (Score:2, Informative)
1. Install Linux and get it connect to your corp network (I run Ubuntu 9.10)
2. Install a virtualization environment (My company has a deal with VMWare)
3. Create a virtual image with Windows which you use to develop on, giving you full admin rights.
It also avoids any impact of Windows bugs or BSOD's.
Re:What? (Score:3, Informative)
Re:You damn well should (Score:1, Informative)
The top performer bit was in relation to development skill, not managing the desktop - that was the whole point of the anecdote if you read the grandparent, that those who can be among the best in getting stuff done on the development side may not be good choices to entrust extra administrative privileges to.
Re:Yes (Score:3, Informative)
As a Unix admin with a development background, I thank you for being competent. I'm technically a security admin (for a huge financial company), so I spend about half of my time arguing with people about how they could just tell me what they need to run as root and I could provide them a sudo rule set - which would reduce the passwords they have to remember *and* keep the environment more secure + auditable (which, due to various regulations like PCI, is more important to the business than cowtowing to lazy developers who don't know how to use the system they're developing).
But the main reason for responding: If you started the process, you can generally attach a debugger to it. The difficulty is in attaching to another user's process. :)
PS: I currently own a NeXT workstation. The pretty UI (and associated display postscript) only barely makes up for mixing the worst parts of BSD and SysV into that Devil's UNIX behind the scenes - I'd leave you alone with it too. ;)
Re:Yes (Score:3, Informative)
Re:Yes (Score:3, Informative)
A few years ago, a 1ghz P3 with 512mb and a 17" CRT was considered high end, and people would be very happy to have one...
Hint: we just clocked over to 2010, not 2000.