SDProp is the Active Directory process that reapplies AdminSDHolder permissions to protected users and groups on a repeating schedule. It runs on the Primary Domain Controller emulator and helps keep privileged objects aligned with the AdminSDHolder ACL, which can also make malicious changes persistent if the template is altered.
How SDProp Works in Active Directory
SDProp is the background Active Directory process that repeatedly reapplies the protected permissions template from AdminSDHolder to privileged users and groups. Its job is consistency: if an object is marked protected, SDProp keeps its ACL aligned with the template on schedule.
This matters because the process is not just a maintenance task, it is part of how directory hardening is enforced over time. Protected objects are meant to retain a controlled security posture even when delegated administration, inheritance, or accidental changes would otherwise alter their permissions.
Why SDProp Exists for Privileged Objects
In Active Directory, privileged objects are treated differently from ordinary accounts and groups because they can reshape access across the domain. SDProp exists to make sure those objects remain under the tighter AdminSDHolder policy rather than inheriting permissions that may be broader or less controlled.
The mechanism is especially important for accounts and groups that are high value targets. Once an object is protected, the directory periodically restores its descriptor to the expected template, which reduces permission drift and limits the chance that inherited changes quietly accumulate on critical identities.
How the AdminSDHolder Template Shapes Access
AdminSDHolder is the security descriptor template that SDProp uses as its source of truth for protected objects. When that template is changed, the next SDProp cycle can apply those changes broadly across the protected set, which is why the template itself deserves the same care as any other privileged control surface.
This relationship is what makes SDProp both useful and sensitive. A legitimate security change can quickly standardize protection, but a malicious or mistaken template change can also propagate persistent access changes to privileged users and groups without touching each object individually.
In practice, the protected set often includes domain admin level accounts and groups, so the process influences access control, inheritance behavior, and the durability of privilege settings. That makes it a core part of directory governance, not just an implementation detail.
Operational Effects and Common Failure Patterns
SDProp can create confusion because it overrides manual ACL edits on protected objects at a scheduled interval. Administrators may believe a permission change “did not stick,” when in reality the process simply restored the protected template as designed.
Its scheduled behavior also means that harmful changes may not be obvious immediately. If AdminSDHolder is altered, the resulting access changes can reappear after each cycle, making the issue look like a recurring configuration problem when it is actually a template-driven persistence mechanism.
Risk and Threat Considerations
SDProp is a protection mechanism, but it also creates a powerful persistence path if an attacker can modify AdminSDHolder or otherwise influence the protected template. Because the process repeatedly reapplies that template, a single malicious ACL change can keep returning on schedule and preserve elevated access on high-value directory objects.
Failure mechanism: compromise of the AdminSDHolder template or protected-object ACLs can be reinforced by the periodic reapplication cycle, causing unauthorized permissions to survive routine cleanup.
Impact: privileged account or group exposure can persist across reset attempts, increasing the chance of domain-wide privilege abuse, stealthy persistence, and delayed incident containment.
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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | SDProp governs protected privileged accounts and groups through recurring ACL enforcement. |
| AC-6 — Least Privilege | AdminSDHolder is used to preserve restrictive permissions on high-value directory objects. | |
| IA-5 — Authenticator Management | SDProp protects objects whose access depends on tightly managed credentials and privileged identity controls. | |
| Recommendation — Review privileged account scope and ensure protected objects are tightly controlled. Limit privileged object permissions to the minimum required access. Harden privileged identity credential handling to reduce persistence risk. | ||
| MITRE ATT&CK | T1098 — Account Manipulation | Altering AdminSDHolder or protected ACLs is a persistence technique tied to account and group control. |
| Recommendation — Monitor for protected-account ACL changes and investigate persistence-oriented manipulation. | ||
| CIS Controls v8 | CIS-5 — Account Management | SDProp affects management of privileged directory accounts and their permissions. |
| CIS-6 — Access Control Management | The process continuously enforces access settings on protected objects. | |
| Recommendation — Inventory privileged accounts and verify their permissions remain intentionally restricted. Restrict access to protected directory objects and review ACL changes quickly. | ||
Practitioner Guidance
Why practitioners should care: SDProp is one of those directory mechanisms that can quietly defend privileged objects or quietly preserve bad changes, depending on the state of the template. Treat AdminSDHolder as a high-impact security control surface, not a normal administrative object.
What to watch for: unexpected permission drift on protected accounts, unexplained restoration of ACL changes, or sudden changes to the AdminSDHolder security descriptor all warrant immediate review. The process is working as intended when it restores policy, but the same behavior can also reveal a compromise that is trying to endure.
Practitioner takeaway: If a privileged object keeps reverting to a surprising permission state, inspect the template and the protected-object set first, because SDProp is usually enforcing what already changed upstream.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
