Windows Server 2025 / How to Manage Local Users and Groups

A local user belongs to one Windows Server installation; a local group collects accounts to which that server can assign rights. Separate everyday and administrative accounts, and grant only the memberships needed for the task.

Distinguish local and domain identities

The local labuser on FS1 is managed by FS1. Creating the same name on another server creates a different identity. Domain accounts are managed in Active Directory and can authenticate across joined computers.

Perform this lab on FS1 before it becomes a domain controller. A controller does not expose ordinary member-server local account management in the same way; a missing Local Users and Groups node on DC1 is not itself an error.

Create the user and group in the GUI

1. Sign in as an administrator on FS1 and run compmgmt.msc.
2. Open System Tools → Local Users and Groups → Users, then create a new user.
3. Create labuser with a unique password. Choose password-change conditions appropriate to the planned sign-in method and policy.
4. Create a group named LabReaders and add labuser. Do not add it to Administrators.

LabReaders is your own group name and does not change with the Windows interface language. Built-in group display names can be localized, so check descriptions and members as well as names.

Membership alone does not grant file access or remote sign-in. You must separately assign the group permissions on a resource or rights in the applicable logon policy.

Create the equivalent configuration with PowerShell

Do not recreate names that already exist from the GUI exercise. On FS1 without these objects, use elevated 64-bit Windows PowerShell. New-LocalUser accepts a SecureString password:

$labPassword = Read-Host 'Password for labuser' -AsSecureString
New-LocalUser -Name 'labuser' -Password $labPassword -Description 'Lab standard user'
New-LocalGroup -Name 'LabReaders' -Description 'Lab read access group'
Add-LocalGroupMember -Group 'LabReaders' -Member "$env:COMPUTERNAME\labuser"
Get-LocalGroupMember -Group 'LabReaders'

The final command should list FS1\labuser in LabReaders. Do not put the password in source code or use a passwordless shortcut. Check platform support in the LocalAccounts module reference.

Verify account state and the actual user session

Check creation separately from effective access. Get-LocalUser shows whether the account is enabled; group membership queries show assignments. Run whoami in the actual standard user’s session, not in an administrator’s window.

Get-LocalUser -Name 'labuser' | Select-Object Name,Enabled,LastLogon
Get-LocalGroupMember -Group 'LabReaders'
whoami
whoami /groups

An existing session can retain its original access token after membership changes. Sign out and back in before comparing results. For failed logon, check account enablement, password, keyboard language, and local versus domain identity. A deny-logon policy can override membership; granting administrator rights is not a general fix.

Disable first when an account is only temporarily unused

These commands perform opposite actions. Run only the one required:

Disable-LocalUser -Name 'labuser'
Enable-LocalUser -Name 'labuser'

Before permanently removing the lab configuration, check for permissions assigned to the group, remove membership, and then delete the group and user if they are no longer needed:

Remove-LocalGroupMember -Group 'LabReaders' -Member "$env:COMPUTERNAME\labuser"
Remove-LocalGroup -Name 'LabReaders'
Remove-LocalUser -Name 'labuser'

A recreated name has a different security identifier (SID), so previous permissions do not automatically follow it. Keep the account if later file-permission exercises need it. Before disabling any administrative account, verify another working administrator sign-in route.