Windows Server 2025 / Cómo administrar usuarios y grupos locales

Un usuario local pertenece a una instalación concreta de Windows Server; un grupo local agrupa cuentas para asignarles permisos y derechos en ese servidor. Separe las cuentas de uso diario de las administrativas y conceda solo la pertenencia a grupos que necesite cada tarea.

Distinguir entre identidades locales y de dominio

El usuario local labuser en FS1 es gestionado por FS1. Crear el mismo nombre en otro servidor crea una identidad diferente. Las cuentas de dominio se gestionan en Active Directory y pueden autenticarse en los equipos unidos.

Realice este laboratorio en FS1 antes de que se convierta en un controlador de dominio. Un controlador no expone la administración de cuentas locales de servidor miembro de la misma manera; la ausencia del nodo Usuarios y Grupos Locales en DC1 no es un error por sí misma.

Cree el usuario y el grupo en la interfaz gráfica

1. En FS1 con Desktop Experience, inicie sesión como administrador y abra compmgmt.msc. En Server Core, utilice el procedimiento de PowerShell de la sección siguiente.
2. Abra Herramientas del sistema → Usuarios y grupos locales → Usuarios. Elija Nuevo usuario en el menú contextual.
3. Cree labuser con una contraseña única. Elija las condiciones de cambio de contraseña apropiadas según el método de inicio de sesión y la política planificada.
4. En Usuarios y grupos locales → Grupos, elija Grupo nuevo, llámelo LabReaders y añada el usuario local labuser. Compruebe que pertenece a FS1; no lo añada a Administradores.

LabReaders es el nombre de su propio grupo y no cambia con el idioma de la interfaz de Windows. Los nombres de grupo integrados pueden ser localizados, así que revise las descripciones y los miembros, así como los nombres.

Ser miembro por sí solo no concede acceso a archivos ni inicio de sesión remoto. Debe asignar por separado los permisos del grupo en un recurso o los derechos en la política de inicio de sesión correspondiente.

Cree la configuración equivalente con PowerShell

No vuelva a crear los nombres si ya completó el ejercicio gráfico. En un FS1 donde estos objetos todavía no existan, use Windows PowerShell de 64 bits abierto como administrador. New-LocalUser recibe la contraseña como SecureString, el tipo de dato que produce Read-Host con -AsSecureString para no introducirla como texto visible en el código:

$labPassword = Read-Host 'Password for labuser' -AsSecureString
New-LocalUser -Name 'labuser' -Password $labPassword -Description 'Lab standard user'
New-LocalGroup -Name 'LabReaders' -Description 'Lab read access group'
Add-LocalGroupMember -Group 'LabReaders' -Member "$env:COMPUTERNAME\labuser"
Get-LocalGroupMember -Group 'LabReaders'

El último comando debe mostrar FS1\labuser como miembro de LabReaders. La referencia al nombre del equipo en Add-LocalGroupMember evita confundirlo con una cuenta de dominio del mismo nombre; consulte la documentación de pertenencia a grupos locales. No escriba la contraseña en el código ni recurra a cuentas sin contraseña. El módulo LocalAccounts no está disponible desde PowerShell de 32 bits en un sistema de 64 bits.

Verifique el estado de la cuenta y la sesión real

Compruebe por separado la creación y el acceso efectivo. Las dos primeras consultas siguientes muestran el estado de labuser y la pertenencia al grupo; Enabled indica si la cuenta está habilitada. Ejecute whoami y whoami /groups en la sesión real del usuario estándar, no en una ventana del administrador, para comprobar su identidad y grupos.

Get-LocalUser -Name 'labuser' | Select-Object Name,Enabled,LastLogon
Get-LocalGroupMember -Group 'LabReaders'
whoami
whoami /groups

Una sesión abierta puede conservar su token de acceso original, es decir, los datos de seguridad con los que se inició, aunque cambie la pertenencia a grupos. Cierre la sesión y entre de nuevo antes de comparar. Si el inicio de sesión falla, revise cuenta habilitada, contraseña, teclado e identidad local o de dominio. Una política que deniega el inicio de sesión puede prevalecer sobre la pertenencia al grupo; dar permisos de administrador no es una solución general.

Desactive primero cuando una cuenta solo esté temporalmente sin uso

Son dos alternativas opuestas: Disable-LocalUser deshabilita la cuenta y Enable-LocalUser la vuelve a habilitar. Ejecute únicamente la línea que corresponda, no todo el bloque como una secuencia:

Disable-LocalUser -Name 'labuser'
Enable-LocalUser -Name 'labuser'

Antes de eliminar permanentemente la configuración del laboratorio, verifique los permisos asignados al grupo, elimine la membresía y luego elimine el grupo y el usuario si ya no se necesitan:

Remove-LocalGroupMember -Group 'LabReaders' -Member "$env:COMPUTERNAME\labuser"
Remove-LocalGroup -Name 'LabReaders'
Remove-LocalUser -Name 'labuser'

Recrear una cuenta con el mismo nombre genera otro identificador de seguridad (SID, Security Identifier), como explica la documentación de identificadores de seguridad. Los permisos anteriores no se transfieren automáticamente. Conserve la cuenta si la necesita para posteriores prácticas de permisos de archivos. Antes de deshabilitar una cuenta administrativa, compruebe otra vía de acceso de administrador que funcione.