What breaks when AdminSDHolder is modified in Active Directory?

When AdminSDHolder is changed, the updated ACL is copied to protected groups and their members by SDProp every 60 minutes by default. That means a malicious permission can keep reappearing even after an administrator removes it from one account. The practical risk is persistent control over highly privileged objects, which can preserve an attacker’s foothold and widen access across the domain.

How AdminSDHolder changes keep privileged permissions from staying fixed

AdminSDHolder is not a normal object permission target. When its ACL is edited, SDProp re-applies that ACL to protected groups and their members on a recurring cycle, so the change behaves like a template for Tier 0 style objects rather than a one-time edit. The result is persistence: a bad ACE can reappear after cleanup, and an intended hardening change can also spread more broadly than expected.

That is why the effect is often noticed as “the permission comes back.” The actual break is in inheritance and propagation control, not just in a single account’s ACL. For privileged users and groups, the AdminSDHolder stamp can override local corrections until the source ACL is fixed.

In practice, this means Active Directory and Entra ID Hardening Guide style tiering matters because protected objects behave differently from ordinary directory objects. If the protected ACL is wrong, every SDProp cycle can reassert the same access model across the protected set.

Why the risk is persistence, not just misconfiguration

AdminSDHolder becomes a force multiplier when it is abused. A malicious ACE on the template can survive routine remediation, which makes it attractive for stealthy privilege retention. Even if defenders remove access from one user or group member, the template can repopulate it and keep the attacker’s control path alive.

This also creates an operational trap for administrators. Teams may believe they have removed excess rights because the immediate object looks clean, while the underlying protected-objects mechanism continues to reapply the unwanted permission. That can extend dwell time and delay the point where access is truly eliminated.

The pattern aligns with the lifecycle and privilege-control themes in the NHI Lifecycle Management Guide, especially where recurring access, ownership, and revocation are concerned. The same logic applies to privileged directory objects: control the source of truth, not only the visible endpoint.

What has to be checked when the ACL on AdminSDHolder is altered

The first question is whether the change was intentional and who approved it. If the ACL was modified outside a controlled maintenance path, treat it as a privileged-access event and review the source of the change, not only the current permission list. The second question is whether the protected set includes objects that should not be inheriting that control at all.

Administrators should also verify whether the change is being mirrored onto members of protected groups, because the blast radius is wider than a single directory object. The presence of a persistent or inherited ACE on a Tier 0 object is more serious than the same ACE on an ordinary user account, because it can affect domain-wide administrative control.

For a broader hardening path, the Active Directory and Entra ID Hardening Guide is useful because it frames protected groups, delegation boundaries, and privileged access as a single control problem. That is the right mental model for AdminSDHolder changes: source control first, object cleanup second.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	AC-2 — Account Management	AdminSDHolder changes affect privileged account and group governance.
	AC-6 — Least Privilege	The issue is persistent overprivilege on protected AD objects.
	AU-6 — Audit Record Review, Analysis, and Reporting	Recurrent ACL reapplication requires monitoring and review to detect unauthorized persistence.
Recommendation — Review protected privileged accounts and revoke any unauthorized ACL changes at the source. Minimize rights on protected directory objects and remove excess permissions from the template. Monitor protected-object ACL changes and investigate repeated reappearance of the same ACEs.
CIS Controls v8	5 — Account Management	Protected AD accounts and groups must be managed and reviewed to prevent persistent misuse.
	6 — Access Control Management	AdminSDHolder defines recurring access control behavior for protected objects.
Recommendation — Continuously review privileged directory accounts and remove unauthorized access paths. Enforce and verify least-privilege access on protected directory objects and their source ACL.
NIST CSF 2.0	PR.AA-05 — Least Privilege	The question concerns excessive and persistent privileged access in AD.
	DE.CM-03 — Personnel Activity is Monitored	Repeated privilege changes on protected objects should be detectable through monitoring.
Recommendation — Apply least-privilege controls to protected directory groups and their members. Alert on unexpected ACL changes to AdminSDHolder and protected AD objects.
MITRE ATT&CK	T1098 — Account Manipulation	Modifying AdminSDHolder ACLs is a form of account and permission manipulation for persistence.
	T1136 — Create Account	Protected-object compromise often supports durable privileged access via directory abuse.
Recommendation — Track and investigate directory permission changes that preserve or restore privileged access. Hunt for directory changes that establish or maintain privileged footholds.

Practitioner Guidance

What to verify: Confirm whether the AdminSDHolder ACL contains any nonstandard ACEs, then compare the protected objects against that template after an SDProp cycle has run. If the same permission reappears, the template is still the active control point.

Decision rule: If a protected object’s permission keeps returning, treat the source ACL as the incident, not the user account you just edited. Fix the template and validate propagation before declaring remediation complete.

What good looks like: Only explicitly approved privileged access exists on the template, the protected group set is understood, and recurring reviews prove that cleanup persists across cycles instead of being overwritten.

Practitioner takeaway: AdminSDHolder problems are usually governance failures of the privileged template, not isolated account mistakes, so the safest remediation is to control the source ACL and then prove the protected set stays stable.