Slashdot Mirror
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?"
We just have a development environment for them. Then once code is ready we copy the most recent backup image of the servers over, they install there, document how, and then our sys admins install. Done and done.
So basically, -1 troll/offtopic is really slashdots way of saying "I hate that you thought of something before me."
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.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
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?
No one should be running an administrator-level account for day-to-day work. It's a huge security risk. If there are tasks that absolutely require administrative rights to do with no workaround (rarely) then you create an administrator account that they log in to for that task only, then log back on to their normal account.
Who here, at some point in developing with Visual Studio, NOT seen it pop up that stupid message saying you have to run the IDE with administrator privileges for something or another?
Here's a quick link with just a few of the examples:
msdn.microsoft.com
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.
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.
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.
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.
...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.
Only to idiots, are orders laws.
-- Henning von Tresckow
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.
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.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
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.
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. ;)
If by "a few years ago" you mean a decade, then yes, I agree completely.
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.