Remove Users From Local Group

What the local group privilege enforcer does

This Automox Worklet™ enforces an allowlist baseline on a named local Windows group. The Worklet reads two variables from the policy: the target group name and a list of accounts that must remain in the group. Any current member not on the allowlist is removed on the next remediation.

Membership enumeration runs net localgroup "$localGroup", strips the banner and footer lines that net prints around the member list, and splits the remaining lines into account names. Removal runs net localgroup "$localGroup" /delete $user for each parsed member that is not in the $excludeUsers allowlist. The allowlist is the only protection for built-in accounts: if you want the local Administrator, an MDM service account, or a help-desk break-glass account to survive remediation, you must add it to $excludeUsers before scoping the policy.

The evaluation script counts members that are not on the allowlist and exits 0 when the count is zero, so the policy can sit on a daily cadence without generating remediation events on already-aligned endpoints. Endpoints that drift, whether through a help-desk ticket that added a temporary admin, a vendor onboarding script, or a forgotten contractor account, are returned to the baseline on the next run.

Why enforce local administrator group membership

Membership in the local Administrators group is the single highest-value privilege on a Windows endpoint. An account in that group can disable Defender, install drivers, dump LSASS, edit HKLM, and pivot laterally with stolen tokens. Former employees, expired contractor accounts, stale break-glass identities, and helpdesk accounts added during a one-off troubleshooting session accumulate quietly. By the time an auditor or an incident response team asks who can elevate on a given host, the answer is usually wider than the policy says. CIS Controls v8 Safeguard 6.8 and CIS Microsoft Windows Benchmarks both call for an explicit, reviewed list of local administrators. NIST 800-53 AC-2 and AC-6 require account management and least privilege. PCI-DSS 7 requires need-to-know access enforcement. All three break when the local Administrators group quietly grows beyond the documented allowlist.

Membership in a local group drifts faster than a small platform team can audit by hand, and the laptops that drift hardest are usually the ones off the corporate network when a GPO update fires. This Worklet enforces the local-group baseline on every Automox evaluation, so the next policy run catches an unexpected member before it becomes an audit finding or a privilege-escalation path. A user who was added to Administrators during a one-off troubleshooting session two months ago is removed automatically on the next evaluation, whether the endpoint is on the VPN, a hotel Wi-Fi, or sitting on a developer's home network.

How local group enforcement works

1. Evaluation phase: The Worklet runs net localgroup "$localGroup", filters out the banner lines (Alias name, Comment, Members, the dashed separator, and the closing "The command completed successfully" line), and splits the remainder into individual account names. Each name is compared against the $excludeUsers allowlist with PowerShell's -notin operator, which is case-insensitive. The script tallies every member that is not on the allowlist; if the count is greater than zero it writes Not Compliant and exits 1, otherwise it writes Compliant and exits 0.

2. Remediation phase: The script re-enumerates the group with the same net localgroup parse, then walks the resulting member list and calls net localgroup "$localGroup" /delete $user for each account that is not on the $excludeUsers allowlist, logging the removal target on each iteration. The next evaluation tick is the canonical proof of remediation: it re-parses the group and exits 0 only when no unauthorized members remain.

Allowlist baseline requirements

• Windows 7, Windows 10, Windows 11, or Windows Server 2008 R2 and later; the Worklet uses net localgroup, which has shipped with every supported Windows release

• Automox agent running as SYSTEM, which holds the group-management privileges needed to modify local group membership

• PowerShell execution policy that permits agent-launched scripts; the Automox agent invokes powershell.exe -ExecutionPolicy Bypass by default

• Target group name set in the $localGroup variable in both evaluation.ps1 and remediation.ps1, quoted exactly as it appears on the endpoint ("administrators", "Remote Desktop Users", "Backup Operators", or a custom security group name)

• Allowlist of approved accounts in the $excludeUsers tuple, with each entry in single quotes and entries comma-separated, for example ('HelpDeskAdmin','Administrator','ServiceAccount'); include service accounts, the local Administrator, and any help-desk break-glass account that must persist

• Account names on the allowlist matched as net localgroup prints them; a domain group nested inside the local group appears as the bare group name (for example, Workstation-Admins), so add it to the allowlist in the same form if it is intentionally permitted

• A pilot policy run on a non-production group of endpoints before scoping to the full fleet, so an over-restrictive allowlist is caught before it removes a needed account

Expected local group state after enforcement

After remediation completes, net localgroup "$localGroup" on the endpoint returns only the accounts on the allowlist. The next scheduled Automox evaluation parses the same group, finds zero unauthorized members, writes Compliant, and exits 0 without scheduling another remediation. Activity logs capture each Removing $user from Administrators group... line for audit evidence.

Validate manually by running net localgroup Administrators on a remediated endpoint and cross-checking the output against the allowlist in your policy. On Windows 10, Windows 11, and Server 2016+, Get-LocalGroupMember -Group "Administrators" | Select-Object Name, ObjectClass, PrincipalSource offers a richer view that distinguishes Local, ActiveDirectory, and MicrosoftAccount principal sources. For audit evidence, export the membership and the policy run identifier together; the Compliant exit-0 line in the next evaluation is the artifact most CIS and NIST 800-53 AC-2 reviews ask for. Re-addition of a removed account through a manual net localgroup Administrators <user> /add is detected on the next evaluation tick, and the Worklet returns the group to the baseline without operator intervention.