Is it common to allow local desktop and/or active directory admin access and rights for developers in organizations?

Question

I work at a company with a staff of about 1000+. We currently have programming development staff that work on web based projects (approx 50 people).

Recently due to security concerns our IT and Security department implemented a restriction no longer allowing local admin access on machines . The entire company runs Windows OS for both workstations and servers. I completely agreed with the decision to remove admin, honestly I thought it was long overdue (as the company deals with patient data and requires HIPAA compliance). Unfortunately I believe they took the decision too far. I assumed a subgroup or AD group would be created for users that legitimately needed admin access to do their job (EX my programming team) something like a Tech group that would retain admin access. However this was not the case, the only group created a specific Admin group for Network and Help Desk staff.

The main problem is, as web developers we run programs that require local admin access and unfortunately can't do our job without them running as admin. Example programs include Visual Studio for ASP.NET web development, MAMP for local development, composer, etc. I believe the main reason these programs need admin access is because they need to run and modify local IIS, command line, etc.

Basically there was short notice of when the local admin access was removed. After about 2 days of the development team being dead in the water in terms of being able to work and me and other team leaders basically yelling and screaming at the IT staff to come up with a solution they finally conceded and found a third party program that works as a pass through allowing the administrators to create the ability for certain programs to run as admin even though we don't have local admin access.

Unfortunately, this program we use for local admin access is incredibly buggy and unreliable and not from a reputable source and there doesn't seem to be much for alternatives out there. (I would prefer not to disclose the program we use.)

My question is, is it typical to not allow Programmers/Developers local admin access at a company or corporation? And if it is common practice to do so, then how do developers run the programs they need as local admin?

A little more information on our network environment (not that it really relates to the question I just thought I'd add this):

1. We use AppBlocker to block programs not on an approved list
2. We use an email security blocker that does things like scan and convert attachments to PDF, etc.
3. We have at least 2 major antivirus programs on all workstations.
4. The network and it's servers very segregated, users only have access to certain servers, folders, and databases that they legitimately need access to.

Answer 1

Here's one data point from a software company that has an interest in security. I know this is common in similar organisations.

There is a number of networks. They are physically separated and airgapped, run different colour-coded network cables.

Each employee has an 'administration' machine, which can connect to the Internet (via a proxy) for doing email etc. All users are strictly locked down, and there's strict device and access control.

In addition to this, each developer has an 'engineering' machine. This has full admin access, and the user can do whatever they like. However it is connected only to the engineering network (no route to the Internet).

In most software development contexts this could be seen as extreme, but in orgs that have conflicting requirements of high security and developer freedom, this is a common solution.

To answer your question, yes it is common to allow developers admin access, but this doesn't always mean admin access to a machine that could cause information security issues.

Answer 2

In my experience, it is common for developers to have admin access on their own machines. It is also common for them not to have admin access on their own machines. However, in the latter situation some accommodation is generally made so they can get their jobs done without too much friction.

One very common accommodation is access to a Hypervisor on the workstation (whether some version of VMWare or the Hyper-V that comes with Windows), along with the specific permissions needed to create and destroy VMs within that hypervisor as needed ^{(Hyper-V/VMWare)}, including creating VMs where they have admin rights to the guest OS. Typically some of these VMs will be long-lived, even if they don't run all the time, where it's rarely a question of needing to prepare an entire VM from scratch just to do what should be a quick test for something that needs administrator privileges.

The Hypervisor may or may not be configured to allow internet access for it's VMs; I've seen it both ways, though personally I strongly favor that internet access should be allowed... at least for the types of development with which I have most experience. But internet access, when granted, can and should at minimum be configured to force VMs into a dedicated vlan, separate from the rest of the corporate network. I'm not sure this is possible to enforce directly via Hyper-V or VMWare, but you can use 802.1x on the ports for many network switches to prevent access to certain vlans from unauthorized machines, including devloper VMs. Then you can give a little tutorial to developers about how to set a vlan tag in a VM and let them know what vlan tags will be permitted on their switch port. I've also seen this enforced via training merely as a policy edict, rather than via technical measures, with perhaps the occasional friendly audit to encourage compliance and make sure devs know it's important.

And, of course, this coincides with providing developers with machines sufficiently powerful to run multiple VMs at one time.

Answer 3

I work for a fairly large investment management firm (~6000 employees) and developers are one of the groups that we approve for local admin access. We tell them not to install any software, as that is handled by local desktop/software compliance.

We also have a Developers AD Group that allows members to change the execution policy on their machines without requiring local admin.

Answer 4

In my experience allowing and disallowing local admin access is common, just as common as dirty workarounds for the latter. - So you should ask yourself:

Which threat to your network is made worse by local admin rights?

To which the answer shoud be: NONE - The access to resources in your network should be restricted on a per user basis, completely unrelated to the fact if this user has local root, admin or masterOfTheUniverse access on his machine. If the user has rights to blow up your network, a local virus does not even need admin access, it can just use the user account to blow up your network. - And if the user-account cannot access something on your network, local admin rights will not change anything about that.

You should trust your developers to handle their own machine responsibly - and with a sensible security configuration in your company local admin rights should be dangerous only for one thing: The local machine. So the only risk you accept by giving out local admin is that a developer breaks his own machine (which he can already do with a cup of coffee).

Addendum: You should grant your developers the possibility to use local-admin rights whenever they need to. This doesn't mean they should be logged in with an unsecured admin-account all the time, but you should trust them to use it sensibly whenever they need it - without asking for permission every time.

Why developers should have local admin-rights

Your developers are people which you entrust the design of core operations of your business. Most companies today are very dependent on their software, so developers are a vital resource to shape a very important part of your company.

First there is the benefit of higher productivity, because the developer can just configure, install and test everything he needs to on his local machine. He may need certain software, helper tools or unusual configurations to experiment with certain aspects of his software (for example run his software on an older version of a OS or with older drivers/SDK).

Second there is the (in my opinion even bigger) benefit of showing your developers how you value them. You show them that you trust them with their own machine - you treat your developers like responsible IT-savy people who can administer their own machine without a babysitter. (In many companies where devs don't get local admin, they will have to ask tech-support or security for every installation/configuration they need. And in many cases these tech-support people know less about the software than your senior lead developer, but they still have to beg for things they simply needs to do their work, which can be very frustrating.)

Answer 5

In my career, with rather small companies (less than 100 people), we always had local admin rights. We either have real desktop machines which are maintained by IT, but got the rights, or we were allowed to have virtual machines of all sorts that we completely managed by our own.

If we had not local admin access, we would try all sorts of bad "solutions" which, as in your case, leads to less security. This is one of those cases, that restrictions actually lead to the opposite of their intention.

Answer 6

In a rather small department of a larger organization (~100 in department, ~3500 in full organization) we chose an in the middle solution:

• sysadmins had 2 accounts, one (non administrator even for the local machine) that was used for non administative tasks (mail, document edition, etc.) and one with AD administrator priviledges that was supposed to be only used for AD administration
• all other users had only one single non administrator account
• devs (and some power users) were provided a local account with local machine administrator privileges. It was supposed to be seldom used when local administration was required.

Refusing administrator rights to devs will be a cause of loss of productivity, and that has an immediate cost for any organization. The choice of granting admin privileges on the local machine to the primary account or to a secondary account should depend on the frequency of administrator operation:

• If more than several times a day, I would advise using the primary account.
• If less than once a week, I would use a secondary account.

Choose your own if you are in between...

Answer 7

In my experience working for larger organizations, it is absolutely not common for developers to have full rights to anything other than development specific resources.

It seems like your organization is on the border of small and large, so...

It sounds like it's time for your organization to develop some more mature development practices.

To be fair, this kind of a change isn't something operations groups should surprise development teams with, like it seems was done in your case.

Security and developer productivity need not oppose each other for your company. You can avoid this clash altogether by performing your development activities on a network that doesn't have access to resources on your core business network.

You aren't doing development against your production assets anyway, right?

If you are, you shouldn't be - it introduces a significant risk to your assets, particularly to their availability.

Much better practice is to have an entire development environment setup that replicates key portions of functionality and data sets (without exposing something like private information about real individuals in your company). This replicated environment makes the separation fairly simple. Your developers need full control of machines in this development environment. They do not need full control of assets outside of the development environment.

There are a number of ways to implement a separate development environment:

• Completely separate hardware (workstations, servers, network devices, etc.), connected to the internet or not
• Virtualized environments (including virtual networking); hosted on your hardware or with a cloud service provider and with or without internet access
• A combination of the two approaches above

You can also implement some kind of bridge (if you're not already using a service of some sort already) for any sharing you need to do in and out of the development environment.

Development environments should be protected like most networks. Don't just throw all your code and development assets online without some thought to access control or basic security measures.

I've also seen some places take this one step further and write all of their code in one environment then build/deploy it all to another completely separate environment for integration testing.

Answer 8

First of all you need to learn that it does not matter what "is common" or "typical" because: typically such situations are handled horribly. You are making the best case for this statement.

If local admin access is needed for a person (be it a contractor or an employee) then it is the obligation of the security team/person - whoever is in charge of that particular area - to find a solution. There are manifold solutions: creating an isolated VLAN, virtual machines and others were named here.

It does not make any sense to inquire upon the setup of other organizations just to hear "we also have admin rights on our machines". You won't find an infrastructure that is exactly the same as yours. The only thing that matters is, that the security team/person plans a secure solution that is then implemented by the IT deparment in this particular organization.

If the solution that has been implemented does not work properly and is therefore still rendering you unable to work, bring it up with the security team/person again. If this does not work, bring it up to your boss or your contractee.

What you are doing right now is burning money and nothing else. If the other participants in this game have not figured this out by now it is bad. But it is good if you do.

Answer 9

This fundamentally depends on context, and in particular on your threat model.

In some organisations, it's common to give developers complete control over their development workstation, to the point of enabling them to install their own OS on it.

In some organisations, all development must be done in an airgapped environment, that no electronic devices can be taken into or out of.

Most organisations fall somewhere between these two extremes. The more locked down the development environment, the less productive your developers will be, and the more likely you are to lose your best talent. Your organisation need to assess the likelihood and impact of a compromised developer workstation, and how much they're willing to reduce developer productivity to mitigate this risk.

Answer 10

The problem you actually have is competent IT are attempting to enforce a boneheaded rule. You really only have one choice, give developers effective admin access.

I keep seeing the same advice being repeated over and over again, that boils down to a second machine that the developer has admin but no internet. If you want to have swiss-cheese security that's the way to go. The lists of software installed on a typical developer's computer are usually longer than a screen. Many of these have only one option for check for updates--internet. You can't patch them via WSU because WSU doesn't know they exist.

Here's what the arguments don't understand: breaching the developer's personal accounts isn't a launching point; it's the jackpot. There is no reason to go for admin from there. The breacher has capacity to modify the codebade to insert backdoors. Gaining admin on the developer's box isn't that much more interesting.

What are you defending against when you want to deny admin? Somebody accessing the codebase? No. Somebody using it as a launching point? If your production LAN isn't protected from your dev boxes you're doing something wrong. The developers installing stuff they shouldn't? No. The dev has a compiler and runs code output by the compiler. This might as well be definition of running unapproved software.

I've heard many many stories of the policy being the devs don't get admin, but the practice of IT looking the other way while the devs overthrew the security policy. I've heard many more of the IT never even finding out. I've heard some of the dev's manager telling the devs to bypass the security checks.

Sooner or later, organizations learn to just give the developers admin. Most of the ones that don't probably end up having done so without actually knowing it.

It's far wiser to just give devs local admin on one box connected to the internet and to the local domain and be prepared to deal with whatever the consequences may be. Protect production instead. There are fewer people who should be accessing production at a high level of privilege, therefore the lockdown is easier, and competent organizations learn to do that.

But suddenly taking away admin like this almost always results in loss of the more important devs. You don't want that.

Since you want to talk about Windows sites, there is one anecdote that outweighs most people's data. Microsoft gives its devs local admin. The maker of Windows has concluded there is insufficient benefit to not giving devs admin to make it worthwhile. Therefore, you should do the same.

Answer 11

I've seen two approaches that work.

1. Give developers admin access to their machines. This is the easiest and most common approach. It is usually the best choice
2. Create a team in the organisation whose whole Job is to ensure that developers can work without admin access. This team will usually be 3-4 people. You will find that developer's hardware requirements increase dramatically as you'll be using containers and or VMs, so budget for buying new hardware for all developers. When you roll out, start with a team of early adopters, then gradually move all of your developers to a machine without admin access. This process will take at least six months.

If you do what your company is doing now then your developers will put up with it for a month or so then start looking for new jobs.

Answer 12

I worked for some time for a company that really believes in security (or so they think).

Every once in a while they would organize a social event, like playing bowling. Joining was free, but you had to add your name to a list in an Excel file, placed in a shared folder. That folder was dedicated to social events, nothing else.

So, you want to play bowling? You want to add your name to that list? Ohhhhhhhhhh, dear... It's not like they can let everybody edit that file, can they? You have to ask for the appropriate permissions.

This is the procedure:

• Open the company's site
• Find the section with some modules ready to be filled in
• Find and download the document called "Release Sheet"
• Print it
• Fill it in with your request and sign it
• Hand it out to the secretary
• The secretary will take all these requests to the manager in the morning of the following day
• Sooner or later the manager will sign it
• The secretary will bring it back to you
• At this point you can scan it
• Open the site used by the IT to handle tickets
• Create a ticket describing (again) what you need, and attach the scanned Release Sheet. Don't forget to set the urgency, from one hour to two weeks.
• Eventually the IT will do it (hopefully)

On average, it would take 3-4 days to get it done. In some cases, weeks. Really efficient, eh? Hey, you asked for access to a certain folder but forgot to mention the subfolder? HA! You've won another round! And, guess what? Since they were following some QA process, they were organizing documents in a lot of different folders. When a new colleague came, he could easily spend weeks trying to get all the permissions he needed.

Now.

• Do you think the managers bothered to check what they were signing? Certainly not. They recognized the Release Sheet, and that was it.
• Do you think the secretaries were checking much more? Maybe they tried, but can they really understand the implications of giving me read/write permission on a certain folder on a certain machine? Certainly not.
• Do you think the IT gave a damn about the urgency? Certainly not.

So, what did this approach lead to? That if you wanted to steal everything the company ever made, you just had to bring in a USB drive and connect it to your PC. No access to that "Confidential_Documents" folder? Just ask for it, they will sign it. And if it's urgent? "Hi, I need that document but I can't access it, can you give me your password?"

So, this "security model" was incredibly slow, clunky and frustrating, and it didn't protect their properties at all, but at least no one could easily mess with the participants to the bowling event (obligatory xkcd).

Please don't be that company. As others have said: don't ask whether it's common (it is), just ask whether it makes sense. And the answer is: no, it doesn't, unless your company likes burning money.

Answer 13

Yes and no - our senior devs do have a separate admin account that permits them to elevate when needed and install applications/updates. They are not permitted to login to the computer with the account though. Their admin account also permits them admin access to regular dev computers to provide quicker support than going through the IT team.

This is all combined with an application white/blacklist, strong password policies, removable device prohibition, gateway proxies, DLP policies, stringent AV rules and more. Their machines are routinely audited and the IT team visibility is high.

Personally, I'd prefer for the devs to not have local admin access. We could investigate the app(s) that needs UAC (find out the folders, regkeys etc that it needs) and mitigate the UAC prompt but that takes time and research and not all companies have the resources to do this. So, we meet them half way and expect two-way trust. We also use multiple corporate products to enforce a multitude of rules so there is some relief in that.

Answer 14

We solved this problem by using a Virtual machine.

Every developer has an normals user account without any admin rights. Inside that user account theres a virtual machine without any internet access. Inside of the virtual machine the developer can run his application with admin rights.

That way we can separate internet access and important data from the use of admin rights while still obtaining a way to run the necessary programs in an enclosed environment.

Answer 15

I'm in the same boat as your software developers. Our company recently went from workstations with admin access to virtual machines without. It was severely impacting our workflow so much that I times I found myself doing nothing but reading articles for the IT department to run something as admin for me.

The thing that management came up with was a two virtual machine approach.

One of our virtual machines was a basic business machine with Email, Web Access, and Microsoft Suite. This satisfied the need to communicate.

The other virtual machine had local admin rights, but was disconnected from the Internet entirely. That way, we could not download anything on that machine. (Although we could still download it from the other and copy the download over..) We still got access to internal sites and whitelisted a couple of things visual studio uses (Nuget, Symbols, etc..)

That approach left the IT department satisfied in terms of their security, while also giving us our admin access back.

The only negative thing is that we cannot use our dual monitors for just one machine since we needed each machine to be on their own monitor, but we usually just used one screen for code and the other for web browsing anyway.

Answer 16

Short answer: Yes, it is common to have local admin access to selected groups, such as developers or IT admins. Basically, people whose day job is a lot easier with admin access while the usual office worker would need it at most once a month and typically much less than that.

Long answer: It depends...

For the general user population, you don't need to run a full risk analysis to understand that admin access has a lot of potential for things going wrong and little advantages to offset that risk.

However, for developers (and a few other groups), a risk analysis is definitely warranted, and a proper decision on the matter based on the facts, circumstances, risk appetite and threat situation of the company is asked for. Pointing to "best practice" and doing a blanked one-size-fits-all move is a cop-out typically caused by the person(s) responsible for information security lacking the time and/or knowledge to run the numbers and come up with a risk treatment decision based on facts.

That doesn't necessarily mean that they are wrong. A full analysis could very well lead to the same conclusion.

At the point you are, from what you write, that is an unknown. You could ask for a proper risk analysis to be done, adding your expert knowledge to the cost of mitigation side of the equation, putting into numbers the lost productivity and other effects of the current measure. This needs to be weighed against the risk that the information security people identify.

There are also other measures that are related. One typical solution that I sometimes recommend (I'm an Information Security Architect by profession, so I get asked these questions on a regular basis) is to seperate the developer network from the ordinary office network to contain the higher-risk area. Harden the developer machines sufficiently and insist on local firewalls and up-to-date virus protection and you are fine against typical attack scenarios. If your company has some outside exposure, you might also add in additional awareness training for developers so they don't fall prey so easily to targeted attacks.

I've personally supervised developer environments of both kinds, and with a little effort both can be made to work well. Just pulling the plug on an established way of work was handling it badly and the backlash you were a part of was to be expected. But what's done is done and it is probably smart to not focus on that and look towards the future.

Answer 17

Segregate Your Networks

You should have relatively isolated environments for development, testing, production, and business. This allows your devs to have privileges where they need them.

Proper segregation prevents unauthorized changes, restricts the spread of malware, and impedes the exfiltration of data.

What Happens Where?

Development

The development network is where coding takes places. Developers should have administrative rights in case they want to test code snippets or run something without packaging it for deployment to test/prod.

Computers run IDEs, source repositories, and prerequisite apps/frameworks for your apps. A dedicated collaboration tool or other dev-specific apps are reasonable.

Testing

The testing network is where compiled, ready-to-ship code is tested. Developers may have admin rights, but regular system admins should be deploying applications.

Deployments should reflect what the admins will maintain in production for internal apps. They should be customer-ready packages for external apps (including install wizard and digital signatures, albeit using a separate signature for testing purposes to prevent accident releases).

Developers often need system logs and debug access, and these are the only reasons they should have admin rights. They should not be involved with installation, configuration, and testing unless absolutely necessary.

Production

The production network is where you provide services to clients and partners. Since a formal deployment process should exist, there is no reason for it to connect to your dev/test networks.

To minimize risks of internet-borne malware and accidental changes, accounts from the dev/test/business networks should have no access to production if possible, which translates to limited permissions with occasional arguments in practice.

Ideally, this network would be completely isolated, but in practice this is impossible in a world where production servers must interface with systems for sales, billing, scheduling, netops, and project management. Get as close to the ideal as you can; it's really all we can do.

Business

This is the primary communications network for the enterprise.

Email, web browsing, and partner connectivity all bring a host of risks. Your development, testing, and production networks should be isolated from these risks to the maximum extent possible.

Details, Details, Details

It is possible that your organization went overboard. It is easier to swing the pendulum all the way over than to deal with the myriad details essential to a flexible, secure network architecture.

The developers can have admin access to their machines, at minimal risk to the enterprise, if:

1. There are separate, unprivileged accounts for internet access
2. Unique accounts are used in each environment
3. Restrictive firewall rules/ACLs exist between environments
4. Standard security measures such as firewall, web proxy, IDS/IPS, etc are in place

Your developers will need four accounts:

• Unprivileged dev account to access resources on the internet (if they do not want to hop back and forth from the business network, which is onerous)
• Privileged dev account to configure workstation and test code
• Privileged test account to debug applications
• Unprivileged business account for email, web, intranet

If you have developers do some validation or QA work, they may also need unprivileged accounts in the test environment.

Developers should have no access to the production network and no administrative privileges on the business network. If this impossible for the moment, then those roles should be separated or else a rigorous change control process should be put in place.

Answer 18

Despite MS-Windows NT having been a multi-user system system since its inception, its not really easy to operate it in such a manner, and developers (including Micosoft's) still tend to ignore the idea of privilege seperation. This kind of access control is poorly documented, tends not to feature in training, often difficult to access via the UI, hard to audit, lack of patterns/tools for applying the seperation....

In fairness, even on Unix/Linux systems, I see a lot of developers failing to use privilege separation appropriately both for real users and for services. But on any platform, placing barriers in the way of implementors seperating privileges is even more counter-productive for security than giving them full (local) admin privileges.

On the other hand, while I know little about developing on MS-Windows, I do find it surprising that local-admin privilege is required to run Visual Studio. And if the only reason you need admin access is for stopping/starting services or reconfiguring them then I don't have a lot of sympathy for you - possible to provide this facility to designated users without giving them local admin. One of the big changes in IIS7 was the delegated admin capability. And its always been easy to delegate reconfig of Apache, MySQL and PHP.

there was short notice of when the local admin access was removed

It sounds like the issue is the Security team aspiring to a level of competence they are unable to deliver (this, in my experience, is very common). They shouldn't have imposed a policy change without doing a proper impact assessment and considering mitigations for any harm to productivity/security.

We have at least 2 major antivirus programs on all workstations

That's a very naive approach to protecting the integrity of these systems and paints a picture of what you are having to deal with.

there doesn't seem to be much for alternatives out there

Getting into a discussion about that probably isn't going to be very productive at this point.

Overall it sounds as if you are in competition with your local security team. They don't understand what you need to do your job, you don't understand how to meet their objectives. And it seems like neither side is willing to negotiate. No off-the-shelf tool is going to fix that.

Answer 19

It is only typical to have local admin access denied to devs in companies where either the devs are so useless/malicious they abuse those privileges, or where the "IT and Security" department is run by clueless knee-jerk idiots who view everyone not in their inner circle as an obvious security threat out to make them look bad.

Considering your "IT and Security" department also mandates two anti-virus programs when Windows comes with a perfectly good free one, I'm pretty sure you can determine where the problem is in your organisation, and work from there.