Remove local admin rights from users without chaos

Local administrator rights are the quiet enabler behind most workstation compromises. A phishing payload running as a standard user is contained: it cannot install a driver, turn off Defender, read LSASS memory or plant a service. The same payload running in an admin session can do all of that, and usually does within minutes. Microsoft's own mitigation reports have long shown that a large share of critical vulnerabilities are far less exploitable without admin rights.

The Accounts & Privileged Access pillar covers the architectural side: admin tiering and unique local passwords with LAPS. This guide is the practical project that sits between them: getting everyday users out of the local Administrators group and keeping them out, without flooding the helpdesk.

Step 1: inventory who is an admin today

You cannot remove what you have not measured. Local group membership drifts through old imaging scripts, helpdesk shortcuts ("I'll just add you for now"), vendor installers and the Microsoft Entra join defaults. Collect it from every device before you change anything.

On a single machine:

Get-LocalGroupMember -Group "Administrators" |
  Select-Object Name, ObjectClass, PrincipalSource

Get-LocalGroupMember throws an error when the group contains orphaned SIDs (accounts that were deleted from the domain). If that happens, fall back to net localgroup Administrators or query through ADSI, and treat every orphaned SID as a cleanup item.

Across the fleet, run the same query through your management tool (Configuration Manager hardware inventory, an Intune remediation script, or Invoke-Command against a list of machines) and collect the output centrally:

$computers = Get-ADComputer -SearchBase "OU=Workstations,DC=corp,DC=example" -Filter * |
  Select-Object -ExpandProperty Name
Invoke-Command -ComputerName $computers -ScriptBlock {
  Get-LocalGroupMember -Group "Administrators" -ErrorAction SilentlyContinue |
    Select-Object @{n="Computer";e={$env:COMPUTERNAME}}, Name, ObjectClass
} | Export-Csv .\local-admins.csv -NoTypeInformation

Sort the results into three buckets:

Domain Users or Authenticated Users in the local Administrators group is more common than it should be, often from a single line in a years-old startup script. It makes every user an admin everywhere, so fix that first.

Step 2: find out why users have admin

For each user in the "individual users" bucket, find the reason before you pull the right. Typical reasons, and what replaces them:

• Installing software. Publish it in Company Portal, Software Center or a curated winget repository, deployed in system context.
• Printers and drivers. Deploy printers and packaged drivers centrally. Do not weaken Point and Print restrictions to compensate.
• Developer tools. Developers often need elevation for a handful of tools (Hyper-V, WSL features, local certificates, debuggers). Handle them with elevation rules, a dedicated dev VM, or a separate admin account on a separate device.
• Line-of-business apps that "need admin". Usually the app writes to Program Files or HKLM. Process Monitor shows exactly where; granting modify rights on one folder or key is far safer than admin on the whole machine.
• Changing network settings, time zone, VPN. Standard users can already change the time zone, and most VPN clients run a service. Test before assuming.

A two-week survey where you ask users with admin rights what they used them for, combined with software install logs, usually shows that most never needed them.

Step 3: enforce membership with Group Policy

Removing users once is not enough; you need policy to own the group so it cannot drift back.

Option A: Group Policy Preferences. Under Computer Configuration > Preferences > Control Panel Settings > Local Users and Groups, create a new Local Group item:

• Action: Update
• Group name: Administrators (built-in)
• Tick Delete all member users and Delete all member groups
• Add the members you want: your Tier 2 admin group and, if you manage it by name, the built-in Administrator

On each refresh, the group is emptied and rebuilt from the list. Several GPP items can target the same group, and item-level targeting lets you add, for example, a lab admin group only on lab machines.

Option B: Restricted Groups. Under Computer Configuration > Policies > Windows Settings > Security Settings > Restricted Groups, add Administrators and fill in Members of this group. This replaces the membership completely. It is simple and reliable when one GPO owns the group, but when several GPOs set Members of this group for the same group, only the last one applied wins, which catches people out.

Pick one mechanism, link it at the workstation OU, and make sure it applies before you remove anyone manually. Otherwise the next policy refresh from an older GPO may add people back.

Step 4: enforce membership with Intune

For Microsoft Entra joined and hybrid devices managed by Intune, use Endpoint security > Account protection > Local user group membership. This uses the LocalUsersAndGroups policy CSP. Each rule has an action:

For standardising the Administrators group, Add (Replace) is the equivalent of Restricted Groups. Include everything you want to keep, including the built-in Administrator and your support group, because anything not listed is removed.

Then stop new admins being created at join time:

• In the Microsoft Entra admin center, under Devices > Device settings, set Registering user is added as local administrator on the device during Microsoft Entra join to None (or Selected for a small group). This only affects devices joined after the change.
• In Windows Autopilot deployment profiles, set User account type to Standard.
• Use the Microsoft Entra Joined Device Local Administrator role for support staff instead of adding individuals to each device. It applies to all Entra joined devices and cannot be scoped to a subset, and changes take effect only after a new Primary Refresh Token is issued (up to 4 hours) and the user signs out and back in.

For per-device-group scoping, add Microsoft Entra groups (by SID) to the Administrators group with the Local user group membership policy above. Windows evaluates at most 20 Entra groups for admin rights, and this group-based method does not apply to Microsoft Entra hybrid joined devices.

Step 5: provide a controlled elevation path

Some users will still need to elevate specific files. Microsoft Intune Endpoint Privilege Management (EPM), licensed through the Intune Suite, Intune Plan 2 or as an add-on, and included in Microsoft 365 E5 since July 2026, lets a standard user run an approved file elevated without being an administrator. You configure two policy types:

• Elevation settings policy: turns EPM on for the device and sets the default elevation response for files that match no rule (deny, require user confirmation, or require support approval).
• Elevation rules policy: per-file rules matched on file name, hash, signing certificate and version, with an elevation type of automatic, user confirmed (with optional justification and Windows authentication) or support approved.

Prefer certificate-plus-file-name rules for signed vendor tools, and hash rules for internal utilities. Avoid rules that elevate script hosts, cmd.exe, powershell.exe, mmc.exe or installers that can launch arbitrary child processes: an elevated shell is local admin by another name.

Without EPM, the fallback is a helpdesk process where a technician enters the device's LAPS password at the UAC prompt. The password is then rotated automatically by the post-authentication action.

Step 6: keep a break-glass path

Plan for the day a device loses domain trust or cannot reach Entra ID. The break-glass account for a workstation is its LAPS-managed local administrator: unique per device, retrievable by the helpdesk reader group, rotated after use. Make sure that account is included in whichever group membership policy you applied in Steps 3 and 4, and that it is denied network and RDP logon so it only works at the console.

What breaks

• Self-installed software and browser extensions that install per-machine. Expect a burst of requests in the first two weeks; the catalogue from Step 2 absorbs most of them.
• Apps that write to protected locations at runtime. They either fail or silently write to the virtualized store (see UAC and Administrator protection). Fix permissions for the specific path.
• Scheduled tasks and scripts created by users that ran with highest privileges. Move the legitimate ones into managed deployment.
• Help desk habits. Technicians used to typing their own domain admin account into a user's machine must switch to LAPS or a Tier 2 account. That change is a security win in its own right.

Verify it

1. Re-run the inventory from Step 1 after policy applies. The only members should be the ones in policy.
2. Audit changes. Enable Audit Security Group Management under Advanced Audit Policy Configuration. The Security log then records event 4732 (a member was added to a security-enabled local group) and 4733 (a member was removed). Alert on 4732 for the Administrators group outside your change process.
3. Check Intune reporting. For the Local user group membership policy, per-device status shows conflicts and failures, typically from a GPO fighting the Intune rule on co-managed devices.
4. Confirm the user token. On a user's device, whoami /groups should not list BUILTIN\Administrators at all for the user's own session.

Checklist

• Fleet-wide inventory of local Administrators membership collected
• Domain Users, Authenticated Users and orphaned SIDs removed
• Reasons for admin rights catalogued and replaced (software catalogue, printers, folder permissions)
• One policy owns the Administrators group (GPP, Restricted Groups or Intune Replace)
• Entra join and Autopilot no longer make users local admins
• EPM or a LAPS-based helpdesk process for elevation, no shared admin accounts
• LAPS account included in policy as break-glass, denied network logon
• Event 4732 on local Administrators monitored

Removing local admin is one of the least glamorous and most effective projects on a Windows hardening plan. Once users are standard users, controls like application control become enforceable, because a standard user can no longer switch them off.