Cómo crear un usuario en VPS Windows para compartir acceso
Aprende a crear cuentas de usuario en Windows Server para compartir el acceso a tu VPS sin exponer la contraseña del administrador, con permisos controlados.
Compartir la contraseña del administrador de la VPS Windows con todo el equipo parece práctico al principio pero se vuelve un problema rápidamente: pierdes el registro de quién hizo cada cambio, cualquier persona puede instalar software arbitrario y la rotación de contraseña debe propagarse manualmente. Crear cuentas individuales con permisos adecuados resuelve esos tres problemas de una sola vez.
Este tutorial muestra cómo crear usuarios locales en Windows Server, conceder acceso remoto vía RDP de forma controlada y revocar el acceso cuando alguien deja el equipo. Los pasos funcionan en Windows Server 2019, 2022 y 2025. Tiempo estimado: 10-15 minutos para configurar 2-3 usuarios.
La persona típica aquí es el administrador de una VPS Windows que necesita dar acceso a colaboradores — desarrollador que necesita publicar una aplicación, diseñador que necesita probar un build, soporte que necesita investigar un problema — sin entregar las llaves del reino.
Requisitos previos
Necesitas una VPS con Windows Server 2019/2022/2025, acceso RDP actual como Administrator y el puerto 3389 (o el puerto personalizado del RDP) abierto en el firewall para las IPs de los colaboradores que van a acceder.
Antes de empezar, decide qué nivel de acceso necesita cada usuario. La regla práctica es dar el mínimo necesario y elevar permisos solo bajo demanda — lo opuesto (dar todo y revocar después) raramente ocurre en la práctica.
Windows Server 2019+ 2 simultáneas Remote Desktop Users 3389 Creando el usuario por la interfaz gráfica
La forma más simple es vía Local Users and Groups, el snap-in MMC nativo de Windows. Sirve bien para la creación puntual de 1-3 usuarios — para volumen mayor, prefiere PowerShell (siguiente sección).
Conéctate a la VPS vía RDP como Administrator. En el menú Inicio, escribe lusrmgr.msc y presiona Enter:
lusrmgr.mscSe abre el administrador de usuarios y grupos locales. Si aparece un mensaje diciendo que el snap-in no funciona con la edición Home, no estás en Server — verifica la edición con winver.
En el panel izquierdo, haz clic en Users. En el panel derecho, haz clic derecho en un espacio vacío y selecciona New User. Completa:
- User name: nombre corto sin espacios (ej: jsilva, mlima)
- Full name: nombre completo (ej: Juan Silva)
- Description: contexto (ej: Dev — acceso temporal hasta 30/06)
- Password y Confirm password: contraseña fuerte con 16+ caracteres
Marca User must change password at next logon. Desmarca Password never expires — una contraseña que no expira es una falla de auditoría.
Haz clic en Create y luego Close. El usuario fue creado pero todavía no puede acceder vía RDP — falta agregarlo al grupo correcto. Haz clic en Groups en el panel izquierdo, haz doble clic en Remote Desktop Users, haz clic en Add, escribe el nombre del usuario y confirma con Check Names. Haz clic en OK dos veces.
Ahora el usuario puede abrir sesión RDP, pero no tiene privilegios administrativos. Ese es el estado por defecto recomendado para acceso compartido.
La política por defecto de Windows Server exige contraseña con un mínimo de 8 caracteres, con 3 de los 4 tipos: mayúscula, minúscula, número, símbolo. Si vas a crear una contraseña temporal para enviar al usuario, genérala con un generador automático — no inventes “Clave@2026” que cae en cualquier diccionario.
Creando usuarios vía PowerShell
Para crear múltiples usuarios o automatizar vía script, PowerShell es más rápido y auditable. Abre PowerShell como Administrator.
Crea una variable con la contraseña. SecureString evita que la contraseña aparezca en texto plano en el historial de PowerShell:
$password = Read-Host -AsSecureString "Ingresa la contraseña del nuevo usuario"Read-Host con -AsSecureString pide la contraseña interactivamente y la almacena en memoria de forma protegida. No escribas $password = ConvertTo-SecureString “miclave” -AsPlainText -Force en un script — el historial de PowerShell la guarda en texto puro.
Crea el usuario con New-LocalUser. Este cmdlet reemplaza al antiguo net user para la creación:
New-LocalUser -Name "jsilva" `
-Password $password `
-FullName "Juan Silva" `
-Description "Dev - acceso temporal hasta 30/06" `
-PasswordNeverExpires $false `
-UserMayNotChangePassword $falseLa flag -PasswordNeverExpires $false (default) garantiza que la contraseña respeta la política de expiración. Si no la pasas, algunos sistemas la tratan como true silenciosamente.
Agrega el usuario al grupo Remote Desktop Users:
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "jsilva"Para verificar que entró en el grupo, ejecuta Get-LocalGroupMember -Group “Remote Desktop Users”. El usuario debe aparecer con el prefijo del nombre de la máquina (NOMBREDELSERVIDOR\jsilva).
Fuerza el cambio de contraseña en el primer inicio de sesión. Este comando todavía usa net user directamente porque el equivalente puro de PowerShell no existe:
net user jsilva /logonpasswordchg:yesEn el siguiente RDP, Windows le pide al usuario que defina una contraseña nueva antes de cargar el escritorio.
Para crear 5-10 usuarios, coloca los datos en un CSV (username,fullname,description) e itera con Import-Csv | ForEach-Object. Pre-generas contraseñas temporales únicas por usuario y envías cada una por el canal seguro apropiado.
Concediendo permisos específicos
Remote Desktop Users solo otorga el derecho de abrir sesión. Para que el usuario haga trabajo real, necesita permisos sobre las carpetas, servicios o bases de datos específicos.
Evita al máximo agregar al usuario al grupo Administrators solo porque “es más simple”. Cuando se convierta en emergencia (alguien necesita ajustar el registry para instalar una app), recién ahí elevas — temporalmente — y quitas después. Los permisos granulares más comunes:
Acceso a carpeta de aplicación
Si el usuario necesita publicar archivos en una carpeta específica (ej: C:\inetpub\wwwroot\app), concede el permiso directamente en esa carpeta sin tocar el resto del sistema:
$acl = Get-Acl "C:\inetpub\wwwroot\app"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
"jsilva", "Modify", "ContainerInherit,ObjectInherit", "None", "Allow"
)
$acl.SetAccessRule($rule)
Set-Acl "C:\inetpub\wwwroot\app" $aclModify otorga lectura, escritura, eliminación y cambio de atributos — sin permitir cambiar el dueño ni la ACL. Full Control raramente es lo que quieres.
Reiniciar un servicio específico
Para permitir que el usuario reinicie un servicio (ej: el servicio de IIS o una app .NET) sin ser admin, usa sc sdset para conceder el derecho RP (start/stop) sobre el SID del usuario:
sc.exe sdset W3SVC "D:(A;;CCLCSWRPWPDTLOCRRC;;;<SID_DEL_USUARIO>)..."El comando completo es largo — busca el SID del usuario con Get-LocalUser jsilva | Select-Object SID y la SDDL actual del servicio con sc sdshow W3SVC, después agrega la entrada antes de aplicar. Permite restart sin dar admin local.
Verificando que todo funciona
Antes de avisarle al colaborador que el acceso está listo, pruébalo tú mismo desde otra máquina (o pídele que pruebe con vos acompañando por llamada).
Desde otra máquina, abre Conexión a Escritorio Remoto (mstsc) y conéctate a la IP de la VPS en el puerto correcto. Usa las credenciales del nuevo usuario:
mstsc /v:TU.IP.AQUI:3389El login debe pedir cambio de contraseña inmediatamente. Después de definir la nueva, el escritorio carga.
Dentro de la sesión, verifica que el usuario NO puede elevar privilegios. Abre PowerShell normal (sin “Run as administrator”) e intenta:
Get-Process | Stop-Process -Name explorerDebe retornar “Access denied” para procesos que no pertenecen al usuario actual. Si se ejecuta sin error, el usuario está en Administrators — revisa la configuración.
Envía usuario y contraseña por canales separados — usuario por correo corporativo, contraseña por mensaje directo efímero (Signal, WhatsApp con mensajes temporales) o gestor de contraseñas (1Password, Bitwarden). La contraseña en correo queda en backups por años.
Quitando acceso cuando alguien se va
La peor falla de auditoría común es dejar cuentas activas de gente que dejó el equipo. Establece un proceso claro: desactiva inmediatamente, elimina después de 30 días.
Disable-LocalUser -Name "jsilva"
Remove-LocalGroupMember -Group "Remote Desktop Users" -Member "jsilva"Disable-LocalUser preserva el SID y todo lo vinculado (ACLs, registros, tareas programadas). Si descubres después que algo dependía de ese usuario, basta con Enable-LocalUser para reactivarlo. Después de 30 días confirmando que nada se rompió:
Remove-LocalUser -Name "jsilva"Próximos pasos
Con los usuarios configurados, vale profundizar en capas adicionales de seguridad y gestión:
- Habilitar Network Level Authentication (NLA) en RDP — fuerza autenticación antes de cargar la interfaz gráfica, bloqueando ataques en la pantalla de login
- Configurar restricción de IPs en el Windows Firewall para que solo las IPs del equipo abran RDP
- Investigar Windows Local Administrator Password Solution (LAPS) si gestionas varias VPS Windows
- Habilitar auditoría de logon (auditpol /set /subcategory:“Logon” /success:enable /failure:enable) para registrar intentos de acceso
- Considerar cambiar el puerto por defecto 3389 del RDP para reducir ruido de scanners automáticos
Si estás poniendo una VPS Windows en producción con varios colaboradores accediendo, una VPS Hostini ofrece KVM dedicado con snapshots — útil para probar cambios de permiso sin miedo, restaurando el estado anterior en segundos si algo se rompe.
Preguntas frecuentes
¿Puedo crear usuarios sin darles acceso remoto (RDP)?
Sí. Por defecto, las cuentas locales nuevas en Windows Server no pueden iniciar sesión remota. Solo quien está en los grupos Administrators o Remote Desktop Users abre sesión RDP. Mantén al usuario fuera de esos dos grupos si solo va a ejecutar tareas locales o ser usado por servicios.
¿Cuál es la diferencia entre Administrators y Remote Desktop Users?
Administrators tiene control total: instala software, modifica el registro, ve archivos de cualquier usuario y puede conceder permisos. Remote Desktop Users solo obtiene el derecho de iniciar sesión vía RDP — los permisos reales dependen de lo que ese usuario tenga en ACLs y en otros grupos. Para acceso compartido seguro, prefiere Remote Desktop Users.
¿Cómo hago para que el nuevo usuario cambie la contraseña en el primer inicio de sesión?
Marca la opción User must change password at next logon al crearlo vía lusrmgr.msc, o ejecuta net user nombre /logonpasswordchg:yes en PowerShell. En el siguiente RDP, Windows fuerza el cambio antes de liberar la sesión. Esto evita que la contraseña temporal que enviaste siga válida indefinidamente.
¿Cuántos usuarios pueden hacer RDP simultáneamente?
Windows Server por defecto permite 2 sesiones RDP administrativas simultáneas sin licencia adicional. Para más sesiones en paralelo se necesita configurar el RD Session Host con licencias CAL. Para 3-4 personas turnándose a lo largo del día, las 2 sesiones por defecto generalmente alcanzan.
¿Cómo elimino el acceso de un usuario que dejó el equipo?
No elimines la cuenta de inmediato — desactívala primero con net user nombre /active:no. Esto preserva ACLs, tareas programadas y registros vinculados al SID. Después de 30 días confirmando que nada se rompió, recién ahí elimínala con net user nombre /delete. La auditoría queda más limpia así.
¿Puedo usar cuentas de dominio en lugar de locales?
Sí, si la VPS forma parte de un dominio Active Directory. Las cuentas de dominio centralizan la gestión y las políticas. Para una VPS aislada o pocos usuarios, las cuentas locales son más simples y suficientes — el dominio solo compensa a partir de 10-15 servidores Windows interconectados.