Nested Membership in Domain Admins Escapes AdminSDHolder Protection

Symptom

A privileged-access review of Domain Admins in an Active Directory domain shows a small, expected membership list, yet accounts outside that list retain effective Domain Admin rights during audits, and one of those accounts has an AdminCount attribute of 0 despite the elevated access. Security tooling that alerts on direct changes to Domain Admins produces no alert when the extra access is granted, because the group used to grant it was never added to Domain Admins itself; it was already nested there beforehand.

False Assumption

The team assumed that AdminSDHolder and the SDProp process protect every account that has effective membership in a protected group such as Domain Admins, including accounts that gain that membership indirectly through group nesting. The observable behaviour is different: SDProp walks the direct membership of protected groups defined in AdminSDHolder’s protected group list, marks those principals as protected (AdminCount=1) and reapplies the AdminSDHolder ACL to them, but it does not recursively expand nested group membership to identify and protect indirect members in the same pass. A nested group’s own members are not individually flagged as protected unless they separately meet a protected-group condition.

Root Cause

Active Directory’s SDProp process, which runs on the PDC emulator and refreshes protected-object ACLs, iterates the AdminSDHolder protected group list and applies AdminCount=1 plus the hardened ACL to the direct members of those groups. A group nested inside Domain Admins is itself marked protected because it is a direct member. However, SDProp’s protection marking does not cascade a second level down to that nested group’s own membership. The result is a structural gap: nested group membership is functionally equivalent to direct membership for access-token purposes (Kerberos ticket construction expands group nesting through the full chain), but it is not treated as equivalent for AdminSDHolder protection or for many audit tools that only enumerate direct membership of the protected group rather than resolving full effective membership through nested groups.

Impact

Anyone with control over the nested group, including its owner, members of a group with delegated management rights over it, or an attacker who compromises an account that can add members to that nested group, can grant themselves or others silent Domain Admin-equivalent rights without ever touching the Domain Admins group directly. Because AdminCount is not set on these indirect members, they do not inherit the AdminSDHolder-hardened ACL, so their own object permissions may remain more permissive than expected for a highly privileged account, and they do not appear in the subset of privileged-account reports that filter on AdminCount=1 or on direct Domain Admins membership. This creates a durable, low-visibility escalation path that persists across membership reviews unless someone explicitly resolves nested group membership.

Diagnosis

Diagnosis is a concise standalone read-only check: resolve full effective membership of Domain Admins through nested groups and compare it against the AdminCount-flagged population to reveal any indirect members that AdminSDHolder has not protected. Run the checks below in an isolated or lab domain first, or use a read-only account with directory-read rights in production, and record the output before drawing conclusions.

Get-ADGroupMember -Identity "Domain Admins" -Recursive | Select-Object Name, SamAccountName, ObjectClass

This lists every effective member of Domain Admins, including principals reached only through nested groups. Next, list the direct membership only, to identify any groups nested inside Domain Admins:

Get-ADGroup -Identity "Domain Admins" -Properties Members | Select-Object -ExpandProperty Members

Cross-reference any group DNs found in the direct membership output against the recursive membership list, then check whether each object identified as an indirect (nested-group) member carries AdminCount=1:

Get-ADUser -Filter * -Properties AdminCount, MemberOf | Where-Object { $_.AdminCount -ne 1 } | Select-Object SamAccountName, AdminCount

A user who appears in the recursive Domain Admins membership from the first command but shows AdminCount 0 or null in this output is an unprotected indirect member and confirms the trap.

Correction

The correction is to remove group nesting from privileged group membership and grant privileged access only through direct, individually accountable membership. In a lab or change-controlled maintenance window, remove the nested group from Domain Admins and, where continued elevated access is genuinely required, add the specific accounts directly so that SDProp protects them correctly:

Remove-ADGroupMember -Identity "Domain Admins" -Members "NestedGroupSamAccountName" -Confirm

This is a state-changing action. Scope: affects only the specified nested group’s membership in Domain Admins; it does not delete the nested group or its own members. Risk: state_changing, not destructive, because membership can be re-added if a business justification is subsequently confirmed. Evidence required before running: the recursive membership and AdminCount cross-reference from the diagnosis step, plus explicit change-approval confirming the nested group’s presence was unintended or unauthorised. Stop condition: do not proceed if any currently on-call privileged workflow depends on that nested group’s membership without a documented replacement access path.

Validation

Validation confirms the nested group no longer appears in either direct or recursive Domain Admins membership and that no account still has orphaned elevated rights. Re-run the direct and recursive membership queries from the diagnosis step and confirm the previously nested group is absent from both outputs. Then confirm AdminCount has not left stale protected ACLs on accounts that no longer require them by re-running the AdminCount cross-reference query and reviewing any AdminCount=1 accounts that are no longer members of any protected group; these require a separate, deliberate cleanup decision and are not resolved by this change alone. Pass condition: Domain Admins recursive membership contains only individually reviewed, directly added accounts, and every account in that list shows AdminCount=1.

Rollback

Rollback boundary: reversing this change restores the previous access relationship but does not retroactively resolve any exposure that occurred while the nested group was in place; treat prior access during the exposure window as a separate investigation item. If the removed nested group’s access is confirmed as required after the change, restore it explicitly as documented, reviewed membership:

Add-ADGroupMember -Identity "Domain Admins" -Members "NestedGroupSamAccountName" -Confirm

Re-adding the nested group does not undo the underlying protection gap; if nesting is restored, re-run the diagnosis queries immediately afterwards to reconfirm which accounts are indirectly exposed, and record the accepted risk explicitly rather than leaving it implicit.

Prevention

Prevention requires a standing control rather than a one-time fix. Add a recurring, read-only check that compares recursive Domain Admins (and other AdminSDHolder-protected group) membership against the AdminCount-flagged population, and alert when any recursive member lacks AdminCount=1. Extend privileged-access reviews to explicitly resolve nested group membership rather than relying on direct-membership listings or on AdminCount filters alone, since both can miss indirectly privileged accounts. Where role-based delegation is needed, prefer directly managed, individually reviewed membership in protected groups over nesting role groups inside them, and document any accepted exception with its owner and review date.