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 maintain a development network and a QA network. The dev and QA teams have admin on the server machines in these networks. This is useful/necessary because we are constantly spinning up and tearing down virtual machines for various scenarios. Devs have local admin on their workstations. In general this has worked fine, except for one moron who used the privilege to turn off her virus scanning.
Production is subject to more structured control in theory, but in practice, I and another couple of guys have /sudo/root on the prod machines, because our corporate admins don't want to learn enough about the software to be useful. So much for PCI...
I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
I would disagree -- the more years I spend programming the less I remember about system administration. I can do basic setup tasks, but fiddling with Active Directories and stuff like that is beyond what I care to learn and has been for what, a decade now?
At an Ancient Telecom company most folks don't have admin rights (and shouldn't) but there is an exception process developers follow, and otherwise the Company-approved packages don't need admin rights to install, plus the help desk has powers.
In modern times, I would give them no admin rights on the box itself, but you could provide virtual machines for them on which they can do whatever they want. The argument that they need to do things that "really, really" :-) require access to the bare metal, doesn't hold anymore, because the applications they are building will anyway need to be able to run in a virtualized environment.
I've done many audits and project plans on this topic in the past, and the issue is always that developers are split personalities: on the one hand they are standard corporate citizens that need email, calendar and word, which must be rock solid and therefore IT controlled, on the other hand they do their development work that requires freedom over their box. In the past the best solution was always to give them two PCs (or a thin client for the standard desktop work), but today I would solve this all through virtual machines.
Browsers shouldn't have a back button!! It's all about going forward...
On one hand, yeah, of course developers should have admin rights on the machine (i.e. local).
On the other hand, I think Windows developers should have to operate as non-admin users as much as possible so that they will realize their software won't work properly when run as a limited user. It's a perennial problem with Windows software, although it is getting better.
So, yes, they should have access to it, but discourage its use except when necessary. No running as admin all the time.
I'm going to end some mystery here: I am guessing the "very large corporation" is Target, a massive US-retail chain. I only know because I used to work on support there, and they tried this crap with trying to delete local admin rights for everyone so nobody could administer their own boxes. Even Microsoft told them this was a bad idea, and you can't remove local admin from a system because it's fundamental to the security model. It was so painful watching the daily e-mails come back from amongst IT and then once every week or two see a management e-mail so loaded in buzzwords I printed it off and hung it on my cube wall next to a train wreck picture and left my coworkers to do the math. They went ahead and tried it anyway -- I've watched whole stores, departments, and even divisions just drop off the network because they rammed some security change through, didn't test it thoroughly -- and now some application is seriously wedged. The days and days of downtime are due to convincing infosecurity that there's a problem and then fixing it -- because they're autonomous to the rest of support and report directly to the board. Which means, no matter how bad they f*** up, it's your fault, not theirs, because they each think they're Agent Smith, saving the corporation from the disorder of computational devices. *face palm*
I feel your pain. I do.
The sad part is, this isn't just that corporation: It's most Fortune 500 companies. Management is so far removed from the IT process that the only input they get is from external sources: Trade magazines and consultants. This, of course, ends in tears. These are the kind of people that read that pen drives are the source of all evil on their network and if you just delete the USB mass storage driver from the system, your problem is solved. I don't know which trade magazine published this idea -- but when I find him, I'm going to end him. Again, not a problem specific to that company -- it's representative of what everyone finds in the field today.
Since corporations with this level of brain damage inevitably give developers underpowered systems, here's your solution: Cannibalize another system, make sure you've got a few extra GB of RAM, and install an virtual machine, then do all your development within that environment. Site licensing is a wonderful thing. Just don't ever join it to the domain and shuffle your test files in and out via a temporary share. Even better, find a standalone system and use that for development so corporate can have their ridiculous security on one system, and you have an unencumbered development platform to develop for and transfer completed work back to the main system.
It's stupid, and you should never have had to do it. But then, what about working for a large corporation is ever simple? So many people trying to ensure they're a crucial part of the business, so few who actually give a damn about it...
#fuckbeta #iamslashdot #dicemustdie
Any developer who can't competently administer his own machine is incompetent
As an IT person who has supported developers, that makes me think that I've only met... like... 2 competent developers ever. Almost every developer thought he could administer his own machine, but very few did a good job at it.
As I see it (and maybe this is BS, but I'm saying it anyway), part of the problem is an issue of mentality. Developers seem to want to think about what *should* happen. Like "Oh, well installing this *shouldn't* make a difference. Changing this setting *shouldn't* make a difference." As though computers all make sense and work the way they're supposed to. In my years of doing support, I've come to the opinion that this is a very bad support mindset. Computers almost need to be treated as magical boxes possessed by evil spirits which might stop working if you anger the computer gods.
And I know, if you're a developer that probably sounds utterly silly and you think I'm a bad support guy. But you see, that's my whole point. Developers tend to have a different mindset. Computer stuff breaks all the time for no reason. Hard drives die, motherboards get fried, and monitors burn out. Sometimes enabling a setting will break your computer in some completely unrelated way. Yeah, yeah, there's a valid scientific reason. If I had access to the source code and I was a master programmer and I had all the time in the world, I could probably figure out exactly what was going on and fix it for real. But for my purposes, I just need the thing to work right now so my user can get back to work. For my purposes, for right now, it's good enough to assume that enabling the setting upsets evil spirits and angers the computer gods. It means "leave that setting alone."
It seems like every developer/administrator I've met wants to ague with that. They want to say, "But that setting *shouldn't* make a difference. Computers only do what they're programmed to do, so I just have to reprogram it right now." All that may be true, but as the support guy, you don't always have time like that. Sometimes you just have to blame the computer gods and move on.
You should treat your development machines as "hostile" and put them on their own network.
You should do this regardless of security issues because developers can also do stuff like saturate your network.
And what a great administrator, bashing people over the head because of your own limitations.
I'm glad you don't administer my development systems.
One of the mid-sized corporations I worked for did not allow admin access to developers on production machines. The reasons for this has been outlined by some other posts already, but mainly because the server team was responsible for the servers. It was also part of a strategy to meet Sarbanes Oxley requirements for servers touching financial data.
In order for it to work smoothly, an exact development copy of the production server is required. This is pretty resource intensive in both servers and admins. Second, the deployment of new applications needs to be communicated to the administrators. This took some time depending on the difficulty of the change. Finally, any issues that popped up in the production server that wasn't seen in the development server required "emergency admin access". It usually meant that a server admin and developer sitting at the same terminal working out an issue.
This method, while not being efficient, forced a couple of best practices. First, because development had to be done a replica of the server, the code was already tested on a server that was identical(as possible) to the original server. Second, because the deployment had to be done by server admins, the developer had to document all the steps required to deploy their application. It let the admins know the changes being made, allowed auditors to see the change, and forced the developer to make an application that was reasonably easy to deploy.
Overall, I think it lead to a pretty clean production environment with much fewer "surprises". However, any code you want to put into production takes twice as long and cost twice as much (approximately). To truly evaluate if it monetarily makes sense, the cost of a failure/fraud in a production environment needs to be calculated. I don't think it is always better one way or another. Although, as a developer it sure was a pain in the ass.
If your devs had access to make changes to the production servers, then the failure was not with them -- the failure was on the system administrator.
As a developer, I try to have *no* access to any production system. If you're connected to the prod database server to, say, look something up for a customer (which shouldn't happen -- you should have tools for this -- but it does), it's far too easy to forget that you're connected to prod when you go back to dev-related tasks and accidentally wipe out a table.
I hate having to be extra-careful to make sure that I'm not in prod. I'd much rather just know that I have no access to production so that I couldn't make changes, intentional or otherwise, at all.
--Jeremy
Jesus was a liberal