Why Your Windows Server Should Not Run as Administrator
Running everything under the built-in Administrator account is the single most common cause of avoidable Windows Server breaches. One compromised password gives an attacker full control, and every session on the box — interactive, service, or scheduled task — shares the same identity, so audit logs cannot tell actions apart. The fix is routine: create a limited account for daily work, keep the built-in Administrator renamed or disabled, and control exactly who can log on over RDP. This guide covers the GUI and PowerShell steps for local accounts on a standalone Windows Server VM.
What “Limited Account” Means on a Server
Local accounts on a domain-joined or standalone server fall into groups: Administrators (full control), Users (normal daily work), and Remote Desktop Users (RDP logon rights, nothing else). A limited account is a member of Users plus Remote Desktop Users — it can run applications, manage files it owns, and log in remotely, but it cannot install software, change system settings, or read other users’ profiles. That boundary is what contains the damage when the account is compromised.
Creating a Local User with the GUI
- Open Computer Management → Local Users and Groups → Users.
- Right-click → New User, enter the username and a strong password (12+ characters, mixed classes).
- Leave “User must change password at next logon” checked for humans; uncheck it for service or automation accounts.
- Right-click the new user → Properties → Member Of → Add, and add Remote Desktop Users.
Creating a Local User with PowerShell
PowerShell is faster and scriptable, which matters when you provision servers repeatedly:
$pass = ConvertTo-SecureString 'Str0ng-Passw0rd-2026!' -AsPlainText -Force
New-LocalUser -Name 'appdeploy' -Password $pass -FullName 'Deploy Account' -Description 'Daily deployment account'
Add-LocalGroupMember -Group 'Remote Desktop Users' -Member 'appdeploy'
Add-LocalGroupMember -Group 'Users' -Member 'appdeploy'Verify with Get-LocalGroupMember -Group 'Remote Desktop Users'. Only members of Administrators and Remote Desktop Users can log on via RDP by default, so leaving a user out of both groups means they cannot connect remotely at all — a useful property for service accounts.
Password and Lockout Policy
Open secpol.msc → Account Policies and set baseline values: minimum password length 12, complexity enabled, account lockout threshold 5, lockout duration 15 minutes. The lockout threshold matters most on an internet-facing VPS: it turns unlimited RDP brute-force attempts into five tries per 15 minutes, which stops the vast majority of automated attacks before they ever test a password list.
Service Accounts: Never Reuse Your Daily Login
Applications that run as Windows services — IIS app pools, SQL Server, backup agents — should each get a dedicated local account with only the permissions that service needs, and “Log on as a service” granted via secpol.msc → User Rights Assignment. If a service runs as your daily user, any compromise of the service is a compromise of your interactive account. Separate identities also mean Event Viewer shows which service failed, instead of a wall of identical entries.
Auditing Who Logs In
With distinct accounts, auditing becomes useful. Check Event Viewer → Windows Logs → Security for event IDs 4624 (successful logon) and 4625 (failed logon), or query them with PowerShell: Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625} -MaxEvents 20. A burst of 4625 events from a single source IP is the signature of a brute-force attempt; lockout policy plus a firewall rule that blocks the offending IP, as covered in our RDP hardening guide, closes that loop. Blocking at the network edge is easier when the host provides a native IPv4 firewall — another detail tracked in our Windows VPS comparison table.
A naming convention makes accounts self-documenting: u- for human users (u-jdoe), svc- for service accounts (svc-iis-pool1), and adm- for break-glass administrators. When an alert fires on an account name, the prefix tells you immediately what kind of identity was involved and which runbook to open. Record each account’s purpose in its Description field — it costs ten seconds at creation and saves hours of archaeology when someone inherits the server a year later. The same convention should extend to RDP: a limited account that only needs application access should not be a member of Administrators just because it is convenient.
Keep the Built-In Administrator Out of Reach
Rename the built-in Administrator account (secpol.msc → Local Policies → Security Options → “Accounts: Rename administrator account”) so attackers cannot assume the default name, and disable it if you have another account in the Administrators group. If you ever lock yourself out, the provider’s out-of-band console is the escape hatch — which is one reason our Windows VPS comparison table notes which hosts include console access with every plan. On a fresh server, pair this user setup with our guide to securing RDP before you expose the box to the internet.
Need a Windows Server VM where you control local accounts from the first boot? Deploy a Windows Server instance on Vultr and use its browser-based console to configure users and policies before you ever open RDP to the internet.
