How to Manage Local Users and Groups on Windows Server 2025

How to Manage Local Users and Groups on Windows Server 2025

Managing local user accounts and groups is a foundational skill for any Windows Server administrator. While enterprise environments typically rely on Active Directory Domain Services for centralized identity management, every Windows Server 2025 instance also maintains a local Security Account Manager (SAM) database containing local accounts that remain active regardless of domain connectivity. Understanding how to create, modify, and audit these accounts — both through PowerShell cmdlets and the graphical Local Users and Groups MMC snap-in — is essential for securing standalone servers, managing break-glass administrator accounts, and enforcing consistent password and lockout policies across your infrastructure.

Prerequisites

• Windows Server 2025 (Standard or Datacenter edition)
• An account with local Administrator privileges
• PowerShell 5.1 or later (included with Windows Server 2025)
• The Microsoft.PowerShell.LocalAccounts module (included in-box)
• Basic familiarity with PowerShell execution and the MMC console

Step 1: Exploring Existing Local Users with PowerShell

Before making changes, audit what local accounts already exist on the server. The Get-LocalUser cmdlet returns all local user accounts from the SAM database, including their enabled state, description, and last logon time.

# List all local user accounts with key properties
Get-LocalUser | Select-Object Name, Enabled, PasswordRequired, LastLogon, Description

# Query a specific account by name
Get-LocalUser -Name "Administrator"

# Find all enabled local accounts
Get-LocalUser | Where-Object { $_.Enabled -eq $true }

# Find accounts that have never logged on
Get-LocalUser | Where-Object { $_.LastLogon -eq $null } | Select-Object Name, Enabled

Review this output carefully before provisioning new accounts. Windows Server 2025 ships with two built-in accounts: Administrator (disabled by default in domain-joined scenarios) and Guest (always disabled). Confirm Guest remains disabled — it should never be enabled on a production server.

Step 2: Creating and Configuring Local User Accounts

Use New-LocalUser to create accounts. Always supply a strong password and a meaningful description so future administrators know the account’s purpose without having to guess.

# Create a secure password object — avoid plaintext passwords in scripts
$SecurePass = Read-Host -AsSecureString -Prompt "Enter password for new account"

# Create a standard local user account
New-LocalUser -Name "svc_backup" `
              -Password $SecurePass `
              -FullName "Backup Service Account" `
              -Description "Used by Veeam backup jobs — created 2025-05-17" `
              -PasswordNeverExpires $true `
              -UserMayNotChangePassword $true

# Create an interactive admin account with expiring password
New-LocalUser -Name "localadmin_ops" `
              -Password $SecurePass `
              -FullName "Operations Local Admin" `
              -Description "Break-glass local admin — rotate password quarterly" `
              -AccountExpires ([datetime]"2026-12-31") `
              -PasswordNeverExpires $false

After creation, you can modify account properties at any time with Set-LocalUser.

# Update the description of an existing account
Set-LocalUser -Name "svc_backup" -Description "Veeam B&R 12 service account — updated 2025-05-17"

# Disable an account without deleting it
Disable-LocalUser -Name "localadmin_ops"

# Re-enable it later
Enable-LocalUser -Name "localadmin_ops"

# Force a password reset on next logon (requires interactive logon, not applicable to service accounts)
Set-LocalUser -Name "localadmin_ops" -Password $SecurePass

Step 3: Managing the Built-in Administrator Account

The built-in Administrator account (SID ending in -500) cannot be deleted or locked out, making it a valuable recovery tool — but also a high-value target. Windows Server 2025 disables it by default when a server is domain-joined. Maintain it as a true break-glass account: rename it, set a strong randomized password stored in a vault, and keep it disabled except during active recovery scenarios.

# Check current state of the built-in Administrator account
Get-LocalUser -Name "Administrator" | Select-Object Name, Enabled, PasswordLastSet

# Rename the built-in Administrator to reduce attack surface
Rename-LocalUser -Name "Administrator" -NewName "WS2025_RecoveryAdmin"

# Set a strong random password (store this in your password vault immediately)
$RecoveryPass = Read-Host -AsSecureString -Prompt "Enter recovery password"
Set-LocalUser -Name "WS2025_RecoveryAdmin" -Password $RecoveryPass

# Ensure it remains disabled until needed
Disable-LocalUser -Name "WS2025_RecoveryAdmin"

Step 4: Working with Local Groups

Local groups control what permissions local and domain accounts have on the server. The built-in Administrators, Remote Desktop Users, and Remote Management Users groups are the most security-sensitive and should be audited regularly.

# List all local groups
Get-LocalGroup | Select-Object Name, Description

# Create a custom local group for application access
New-LocalGroup -Name "AppServer_Operators" `
               -Description "Members can restart app services but have no admin rights"

# Add a local user to a group
Add-LocalGroupMember -Group "AppServer_Operators" -Member "svc_backup"

# Add a domain account to a local group (requires domain connectivity)
Add-LocalGroupMember -Group "Administrators" -Member "CONTOSOServer_Admins_GG"

# Inspect group membership
Get-LocalGroupMember -Group "Administrators" | Select-Object Name, ObjectClass, PrincipalSource

# Remove a member from a group
Remove-LocalGroupMember -Group "Administrators" -Member "localadmin_ops"

Step 5: Configuring Password and Account Lockout Policies

Local password policy is configured separately from Active Directory’s fine-grained password policies. On standalone servers, use net accounts or the Local Security Policy MMC (secpol.msc) to enforce minimum standards. Note that on domain-joined servers, domain GPO password policy overrides local policy for domain accounts, but local accounts remain governed by the local policy.

# View current local account policy settings
net accounts

# Set password policy: minimum length 14 chars, max age 90 days, history 24 passwords
net accounts /MINPWLEN:14 /MAXPWAGE:90 /MINPWAGE:1 /UNIQUEPW:24

# Set account lockout policy: lock after 5 bad attempts, 30-minute lockout duration
net accounts /LOCKOUTTHRESHOLD:5 /LOCKOUTDURATION:30 /LOCKOUTWINDOW:30

# Verify the updated policy
net accounts

For more granular control, open the Local Security Policy editor and navigate to Security Settings > Account Policies. This GUI exposes the same settings but also allows configuring Kerberos policy and audit policy from a single interface.

Step 6: Using the Local Users and Groups MMC Snap-in

Some tasks are easier through the graphical interface, particularly when onboarding less experienced team members or performing one-off account resets. Open the MMC snap-in directly from PowerShell:

# Open Local Users and Groups MMC
lusrmgr.msc

# Alternatively, access via Computer Management
compmgmt.msc

Within lusrmgr.msc, right-click any user to access Properties, where you can set account expiration dates, specify profile paths, assign logon scripts, and configure Remote Desktop Services profile settings. These advanced properties are not exposed through the Set-LocalUser cmdlet and require either the MMC or direct registry/WMI manipulation.

Step 7: Removing Accounts and Auditing Changes

When an account is no longer needed, remove it promptly. Before deletion, document which groups the account belonged to in case you need to recreate it.

# Document group memberships before removal
$AccountName = "localadmin_ops"
Get-LocalGroup | ForEach-Object {
    $group = $_.Name
    Get-LocalGroupMember -Group $group -ErrorAction SilentlyContinue |
        Where-Object { $_.Name -like "*$AccountName*" } |
        Select-Object @{N='Group';E={$group}}, Name
}

# Remove the account
Remove-LocalUser -Name "localadmin_ops"

# Verify deletion
Get-LocalUser -Name "localadmin_ops" -ErrorAction SilentlyContinue

Local Accounts vs. Domain Accounts: Key Differences

Understanding when to use local vs. domain accounts helps you make the right architectural decisions.

• Local accounts are stored in the SAM on each individual server. They work without network connectivity, making them ideal for recovery scenarios. However, they cannot be managed centrally and must be maintained on each server individually — a significant operational burden at scale.
• Domain accounts are stored in Active Directory and can be centrally managed, audited, and governed by Group Policy. They require domain controller connectivity to authenticate (unless cached credentials exist).
• Microsoft Accounts and Azure AD accounts can also be used with Windows Server 2025, though this is uncommon in traditional server deployments.
• For service accounts on domain-joined servers, prefer Group Managed Service Accounts (gMSA) over local accounts — gMSAs have automatically rotating passwords and can be used across multiple servers.

Best Practices for Local Admin Management

• Audit local Administrators group membership monthly. Unauthorized additions are a common lateral movement technique in ransomware attacks.
• Use Microsoft LAPS (Local Administrator Password Solution) to automatically randomize and vault the local Administrator password on every managed server. Windows Server 2025 supports Windows LAPS natively via Set-LapsADPasswordExpirationTime and related cmdlets.
• Never share a single local admin account across multiple servers. Use LAPS or a secrets manager to maintain unique credentials per host.
• Disable unused built-in accounts (Guest is disabled by default; ensure it stays that way).
• Enable auditing of account management events in Local Security Policy so that account creation, deletion, and group membership changes are recorded in the Security event log (Event IDs 4720, 4722, 4723, 4724, 4725, 4726, 4732, 4733).

Managing local users and groups may seem straightforward, but it is frequently the source of privilege escalation vulnerabilities and audit findings on Windows Server environments. By combining PowerShell automation for consistency, the MMC for detailed property editing, and strong password and lockout policies enforced through net accounts or GPO, you can maintain a well-governed local identity posture on every Windows Server 2025 host in your environment. Regular reviews — ideally integrated into a quarterly access recertification process — will ensure that only legitimate accounts with justified privileges remain active.