Restricted Groups Local Administrators: Verify Members Before Rollout

What Restricted Groups Local Administrators Policies Actually Control

Reviewing restricted groups local administrators policies starts with a practical question: which identities must retain administrative access on each workstation or member server? A GPO entry is only one piece of evidence. Before deploying a membership baseline, compare the intended population with the actual group, inspect the policy's two membership properties, and prove which computers receive it.

This guide describes a verification and rollout procedure, checked against Microsoft documentation and the etc-collector implementation on October 4, 2026. The commands are consultation examples for an authorized Windows administrator; none was executed against a domain for this article. No membership change or deployment result is claimed.

Microsoft documents two different operations in Restricted Groups:

Microsoft supports this mechanism for local groups, not for managing membership of domain groups. Adding a domain security group to a computer's local Administrators group is a different operation from editing that domain group's own members. This runbook concerns workstations and member servers; domain controllers require a separate administration design.

The local group also differs from User Rights Assignment. Review GPO privileges such as SeDebug and SeTcb separately from local Administrators membership. A membership review cannot certify those privilege assignments.

How It Works: Read the Policy Before Interpreting the Finding

In the GPO's SYSVOL files, examine Machine\Microsoft\Windows NT\SecEdit\GptTmpl.inf, including the complete [Group Membership] section. Record the GPO GUID, display name, source domain controller, collection time and whether reading the file succeeded. Preserve the raw lines alongside the policy editor view.

The following is an illustrative template, reflecting the key format read by the collector. Angle-bracket values are placeholders, not valid SIDs or a deployable baseline:

[Group Membership]
*S-1-5-32-544__Members = *<approved-domain-group-SID>,*<approved-local-account-SID>

Identify the principal before __, then check whether the actual file contains __Members, __Memberof, both, or neither for that principal. Record an explicitly empty __Members value separately from a missing key. These distinctions cannot be recovered from an empty parsed members array alone.

Microsoft's security-template procedure shows the two editing areas: Members of this group and This group is a member of. That article describes the historical Windows Server 2003 snap-in workflow; use it to understand the properties, rather than treating its old interface or platform list as current deployment guidance.

Prefer a SID-based review when display names differ between languages. Microsoft's security identifier documentation identifies S-1-5-32-544 as built-in Administrators. Keep both the SID and resolved name in the evidence. A localized name being valid on Windows does not mean a collector's string comparison recognizes it.

Do not manually edit a production SYSVOL file to make an audit finding disappear. Review and author the intended GPO through your approved management process, then inspect the resulting file and endpoint behavior.

Detection: Establish Membership, Scope and Change Evidence

Step 1 — Capture the endpoint baseline

On each selected workstation or member server, obtain the current direct membership before changing policy. Microsoft gives this exact Get-LocalGroupMember example for an English group name:

Get-LocalGroupMember -Group "Administrators"

For a language-independent group selection, the same documentation defines the -SID parameter. This consultation example uses that documented parameter with the built-in group SID:

Get-LocalGroupMember -SID 'S-1-5-32-544'

Use a supported Windows PowerShell context; Microsoft notes that the LocalAccounts module is unavailable in 32-bit PowerShell on a 64-bit system. Save the result with the computer identity and timestamp. If the command fails, retain the error and mark that device unresolved rather than recording an empty group.

For each returned principal, record its SID, resolved account or group, operational owner and reason for access. Where a domain group is listed, separately review the people and nested groups entitled through it. The direct local member list alone does not answer who ultimately receives access through that group.

Step 2 — Prove the computer receives the intended policy

Review GPO links, computer configuration status, security filtering, WMI filtering and inheritance. Include representative devices from the intended scope and devices that should remain outside it. Do not infer application from a descriptive GPO name or the presence of its file in SYSVOL.

Microsoft documents gpresult for Resultant Set of Policy information. These read-only examples combine its documented computer scope and output switches:

gpresult /scope computer /r
gpresult /scope computer /h computer-policy.html

The first displays a summary; the second saves an HTML report. Run them in an authorized context that can obtain computer policy data. Retain the applied and denied GPO evidence, timestamp and any reporting errors. On ARM64, Microsoft's page specifies the SysWow64 gpresult executable for the HTML option.

Use RSoP to investigate application and precedence, then corroborate the actual membership on the endpoint. Neither a report nor a readable template substitutes for that final observation.

Step 3 — Identify other membership writers

Inventory Group Policy Preferences Local Users and Groups items, their actions and targeting. Microsoft's Group Policy Preferences reference lists this extension as a mechanism for changing local users and groups. Also ask the device-management owner about scripts and MDM profiles affecting the same group.

For MDM-managed devices, inspect the LocalUsersAndGroups Policy CSP. Its Update action can add or remove specified members while preserving unspecified members; Restrict replaces membership. For this CSP's Restrict action on built-in Administrators, include the built-in Administrator account in the add-member list; Microsoft documents an error if a replacement attempts to remove it. The documentation warns that applying both the LocalUsersAndGroups and RestrictedGroups CSP policies to one device is unsupported. That warning concerns the two named CSP policies; it is not a universal precedence rule for every GPO/MDM combination.

Document which system owns membership for each device population. Resolve overlapping instructions before the pilot; do not guess which writer will leave the final state you intended.

Step 4 — Monitor additions and removals

Microsoft's event pages verify these Security-log records under Audit Security Group Management:

Collect from the relevant endpoints, not only domain controllers. For this workflow, select events whose TargetSid is S-1-5-32-544, and retain the computer, time, MemberSid, subject identity and SubjectLogonId. Verify successful audit collection and forwarding before relying on an absence of events.

Compare changes with the deployment record and application tests. An unexpected addition after a policy refresh can justify investigating another management source or manual change; it does not by itself identify the responsible GPO or establish an attack. These events describe membership changes, not the complete current member list.

Remediation: Roll Out an Approved Membership Baseline

Step 1 — Approve the access population

Create separate baselines where workstation and server roles have different needs. For every retained principal, require an owner, purpose and scope. For every proposed removal, ask the affected application or support owner to validate the impact. Record exceptions with their device population, justification and review date.

Use the tiered administration model to define owners, administrative populations and logon boundaries. A local membership baseline belongs inside that architecture; it does not replace the decision about where those identities may sign in.

Step 2 — Establish a usable recovery route

Before replacement, test the approved recovery process on pilot devices. Confirm the designated local administrative account, its required membership and the authorized team's ability to recover access if normal domain administration fails. Keep credentials out of policy-review exports and shared evidence files.

Windows LAPS manages and backs up local administrator account passwords on supported joined devices. For a LAPS-managed recovery account, verify password management and authorized retrieval separately from the account's membership and usable sign-in route. Merely having a LAPS policy does not complete the recovery test.

Step 3 — Prepare the policy and pilot gates

Back up the existing GPO and retain the previous member observations. Prepare the approved list in the policy editor, review the resulting template, and define the pilot's exact links and filters. Agree on rollback responsibilities and a restoration procedure for membership, not just the GPO configuration.

Do not assume removing a GPO link will recreate every member removed during enforcement. Require a tested recovery procedure that restores necessary access and addresses the authoritative membership writer. Pause if collection, ownership, name resolution or scope remains uncertain.

Step 4 — Validate after application

Deploy through the approved change process to the pilot population. Once policy processing has occurred, repeat the membership and gpresult consultation commands above. Compare the before-and-after SIDs with the approved list and documented built-in account behavior. Review additions and removals during the window.

Ask application and support owners to test their real administrative tasks, maintenance jobs and recovery access. Repeat observations after subsequent policy processing or device-management activity to expose conflicting writers. An inaccessible device or failed application test remains an open rollout gate.

Step 5 — Expand only from recorded evidence

Advance by device role or administrative population after the pilot owner accepts the results. Preserve exceptions explicitly, rather than hiding them in a broader group. Schedule later membership reviews and alerts for departures from the approved state. Keep excluded and unobserved devices visible in the report.

How EtcSec Detects This

EtcSec's M29_LOCAL_ADMIN_NOT_RESTRICTED check is a configuration review signal. The etc-collector source was read at commit 15fc6399c215eabc415c370b762303cfcd7a353a, including m29_local_admin.go:38, gptmpl_parser.go:367 and SMB client.go:154 and :214.

The actual Detect() branches are:

Count 1 is this detector's signal, not a count of affected computers. The matcher does not accept other localized names. It does not evaluate MembersSIDs, MemberOfSIDs, the approved access population, GPO links or applicability, or actual endpoint membership.

The parser aggregates Members and Memberof into one specification per principal and creates that specification before checking the suffix. An empty Members value and an absent Members property are indistinguishable in the resulting members array. A matching specification with only Memberof can therefore suppress the finding without establishing a Members replacement baseline.

The SMB provider populates the policy values when reading GptTmpl.inf succeeds. It still inserts a policy object when that read fails. For this check, a failed read can resemble missing configuration; the finding does not expose a dedicated collection-success distinction. A matching entry in a GPO outside a computer's effective scope can also suppress the signal.

The rollout decision should identify the exact policy, approved populations, pilot observations, recovery test and unresolved devices. A quiet detector alone is insufficient evidence to close that decision.