Every Windows VPS ships with a built-in Administrator account, and far too many servers spend their entire life with every login routed through it. One leaked or guessed password then equals total control of the machine \u2014 no second layer, no audit trail that means anything. The fix is a boring, effective discipline called least privilege: standard accounts for daily work, separate administrative accounts for elevated tasks, and RDP rights granted only to the people who need them.<\/p>\n\n
This works on any Windows Server edition you can rent, but it is easier when the provider gives you console access for recovery. Compare Windows VPS plans on our comparison table<\/a> and note which ones include out-of-band console access \u2014 you will want it the day you lock yourself out.<\/p>\n\n Create a normal user and keep it out of the Administrators group:<\/p>\n\n Standard users can run applications and browse the web, but they cannot install software, change system settings, or touch other users’ data \u2014 which is exactly the blast radius you want when an account gets compromised.<\/p>\n\n Membership in the Remote Desktop Users<\/strong> group is enough to log on over RDP:<\/p>\n\n A user in this group can establish a session but still cannot elevate. When the user needs to perform an administrative task, have them use Run as administrator<\/strong> and supply the admin credentials \u2014 the action is then auditable and scoped.<\/p>\n\n Create one dedicated administrator account for break-glass and elevated work, instead of using the built-in one:<\/p>\n\n Only after the new admin works, rename the built-in Administrator (or disable it):<\/p>\n\n Never disable the built-in account until you have verified you can log on with the replacement \u2014 and always keep provider console access as the final recovery path.<\/p>\n\n Check your current membership at any time with Minimum length and lockout thresholds stop the most common attacks:<\/p>\n\n Combine this with the RDP hardening steps \u2014 NLA, a non-default port, and source IP restrictions \u2014 so credentials are never the only line of defense.<\/p>\n\n For teams, document the policy in one short page: who has admin, who has standard access, and how to request elevation. The documentation takes fifteen minutes to write and prevents the slow drift back to \u201ceveryone just logs in as Administrator\u201d that undoes all of this work within a quarter.<\/p>\n\n Open Turn on logon auditing and review successes and failures:<\/p>\n\n Event ID 4624 is a successful logon, 4625 a failure. Check for logons at odd hours or from unexpected source IPs:<\/p>\n\n Auditing is only useful if someone reviews it. Skim the log weekly, and consider forwarding the Security log to a central log collector if you manage more than one VPS.<\/p>\n\n Scheduled tasks and application pools should never run under a human account. Create dedicated local service accounts with only the rights the job needs, then register the task with that identity:<\/p>\n\n If a task must touch a network share, use a managed service account or a domain account with a tightly scoped ACL instead of granting the interactive Administrator account to the scheduler.<\/p>\n\nCreate a Standard User for Daily Work<\/h2>\n\n
$pw = ConvertTo-SecureString \"Long-Random-Passphrase-42\" -AsPlainText -Force\nNew-LocalUser -Name \"devops\" -Password $pw -FullName \"DevOps User\"<\/code><\/pre>\n\nGrant RDP Access Without Admin Rights<\/h2>\n\n
Add-LocalGroupMember -Group \"Remote Desktop Users\" -Member \"devops\"<\/code><\/pre>\n\nKeep a Separate Admin Account<\/h2>\n\n
$apw = ConvertTo-SecureString \"Another-Long-Passphrase-77\" -AsPlainText -Force\nNew-LocalUser -Name \"svcadmin\" -Password $apw -FullName \"Service Admin\"\nAdd-LocalGroupMember -Group \"Administrators\" -Member \"svcadmin\"<\/code><\/pre>\n\nRename-LocalUser -Name \"Administrator\" -NewName \"LocalAdmin-Renamed\"\n# or: Disable-LocalUser -Name \"Administrator\"<\/code><\/pre>\n\nwhoami \/groups<\/code> or list all local users with Get-LocalUser<\/code>. You should be able to explain, for every account on the box, who owns it and why it has the rights it has. If you cannot, that account is a liability.<\/p>\n\nEnforce Password and Lockout Policies<\/h2>\n\n
net accounts \/minpwlen:14 \/maxpwage:90 \/lockoutthreshold:5 \/lockoutduration:30 \/lockoutwindow:30<\/code><\/pre>\n\nControl Who Can Log On via RDP<\/h2>\n\n
secpol.msc<\/code> \u2192 Local Policies<\/strong> \u2192 User Rights Assignment<\/strong> \u2192 Allow log on through Remote Desktop Services<\/em>. Remove groups that should not have remote access and keep only the specific users or the Remote Desktop Users group. This gives you an explicit allowlist at the policy level, independent of firewall rules.<\/p>\n\nAudit Logon Events<\/h2>\n\n
auditpol \/set \/subcategory:\"Logon\" \/success:enable \/failure:enable<\/code><\/pre>\n\nGet-WinEvent -FilterHashtable @{LogName='Security'; Id=4624} -MaxEvents 20 | Select-Object TimeCreated, @{n='User';e={$_.Properties[5].Value}}<\/code><\/pre>\n\nService Accounts for Scheduled Tasks<\/h2>\n\n
schtasks \/create \/tn \"NightlyBackup\" \/tr \"powershell.exe -File C:\\Scripts\\backup.ps1\" \/sc daily \/st 02:00 \/ru \"NT AUTHORITY\\SYSTEM\"<\/code><\/pre>\n\nAccount Type Quick Reference<\/h2>\n\n