AdminSDHolder, SDProp and Protected Groups Guide

One object in every Active Directory domain decides the permissions on all of its most privileged accounts, and a single unwanted entry on it is copied to every one of them within the hour. That object is AdminSDHolder, and the process that copies it is SDProp. Together they protect Domain Admins, Enterprise Admins and other protected groups from weak delegation, but they also create a persistence route for attackers, and they leave behind accounts with adminCount=1 and broken inheritance long after those accounts stop being administrators. This guide is for Active Directory engineers, PAM teams and detection engineers. It explains how the mechanism works, which groups and accounts it covers, how service accounts and tools get caught up in it, what to log and alert on, a hardening baseline and the misconfigurations seen most often. For the wider administrative model, see the Tiered Administration and Enterprise Access Model Guide.

Key takeaways

AdminSDHolder is a template: the object CN=AdminSDHolder,CN=System,DC=... holds the security descriptor that SDProp stamps onto every protected account and group.
SDProp runs hourly on the PDC emulator: by default every 60 minutes it resets any protected object whose permissions differ from the template, and inheritance stays disabled on those objects.
A change to the template is a change to all of tier 0: an extra entry on AdminSDHolder gives that principal the same rights over every protected account, and removing it from individual accounts does not help because SDProp puts it back.
adminCount outlives membership: accounts removed from protected groups keep the protected security descriptor and disabled inheritance until someone cleans them up, which breaks delegation and hides former administrators.
Treat the template as tier 0 configuration: baseline its ACL, audit every change with event 5136, alert on event 4780 patterns and review protected group membership continuously.

How identity and access work in AdminSDHolder and SDProp

Active Directory permissions normally flow down the directory tree through inheritance, so whoever is delegated control of an organisational unit gains control of the objects inside it. For administrative accounts that would be dangerous: a help desk team delegated password resets on an OU could reset a Domain Admin's password. AdminSDHolder and SDProp break that path.

The template: AdminSDHolder lives in the System container of each domain. Microsoft documents that it is owned by Domain Admins by default, that Enterprise Admins, Domain Admins and Administrators can modify it, and that members of Administrators or Enterprise Admins can take ownership.
The propagator: SDProp (Security Descriptor Propagator) runs on the domain controller holding the PDC emulator role. By default it runs every 60 minutes and compares the security descriptor of each protected account and group with AdminSDHolder; where they differ, it overwrites the object's permissions with the template.
Inheritance disabled: protected objects do not inherit permissions from their parent container, so moving a protected account to a delegated OU does not give that OU's delegates control over it.
The marker: the system sets the adminCount attribute on users and groups that have had their ACLs changed because they were members of an administrative group, directly or transitively. Nested group membership therefore counts.
Interval and manual runs: the interval can be changed with the DWORD AdminSDProtectFrequency under HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters on the PDC emulator, from 60 to 7,200 seconds. Microsoft advises against lowering it in production because of LSASS overhead and recommends triggering a manual run for testing instead, by writing RunProtectAdminGroupsTask to rootDSE.

Admin roles and privileged access

Microsoft lists the same protected accounts and groups for Windows Server 2016, 2019, 2022 and 2025. Every one of them is tier 0 or can reach tier 0.

Protected account or group	Why it is protected	Recommended standing state
Enterprise Admins, Schema Admins	Forest-wide control; schema changes	Empty except during approved changes
Domain Admins, Administrators	Full control of the domain and domain controllers	Minimal named admin accounts, ideally just-in-time
Administrator (built-in account)	Domain's built-in admin account	Long random password in a vault, used for break-glass only
Krbtgt	Key for all Kerberos tickets in the domain	Not used for logon; password rotated on a schedule and after compromise
Domain Controllers, Read-only Domain Controllers	Computer accounts of domain controllers	Only DC computer accounts
Account Operators, Server Operators, Print Operators, Backup Operators	Built-in operator groups with rights that can lead to domain compromise	Empty; delegate specific tasks instead
Replicator	Legacy file replication	Empty
Key Admins, Enterprise Key Admins	Can manage key credentials on objects	Empty unless a documented need exists

Operator groups deserve attention because they look harmless. Backup Operators can back up and restore files on domain controllers, Server Operators can manage services on them, and Account Operators can manage many non-protected accounts and groups. The dSHeuristics attribute includes a character at position 16, dwAdminSDExMask, that can exclude certain operator groups from SDProp protection. Excluding a group means its members lose protection while keeping their rights, so leave the default unless you have a documented reason, and check the value during audits. See the Active Directory and Entra ID Hardening Guide.

How the template becomes a persistence route

Because SDProp copies whatever is on AdminSDHolder, an attacker who has reached Domain Admin can add an access control entry for an account they control to the template. Within the next SDProp cycle, that account has the same rights over every protected user and group, and defenders who remove the entry from individual admin accounts see it return within the hour. The technique maps to MITRE ATT&CK T1098 Account Manipulation; if the added rights include directory replication permissions, it enables T1003.006 DCSync. The defence is simple in principle: know exactly what the template ACL should be, detect any change to it, and treat a change as a tier 0 incident. See the Active Directory Domain Compromise Response Playbook.

Integrations, API tokens and service accounts

Non-human identities are the most common source of unexpected protected accounts and of pressure to weaken the template.

Service accounts in protected groups: backup agents placed in Backup Operators, monitoring or deployment tools in Domain Admins, and scripts run as the built-in Administrator all become protected, gain adminCount=1 and give anyone who steals their credentials tier 0 reach. Replace them with delegated, task-specific rights and group managed service accounts where the product supports them. See the Service Account Security Guide.
Vendor installers: some products ask for membership of a privileged group during installation and never remove it. Review protected group membership after every installation and remove rights once setup is complete.
Help desk and IAM tools: because protected accounts block inherited delegation, password reset tools and IGA connectors fail on administrators. The wrong fix is to grant the tool's service account rights on AdminSDHolder, which hands it control of tier 0. The right fix is to manage admin accounts through a separate tier 0 process or PAM.
Directory synchronisation accounts: accounts used by hybrid identity synchronisation can hold sensitive permissions such as replication rights without being in a protected group, so SDProp does not cover them. Inventory and monitor them separately as tier 0. See the Active Directory ACL and Delegation Hygiene Guide.
Orphaned service accounts: a service account once added to Domain Admins "temporarily" keeps adminCount=1, the protected security descriptor and its old password long after removal; it is a favourite target because nobody owns it.

Logging and detection

Most of the useful signals come from domain controllers, so the audit policy must be applied to the Domain Controllers OU and the events forwarded to your SIEM.

Event or signal	Source and prerequisite	What it tells you	Suggested use
5136 A directory service object was modified	Audit Directory Service Changes; requires a SACL with Write auditing on the object	Who changed which attribute; filter on Object DN `CN=AdminSDHolder,CN=System,...` and the security descriptor attribute; Value Added and Value Deleted pairs share a Correlation ID	High-severity alert on any change to AdminSDHolder
4780 The ACL was set on accounts which are members of administrators groups	Audit User Account Management, on the PDC emulator	SDProp reset a protected account's ACL to the template, meaning someone changed it	Investigate and correlate with the 5136 that changed the account; note Microsoft says it does not generate on some versions, so absence proves nothing
4728, 4732, 4756 member added to a security-enabled global, local or universal group	Audit Security Group Management	New members of protected groups	Alert on any addition to protected groups outside approved changes
Template baseline drift	Scheduled read of the AdminSDHolder ACL	Any entry not in the approved baseline	Daily comparison, independent of event logging
Orphaned `adminCount=1`	Scheduled LDAP query comparing `adminCount` with current transitive membership	Former administrators and service accounts with stale protection	Weekly report to the AD team
`dSHeuristics` position 16	Scheduled read of the Directory Service object	Operator groups excluded from protection	Alert on any non-default value

Metrics that show the control is working

Template drift: number of non-baseline entries on AdminSDHolder (target zero, always).
Standing protected group members: count of members of Domain Admins, Enterprise Admins, Schema Admins and the operator groups, trending to the minimum.
Orphaned adminCount objects: accounts with adminCount=1 that are no longer in a protected group, trending to zero.
Service accounts in protected groups: target zero, with documented exceptions only.
Time to detect a protected group change: from event to analyst acknowledgement, tested with planned changes.

For broader AD event coverage, see the Active Directory Security Monitoring and Event IDs Guide.

Hardening baseline

A phased approach lets you clean up without breaking administration or automation.

Baseline the template: export the current AdminSDHolder ACL in every domain and compare it with a known-good default from a clean test domain at the same functional level. Investigate every extra entry; an unexplained entry for a user or service account is a potential compromise indicator, not a clean-up task.
Turn on auditing: enable Audit Directory Service Changes and Audit User Account Management on domain controllers, add a SACL with Write auditing on AdminSDHolder, and confirm 5136 events arrive in the SIEM by making a harmless test change in a test domain first.
Reduce protected membership: empty Enterprise Admins and Schema Admins, empty the operator groups, and reduce Domain Admins to named, dedicated admin accounts managed through PAM or just-in-time membership. See the JIT Access Guide.
Remove service accounts from protected groups: replace with task-specific delegation, test each application in a pilot, and keep a rollback plan of re-adding the account temporarily if a critical function fails.
Clean up orphaned adminCount objects: for each account no longer in a protected group, clear adminCount, re-enable inheritance on the object so it receives the permissions of its OU, and confirm with a manual SDProp run that it is not protected again (which would reveal hidden nested membership). Do this in small batches and record the previous security descriptor so you can restore it.
Protect admin accounts further: add administrators to the Protected Users group where compatible, set "Account is sensitive and cannot be delegated", and allow logon only from privileged access workstations. See the Privileged Access Workstations Guide.
Lock the configuration: keep AdminSDProtectFrequency at its default, leave dwAdminSDExMask at its default, and alert on changes to either.

Decision guidance

Small domains: focus on the baseline, the 5136 alert and emptying operator groups; these need no extra tooling.
Large or multi-domain forests: each domain has its own AdminSDHolder and PDC emulator, so automate baselines and orphan reports per domain and include them in tier 0 change management.
Suspected compromise: if an unknown entry appears on the template, do not just delete it. Preserve evidence, assume tier 0 compromise and follow the domain compromise playbook, because the attacker needed tier 0 rights to add it.

Framework	Reference	How this guide applies it
NIST SP 800-53 Rev. 5	AC-6(5) Privileged Accounts, AC-6(7) Review of User Privileges	Minimal protected membership and regular review, including orphaned adminCount
NIST SP 800-53 Rev. 5	AC-2(4) Automated Audit Actions, AU-6 Audit Record Review, CM-3 Configuration Change Control	Auditing and alerting on template and group changes, change control for tier 0
NIST CSF 2.0	PR.AA-05, DE.CM-03	Least privilege for privileged groups; monitoring personnel activity and technology usage
MITRE ATT&CK	T1098 Account Manipulation, T1003.006 DCSync, T1069.002 Domain Groups	Persistence via template ACL, replication rights abuse, discovery of protected groups
CIS Controls v8.1	Control 5 Account Management, Control 8 Audit Log Management	Dedicated admin accounts and centralised audit logs

Common misconfigurations

Extra entries on AdminSDHolder: rights added for a help desk group, IAM connector or monitoring account to "fix" failures on admin accounts, silently granting control of every protected object.
Thousands of orphaned adminCount objects: former admins and old service accounts with disabled inheritance, which breaks normal delegation and makes it hard to see who is really privileged.
Populated operator groups: Backup Operators or Server Operators used for convenience, giving domain controller access to people and tools outside tier 0.
Service accounts as Domain Admins: automation running with full domain rights because it was easier than delegation; their credentials often sit in scripts or scheduled tasks.
No auditing on the template: no SACL on AdminSDHolder, so a malicious change leaves no 5136 event.
Changed SDProp settings: a lowered interval left over from testing, or a non-default dwAdminSDExMask nobody remembers setting.

Practitioner checklist

Export and baseline the AdminSDHolder ACL in every domain, and investigate every non-default entry.
Add a Write-auditing SACL to AdminSDHolder and alert on every 5136 for that object.
Collect event 4780 from PDC emulators and correlate it with the change that triggered it.
Alert on additions to every protected group (4728, 4732, 4756) outside approved changes.
Empty Enterprise Admins, Schema Admins and the operator groups; minimise Domain Admins.
Remove service accounts and vendor tools from protected groups and use task-specific delegation.
Report and clean up accounts with orphaned adminCount=1, re-enabling inheritance in small, reversible batches.
Check AdminSDProtectFrequency and dSHeuristics position 16 are at their defaults.
Treat any unexplained template change as a tier 0 compromise and preserve evidence before remediation.

AdminSDHolder, SDProp and Protected Groups Guide: Securing and Monitoring Active Directory’s Privileged Template