Sneaky Active Directory Persistence #15: Leverage AdminSDHolder & SDProp to (Re)Gain Domain Admin Rights

The content in this post describes a method by which an attacker could persist administrative access to Active Directory after having Domain Admin level rights for 5 minutes.

I presented on this AD persistence method at DerbyCon (2015).

Complete list of Sneaky Active Directory Persistence Tricks posts

AdminSDHolder Overview

AdminSDHolder is an object located in the System Partition in Active Directory (cn=adminsdholder,cn=system,dc=domain,dc=com) and is used as a security template for objects that are members of certain privileged groups. Objects in these groups are enumerated and any objects with security descriptors that don’t match the AdminSDHolder ACL are flagged for updating. The Security Descriptor propagator (SDProp) process runs every 60 minutes on the PDC Emulator and re-stamps the object Access Control List (ACL) with the security permissions set on the AdminSDHolder.


Objects protected by AdminSDHolder have the attribute “AdminCount” set to 1 and security inheritance is disabled.

Note that when an object is removed from one of the protected groups, AdminCount is not set to another value. This is due to early feedback when Windows 2000 was released.

Default AdminSDHolder Security ACLs

The AdminSDHolder object permissions are used as an ACL template for domain privileged groups.

Relevant AdminSDHolder default ACLs:

  • Authenticated Users: Read
  • SYSTEM: Full Control
  • Administrators: Modify
  • Domain Admins: Modify
  • Enterprise Admins: Modify



AdminSDHolder Default Protected Objects

SDProp Protected Objects (Windows Server 2008 & Windows Server 2008 R2):

  • Account Operators
  • Administrator
  • Administrators
  • Backup Operators
  • Domain Admins
  • Domain Controllers
  • Enterprise Admins
  • Krbtgt
  • Print Operators
  • Read-only Domain Controllers
  • Replicator
  • Schema Admins
  • Server Operators

A subset of these groups can be excluded from control, including Account Operators, Server Operators, Print Operators, Backup Operators.


Around 60 minutes later, the PDC Emulator runs and the account now has full control on the Domain Admins group.

Or, run SDPRop manually.

In Windows Server 2008 R2, Microsoft introduced a new rootDSE LDAP modify operation, called RunProtectAdminGroupsTask, to start the AdminSDHolder process.

The new Windows 2008 R2 RunProtectAdminGroupsTask-based mechanism provides a more efficient mechanism to enforce AdminSDHolder application. Under the hood, the older FixUpInheritance-based mechanism doesn’t really kick off the AdminSDHolder process—it starts the Security Descriptor Propagator Update (SDProp) process. SDProp has the same effect on the ACLs of critical security groups and accounts but takes much longer to complete. SDProp is the background AD process that propagates changes of inheritable ACEs on parent objects to their child objects. It’s automatically triggered when an object’s ACL is modified or when an object is moved. SDProp affects all AD child objects’ ACLs and not only the ACLs of critical AD security groups and accounts and will thus consume much more DC processing time.
SDProp Reference on


Manual triggering of the SDProp process

FixUpInheritance (prior to Windows 2008 R2):


Windows 2008 R2 RunProtectAdminGroupsTask-based mechanism:



Exploiting AdminSDHolder & SDProp

Add the account or group to the AdminSDHolder object permissions granting either Full Control or Modify rights.
The user “Bobafett” is added in this example.


After running SDProp, Bobafett is automatically added to the Domain Admins group (along with the others listed above). Now this account can modify the Domain Admins group membership.


Note that the user account Bobafett has no group membership.


Despite not being a member of any groups, this account can now modify the group membership of Domain Admins.




AdminSDHolder is a sneaky method for an attacker to persist granting the ability to modify the most privileged groups in Active Directory by leveraging a key security component. Even if the permissions are changed on a protected group or user, SDProp will change the securtiy permissions to match that of the AdminSDHolder object.



Monitor the ACLs configured on the AdminSDHolder object. These should be kept at the default – it is not usually necessary to add other groups to the AdminSDHolder ACL.

Monitor users and groups with AdminCount = 1 to identify accounts with ACLs set by SDProp.
Find all users with security ACLs set by SDProp using the PowerShell AD cmdlets:

Import-Module ActiveDirectory
Get-ADObject -LDAPFilter “(&(admincount=1)(|(objectcategory=person)(objectcategory=group)))” -Properties MemberOf,Created,Modified,AdminCount








(Visited 36,244 times, 11 visits today)


Skip to comment form

    • jjingles on September 28, 2015 at 10:35 am

    Maybe interesting schedule task that check the ACL change; very simple example:

    get-acl -Path “AD:\CN=AdminSDHolder,CN=System,DC=Domain,DC=test” | Select-Object -ExpandProperty Access | Export-Csv -Encoding Unicode C:\temp\ACLAdminHolder.csv

    $currentGroup = get-acl -Path “AD:\CN=AdminSDHolder,CN=System,DC=Domain,DC=test” | Select-Object -ExpandProperty Access
    $baselineGroup = import-csv -Path “C:\temp\ACLAdminHolder.csv”
    $diff = Compare-Object -ReferenceObject $baselinegroup -DifferenceObject $currentGroup -Property “IdentityReference”
    if ($diff -ne $null)
    foreach ($item in $diff)
    $user = $item.IdentityReference
    if ($item.SideIndicator -eq “=>”)
    $mailbody = “AdminSDHolder ACL change detected, compare results”

    $mailbody = “AdminSDHolder ACL change detected, compare results”
    send-mailmessage -from “KK@domain.test” -to “admin_with_serious_problems@domain.test” -subject “Check AdminHolderACL” -body $mailbody -smtpServer “mail1.domain.test”

    Other audit/monitor tools could do the same in real-time too.
    In any case, we would have a lot of problems…
    Thanks for all of your info.
    Blue Team SysAdminsGroup

      • Grégory on September 29, 2015 at 7:44 am


      For me, the best way to check changes on ACLs (and many other objects or attributes) is to check replication metadata.
      With your solution you won’t be able to detect modifications if the attackers revert changes.
      Whereas with replication metadata you’ll see a jump of 2 in the version of the metadata.

      You can’t also rely on logs because an attacker could have modify the searchflags attribute of one of the schema attribute to disable audit. For example, modify the searchflags attribute (add never_audit_value) of the nt-security-descriptor attribute in the schema and then you could modify ACLs without being detected.

      Have a look at my old wiki article (in french …) :


        • jjingles on October 1, 2015 at 7:12 am

        As Sysadmin (I’m not a security expert), I appreciate so much this kind of information and help; I can try more things to secure our “environment”.
        Thanks a lot again!

  1. Really interesting article, and clever way to hide the power of a sleeper account.. Question though: The title says “…get domain admin rights”. Don’t you already need to be a Domain admin or equivalent to modify the AdminSDHolder object?

    1. Noted. Title updated.

Comments have been disabled.