How do you handle high privilege AD group membership?

  • Last Post 24 June 2017
ahobbs posted this 16 June 2017

Hey list
We had an audit and it was highlighted that we shouldn't have our admin accounts as members of the domain administrators group permanently. We have 8 users within our AD environment consisting of 20,000 user accounts and they want us reduce this to 3.
The suggestions are to implement Microsoft PAM or look at a 3rd Party solution such as CyberArk, both have cost and overheads associated with it.
How do you all manage membership of high privilege groups such as Domain Admins? we use role based access hence why 8 users are members of the Domain Admins group at present. 
Any advice or thoughts appreciated.

Order By: Standard | Newest | Votes
webster posted this 16 June 2017

To me, 8 is not bad. I would be stunned if I found a place with only 8 domain admins! I usually deal with places with many 10s or hundreds of DA accounts (most of them service







ahedge posted this 16 June 2017

I would tell them Auditors to “stuff it.”  8 accounts in the Domain Admins group in an environment your size is not unreasonable.  Spending $100,000 or more just to reduce

that from 8 to 3 accounts is probably not the best use of your security dollars.


Not saying that CyberArk or BeyondTrust type solutions don’t have value, but my driver would not be this issue.


The bigger question that you might ask is “where is the Domain Admins group used?”  If you use it everywhere that would be a bigger risk then the number of members that you

have in the group.



Arthur J. Hedge III CISSP

Castle Ventures Corporation





SmitaCarneiro posted this 16 June 2017

Agree with Arthur, 8 is not bad in an environment of your size.


Smita Carneiro, GCWN

Active Directory Systems Engineer

IT Security and Policy

Ross Enterprise Center

3495 Kent Avenue, Suite 100

West Lafayette, IN 47906



marcuscoh posted this 16 June 2017

If we're speaking strictly numbers, I would agree with the sentiment that 8 is good in contrast to 20000. However, you haven't defined the characteristics of those 8 accounts and what they're being used for. I think in this case, context matters.


bpffa posted this 16 June 2017

Do you leverage Domain Admin privileges regularly?  If not keep the group empty and elevate in as needed.


I use the Restricted Groups features on a GPO applied directly to the Domain Controller OU to maintain strict membership. The only permanent members are failsafe

accounts that are stored & password rotated by Thycotic.


Our dedicated Domain Admin accounts are members of the Administrators group, regulated by Restricted Groups in GPO and can elevate into Domain Admin membership

as needed. I also limit the dedicated Domain Admins to only log onto DC’s and the DC tools server (as DC’s are Core installs) via Authentication Silos.


Group Policy refresh is 5 minutes on DC’s so you need to log in quickly after the group add.


I also leverage log monitoring to alert on group add into Domain/Enterprise and various other groups. I configured the monitoring to trigger on the group SID

rather than samaccountname as well.


So far this passes our Audit and the only real “cost” is a log monitoring tool but there are many good free options out there (logstash/kibana & greylog)





andrewcace posted this 16 June 2017

Another thing to consider is the usage of your DA accounts. Are they dedicated to domain admin purposes and are restricted by GPO into only logging into domain controllers?

You might be able to show the auditors that you have mitigated the risk by limiting how the DA accounts may be used.





jheaton posted this 16 June 2017

We’re in that situation Webster.  We have a lot of service accounts that are DA.  Most likely, it’s just because no one has taken the time to figure out the actual

rights needed, but I know there have been a couple that I just wasn’t able to reduce that access for.



webster posted this 16 June 2017

I would also be concerned about accounts (Users and Groups) that have AdminSDHolder set.


Just did an ADMT migration to a new 2016 Forest but Exchange stayed in the old Forest. When they went to link the accounts in the new Forest to Exchange in the old Forest,

it was a no-go because they had 183 accounts that were protected with AdminSDHolder. Found a PoSH script that reset that flag and allowed them to finish their linking. Turns out many years ago, a lazy admin got tired of the support calls and made Domain Users

a member of Domain Admins.






ahobbs posted this 16 June 2017

Hi Brendan
I like your solution to managing Domain Admins. I think if you were to ask any of the 8 members of the DA group they use it all the time but I suspect your solution could be adapted in our environment.
We've got SCOM alerts for when people are added/removed, to be honest we all thought their recommended was a bit strong..
I assume every time you want your privileges elevated you assign them by using one of the failsafe accounts?


a-ko posted this 16 June 2017

I think his solution is a little bit on the extreme side.


You will always have some need for “Domain Admin” privileges somewhere. And no attack on a Windows Domain infrastructure leverages the fact that a particular account is a member

of that group.


  • Audit where your DA privileges are used. A significantly better and cheaper investment is to have special privileged-access-only workstations that are used when DA is needed.

    • This helps to prevent credentials from being harvested for later use

    • Ensure these DA/Privileged workstations do not share the same admin password as general desktops in the environment.

    • Ensure that no regular workstation admin can log in to the privileged workstation

    • Ensure that policies are set to prevent PTH-like attacks.

  • Check the boxes that say the following for the DA accounts:

    • This account supports AES256

    • This account is sensitive and cannot be delegated

  • Use smart cards for DAs

  • Reduce the # of trusted root certificates in the certificate store. Only include the bare minimum of what you need.

  • Have a robust PKI infrastructure in place to augment authentication (Kerberos supports X.509 certs, etc.)

  • Use Windows 10 and Credential Guard, Device guard on your admin workstations (and probably your user workstations too if you can manage it)

  • Aggressively patch your DCs and prioritize their patching over other infrastructure you manage

  • Implement the MS Red forest model with AD2016 + MIM2016


Extreme cases of needing to rotate passwords and such just aren’t necessary, especially when the passwords are limitedly used in the environment. It’s pointless and creates needless

hardship, and in the case of below, makes you spend money on tools that do this.


A randomly generated, non-expiring “recovery password” that is of sufficient length that is ONLY used on the Domain Controllers when “shit hits the fan” can be the same password

until the end of time. Because your only risk model here is compromise of the Domain Controller through other means. The password will only ever sit in memory on the DC, and it will only live within the ntds.dit file on the DC (and possibly the credential

cache otherwise) ; so the only place someone has to compromise to get that password is a DC itself…





darren posted this 16 June 2017

This is an interesting topic, primarily because I think too much emphasis is often placed on protecting Domain Admins (which I do think is important) and not enough on privileged access in general. I suppose auditors will catch up eventually,

but I agree 100% that the important question to ask is, “where is privileged access granted?” rather than, who is in the privileged access groups. To that end, I’m seeing a lot more “red team” tools that take advantage of loose or default AD infrastructure

delegations to walk their way to privileged access. It’s only a matter of time before these become more widely exploited, given what I know to be fairly lax  delegation of most AD environments. Have a look these two recent blog posts for a sense of it. I encourage

everyone to download and run Bloodhound, as an example, in your environments to see how bad it is (that is, if your infosec team lets you






ken posted this 17 June 2017

The absolute number of DA accounts is, well, not all that important in the grand scheme of things.


Suggest you speak to your security folk, because the real questions are around what controls you have in place (I don’t know what framework they have in-place), but typically there’s a hierarchy

of controls (deterrent, preventative, containment, detective etc.) and the combination of whatever controls you have in place should bring risks you face “into appetite”. I know this all sounds like high-level “fluff”, but it’s the only way to keep a lid on

these issues sustainably – otherwise you’ll always be chasing your tail with audit findings. Happy to talk through the process of deriving a posture off-line (unless people want to discuss it here)


We have CyberArk in-place (as a default PAM solution – plus lots of others to cater for all the other esoteric platforms we have), so every request to access

a DA privilege is logged. Also, our design is not to allow individuals to have DA access – when you request DA access you’re granted access to use a proxy account. This helps with the overall account lifecycle process – if you leave or move to another division,

we don’t need to worry as much about revoking your access to every resource, because your personal account never had access to any privileged resources.


At the same time as having a PAM preventative control, we’ve also had to uplift our detective controls (auditing access, revalidating access), to comply

with all the various regulatory requirements out there. It’s that combination of:

  1. Understanding the environment
  2. Clamping down on 90% of access (needs organisational buy-in)

That allows the other 10% of access to be managed ‘by exception’






bobfree posted this 21 June 2017

We have 4 DA/EA level folks, none are permanent but elevate in a controlled fashion when necessary which isn’t that often. 
We got by with 3 for many, many years and recently added a 4th as we expanded Privileged Access services in our group. I figured if joe could run Ford with 3 EA level folks we could get there, and we did in the Server 2003 era. It was a battle at first but well worth it.
Today, our AD Admin accounts are denied login to anything but Tier 0 systems. No one outside our team has access to those systems.
We started out with EnterpriseAdministator back in the NT days (yea, I was a marshall :-D ) and have made heavy use of delegations ever since. We moved to NetIQ with their acquisition of MissionCritical, users hated it and ended up moving to ActiveRoles.    IMO, the question is "what do you REALLY need to be a DA or EA for that you can't do within our delegation framework."  There aren't a whole lot of answers besides the obvious ones. For those we use JIT.
 Environment is 30K + active users. 6 forests.


PARRIS posted this 21 June 2017

The audit requirement is usually that your day to day logons should not have permanent DA access, this makes perfect sense and minimises all kinds of risks.

Imagine if you had malware in an email - instant DA, does not bear thinking about.

In our organisation we have separate named DA accounts for the resources that need them.

This meets the audit requirement, but best practice is to build on this further and look at other solutions.



Mark Parris


Cloud | Identity | Security


MVP Enterprise Mobility | MCM Directory Services

Mobile: +44

7801 690596

E-mail: mark@xxxxxxxxxxxxxxxx


Twitter | Blog | LinkedIn | Skype


bobfree posted this 21 June 2017

>The audit requirement is usually that your day to day logons should not have permanent DA access, 
IMO it should be "that your day to day logons should not have any administrative access whatsoever". 
We've had separate accounts for admins since the 80's so I guess I kind of assumed it's common practice everywhere by now. 


duykato posted this 21 June 2017

In our environment all Domain Admins are smart carded and all changes are performed via a buddy system. The person executing the changes focuses on just that while the buddy handles all the monitors (putting domain controllers into downtime to reduce noise to the other Domain Admins) and sends out communications to change management and other team members.
Also to log onto DCs you must use a specific laptop assigned to each DA. Kinda over kill but something we are experimenting with.
On Jun 21, 2017, at 12:03 PM, Bob Free <> wrote:
>The audit requirement is usually that your day to day logons should not have permanent DA access, 
IMO it should be "that your day to day logons should not have any administrative access whatsoever". 
We've had separate accounts for admins since the 80's so I guess I kind of assumed it's common practice everywhere by now. 


PARRIS posted this 21 June 2017

I concur, and probably over simplified the statement.



Mark Parris


Cloud | Identity | Security


MVP Enterprise Mobility | MCM Directory Services

Mobile: +44

7801 690596

E-mail: mark@xxxxxxxxxxxxxxxx


Twitter | Blog | LinkedIn | Skype


kurtbuff posted this 22 June 2017

Are you referring to PAWs?

I'm looking at implementing that with my next laptop.



ken posted this 22 June 2017

Is anyone using one of the PAM products out there like CyberArk, IBM SPIM, OPAM, BeyondTrust etc.?



bobfree posted this 22 June 2017

Yes. Across the enterprise. Windows/*NIX servers and end user systems. Privileged access on those platforms is strictly managed, monitored and recorded
Windows admins no longer have permanent administrative access. They either need need to elevate with PBW or go through a process to check out a proxy account. *NIX/sudo is strictly managed with PBUL. 
End user systems also use a similar system with PBW but can't elevate to full Admin
Such entitlements are based on AD groups that are managed in an automated, centralized IAM system and a rather intricate system of GPOs.


ken posted this 23 June 2017

Similar here. Not sure I want to divulge what we use on a public forum, but definitely with all the various regulatory requirements out there requiring not only a process, but proof the process is

working and comprehensive, using some of these third party tools is almost essential now.


Happy to discuss offline with those who are interested.



a-ko posted this 23 June 2017

While PAM solutions such as this defeat the ‘elevated all day err day’ problem, there are still elevation attacks that can occur with these solutions.


Attackers realistically only need a very minute amount of time to successfully perform an attack, and while these tools shrink this window, they aren’t wholly eliminated.


  1. Combine these tools with common sense management. PAWs are incredibly important for this task. Don’t just implement a PAM solution and go “well, you can still do this on your everyday workstation because now we’ve

    spent 6-figures on some fancy tool where the marketing documents tell us this stops the hackers.”

  2. Understand HOW attackers can breach your environment and HOW they can get around.

    1. Maybe you use a single PAM-managed group to control administrative access for convenience. All it takes is a single compromise of the user’s NTLM hash or Kerberos ticket to perform PTH or PTT attacks.

    2. Domain Admins is usually a “single group”, by design, and so it is ESPECIALLY vulnerable to this.

  3. Many PAM solutions control group membership, but don’t control token lifetime settings. An attacker just needs to compromise a Kerberos TGT with a PAC that says you’re a member of that group.

    1. There are GPOs that can control whether a server performs PAC validation, but this requires additional validation between the server and the Domain Controller.

    2. TGTs are good for 10 hours and renewable up to 7 days by default. Your PAM solution likely isn’t controlling that, and is controlling group membership only (which gets thrown into the PAC).

  4. The above attacks don’t rely on the password, nor care about the password.

  5. I doubt you’re PAM managing shared domain service accounts with elevated access (Splunk, Vulnerability scanner credentials, anyone?)


These tools aren’t silver bullets, and again; there are a lot of cheaper ways to solve attacks than dropping money on PAM solutions.


In fact, I’d wager the way most of these tools are implemented they provide a false sense of security that now that you somehow control authorization more tightly you can ignore

the rest of the controls that you REALLY, STRONGLY, IDEALLY, SHOULD implement (things like membership in the Protected Users group, etc.)


-Mike Cramer





ken posted this 24 June 2017

These are all good points. We don’t use PAW per se, as we have a dedicated physical network/hosting environment for administrative tools. It used to host VDI infrastructure (for generic RDP/SSH/etc.

access), but now we enter (mostly) via the PAM solution.


Pass-the-hash is probably less relevant, as the PAM product changes the account password once the user’s session is done – i.e. in our setup, users just have a regular account that they use to login

to the PAM solution. They use a proxy account to do the admin stuff (whether DA or not). When the session is done, the proxy account’s password is reset.


Being in a banking environment, whilst Domain Admins is reasonably important, most of our most critical apps don’t really care (or know much) about Active Directory – they’re designed to be IDM-platform

agnostic, and either implement their own IDM store, or can be pointed to a subset of users in an LDAP directory/directories. Being DA doesn’t give you any privileges within those apps – you’d need to compromise a separate account that does have access.


I’d certainly disagree that an enterprise PAM solution is more expensive than the alternatives, if you work in an enterprise and particularly if you work in a regulated environment where you need

to both provide accurate financial data, but prove that the data is accurate. Technically other solutions may be superior, but the “proving” part is really hard with home-grown solutions.


In terms of “service accounts” – these are mostly not managed by PAM, but our privileged account standard still mandates that all privileged accounts (whether interactive user accounts, or service

accounts) need to have the enterprise approved preventative or detective controls wrapped around their use. So we have other tools to manage/audit their usage.


But I agree – no technology is a “silver bullet”, whether it be for privileged accounts, or anything else. Otherwise we wouldn’t have hacks, outages, coding errors/bugs and just about anything else

that bedevils IT. The solution is to have mature frameworks and architectures that ensure you understand “what matters most” and drive the right standards/policies for the business. From there, the correct mix of processes and products can be implemented to

ensure that you’re protecting “what matters most” against the threats your business faces.