Share via

ADPoSh: Find and Fix AdminSDHolder Orphans (AdminCount)

  • Article

What exactly is an AdminSDHolder Orphan?  This occurs when a security principle/object (User, Group, Computer) in Active Directory gets removed from one of the Privileged Built-in Groups (Protected Groups) in Active Directory, whether directly or nested.

To understand this more read up on AdminCount, SDProp or AdminSDHolder topics.  In a nutshell every hour a process runs on the PDC, that looks at every object within the protected groups, that reviews the ACL on the object and validates it matches the AdminSDHolder Object.  If it does not the process will disable inheritance on the object, set the correct ACls and will set the AdminCount attribute on the Object to 1. The reason they do this is to prevent unauthorized changes to elevated accounts by lower level admins that might have control over OU’s.

AdminSDHolder:

image

AdminCount:

image

Disable Inheritance:

image

Now to the point of this blog.  SDProp does not undo this once an object gets removed from one of the groups.  Over time we find this causes confusion over which accounts are still privileged or delegated Admins aren't able to administer the objects due to the inherited Acls not being set. I also find that during Merger and Acquisition activities like Domain consolidations old privileged accounts are migrated without cleaning this up which gets confusing. The recommendation is to review the objects that have AdminCount set and see if it needs to be undone. Here is the script I use to handle this problem.

Full PowerShell Script can be found on my github: FindandFixADObjectswithStaleAdminSDHolder.ps1

The script will pull every object with AdminCount Set to 1 that is not a critical system object (do not want to change administrator or krbtgt).  It then searches in the Privileged Groups to verify if an object is no longer a member.  Creates two reports:

  • report_ADObjectswithStaleAdminCount.csv – list of stale objects
  • report_ADObjectsMembersofPrivilegedGroups.csv – mapping to which objects are members of which privileged group, also provides a date of when admincount was set.

If the .\FindandFixADObjectswithStaleAdminSDHolder.ps1 –reportonly  switch isn't used it then takes the list of stale objects and deletes the AdminCount value and using the AD PSProvider and set-acl, it enables inheritance.

I highly recommend running this script monthly or during your regular review of privileged accounts.  I hope you find this useful.

-Chad

Update:

Incase you don’t have a process around reviewing Privileged Group members on a regular bases, Here is a link to a script I borrowed and added to to help track group changes.

github: CreateADPrivilegedGroupChangeReport.ps1

What makes this different is the script looks to see if a users primary group has changed.

Resources:

Technet Magazine: Overview of AdminSDHolder, protected groups and SDPROP

Five common questions about AdminSdHolder and SDProp

Comments

  • Anonymous
    December 15, 2018
    Please check you GitHub links. They return an HTTP 404 (not found). It is possible your GitHub project is not exposed to everyone.
  • Anonymous
    March 15, 2019
    It's "security principal" not "principle".