Over a million developers have joined DZone.

When to Grant Domain Admin Permissions

· DevOps Zone

The DevOps zone is brought to you in partnership with Sonatype Nexus. The Nexus suite helps scale your DevOps delivery with continuous component intelligence integrated into development tools, including Eclipse, IntelliJ, Jenkins, Bamboo, SonarQube and more. Schedule a demo today

So I’m sure we’ve all had to contemplate this at some point in our development lifetime – when is it appropriate to grant developers and architects the key to the domain? 

There are quite a range of developers and software engineers out there, and for various reasons they do, from time to time, require elevated permissions to do their work.

Recently a situation occurred on a friend’s project where one of the team’s senior members needed Domain Admin rights to install and configure some off-the-shelf enterprise software in a combined development/test environment. 

Now, as long time readers of this blog will know, I’m generally uncomfortable with developers and engineers (and testers for that matter) having Domain Administration rights unless it is essential to their tasking – and even then, for a limited time. 

The temptation to not thoroughly document (or indeed, understand) the configuration due to the more relaxed (less prohibitive) nature of having administration rights can lead to larger issues and mistakes when it comes time to deploy work into a controlled environment. 

Personally, I don’t disable UAC on my local machine and instead elevate permissions when and as needed.  I do run with local Administrator permissions (from time to time), but generally I prefer to have a separate account (Rob.Admin, for example) and try to limit how often I need to use Administration rights.

Now, returning to the recent scenario – the request to be granted Domain Admin permissions was only for the duration of installing and configuring a tricky piece of enterprise software, which uses a plethora of services and certificates which do require some configuration at the domain level.  It will require a few hours of debugging and testing and verification.

It’s not something that is necessarily done right the first time (which is why it’s done in a test environment first) and shouldn’t require the time or resources from infrastructure support.  As I mentioned, this is a test environment, and the project team should be trusted to carry out the required installation and configuration – following the standards of the platform.

So now we have to request the equivalent of hand holding from system support to perform all the tasks we need, bearing in mind the main point of this exercise is to document and test an installation guide to be reviewed by system operations staff to promote to the next environment.  I can’t see the system support folks staying back after hours to help the team debug the configuration, so what benefit is there in enforcing this policy?

What do you think?  Should a team have Domain Admin rights for a development/test environment, even if it is just to test out and debug the installation and configuration of software?  Do you think this is reasonable? 

Looking forward to your thoughts (leave a comment).

The DevOps zone is brought to you in partnership with Sonatype Nexus. Use the Nexus Suite to automate your software supply chain and ensure you're using the highest quality open source components at every step of the development lifecycle. Get Nexus today

Topics:

Published at DZone with permission of Rob Sanders, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}