Showing results for 
Search instead for 
Did you mean: 
Create Post

Who Watches the Watcher? Admin Privileges are a Little Scary, but Don’t Have to Be

Product Manager

I was watching a recent webcast titled, “Protecting AD Domain Admins with Logon Restrictions and Windows Security Log” with Randy Franklin Smith where he talked (and demonstrated) at length techniques for protecting and keeping an eye on admin credential usage. As he rightfully pointed out, no matter how many policies and compensating controls you put into place, at some point you really are trusting your fellow IT admins to do their job—but not more—with the level of access we grant and entrust in them.

However, there’s a huge catch 22—as an IT admin I want to know you trust me to do my job, but I also have a level of access that could really do some damage (like the San Francisco admin that changed critical  device passwords before he left). On top of that, tools that help me and my fellow admins do my job can be turned into tools that help attackers access my network, like the jump box in Randy’s example from the webcast.

Now that I’ve got you all paranoid about your fellow admins (which is part of my job responsibilities as a security person), let’s talk techniques. The name of the game is: “trust, but verify.”

  1. Separation of duties: a classic technique which really sets you up for success down the road. Use dedicated domain admin/root access accounts separate from your normal everyday logon. In addition, use jump boxes and portals rather than flat out providing remote access to sensitive resources.
  2. Change management: our recent survey of federal IT admins showed that the more senior you are, the more you crave change management. Use maintenance windows, create and enforce change approval processes, and leave a “paper” trail of what’s changing.
  3. Monitor, monitor, monitor: here’s your opportunity to “verify.” You’ve got event and system logs, use them! Watch for potential misuse of your separation of duties (accidental OR malicious), unexpected access to your privileged accounts, maintenance outside of expected windows, and changes performed that don’t follow procedure.

The age old battle of security vs. ease-of-use wages on, but in the real world, it’s crucial to find a middle ground that helps us get our jobs done, but still respects the risks at hand.

How do you handle the challenge of dealing with admin privileges in your environment?

Recommended Resources

REVIEW - UltimateWindowsSecurity Review of Log & Event Manager by Randy Franklin Smith -

VIDEO – Actively Defending Your Network with SolarWinds Log & Event Manager


Level 13

This is certainly a challenge! I've had some success using log monitoring to track certain types of changes, but ultimately, if someone has the access, knowledge and will to do real damage, the most you can hope for is to detect it quickly.

Level 15

True.  I have done a fair amount of research and the best practices that I have arrived at is to assign each Admin two sets of credentials.  One that is a "normal" user for their day-to-day work and then an "Admin" account for their required administrative duties.  This is similar to the user/root found in Unix systems and the operator/Sysadmin in AS/400. 

The benefit of course is accountability but that only goes if the person is not malicious or hopefully like clubjuggle‌ stated.  detect it quickly.


The separate "elevated privilege" account is a good thing.  Similarly is the use of sudo in unix environments.

It allows root level or other user level access while logging activity for audit purposes.

Your 3 points are ones I am a firm believer/practitioner of.  While I may have the rights to change certain system parameters on certain servers, it is the job function of the windows server admins to do so.  That way they are aware of any changes and potential conflicts down the road is a prime example...

Level 14

Separation of duties and monitor turnover of personnel so that accounts are adjusted/added/deleted accordingly.  Cross-training will catch a lot too.

Level 17

Nice Bullet Points!

Product Manager
Product Manager

Turnover is another excellent point. I've seen some environments where the admins really had a "get it done at any cost" kind of mindset and ended up with services, scheduled tasks, and all kinds of mess configured under someone's account that actually prevented them from even changing the password on the account for fear something would go down. Scary.

Product Manager
Product Manager

Props to ubuntu for really pushing the sudo (or "runas" for a MS analog) process more handily onto the linux world, even if their audience didn't quite understand why it was happening.

Level 13

Separate the "Powers", Log the activity, Restrict who can do what.  Trust your fellow IT Admin -- Not as one day he or she can turn on you and you will be up a creek without a paddle!

Level 8

Good stuff here. The only thing missing is: Consequences.

Granted, this probably isn't the place for management techniques... but without appropriate consequences, you can monitor and rule all day to no real effect.

Level 13

As a former auditor, I think the challenge is that you can only restrict so much. Someone has to have Domain Admin rights, for example, and there's always the change they could use those powers for evil. In some cases, the best you can do is have mitigating controls in place to detect rogue activity quickly, and make sure you are prepared to contain and reverse any damage if necessary.

Of course, you should still separate duties and restrict access the best wherever possible, as this aids in detection of rogue activity.


Bottom line is at some point some people have to be "trusted."  So trust but verify then.  Also background investigations don't hurt either... lol!  The ramifications of what happened recently at the OPM with not encrypting and allowing the data loose they did may be felt for generations to come here in the US.  I hope the FBI has some idea who really got all of that information.  The damage is done.

Level 15

Oddly enough, these features are missing from Orion NPM & NCM itself.
Most software products do not have a true Admin function, as per my post 4 years ago here:

Extreme Disappointment in NCM 7.0 Integration Configuration

I'd like to give some users "admin" access, without access to add or remove users.

There needs to be an "Allow Account Management Rights" check box as well.

Level 13

I agree. I know this is a hard thing to retrofit, but it's the kind of thing that can become and audit/regulatory concern.

Level 15

We setup roles but I did not delve into the admin role.  I agree it could be beneficial to have this enhancement. 

Level 14

Hopefully, this admin is prosecuted to the fullest extent of the law.


Bottom line is the admins need to be trusted! I know some do unscrupulous things but someone needs to be able to do anything and everything. The key is to never abuse the power.

Level 12

trust, trust and more trust is really required, to be able to handle some admins who misuse the opportunity given to them and they can not handle the idea that they are being monitored.

Trust! But Verify! Watch the Watcher! Checks & Balances! Monitor the Monitor. Fox Watching the Hen House! War Games!!!

All of these apply in security. Always know what is going on, what changes are made in key sensitive areas.

The First Rule that I follow and always put into application is... "I cannot be trusted!" All alerting, monitoring, reporting is delivered to me, my management, as well as service owners of the technologies that I am monitoring. Transparency and accountability all at once.