How to Create a Windows VPS User to Share Access Without the Admin Password
Learn how to create user accounts on Windows Server to share VPS access without exposing the administrator password, with controlled permissions and proper auditing.
Sharing the Windows VPS administrator password with everyone on the team feels practical at first but turns into a problem quickly: you lose track of who made each change, anyone can install arbitrary software, and password rotation has to be propagated manually. Creating individual accounts with appropriate permissions solves all three problems at once.
This tutorial shows how to create local users on Windows Server, grant RDP remote access in a controlled way, and revoke access when someone leaves the team. The steps work on Windows Server 2019, 2022 and 2025. Estimated time: 10-15 minutes to set up 2-3 users.
The typical persona here is the admin of a Windows VPS who needs to grant access to collaborators — a developer who needs to publish an app, a designer who needs to test a build, support that needs to investigate an issue — without handing over the keys to the kingdom.
Prerequisites
You need a VPS running Windows Server 2019/2022/2025, current RDP access as Administrator, and port 3389 (or the custom RDP port) open in the firewall for the IPs of the collaborators who will connect.
Before you start, decide what level of access each user needs. The practical rule is to grant the minimum required and escalate permissions only on demand — the opposite (granting everything and revoking later) rarely happens in practice.
Windows Server 2019+ 2 simultaneous Remote Desktop Users 3389 Creating the user via the graphical interface
The simplest way is via Local Users and Groups, the native Windows MMC snap-in. It works well for one-off creation of 1-3 users — for higher volumes, prefer PowerShell (next section).
Connect to the VPS via RDP as Administrator. In the Start menu, type lusrmgr.msc and press Enter:
lusrmgr.mscThis opens the local users and groups manager. If a message appears saying the snap-in does not work with the Home edition, you are not on Server — verify the edition with winver.
In the left pane, click Users. In the right pane, right-click an empty space and select New User. Fill in:
- User name: short name without spaces (e.g., jsmith, mlee)
- Full name: full name (e.g., John Smith)
- Description: context (e.g., Dev — temporary access until 06/30)
- Password and Confirm password: strong password with 16+ characters
Check User must change password at next logon. Uncheck Password never expires — a password that never expires is an audit failure.
Click Create and then Close. The user has been created but cannot yet access via RDP — you still need to add them to the right group. Click Groups in the left pane, double-click Remote Desktop Users, click Add, type the user name and confirm with Check Names. Click OK twice.
Now the user can open an RDP session, but has no administrative privileges. This is the default recommended state for shared access.
The default Windows Server policy requires a password with at least 8 characters, with 3 of the 4 types: uppercase, lowercase, number, symbol. If you are creating a temporary password to send to the user, generate it with an automatic generator — do not invent “Password@2026” that lands in any dictionary.
Creating users via PowerShell
To create multiple users or automate via script, PowerShell is faster and more auditable. Open PowerShell as Administrator.
Create a variable with the password. SecureString prevents the password from appearing in plain text in the PowerShell history:
$password = Read-Host -AsSecureString "Enter the new user's password"Read-Host with -AsSecureString prompts for the password interactively and stores it in memory in a protected way. Do not write $password = ConvertTo-SecureString “mypassword” -AsPlainText -Force in a script — the PowerShell history keeps it in plain text.
Create the user with New-LocalUser. This cmdlet replaces the old net user for creation:
New-LocalUser -Name "jsmith" `
-Password $password `
-FullName "John Smith" `
-Description "Dev - temporary access until 06/30" `
-PasswordNeverExpires $false `
-UserMayNotChangePassword $falseThe -PasswordNeverExpires $false flag (default) ensures the password respects the expiration policy. If you do not pass it, some systems silently treat it as true.
Add the user to the Remote Desktop Users group:
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "jsmith"To verify they are in the group, run Get-LocalGroupMember -Group “Remote Desktop Users”. The user should appear with the machine name prefix (SERVERNAME\jsmith).
Force a password change on first login. This still uses net user directly because the pure PowerShell equivalent does not exist:
net user jsmith /logonpasswordchg:yesOn the next RDP, Windows asks the user to set a new password before loading the desktop.
To create 5-10 users, put the data in a CSV (username,fullname,description) and iterate with Import-Csv | ForEach-Object. You pre-generate unique temporary passwords per user and deliver each one through the appropriate secure channel.
Granting specific permissions
Remote Desktop Users only grants the right to open a session. For the user to do real work, they need permissions on specific folders, services or databases.
Avoid adding a user to the Administrators group just because “it is simpler”. When it becomes an emergency (someone needs to tweak the registry to install an app), then yes — temporarily elevate and remove afterwards. The most common granular permissions:
Access to an application folder
If the user needs to publish files to a specific folder (e.g., C:\inetpub\wwwroot\app), grant permission directly on that folder without touching the rest of the system:
$acl = Get-Acl "C:\inetpub\wwwroot\app"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
"jsmith", "Modify", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$acl.SetAccessRule($rule)
Set-Acl "C:\inetpub\wwwroot\app" $aclModify gives read, write, delete and attribute changes — without allowing the owner or ACL to be changed. Full Control is rarely what you want.
Restarting a specific service
To allow the user to restart a service (e.g., IIS or a .NET app) without being admin, use sc sdset to grant the RP (start/stop) right on the user’s SID:
sc.exe sdset W3SVC "D:(A;;CCLCSWRPWPDTLOCRRC;;;<USER_SID>)..."The full command is long — look up the user’s SID with Get-LocalUser jsmith | Select-Object SID and the service’s current SDDL with sc sdshow W3SVC, then add the entry before applying. Allows restart without granting local admin.
Verifying that everything works
Before telling the collaborator that access is ready, test it yourself from another machine (or ask them to test with you watching on a call).
From another machine, open Remote Desktop Connection (mstsc) and connect to the VPS IP on the right port. Use the new user’s credentials:
mstsc /v:YOUR.IP.HERE:3389Login should immediately prompt for a password change. After setting the new one, the desktop loads.
Inside the session, verify that the user CANNOT elevate privileges. Open a normal PowerShell (without “Run as administrator”) and try:
Get-Process | Stop-Process -Name explorerIt should return “Access denied” for processes that do not belong to the current user. If it runs without error, the user is in Administrators — review the configuration.
Send username and password through separate channels — username via corporate email, password via ephemeral direct message (Signal, WhatsApp with disappearing messages) or password vault (1Password, Bitwarden). Passwords in email stay in backups for years.
Removing access when someone leaves
The most common audit failure is leaving active accounts for people who left the team. Establish a clear process: disable immediately, delete after 30 days.
Disable-LocalUser -Name "jsmith"
Remove-LocalGroupMember -Group "Remote Desktop Users" -Member "jsmith"Disable-LocalUser preserves the SID and everything tied to it (ACLs, logs, scheduled tasks). If you discover later that something depended on that user, just Enable-LocalUser to reactivate. After 30 days confirming nothing broke:
Remove-LocalUser -Name "jsmith"Next steps
With users configured, it is worth digging deeper into additional security and management layers:
- Enable Network Level Authentication (NLA) on RDP — forces authentication before loading the graphical interface, blocking attacks at the login screen
- Configure IP restrictions in the Windows Firewall so that only team IPs can open RDP
- Investigate Windows Local Administrator Password Solution (LAPS) if you manage several Windows VPSs
- Enable logon auditing (auditpol /set /subcategory:“Logon” /success:enable /failure:enable) to record access attempts
- Consider changing the default 3389 RDP port to reduce noise from automated scanners
If you are putting a Windows VPS into production with several collaborators connecting, a Hostini VPS offers dedicated KVM with snapshots — useful for testing permission changes without fear, restoring the previous state in seconds if something breaks.
Frequently asked questions
Can I create users without giving them remote (RDP) access?
Yes. By default, new local accounts on Windows Server cannot log in remotely. Only members of the Administrators or Remote Desktop Users groups can open an RDP session. Keep the user out of those two groups if they only need to run local tasks or be used by services.
What is the difference between Administrators and Remote Desktop Users?
Administrators has full control: installs software, edits the registry, sees any user's files and can grant permissions. Remote Desktop Users only gets the right to sign in via RDP — the actual permissions depend on what else that user has in ACLs and other groups. For safe shared access, prefer Remote Desktop Users.
How do I force the new user to change their password on first login?
Check the User must change password at next logon option when creating via lusrmgr.msc, or run net user name /logonpasswordchg:yes in PowerShell. On the next RDP, Windows forces the change before letting the session start. This prevents the temporary password you sent from staying valid indefinitely.
How many users can RDP simultaneously?
Standard Windows Server allows 2 simultaneous administrative RDP sessions without extra licensing. For more parallel sessions you need to configure the RD Session Host with CAL licenses. For 3-4 people taking turns throughout the day, the default 2 sessions usually suffice.
How do I remove access for a user who left the team?
Do not delete the account right away — disable it first with net user name /active:no. This preserves ACLs, scheduled tasks and logs linked to the SID. After 30 days confirming nothing broke, then delete it via net user name /delete. Audit stays cleaner that way.
Can I use domain accounts instead of local ones?
Yes, if the VPS is part of an Active Directory domain. Domain accounts centralize management and policies. For an isolated VPS or just a few users, local accounts are simpler and sufficient — a domain only pays off from 10-15 interconnected Windows servers onward.