Open compmgmt.msc on any Windows server or workstation, expand Local Users and Groups, click Groups, and you see roughly 20 built-in local groups staring back at you. Each one bundles a specific set of operating-system-level rights. Putting a user (or a service account) into one of these groups is the simplest way to grant a defined slice of administrative power without handing over Full Administrator.
This is Part 4 (the final part) of the Windows Permissions Deep Dive pathway. Parts 1–3 covered the design rules, the share-vs-NTFS stacking, and the NTFS Advanced Permissions dialog. Part 4 covers the OS-level counterpart: the built-in local groups that determine who can do what on the box itself.
Local groups vs domain groups — the scope distinction
The groups in Local Users and Groups are local to one machine. A user added to the local Backup Operators group on NODE-01 has backup-operator rights on NODE-01 only; the same account is a regular user on NODE-02.
Domain groups (managed in Active Directory Users and Computers) live in AD and grant rights across all domain-joined machines that reference them. The two systems work together: best practice is to put domain groups into local groups. For example, you create a domain group DOMAIN\Server-Admins, then add that domain group as a member of the local Administrators group on every server. New admin? Add them to DOMAIN\Server-Admins — they automatically have local-admin on every server, without touching individual machines. This is the AGDLP / AGUDLP pattern in practice.
This article walks the built-in local groups themselves. The pattern of nesting domain groups inside them is identical regardless of which local group you target.
The 21 built-in local groups
1. Access Control Assistance Operators
Members can query and modify file and directory authorization remotely — specifically, they can pull effective-access reports across the network for troubleshooting permissions. They cannot install software, log on interactively, or change system settings. Rarely populated in small environments. Useful in large shops where a tier-2 IT person investigates access-denied tickets without needing local admin.
2. Administrators
Total control of the machine: install drivers, modify the registry, install services, change firewall rules, manage every other group. The Built-in Administrator account is in this group; on domain-joined servers, the Domain Admins domain group is nested here by default, granting domain admins local-admin on every domain machine.
This is the highest-privilege group on the box. Audit its membership ruthlessly. Every member of Administrators is a candidate for credential theft and lateral movement, so the right answer is to keep it as small as humanly possible and require MFA for any account in it.
3. Backup Operators
Bypass the ACL on every file for the express purpose of backing it up — and equally bypass the ACL when restoring. They can also shut the system down (backup software sometimes needs a maintenance reboot).
The privilege bundle (SeBackupPrivilege and SeRestorePrivilege) is dangerous because a Backup Operator can read every file on the box including SAM hashes, NTDS.dit, and BitLocker recovery passwords. Treat membership here as nearly equivalent to local admin. Reserve for genuine backup-service accounts; do not add humans here as a convenience.
4. Cryptographic Operators
Manage cryptographic configuration: enroll, install, and replace certificates, configure CNG providers, manage SSL bindings via netsh. They cannot do anything outside the cryptographic surface. Useful when a non-admin web-services person needs to rotate certificates without getting Administrators rights.
5. Device Owners
Modern group (Windows 10/11 era), partially designed for tablet / kiosk / shared-device scenarios. Members can manage some device settings like Bluetooth pairings, USB device installation, and certain personalization controls without admin rights. Rarely used in server environments. If you see it populated on a server, it is usually a leftover from imaging.
6. Distributed COM Users
Allowed to launch, activate, and use Distributed COM (DCOM) objects on the machine. DCOM is the legacy RPC plumbing behind a handful of older Windows technologies including older WMI scenarios. Modern PowerShell remoting uses WinRM, not DCOM. Tightly limit DCOM Users — it is a recurring lateral-movement attack surface.
7. Event Log Readers
Read the Security, System, and Application event logs — nothing more. Cannot clear logs, cannot modify entries, cannot tweak audit policy. Useful for tier-2 monitoring personnel, internal SOC analysts on standalone servers, and tools that need to scrape logs without elevated rights. Adding a service account here is the right move for any log-shipping agent.
8. Guests
The lowest-trust group on the machine. The default Guest account belongs here and is disabled by default for a reason. If a Guests user logs on, they get a temporary profile and almost no access to anything. Use sparingly — in modern Windows deployments, you simply do not enable Guest. If you find Guest enabled in production, that is a finding to remediate, not a feature to keep.
9. Hyper-V Administrators
Full administrative control of the Hyper-V role: create / delete VMs, modify virtual switches, change VM configurations, manage the VHDX files. They are not local admins on the host — they cannot install software outside of Hyper-V, cannot modify network adapters that are not Hyper-V virtual switches, cannot change the host’s domain membership.
This is the right group for a colleague who manages VMs on a Hyper-V host but should not have unrestricted control of the host OS. Compatible with the principle of least privilege.
10. IIS_IUSRS
The identity that hosted IIS application pools run under. You do not typically add humans here. Web application pools default to the IIS APPPOOL\PoolName virtual accounts which are members of IIS_IUSRS by default. Granting this group access to a folder is how you allow IIS to read the website’s content directory.
11. Network Configuration Operators
Change network adapter settings: IP addresses, DNS, routes, enable/disable NICs, rename connections. Cannot install or remove networking components, cannot change firewall policy. Useful for the network team to make routing tweaks on a server without granting full admin. Common in shops where networking and server administration are separated functions.
12. OpenSSH Users
New group introduced with the OpenSSH Server optional feature in Windows. Members can connect to the machine via ssh. Without membership, an account that can otherwise log on locally will be refused over SSH. Useful for managing a Windows host from Linux clients or from PowerShell over SSH, without needing to enable WinRM.
13. Performance Log Users
Schedule and configure Performance Monitor data collection sets, run trace sessions, create event-trace logs. Members can configure logging — not just view live counters. Useful when you want a performance analyst to instrument the system without granting admin rights.
14. Performance Monitor Users
The read-only counterpart to #13. Members can view live performance data through Performance Monitor but cannot create or modify data collector sets. Good for tier-1 monitoring staff.
15. Power Users
Deprecated. Power Users existed on Windows 2000 / XP / 2003 as a middle ground between regular Users and Administrators — they could install applications, modify some system settings, change time, etc. The category went away with Vista when UAC took over the “elevate when needed” role. The group is kept for backward compatibility but grants no special rights on modern Windows.
If your environment still relies on Power Users behavior, it is signaling that an old line-of-business app expects it — investigate the application, not the group.
16. Remote Desktop Users
Permission to log on via Remote Desktop Protocol (RDP). By default, only Administrators can RDP to a machine. Adding a user to Remote Desktop Users grants RDP access without granting admin rights — they get an interactive desktop with whatever else their account permissions allow.
This is the right group for non-admin users who occasionally need to use a remote machine’s desktop, for example developers using a shared lab box.
17. Remote Management Users
The RDP-equivalent for WinRM-based management. Members can connect via PowerShell Remoting (Enter-PSSession, Invoke-Command), Server Manager remote management, and WMI over WinRM. They do not get an interactive desktop, only WinRM access. Modern Windows administration leans heavily on this group — it is far more useful in 2025 than Remote Desktop Users for day-to-day server admin.
18. Replicator
Legacy group used by the (long-deprecated) File Replication Service. On modern Windows it is still listed but unused. Do not add users here. On domain controllers, the actual AD replication is handled by DFSR or the AD replication subsystem, neither of which use this group.
19. System Managed Accounts Group
Automatically managed by Windows. Contains the special NT SERVICE\ accounts used by Windows services. You do not modify this manually — Windows manages membership as part of service installation. Useful to know it exists so you do not panic when you see service-named principals listed here.
20. User Mode Hardware Operators
Modern, narrow group for handling certain user-mode hardware operations — for example, USB device installation prompts that older systems pushed straight to admin. Rare in server environments. May not exist on every SKU.
21. Users
The default group every non-admin user automatically belongs to. Members can log on locally, run programs, read most public areas of the file system, use printers, and modify their own profile. Cannot install software system-wide, cannot change machine-wide settings, cannot RDP unless also in Remote Desktop Users.
On domain-joined machines, the special group Authenticated Users is automatically a member of local Users, which is what gives any authenticated domain account the baseline ability to log on to any domain machine.
The half-dozen groups you actually use
Out of the 21 built-in groups, only six see real day-to-day use in modern Windows environments:
- Administrators — the small list of people / service accounts that genuinely need full control. Goal: keep tiny.
- Remote Desktop Users — non-admin RDP access.
- Remote Management Users — non-admin WinRM/PowerShell remoting.
- Backup Operators — the service account that runs your backup software.
- Event Log Readers — log-shipping agents and analyst accounts.
- Hyper-V Administrators — on Hyper-V hosts only, for non-admin VM operators.
The others either get populated by Windows itself (System Managed Accounts, IIS_IUSRS), exist for compatibility (Power Users, Replicator), or address a corner case you can investigate when it comes up.
Adding members — the right pattern
Within Computer Management, right-click any group, choose Properties, click Add, type the user or group name, click Check Names, click OK.
The right pattern, every time:
- Create a domain security group with a meaningful name, e.g.
DOMAIN\Servers-RDPUsers - Add that domain group as a member of the local group, e.g. local
Remote Desktop Users - From then on, manage who has access by managing domain group membership — never touch the local group again
This is just Rule 1 of Part 1 applied to OS-level rights: assign permissions to groups, not users. The wrinkle is that the local group is itself the “permission target” here — you nest a domain group into it.
From the command line, the equivalent is net localgroup:
net localgroup "Remote Desktop Users" "DOMAIN\Servers-RDPUsers" /add
PowerShell equivalent (Windows Server 2016+):
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\Servers-RDPUsers"
Things that bite people
Adding humans directly to local groups on individual servers
You will not remember six months later which servers you visited. Use the domain-group-nested-in-local-group pattern even for a single server — ten extra seconds, weeks of saved untangling later.
Backup Operators on user-facing servers
Backup Operators on a domain controller, file server, or other sensitive system is effectively local admin because it can read every protected file. Audit it as carefully as Administrators.
Power Users still listed in documentation
Older documentation and some compliance frameworks still mention Power Users. On modern Windows, this group does nothing — it is kept for legacy app compatibility. Migrate references away.
Built-in Administrator left enabled
The built-in local Administrator account (RID 500) is enabled by default in some Windows Server editions. Disable it after creating named admin accounts, or at minimum rename it and rotate the password regularly. CIS benchmarks call this out explicitly.
Domain Admins in every server’s local Administrators
Default behavior puts Domain Admins into every machine’s local Administrators group. This is the path for Golden-Ticket-style attacks: compromise one machine, capture a Domain Admin token, pivot to the domain controller. Tiered-administration models explicitly remove Domain Admins from server local Administrators groups and use a separate Server-Admins group instead.
Adding service accounts to Administrators “to avoid problems”
Service accounts almost never need full local admin. They need specific rights: log-on-as-a-service, write to a specific directory, read certain registry keys. Granting admin to the service account because troubleshooting was hard is how environments accumulate over-privileged service accounts that survive forever.
RDP works for one user, not another — check both groups
RDP requires the account to be either in Administrators or Remote Desktop Users and have the “Allow log on through Remote Desktop Services” user right (set via Group Policy or secpol.msc). The user right is a separate hurdle from group membership.
The pathway recap
Four-part series complete. Across the pathway:
- Part 1 — The Five Golden Rules — the design principles that prevent ACL chaos
- Part 2 — Share vs NTFS Stacking — how the two file permission layers combine
- Part 3 — NTFS Advanced Permissions — the 14 special permissions behind the basic Security tab
- Part 4 (this article) — Local Groups in Windows — the built-in OS-level role groups
With these four pieces, the Windows permissions model is no longer a black box. Files and folders go through Share-then-NTFS stacking. The NTFS layer is built from 14 special permissions bundled into friendly basic names. Access to the operating system itself is delegated through the 21 built-in local groups. Designed cleanly per the five rules, the whole system collapses into a small, auditable, maintainable model.
What’s next
This pathway covered the conceptual model. Future hands-on pathways will cover practical deployments: Active Directory delegation (using these rules and groups for real-world OU management), file server hardening (auditing, encryption, classification), and JEA (Just Enough Administration) for PowerShell-based delegated admin without granting local-admin rights. Pathway index: Windows Permissions Deep Dive.