Diagnosing a Hidden Privileged Access Configuration Trap in Active Directory

Symptom

A permission that an administrator explicitly grants on a privileged Active Directory account or group disappears within about an hour, with no error message and no obvious cause beyond the original grant and a later, unexplained removal.

Teams typically notice this when a delegated helpdesk role is given rights over a break-glass account, or when a service account is added to an access control list on a Tier 0 object, and the access silently stops working shortly afterwards. Because nothing fails at the moment the change is made, the change is assumed to have succeeded.

False Assumption

The change is assumed to be permanent because Active Directory reports success when the access control entry (ACE) is added and the object appears correct immediately afterwards.

Administrators reasonably assume that once an ACE is written to an object’s security descriptor, it stays there until someone deliberately removes it. That holds for ordinary objects. It does not hold for objects Active Directory classifies as protected, including the built-in privileged groups (for example Domain Admins, Enterprise Admins and Schema Admins) and their direct members.

Root Cause

The underlying mechanism is AdminSDHolder and its associated SDProp (Security Descriptor Propagator) process, which periodically reapplies a template access control list to every object it considers protected, overwriting any ACE not already present on that template.

AdminSDHolder is a container object used as the authoritative template for permissions on protected accounts and groups. On a recurring interval, SDProp compares the security descriptor on each protected object against AdminSDHolder’s template and rewrites it to match, discarding inheritance and any manually added entries not part of the template. This is a deliberate anti-tampering control, not a fault, but its effect is indistinguishable from a silent permission failure unless the reader already knows the object is protected.

Impact

The practical impact is that delegated access to privileged accounts and groups appears to work at first and then fails unpredictably, eroding trust in the delegation model.

Because the failure is delayed and silent, it is often diagnosed as an intermittent identity fault rather than a configuration interaction, extending time to resolution and encouraging workarounds – such as adding accounts directly to a protected group – that increase the actual blast radius of privileged access.

Diagnosis

Confirm the trap by comparing the target object’s access control list immediately after a change against its state after the next SDProp interval, and by checking whether the object is a member of a group AdminSDHolder treats as protected.

• Capture the target object’s security descriptor immediately after applying the change.
• Capture AdminSDHolder’s own security descriptor as a baseline template.
• Wait for, or confirm, the next SDProp cycle and capture the target object’s security descriptor again.
• Compare the two captures; a reverted ACE on a protected-group member is the signature of this trap rather than an unrelated access control error.

Get-ADObject -Identity "CN=AdminSDHolder,CN=System,DC=example,DC=com" -Properties ntSecurityDescriptor | Format-List

(Get-ADUser -Identity "svc-privileged-example" -Properties ntSecurityDescriptor).ntSecurityDescriptor.Access

dsacls "CN=Domain Admins,CN=Users,DC=example,DC=com"

Replace the example distinguished names with the actual domain and object names for the environment under test, and run these read-only queries in an isolated or non-production directory first, as required by the validation prerequisites.

Correction

The correction is to delegate access through a security group or organisational unit structure outside the AdminSDHolder-protected scope rather than modifying the protected object directly.

Rather than adding an ACE to the protected object itself, which SDProp removes on its next pass, create or reuse a security group that is not itself a protected-group member, grant that group the required rights at the intended scope, and add the relevant accounts to that group. This keeps the delegation intact across SDProp cycles because it never touches the protected object’s own security descriptor.

Validation

Validation is complete only once the delegated access has survived at least one full SDProp interval after the correction was applied.

1. Record the security descriptor of the target object and the new delegation group before and immediately after the change.
2. Wait for at least one SDProp interval (confirm the environment’s actual interval rather than assuming a default) and capture the security descriptor again.
3. Confirm the delegated group’s rights are unchanged and that the protected object’s own ACL has reverted to the AdminSDHolder template, as expected.
4. Confirm the intended user or service can exercise the access through the new group in a non-production or isolated test.

Rollback

Rollback is limited to reversing the delegation change and does not require touching AdminSDHolder or SDProp configuration.

If the new group causes unexpected access loss or unintended privilege exposure, remove the affected accounts from the new delegation group, restore the previous group membership recorded before the change, and re-validate access before removing the temporary group. Because AdminSDHolder and SDProp were never modified, there is no directory-wide configuration to roll back – only the group membership and delegation grant introduced during correction.

Prevention

Prevent recurrence by treating any object that is a member of a built-in privileged group as protected by default and delegating through groups and OUs that sit outside that scope from the start.

• Maintain a documented list of protected groups and objects for the environment, including any custom groups added to AdminSDHolder’s scope.
• Record the environment’s actual SDProp interval and dsHeuristics/adminSDProtectFrequency configuration, since these can be customised away from documented defaults.
• Require a post-change verification step, timed to span at least one SDProp interval, before any delegation involving a privileged account or group is considered complete.
• Review delegation models periodically against current Microsoft Learn guidance, since protected-group membership and propagation behaviour can change between platform versions.

The next safe decision is to confirm the current SDProp interval and protected-group list for this specific environment before extending this correction pattern to other privileged workflows.