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?"
Yes. Both at the company I work for and the regional bank I developed for a couple years ago. It is impossible, IMO, to do many functions without these privileges.
See my journal for slashdot ID's by year. Mine created in 2005. http://slashdot.org/journal/289875/slashdot-ids-by-year
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.
Whale
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?!
We're local admins of the application servers, and a couple of us have domain admin rights. We generally haven't run into problems with this, as we have a strict policy of making fun of anyone who screws up badly. It involves Photoshop and is generally a memorable way to resolve the situation.
In the Windows world you can override other things using GPOs, but it's too much of a pain from the admin side (I've found, as have my coworkers over the years) to try and lock down developer machines by removing local admin rights. I've got better things to do than schedule up a time to install things via an account with local admin rights every time something new comes along for them.
The flip side is that they have greater responsibility for maintaining their desktop/laptop systems. If it gets screwed up enough, they know they're getting the thing re-imaged with the company standard desktop image and will need to reinstall their tools they use for their personal dev environment.
Works out pretty well, aside form the devs that install absolutely everything they come across, "Oooh that looks cool! [installs][never uses again]". They can be a pain.
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.
What has that got to do with LOCAL admin rights?
LOL! Giving developers admin access to production machines is like giving grenades to babies, its only a matter of time.
Ultimately it comes down to a conflict of interest between developers who's interest is to changes things (new features, new version, etc) and admins who's interest is not to change things (SLA's, guaranteed uptime, don't touch a working system).
If this conflict is not properly balanced (dev's with fingers in production, admins controlling the dev environment), you will have problems and usually ends up being a very costly mistake.
GPLv2: I want my rights, I want my phone call! DRM: What use is a phone call, if you are unable to speak?
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.
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
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.
The key word was local. He wants to know if he should give his developers admin rights on their machine, not to the entire network like you're talking about.
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
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!!!
The entire development team where I work has full admin privileges on their local workstations. Not giving them that would be disastrous for productivity...
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.
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
Wherever You Go, There You Are
Why not simply work on virtual machines? Then you know they are clean and you can have all the rights you want and still have comply with company rules.
In a lot of environments, setting up a good seperation is simply to costly in time, so you either end up with dev's with not enough rights to do their job or to many where they can endanger systems they shouldn't.
So it should not be needed to have local admin rights, but then the sysadmins got a hell of a job to setup everything so that it is not needed. Most sysadmins simply ain't capable of that, or if they are, are not given the time.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
if the developers have to develop for a multi user and limited rights user OS they will actually build software that obeys those constraints.
That's why you use an OS that has a counterpart to sudo, like Windows Vista, Windows 7, Mac OS X, or Ubuntu. You'll still get "permission denied" for apps that you develop, but you still have the right to elevate to run an installer.
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.
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.
I've worked in a variety of situations ranging from developers having root access to all workstations and production servers to having no admin rights on the workstation at all. There's a definite connection between developer's admin privileges and overall corporate culture. The less permissive the workstation environment is for the developer, the less creativity and innovation flows from the organization. I've especially seen this in banks where you're not allowed to install any software without a security officer's blessing. Contrast this with my current company, where each developer is fully responsible for maintaining their machine.
By depending on each other to understand the OS and learn the best tips and tricks for choosing which tools to use, every developer becomes capable of troubleshooting issues on the production machines. As a result, we takes just one operations / sysadmin person to manage the systems for a 20 person company. Of course, granting that level of permission requires a high level of trust that is often earned over time.
"You know the company policy, but now I will ask you directly: Do you have any software on your computer that I have not personally reviewed?"
Yes
"WHY?!?!"
Because I write it. It's my job, and I don't have time to submit every program I write to you for approval before I install it on my machine to test it.
Admin Draws deep breath...
"AND...that makes sense. OK, you can have admin privileges on this machine".
I know places that don't give their devs admin privileges. It makes their jobs much harder. Security has to make sense to keep a corporate network safe, not to inconvenience everyone or make their jobs harder.
My company's IT department is totally incompetent. Their solution to everything is whatever Microsoft sells, regardless if it's actually a better choice than another option out there. They don't even give any sort of open source solution a second look. My boss and I (the only two developers at our office) don't have domain logins and administer our own machines. We don't have access to any of the intranet apps, but I've never needed them. We do hardware development so we need admin rights. We administer our own development servers, as well. The NAS thing IT installed failed, and it wasn't backed up anywhere, so the entire office lost their shared and backed up data. Except us, since we knew that would probably happen. We don't trust them to back up our code.
For the other employees at the office, whenever it's time to update software or install patches, one of the IT droogs calls an employee and tells them they'll be taking over their machine to update it (remotely, because there aren't any IT staff at our office -- they're all at another office). They do this in the middle of the friggin' day. And since they do the updates manually instead of automated updates, they'll take over someone's machine for sometimes hours, so they can't get any work done.
So, yes, we have local admin rights. We are our own admins since we can't trust our IT department to do things right. We still have a single T1 to the office (actually two, but they don't know how to configure the router properly to get both of them working), and we're told to "schedule" our downloads for after hours so as not to use up bandwidth. I got blocked from the network awhile back for downloading some stuff to do my damn job. No warning. They just blocked the IP, so I'd change it, and they'd block it again. Finally they called me and told me that I need to wait til after business hours to get this 50MB file I need to get my work done.
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.
actually it's usually about the manager's making *their* jobs easier. Having to explain why you need 2 machines (1 prod/1 dev) for a developer and 2 separate networks that need to be segmented and separately secured with separate configurations let alone the expense involved tends to get a big fat 'no' from mgmt. "Just do it the quickest and cheapest you can".
An Admin is well within his rights to maintain control over what is installed. Remember all the inadvertent leaks of documents because a user installed some file sharing program? That's an admin who didn't have, or wasn't allowed, adequate control over systems under his umbrella.
Developers DO need full admin rights on their dev boxes. You *really* don't want to be bothering the admin teams with "hey I need to restart IIS and/or reboot my machine" every 15 minutes if you're troubleshooting something.
the proper solution is separate networks where the developers simply can't cause significant damage by having admin rights. Unfortunately as has been said above, it's just easier to give developers admin rights on their systems without them being on separate networks from production systems.
People in cars cause accidents....accidents in cars cause people
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
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
I have 3 IDE's open because most of my work is front end stuff (AJAX/Silverlight), so I'll usually have VS2008 and Blend 3 open. Then if I need to be working on back end services, I'll have another VS2008 open for that. And invariably, someone at some point in time during the day will swing by with a question, debug request, or something else for another app, so I usually wind up with a 3rd copy of VS2008 or VB6 open.
For our SQL Server stuff I us the VS2008 server explorer, it handles most of the basic functionality I need, but not views, nor the AS400.
For the AS400 we have a custom .Net app that gives full intellisence, meta data searching, and descriptions in a traditional SQL+ like interface. So if I'm working on anything that hits the AS400, that app is open.
-Rick
"Most people in the U.S. wouldn't know they live in a tyrannical state if it walked up and grabbed their junk." - MyFirs
Here is what you need to do: (I also work for a similar corporation with the exact same policies, maybe the same one?)
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.
If you mod me down, I *will* introduce you to my sister!
With these bozos calling the shots, it took less than a year to turn a world-class development shop into a ghost town.
Like it or not IT pals, developers have to do things on their boxes that normal users should not be able to. If you try and prevent them you will force them to come up with even more dangerous workarounds (tunnels to home boxes, dark nets, etc). If you're worried about security isolate their network, but don't make it impossible to do their jobs.
What has worked best for me was when we gave them non admin on their dev boxes but admin on the test machines. These test machines had a "deep freeze" that when they rebooted the machines they essentially went back to a clean slate. It took some getting used to for those who always had admin before, but this ensured a clean install w/o extra software would work on a base system.
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^H^H^H^H^H^HPOSSIBLE, and never the twain shall meet.
There fixed it for you.
These posts express my own personal views, not those of my employer
"worked best for me"? I'm sorry, but isn't your job to support the others and make their work easier, not the other way around? Obviously you should make your own work more efficient, but not in the expense of the others. So are you sure your solution has not harmed anyone? "It took some getting used to" sounds like harm to me.
What if the developer is developing that very server? And it needs admin privileges to restart?
Bingo Dictionary - Pragmatist, n. A myopic idealist.