AdminSDHolder Protection Silently Skips Groups Nested Below Domain Admins

Symptom

A helpdesk team lead reports that a service account, member of a nested group two levels below Domain Admins, unexpectedly lost the ability to perform a privileged directory operation after what the platform team believed was a routine ACL cleanup on an unrelated group. Event logs show no explicit permission removal on the service account itself, and the account’s group membership in Active Directory Users and Computers appears unchanged.

False Assumption

The operations team assumed that because the account was nested inside Domain Admins, it was protected by the AdminSDHolder and SDProp mechanism the same way direct Domain Admins members are, and that any ACL change made to the account’s immediate parent group would be automatically reconciled against the protected security descriptor template within the standard 60-minute SDProp cycle.

Root Cause

AdminSDHolder and the SDProp process (documented as part of the broader identity governance controls referenced in the Microsoft cloud security benchmark) apply the protected security descriptor directly to security principals that Active Directory classifies as members of a defined protected group, using group membership evaluated by SDProp’s own enumeration logic. When a user or service account is nested two or more levels below Domain Admins through an intermediate custom group, Active Directory’s SDProp walk in many observed configurations treats the intermediate group as the protected object rather than propagating protection transitively down to every nested member; the exact enumeration depth and behaviour is version- and configuration-dependent, so this must be confirmed against the running domain rather than assumed. The intermediate group itself retains the AdminAccessAllowed marker (adminCount=1) if it was ever processed, but ordinary members added later, or members several hops removed, can be excluded from the automatic ACL reset that AdminSDHolder guarantees for directly enumerated privileged accounts. Consequently, a permissions change applied to the intermediate group’s ACL, such as removing an ACE that granted the effective privileged capability, is never overwritten because SDProp never re-applies the AdminSDHolder template to that object or, in some nesting patterns, to its descendants.

Impact

The affected account loses privileged capability without any corresponding alert, because monitoring built around AdminSDHolder protection (for example, alerting on adminCount changes or on ACL modifications to protected objects) does not fire, since the object was never brought under that protection in the first place. This produces two risks: a false sense of assurance that nested privileged accounts are protected identically to direct members, and a silent, unannounced loss of intended access that can disrupt automation or emergency-access accounts at the worst possible moment.

Diagnosis

Confirm the nesting depth and adminCount state before assuming SDProp coverage. Run the following read-only checks in an isolated or non-production domain, or against a domain controller you are explicitly authorised to query, after confirming the AD domain and forest functional level and the DC’s operating system version.

Get-ADGroupMember -Identity 'Domain Admins' -Recursive | Select-Object Name, SamAccountName, DistinguishedName

Get-ADUser -Identity 'svc-privileged-task' -Properties adminCount, memberOf | Select-Object Name, adminCount, memberOf

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

Expected evidence: the recursive membership query shows the account nested through an intermediate group; the adminCount property on the account is 0 or unset rather than 1, indicating SDProp has not applied protection directly to that object; and the intermediate group’s own adminCount and ACL history show it was modified without triggering a corresponding reset on the nested member.

Correction

The correction must be scoped, reversible and validated before touching any production identity. In an isolated test domain, first capture the current ACL and adminCount state of the affected account and intermediate group so the prior state can be restored. Then either (a) add the affected account as a direct member of Domain Admins or another group SDProp explicitly enumerates as protected, removing the problematic nesting, or (b) if nesting must be retained for organisational reasons, apply an explicit, documented ACE on the account matching the required privileged capability and add continuous monitoring for adminCount and ACL drift on that specific object, since it will not be covered by AdminSDHolder’s automatic reset.

# Capture current state before change (read-only, run first)
Get-ADUser -Identity 'svc-privileged-task' -Properties adminCount, memberOf, nTSecurityDescriptor |
  Export-Clixml -Path 'C:AD-Rollbacksvc-privileged-task-preimage.xml'

# State-changing: move account to direct Domain Admins membership
Add-ADGroupMember -Identity 'Domain Admins' -Members 'svc-privileged-task'
Remove-ADGroupMember -Identity 'Intermediate-Priv-Group' -Members 'svc-privileged-task' -Confirm:$true

Apply this only in the isolated test domain first. Do not run the state-changing step against a production forest until the validation steps below pass in the test environment and a change window with rollback approval is confirmed.

Validation

Validation confirms the account is now covered by AdminSDHolder protection and that the intended privileged capability is intact. After allowing one full SDProp cycle (up to 60 minutes, or trigger manually in the test domain), re-run the diagnosis queries: adminCount on the account should now read 1, and Get-ADUser’s memberOf should show direct membership in a protected group. Separately, functionally test that the service account can still perform its intended privileged operation, and confirm no unrelated ACEs were lost from the intermediate group during the change.

Rollback

If validation fails, or if direct Domain Admins membership is organisationally unacceptable, restore from the captured pre-image: re-add the account to the original intermediate group and remove it from Domain Admins, then restore the recorded ACL state on the intermediate group from the exported XML. Re-run the diagnosis queries to confirm the account has returned to its prior nested state before considering the rollback complete. Treat any domain-wide SDProp behaviour change as out of scope for this rollback; only the specific account and group membership are reverted.

Prevention

Treat nested nomination into Domain Admins-adjacent groups as a governance decision, not a convenience. Maintain an explicit inventory of every group nested inside default AdminSDHolder-protected groups, and audit adminCount against actual SDProp enumeration depth on a scheduled basis rather than assuming nesting equals protection. Where nested privileged access is operationally required, document the intermediate group as an explicitly monitored object with its own ACL-change alerting, since it will not inherit AdminSDHolder’s automatic reset guarantee.