SDProp

How SDProp Works in Active Directory

SDProp, short for Security Descriptor Propagator, is the Active Directory process that reapplies the AdminSDHolder security descriptor to protected objects on a schedule. That repeated stamping is what keeps highly privileged accounts and groups aligned to a known ACL template instead of allowing ad hoc permission changes to persist.

Its job is not to create new permissions, but to normalise the security descriptor on objects that Active Directory treats as sensitive. In practice, that means SDProp acts as a correction mechanism for permission drift, especially where an object has inherited or direct ACL changes that should not remain in place.

Why Protected Object Re-Stamping Matters

The importance of SDProp comes from the kind of objects it touches. Protected users and groups are often the highest-value targets in a domain, so their security descriptors must be stable and predictable. If an attacker or over-permissive admin changes those permissions, SDProp can eventually overwrite the change, but not immediately, which creates a temporary window of exposure.

This delay matters because the object may remain in an unsafe state long enough for abuse, persistence, or privilege expansion. The same scheduling behaviour also means defenders can sometimes observe a risky change before the next re-stamp, which makes timing relevant to incident response and change review.

AdminSDHolder, Protected Groups, and Permission Drift

SDProp is tightly coupled to AdminSDHolder, the protected template that defines the baseline security descriptor for protected objects. When the AdminSDHolder ACL is modified, the effect can propagate to all protected objects, which is why changes to that template are unusually sensitive and should be treated as domain-wide in impact.

Because protected objects are re-stamped rather than managed like ordinary directory entries, they can behave differently from the rest of the domain. That difference is often misunderstood, especially when administrators expect inheritance or one-off ACL edits to “stick” on accounts that are actually protected.

For a practical walkthrough of protected-object behaviour, the AdminSDHolder, SDProp and Protected Groups Guide covers protected groups, template ACL abuse, orphaned adminCount clean-up, and the event signals associated with these changes.

Operational Signals and Review Points

SDProp is best understood as both a control and a signal. A protected object whose permissions keep reverting indicates that the object is being governed by the AdminSDHolder mechanism, while unexpected changes to the template or to protected memberships can point to a governance problem, a misconfiguration, or malicious tampering.

Common review points include who can edit AdminSDHolder, which objects are marked protected, whether orphaned adminCount values remain, and whether change events around protected ACLs are being captured. In this area, visibility is as important as configuration, because the defender may need to distinguish intended re-stamping from hostile interference.

Risk and Threat Considerations

SDProp creates a security window between a risky directory change and the next scheduled reapplication of the protected descriptor. That gap is small in operational terms, but it is long enough for an attacker or careless admin to exploit inconsistent permissions on a high-value object.

Failure mechanism: An attacker changes the ACL on a protected object or the AdminSDHolder template, then uses the period before the next SDProp run to abuse delegated rights, preserve access, or alter group membership and control paths.

Impact: The result can be temporary but meaningful exposure of privileged accounts and groups, delayed remediation, and an incomplete post-incident view if defenders do not check whether access was abused during the drift window.

Practitioner Guidance

What to watch for: Treat AdminSDHolder edits, unexpected protected-object ACL changes, and orphaned protected-state artefacts as high-signal events. The key judgement is not only whether a permission change exists, but whether it affects an object that SDProp will continue to restamp.

Governance implication: AdminSDHolder ownership should be tightly controlled because it defines the baseline for every protected object it covers. If you allow broad write access to that template, you are effectively allowing broad influence over the security posture of the most sensitive directory principals.