Security Descriptor Propagation (SDProp)

How SDProp Works in Active Directory

SDProp is a background protection mechanism in Active Directory, not a one-time permission setting. It periodically reapplies a known-good security descriptor to protected objects, which means the object’s effective permissions, owner and audit settings are continually restored to a template state even if someone changes them elsewhere.

That design matters because protected groups and accounts are often the highest-value targets in a domain. SDProp is the enforcement layer that helps keep delegated administration, inheritance breaks and manual edits from becoming permanent drift on those objects.

Why Protected Objects Need SDProp

Protected objects are treated differently from ordinary directory objects because they sit at the top of the privilege hierarchy. If their access control entries, ownership or auditing can be altered and those changes persist, an attacker or careless administrator can create durable privilege escalation, persistence or concealment paths.

SDProp closes that gap by repeatedly comparing the protected object’s security state against the template applied through AdminSDHolder. In practice, this is why membership in privileged groups is not just an authorization concern, but also a governance and persistence concern for directory security.

AdminSDHolder, Template ACLs and Protected Group Behaviour

The template behind SDProp is typically associated with AdminSDHolder, which acts as the source of truth for protected security descriptors. When an object is stamped as protected, it can stop inheriting permissions in the normal way, so the template becomes the mechanism that preserves a consistent control posture.

This also explains some common operational side effects. Objects that are protected may behave differently from other directory objects during delegation, clean-up and auditing, and stale protection states can leave accounts with unexpected privilege history. The AdminSDHolder, SDProp and Protected Groups Guide covers the related protected-group patterns, template ACL abuse and orphaned adminCount issues that often appear alongside SDProp investigations.

Security Monitoring and Recovery After SDProp-Related Changes

Because SDProp can overwrite unauthorised changes, it is useful both as a control and as an investigative clue. Sudden permission changes on protected objects, unexpected changes to adminCount-related state, or modifications to the template itself can indicate attempted persistence or defensive tampering.

After suspicious changes are discovered, the important question is not only whether the final ACL looks correct, but whether the protected account or group was modified before SDProp restored it. A compromise review should therefore include change history, directory auditing, and review of who touched the template and protected objects during the period of exposure.

Risk and Threat Considerations

SDProp reduces one class of directory persistence, but it also creates a concentrated control point: if the template, protected-object state or related administration is abused, the attacker can influence many high-value accounts at once. The main risk is not the periodic copy itself, but the fact that privileged directory objects can be targeted for durable access, concealment or delegated-control abuse.

Failure mechanism: An attacker or misconfiguration changes a protected object or the template that SDProp enforces, then relies on the object’s privileged status and the timing of refresh cycles to retain or briefly exploit elevated control before the system restores the descriptor.

Impact: The result can be persistent privilege abuse, altered auditing, broken delegation assumptions, and delayed detection of tampering on accounts or groups that guard the domain.

Practitioner Guidance

Why practitioners should care: SDProp is one of those controls that looks passive until it fails, or is bypassed, and then the blast radius is immediate. Treat protected groups, AdminSDHolder state and descriptor drift as part of your privileged-access hygiene, not just as directory housekeeping.

What to watch for: Pay attention to unexpected changes on protected accounts, repeated reversion of ACLs, orphaned adminCount settings, and modifications to the template that SDProp applies. Those signals often tell you whether the issue is normal administrative churn or a genuine privilege persistence attempt.

Related resources from NHI Mgmt Group

• Security Descriptor Propagator (SDProp)
• How can security teams tell whether secret exposure has become a propagation risk?
• When does DNS propagation become a security problem rather than an operations issue?
• What breaks when traditional security controls cannot see adversary propagation inside the environment?