DevOps Zone is brought to you in partnership with:

Rob is a professional IT specialist with over 14 years of commercial expertise working for small, medium and large enterprise customers and clients as well as local, state and federal governments within Australia and internationally. Of these fourteen years, six have been served in a professional consultancy capacity, three as a project manager and eleven years in professional software engineering and architecture. Rob is a DZone MVB and is not an employee of DZone and has posted 58 posts at DZone. You can read more from them at their website. View Full User Profile

When to Grant Domain Admin Permissions

03.24.2013
| 3260 views |
  • submit to reddit

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).

Published at DZone with permission of Rob Sanders, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)