Crear usuarios locales y políticas de contraseñas con PowerShell

Qué estás gestionando realmente (y por qué sigue dándote problemas)

Un “usuario local” suena simple: un nombre de usuario y una contraseña almacenados en una máquina Windows. Pero operativamente,
estás gestionando tres sistemas superpuestos:

• El objeto de cuenta (habilitado/deshabilitado, estado de la contraseña, pertenencia a grupos, perfil, privilegios).
• La superficie de la política de autenticación (longitud de contraseña, complejidad, umbral de bloqueo, caducidad).
• El radio de impacto (dónde funciona esa credencial y qué puede hacer).

Las cuentas locales son un riesgo para la fiabilidad porque son pegajosas. Sobreviven a los proyectos.
Resisten migraciones. No aparecen en tu panel IAM central. Y cuando tienes más que unas pocas máquinas,
“recordaremos rotar esa contraseña” se convierte en un cuento para dormir que le cuentas a los auditores.

El trabajo no es “crear un usuario.” El trabajo es: crear un usuario que sea predecible, detectable, gobernado y reversible.
Predecible significa nomenclatura consistente, pertenencia a grupos consistente, reglas de contraseña consistentes. Detectable significa
que puedas inventariarlo y explicar por qué existe. Gobernado significa que las políticas se aplican (o al menos se miden). Reversible
significa que puedes deshabilitarlo limpiamente sin romper el servidor.

Si estás pensando “esto es exagerado para usuarios locales,” felicidades: nunca has tenido que responder a una investigación de movimiento lateral
donde la credencial favorita del atacante fue una contraseña de administrador local compartida en 700 máquinas.

Hechos y contexto histórico que puedes usar en debates

A los ingenieros les encantan los hechos que pueden usar en reuniones. Aquí hay algunos que importan cuando la sala empieza a discutir sobre “solo una cuenta local”.

1. Windows ha tenido cuentas locales desde NT—y muchas configuraciones de seguridad por defecto se diseñaron cuando las redes eran más pequeñas y planas.
   El legado sigue moldeando el comportamiento actual.
2. La consola “Usuarios y equipos locales” no siempre existió en todos los SKUs (ausente en algunas ediciones), por eso
   los scripts y net.exe se convirtieron en la lingua franca de la automatización administrativa.
3. La política de contraseñas no es por usuario por defecto. En máquinas independientes es mayormente una política a nivel de equipo; en sistemas unidos al dominio,
   normalmente gana la política de dominio, a menos que haya políticas de granularidad fina o anulaciones locales.
4. El módulo LocalAccounts de PowerShell (cmdlets como New-LocalUser) llegó relativamente tarde comparado con la edad de la administración Windows.
   Los scripts más antiguos usan ADSI o net user porque tenían que hacerlo.
5. La política de bloqueo de cuentas es una palanca de fiabilidad, no solo de seguridad. Si es demasiado estricta te haces un DoS con servicios que fallan por errores humanos;
   si es demasiado laxa, el fuerza bruta se convierte en un pasatiempo.
6. “La contraseña nunca caduca” no es solo una casilla; es una aceptación de vida ilimitada de la credencial.
   Eso necesita controles compensatorios (sistema de rotación, LAPS, checkout de un almacén, etc.).
7. La pertenencia a grupos es el verdadero modelo de permisos para la mayoría de los administradores. El objeto usuario es aburrido; los grupos son donde está el fuego.
8. Windows mantiene múltiples fuentes de verdad para las configuraciones de seguridad (política de seguridad local, políticas en el registro, política de dominio, procesamiento de GPO).
   Tu script puede “establecer” algo y aun así perder en la siguiente actualización.
9. Las cuentas integradas se comportan de forma diferente. “Administrator” y “Guest” tienen manejo especial y carga histórica; renombrarlas no elimina su identidad.

Herramientas principales: LocalAccounts, ADSI, net.exe, secedit

Hay cuatro maneras prácticas de gestionar usuarios locales y la política de contraseñas en la automatización de Windows. Usarás todas dependiendo de la versión del SO, restricciones de remoting y cuán profundo necesites llegar.

1) Módulo LocalAccounts de PowerShell

Cmdlets como Get-LocalUser, New-LocalUser, Add-LocalGroupMember son legibles y relativamente seguros.
Son ideales para builds modernos de Windows Server y Windows 10/11. También hacen los errores legibles.

2) ADSI (proveedor WinNT)

Antiguo pero fiable. Funciona cuando LocalAccounts no está disponible. También útil cuando necesitas compatibilidad en flotas mixtas.
Desventaja: no es tan amigable; puedes hacerte daño con one-liners y no notarlo hasta que la producción empiece a cojear.

3) net.exe (net user, net localgroup, net accounts)

La herramienta de supervivencia: está, funciona y básicamente está soportada en todas partes.
También es basada en texto, lo que significa que parsear salidas puede ser molesto. Aun así: para inspecciones de política y comprobaciones rápidas,
es brutalmente efectiva.

4) secedit (exportar/importar política de seguridad local)

Cuando necesitas ver o aplicar opciones de seguridad a nivel de máquina en bloque, secedit puede exportar la política a un archivo estilo INF.
Puedes versionar ese archivo, compararlo y aplicarlo. No es bonito, pero es honesto.

Una idea parafraseada que ha guiado las operaciones por décadas: La esperanza no es una estrategia — Ed Yourdon.
Las cuentas locales son donde la esperanza va a retirarse. Trátalas como cualquier otra superficie de producción.

Principios del operador: decide primero, luego automatiza

Los scripts que gestionan usuarios fallan por razones aburridas: la cuenta ya existe, la máquina está unida al dominio, la política de contraseñas
la impone un GPO, WinRM está medio configurado, o el operador no tiene admin local. Así que no empieces escribiendo código. Empieza decidiendo:

• Intención: ¿Por qué existe esta cuenta local? ¿Break-glass humano? ¿Cuenta de servicio? ¿Soporte de un proveedor?
• Alcance: ¿Qué máquinas? ¿Qué OU? ¿Qué entornos?
• Autoridad: ¿Quién posee el ciclo de vida de la credencial? ¿Un vault? ¿Un equipo? ¿Un servicio de plataforma?
• Controles: Caducidad, bloqueo, auditoría, restricciones de pertenencia, denegar inicio interactivo cuando sea posible.
• Reversibilidad: ¿Cuál es el procedimiento para deshabilitar? ¿Qué alertas saltan si desaparece?

Y sí, puedes automatizar todo eso. La trampa es automatizar las suposiciones equivocadas más rápido.

Chiste #1: Si tu “administrador local temporal” es más antiguo que tu cafetera, no es temporal—es un fósil con privilegios.

Tareas prácticas (comandos, salidas, decisiones)

La forma más rápida de mejorar es realizar operaciones reales e inspeccionables y vincular cada salida a una decisión.
Abajo hay tareas que realmente ejecutarás en producción. Los comandos se muestran como si se ejecutaran desde un shell en un host.
Adapta nombres de host y rutas a tu entorno.

Task 1: Confirmar el SO y la compilación (porque la disponibilidad de cmdlets importa)

cr0x@server:~$ powershell -NoProfile -Command "Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsBuildNumber"
WindowsProductName WindowsVersion OsBuildNumber
----------------- -------------- -------------
Windows Server 2022 Datacenter 21H2           20348

Qué significa: Estás en una compilación de servidor moderna; el módulo LocalAccounts suele estar presente.
Decisión: Preferir Get-LocalUser/New-LocalUser sobre ADSI/parseo de net.

Task 2: Comprobar si el módulo LocalAccounts está disponible

cr0x@server:~$ powershell -NoProfile -Command "Get-Module -ListAvailable Microsoft.PowerShell.LocalAccounts | Select-Object Name, Version"
Name                               Version
----                               -------
Microsoft.PowerShell.LocalAccounts 1.0.0.0

Qué significa: Los cmdlets existen localmente.
Decisión: Úsalos para CRUD de cuentas; recurre a ADSI solo en casos límite.

Task 3: Inventariar usuarios locales existentes y sus flags de contraseña

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalUser | Select-Object Name, Enabled, PasswordRequired, PasswordExpires, LastLogon | Format-Table -Auto"
Name               Enabled PasswordRequired PasswordExpires LastLogon
----               ------- ---------------- -------------- ---------
Administrator      False   True             False
DefaultAccount     False   False            False
Guest              False   False            False
svc_backup         True    True             True           1/21/2026 3:12:09 AM
vendor_support     True    True             False          12/11/2025 10:44:18 AM

Qué significa: Ya tienes al menos dos cuentas no integradas; una no caduca.
Decisión: Decide si vendor_support debe estar limitada en el tiempo o deshabilitada cuando no se use. “Nunca caduca” necesita un control compensatorio.

Task 4: Crear un nuevo usuario local de forma segura (sin contraseña en texto plano en tu historial)

cr0x@server:~$ powershell -NoProfile -Command "$pw=Read-Host -AsSecureString 'Enter password'; New-LocalUser -Name 'svc_app' -Password $pw -Description 'App service account' -PasswordNeverExpires:$false -UserMayNotChangePassword:$true"
Enter password: ********

Qué significa: Cuenta creada; la contraseña se capturó como SecureString.
Decisión: Inmediatamente establece la pertenencia a grupos y los derechos; no dejes una cuenta de servicio sin permisos mínimos.

Task 5: Verificar las propiedades de la cuenta que realmente importan

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalUser -Name 'svc_app' | Select-Object Name, Enabled, UserMayChangePassword, PasswordExpires, PasswordLastSet | Format-List"
Name                  : svc_app
Enabled               : True
UserMayChangePassword : False
PasswordExpires       : True
PasswordLastSet       : 2/5/2026 1:03:27 PM

Qué significa: Esta cuenta no puede cambiar su propia contraseña y la expiración está habilitada.
Decisión: Poner la rotación de contraseñas bajo un mecanismo controlado (vault + rotación programada, o solución de administrador local gestionado), no “alguien lo recordará.”

Task 6: Añadir la cuenta a un grupo local (y verificar)

cr0x@server:~$ powershell -NoProfile -Command "Add-LocalGroupMember -Group 'Users' -Member 'svc_app'; Get-LocalGroupMember -Group 'Users' | Select-Object Name | Sort-Object Name | Select-Object -First 10"
Name
----
BUILTIN\Administrator
NT AUTHORITY\INTERACTIVE
NT AUTHORITY\Authenticated Users
SERVER01\svc_app

Qué significa: La cuenta es un usuario estándar, no un administrador.
Decisión: Manténla así a menos que puedas probar que la aplicación necesita admin. “Necesita admin” suele ser sinónimo de “nadie probó permisos”.

Task 7: Auditar la pertenencia a Administrators locales (el grupo que arruina tu semana)

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalGroupMember -Group 'Administrators' | Select-Object ObjectClass, Name, PrincipalSource | Format-Table -Auto"
ObjectClass Name                          PrincipalSource
----------- ----                          ---------------
User        SERVER01\Administrator         Local
Group       CONTOSO\Domain Admins          ActiveDirectory
User        SERVER01\vendor_support        Local

Qué significa: Un usuario proveedor local es administrador local. Eso es una credencial de alto riesgo por definición.
Decisión: Si se necesita acceso de proveedor, pásalo a acceso limitado en el tiempo (habilitar/deshabilitar bajo demanda), rotar la contraseña tras su uso, o eliminarlo de Administrators.

Task 8: Deshabilitar una cuenta sin borrarla (la reversibilidad es una característica)

cr0x@server:~$ powershell -NoProfile -Command "Disable-LocalUser -Name 'vendor_support'; Get-LocalUser -Name 'vendor_support' | Select-Object Name, Enabled"
Name           Enabled
----           -------
vendor_support False

Qué significa: El inicio de sesión queda bloqueado, pero la cuenta y el SID permanecen.
Decisión: Prefiere deshabilitar en lugar de borrar cuando no estés seguro sobre dependencias; borrar puede huérfanos ACLs y romper tareas programadas en silencio.

Task 9: Encontrar dónde se referencia una cuenta (las tareas programadas son reincidentes)

cr0x@server:~$ powershell -NoProfile -Command "Get-ScheduledTask | Where-Object {$_.Principal.UserId -match 'svc_app|vendor_support'} | Select-Object TaskName, State, @{n='UserId';e={$_.Principal.UserId}} | Format-Table -Auto"
TaskName           State  UserId
--------           -----  ------
NightlyBackup      Ready  SERVER01\svc_app

Qué significa: svc_app es usado por una tarea programada; deshabilitarlo rompería ese trabajo.
Decisión: Trata la cuenta como parte de un grafo de dependencias de la aplicación. Rota con cuidado; prueba la ejecución de tareas tras los cambios.

Task 10: Inspeccionar rápidamente la política efectiva de contraseñas y bloqueo (net accounts)

cr0x@server:~$ powershell -NoProfile -Command "net accounts"
Force user logoff how long after time expires?:       Never
Minimum password age (days):                          1
Maximum password age (days):                          60
Minimum password length:                              14
Length of password history maintained:                24
Lockout threshold:                                    5
Lockout duration (minutes):                           15
Lockout observation window (minutes):                 15
Computer role:                                        WORKSTATION
The command completed successfully.

Qué significa: Esta máquina espera contraseñas de 14 caracteres, expiran a 60 días, se bloquea tras 5 fallos.
Decisión: Las cuentas de servicio con riesgo de inicio interactivo deberían estar restringidas; si deben existir, asegúrate de no provocar bloqueos con credenciales almacenadas obsoletas.

Task 11: Cambiar ajustes de política de contraseñas (donde esté permitido) con net accounts

cr0x@server:~$ powershell -NoProfile -Command "net accounts /minpwlen:16 /maxpwage:45 /uniquepw:24 /lockoutthreshold:5 /lockoutduration:15 /lockoutwindow:15"
The command completed successfully.

Qué significa: Política local actualizada—salvo que un GPO la anule.
Decisión: En máquinas unidas a dominio, trata esto como herramienta de diagnóstico, no como mecanismo de aplicación de políticas. Si el GPO lo sobrescribe, tu “cambio” desaparecerá.

Task 12: Verificar el estado de unión al dominio (la fuente de política importa)

cr0x@server:~$ powershell -NoProfile -Command "(Get-CimInstance Win32_ComputerSystem).PartOfDomain"
True

Qué significa: Probablemente aplican políticas de dominio.
Decisión: No asumas que los comandos locales de política se mantendrán; comprueba la política resultante y la precedencia de GPO.

Task 13: Exportar la política de seguridad local a un archivo para comparar

cr0x@server:~$ powershell -NoProfile -Command "secedit /export /cfg C:\Windows\Temp\secpol.cfg /areas SECURITYPOLICY"
The task has completed successfully.
See log %windir%\security\logs\scesrv.log for detail information.

Qué significa: Ahora tienes una representación en texto de muchas configuraciones de seguridad locales.
Decisión: Haz diff de este archivo entre servidores para encontrar deriva de configuración. La deriva suele ser el error real.

Task 14: Extraer valores de política de contraseñas del config exportado

cr0x@server:~$ powershell -NoProfile -Command "Select-String -Path C:\Windows\Temp\secpol.cfg -Pattern 'MinimumPasswordLength|MaximumPasswordAge|PasswordComplexity|LockoutBadCount' | ForEach-Object {$_.Line}"
MinimumPasswordLength = 14
MaximumPasswordAge = 60
PasswordComplexity = 1
LockoutBadCount = 5

Qué significa: La complejidad está activada (1), longitud mínima 14, máxima 60, bloqueo a 5.
Decisión: Si los escáneres se quejan, puedes probar qué está configurado. Si las configuraciones difieren entre nodos de un clúster, arregla la consistencia primero.

Task 15: Establecer “La contraseña nunca caduca” para un usuario local específico (con una razón, no un encogimiento de hombros)

cr0x@server:~$ powershell -NoProfile -Command "Set-LocalUser -Name 'svc_backup' -PasswordNeverExpires $true; Get-LocalUser -Name 'svc_backup' | Select-Object Name, PasswordExpires"
Name       PasswordExpires
----       --------------
svc_backup False

Qué significa: La cuenta dejará de expirar.
Decisión: Haz esto solo cuando tengas rotación fiable en otro lugar (gestión por vault, actualización programada + plan de reinicio de servicios, o solución gestionada). De lo contrario estás cambiando cortes por brechas.

Task 16: Encontrar usuarios locales inactivos (último inicio de sesión anterior a N días)

cr0x@server:~$ powershell -NoProfile -Command "$cutoff=(Get-Date).AddDays(-90); Get-LocalUser | Where-Object {$_.Enabled -and $_.LastLogon -and $_.LastLogon -lt $cutoff} | Select-Object Name, LastLogon | Sort-Object LastLogon"
Name           LastLogon
----           ---------
svc_legacy     10/2/2025 11:18:44 AM
vendor_support 11/3/2025 8:20:01 AM

Qué significa: Cuentas habilitadas no han iniciado sesión en 90 días.
Decisión: Candidatas para deshabilitar, pero primero comprueba tareas programadas, servicios y configuraciones “run as”. Inactivo no siempre significa sin uso—aunque a menudo sí.

Task 17: Comprobar servicios de Windows por dependencias “Iniciar sesión como”

cr0x@server:~$ powershell -NoProfile -Command "Get-CimInstance Win32_Service | Where-Object {$_.StartName -match 'svc_app|svc_backup'} | Select-Object Name, State, StartName | Format-Table -Auto"
Name           State   StartName
----           -----   ---------
AppWorker      Running .\svc_app
BackupAgent    Running .\svc_backup

Qué significa: Estas cuentas están ligadas a servicios en ejecución.
Decisión: Cualquier cambio de contraseña requiere una actualización coordinada de las credenciales del servicio (y idealmente una ventana de reinicio). De lo contrario, disfruta de tu incidente autoinfligido.

Task 18: Exportar inventario de usuarios locales a CSV para revisión centralizada

cr0x@server:~$ powershell -NoProfile -Command "Get-LocalUser | Select-Object Name, Enabled, PasswordExpires, PasswordLastSet, LastLogon, Description | Export-Csv -NoTypeInformation C:\Windows\Temp\local-users.csv; Get-Item C:\Windows\Temp\local-users.csv | Select-Object Name, Length"
Name            Length
----            ------
local-users.csv 924

Qué significa: Ahora tienes un artefacto pequeño que puedes ingerir en tu canal de inventario.
Decisión: Establece una línea base “conocida buena” y alerta sobre cambios. La deriva de cuentas es una señal, no ruido de fondo.

Realidad de la política de contraseñas en Windows (local vs dominio)

La política de contraseñas es donde las buenas intenciones mueren en silencio. El detalle clave: en un host independiente,
la “política de contraseñas” es mayormente una política a nivel de máquina aplicada a cuentas locales. En un host unido al dominio,
la política de dominio suele controlar lo que se aplica, y los ajustes locales pueden no importar.

Qué puedes controlar de forma fiable localmente

• Existencia y estado de usuarios locales: crear, deshabilitar, renombrar (con cuidado), establecer descripción, ajustar flags.
• Pertenencia a grupos locales: quién está en Administrators, Remote Desktop Users, etc.
• Algunos ajustes de contraseña/bloqueo a nivel de máquina en servidores independientes o donde el GPO lo permita.
• Flag de expiración por usuario (PasswordNeverExpires) en cuentas locales.

Qué te sorprenderá si no pruebas

• Sobrescritura por GPO de dominio: configuraste longitud mínima a 16 localmente, el GPO dice 14, y tras el refresh vuelves a 14.
  Tu script “funcionó” y aun así perdió.
• Diferente aplicación según tipo de credencial: inicios de servicio, tareas programadas, RDP y acceso SMB pueden fallar de formas distintas.
  La cuenta existe, pero el contexto de autenticación cambia el modo de fallo.
• Bloqueos por contraseñas antiguas en caché: rotas una contraseña, pero un servicio sigue intentando la antigua cada minuto y te bloquea.

Chiste #2: Las políticas de contraseñas son como paraguas—todos coinciden en que son necesarias hasta que les pides que lleven uno bajo la lluvia.

Opinión firme: deja de gestionar manualmente contraseñas de administradores locales

Si tu entorno es lo bastante grande como para justificar un script, es lo bastante grande como para justificar gestión centralizada.
Para cuentas administrativas locales quieres contraseñas únicas por host y rotación automática. Los humanos son inconsistentes,
y a los atacantes les encanta la consistencia.

Si debes tener administradores locales para break-glass, usa un runbook operacional: checkout controlado, validez corta, rotar tras uso,
y monitorear cambios de pertenencia. La meta no es “perfecto.” La meta es “no vergonzoso.”

Tres mini-historias corporativas desde el terreno

Incidente causado por una suposición errónea: “La política local aplica en todas partes”

Un equipo de plataforma desplegó un job de PowerShell para “endurecer” máquinas Windows independientes usadas en una línea de fabricación.
El script establecía longitud mínima de contraseña y umbral de bloqueo usando net accounts. Se ejecutó en verde. Todos siguieron adelante.

Un mes después, otro equipo unió la mitad de esas máquinas al dominio para habilitar parcheo e inventario centralizados.
Nadie le dijo al equipo de plataforma porque la unión fue “solo una mejora rápida.”

Entonces la línea empezó a fallar de una nueva manera: una cuenta de servicio estable desde hace años comenzó a bloquearse.
El servicio corría bajo un usuario local cuya contraseña había sido rotada por una persona en una máquina y copiada “por conveniencia” al resto.
En los nodos recién unidos al dominio, una política de bloqueo de dominio más estricta entró en juego. El servicio reintentó con la contraseña antigua, se bloqueó,
y la línea se detuvo.

El postmortem tuvo una frase que importó: asumieron que la política local era la que mandaba.
La solución fue otra frase: detectar el estado de unión al dominio, medir la política resultante y tratar la rotación de contraseñas como un sistema, no un ritual.

Optimización que salió mal: “Rotemos todo cada noche”

Una iniciativa de seguridad exigió rotación frecuente de contraseñas. El equipo que lo implementó quería ayudar, así que construyeron un job nocturno de rotación.
Actualizaba contraseñas locales de cuentas de servicio e intentaba “reparar” servicios afectados configurando las nuevas credenciales y reiniciándolos.

Durante una semana pareció brillante. Las gráficas de edad de contraseña bajaron. Los dashboards de cumplimiento subieron. El equipo fue invitado a más reuniones,
lo que nunca es una recompensa pero a menudo se confunde con una.

Luego vino Patch Tuesday. Varios servidores arrancaron más lento de lo habitual, y el job de rotación se solapó con el arranque de servicios.
Servicios a medio iniciar tuvieron sus credenciales actualizadas a mitad de arranque, luego se reiniciaron otra vez. Algunos servicios no toleraron reinicios mientras se inicializaban.
Unos cuantos quedaron en estado fallido y se quedaron así. El monitoring se encendió como un espectáculo navideño.

El problema no fue la rotación en sí; fue el acoplamiento: cambios de contraseña y reinicios ocurrieron durante una ventana de arranque inestable,
sin comprobaciones de salud por aplicación.
Lo arreglaron añadiendo ventanas de mantenimiento, validación específica por servicio y rotando con menos frecuencia pero más seguro.
Cumplimiento aceptó el intercambio porque las interrupciones también son un problema de seguridad.

Práctica aburrida pero correcta que salvó el día: “Inventario primero, luego cambio”

Otro equipo tenía la costumbre que parecía dolorosamente lenta: antes de cambiar cuentas locales, ejecutaban un script de inventario que exportaba:
usuarios locales, pertenencia a grupos, identidades de inicio de servicios y principales de tareas programadas. Cada ticket de cambio incluía el diff.

Cuando un proveedor pidió un administrador local “para resolver problemas”, el equipo creó una cuenta dedicada, deshabilitada por defecto, y documentó su
pertenencia a grupos requerida y comportamiento de expiración. La habilitaban solo durante sesiones del proveedor.

Meses después, un escaneo de respuesta a incidentes interno marcó esa cuenta como “admin presente.” La reacción de otro grupo fue borrarla inmediatamente. El diff de inventario los salvó: mostraba que la cuenta estaba deshabilitada y no había iniciado sesión desde la última sesión del proveedor.
También listaba tres tareas programadas que referenciaban el nombre de usuario—pero esas tareas también estaban deshabilitadas, ligadas a un compromiso antiguo.

El equipo deshabilitó las tareas permanentemente, removió la cuenta de Administrators y la mantuvo deshabilitada como marcador de identidad hasta que el contrato terminó.
Sin interrupciones, sin drama, sin negaciones de acceso sorpresa en el peor momento posible. Lo aburrido ganó.

Guion de diagnóstico rápido

Cuando “cosas de usuarios locales/política de contraseñas” fallan, suele romperse en uno de tres lugares: estado de la identidad, aplicación de la política o uso por dependencias.
Así es como encuentras el cuello de botella rápidamente sin hacer danza interpretativa en el Visor de Eventos.

Primero: confirma con qué estás tratando (standalone vs dominio, cmdlets disponibles)

• Comprueba unión al dominio: (Get-CimInstance Win32_ComputerSystem).PartOfDomain
• Comprueba compilación del SO: Get-ComputerInfo
• Comprueba módulo LocalAccounts: Get-Module -ListAvailable Microsoft.PowerShell.LocalAccounts

Por qué: Determina si los cambios locales de política son reales y qué ruta de automatización es confiable.

Segundo: inspecciona el estado del objeto de cuenta

• ¿Está habilitada? Get-LocalUser -Name X | Select Enabled
• Flags de contraseña: PasswordExpires, PasswordLastSet, UserMayChangePassword
• Pertenencia a grupos: Get-LocalGroupMember -Group Administrators

Por qué: “Inicio de sesión falló” a menudo significa “cuenta deshabilitada” o “no en el grupo correcto”, no “contraseña equivocada.”

Tercero: identifica qué está usando la credencial

• Servicios: Get-CimInstance Win32_Service | Where StartName -match X
• Tareas programadas: Get-ScheduledTask | Where Principal.UserId -match X

Por qué: Cambiar contraseñas es fácil; cambiar todos los consumidores es donde nacen las interrupciones.

Cuarto: valida la aplicación de la política (qué está realmente en efecto)

• net accounts para la vista local actual
• secedit /export para capturar el estado de política y comparar entre hosts

Por qué: Si un GPO sobrescribe tus cambios, necesitas ajustar la fuente de verdad, no el síntoma.

Errores comunes: síntomas → causa raíz → solución

1) “Mi script configuró la longitud mínima, pero no cambió”

Síntomas: net accounts muestra valores antiguos después de un rato; el escáner de seguridad sigue informando configuraciones previas.
Causa raíz: Un GPO de dominio sobreescribe la política local; o la máquina está gobernada por una baseline de seguridad.
Solución: Confirma el estado de unión al dominio y luego ajusta la política en la capa gobernante. Localmente, trata los cambios como efímeros a menos que controles el GPO.

2) “Cuenta creada con éxito, pero falla el inicio de sesión”

Síntomas: El usuario existe, está habilitado, pero no puede iniciar sesión vía RDP/SMB/interactivo.
Causa raíz: Derechos faltantes (p. ej., no está en Remote Desktop Users), la política local niega el inicio de sesión,
o la cuenta está forzada a cambiar contraseña en el próximo inicio y no puede hacerlo en ese contexto.
Solución: Comprueba pertenencia a grupos y asignaciones de derechos locales; para cuentas de servicio, evita escenarios de inicio interactivo por completo.

3) “El servicio empezó a fallar tras la rotación de contraseña”

Síntomas: El servicio no arranca; los logs de Eventos muestran fallo de logon; la tarea programada devuelve 0x52e (contraseña incorrecta).
Causa raíz: La contraseña cambió en la cuenta pero no se actualizó en el consumidor del servicio/tarea; o no se reinició.
Solución: Encuentra todos los consumidores (servicios + tareas), actualiza credenciales y luego reinicia en una ventana controlada. Valida la salud después.

4) “La cuenta sigue bloqueándose”

Síntomas: Eventos de bloqueo; fallos repetidos de autenticación; la cuenta se desbloquea y se bloquea de nuevo rápidamente.
Causa raíz: Algún proceso sigue usando credenciales antiguas (servicio, tarea, unidad mapeada, credencial en caché).
Solución: Identifica todos los consumidores, actualízalos y luego resetea el bloqueo. Si no lo encuentras, deshabilita temporalmente la cuenta y mira qué falla.

5) “Get-LocalUser dice LastLogon está vacío así que no sé si se usa”

Síntomas: LastLogon está en blanco para algunas cuentas aunque sospeches actividad.
Causa raíz: LastLogon no siempre se rellena para todos los tipos de autenticación y no es un rastro de auditoría completo.
Solución: Usa logs de eventos/política de auditoría si necesitas uso definitivo, e inventaria dependencias (servicios/tareas) como señal más fuerte.

6) “Renombramos Administrator; los atacantes aún lo encuentran”

Síntomas: Herramientas de seguridad aún identifican al admin integrado; las auditorías lo siguen referenciando.
Causa raíz: La cuenta integrada se identifica por SID (RID 500), no solo por el nombre.
Solución: Renombra si la política lo requiere, pero también deshabilita donde sea posible, usa LAPS/contraseñas únicas y monitorea el comportamiento del RID 500.

7) “Nuestra automatización corrió, pero algunos servidores no cambiaron”

Síntomas: La flota tiene usuarios/políticas locales inconsistentes; algunos nodos tienen admins extras.
Causa raíz: Fallos de remoting, problemas de permisos, o scripts que no validan resultados (asumen éxito).
Solución: Haz los scripts idempotentes y verifica el estado tras cada acción; exporta inventarios y haz diff; falla la ejecución cuando quede deriva.

Listas de comprobación / plan paso a paso

Plan A: Crear una cuenta de servicio local con valores por defecto sensatos

1. Inventario antes del cambio: exporta usuarios locales actuales y la pertenencia a Administrators.
2. Crea la cuenta con un método de entrada de contraseña seguro (prompt SecureString o inyección desde un vault).
3. Establece flags intencionalmente: comportamiento de expiración, usuario-puede-cambiar-contraseña, habilitado/deshabilitado.
4. Otorga pertenencia mínima a grupos: empieza con Users; evita Administrators.
5. Vincula dependencias: configura el servicio/tarea para usar la cuenta.
6. Valida: inicia el servicio, ejecuta la tarea, revisa logs, confirma que no hay bloqueos.
7. Documenta: campo de descripción en el usuario; añade propietario y propósito; registra en el inventario.

Plan B: Hacer cumplir la política de contraseñas y bloqueo en servidores independientes

1. Comprueba si el host está unido al dominio. Si lo está, detente y ve a gestionar la política en GPO.
2. Usa net accounts para leer ajustes actuales; exporta con secedit para obtener un artefacto de diff.
3. Aplica la política con net accounts (o con un enfoque consistente de plantillas de seguridad).
4. Vuelve a leer los ajustes y confirma que se mantuvieron.
5. Prueba creación de cuentas y cambio de contraseña contra las nuevas reglas (no descubras la aplicación durante un outage).

Plan C: Flujo seguro de deshabilitar/eliminar cuentas locales

1. Identifica dependencias (servicios, tareas, uso “run as”) antes de tocar la cuenta.
2. Deshabilita la cuenta primero; monitoriza por fallos.
3. Si no hay fallos, quítala de grupos privilegiados inmediatamente (Administrators, Remote Desktop Users).
4. Tras un periodo de observación, considera borrarla si es necesario—pero guarda evidencia de lo que se eliminó.
5. Actualiza inventario y baseline para que no “vuelva a crecer” sin ser detectada.

Plan D: Higiene a nivel de flota (la parte que la gente evita)

1. Estandariza convenciones de nombres (p. ej., svc_* para servicios, bg_* para break-glass).
2. Centraliza el inventario: recoge usuarios locales, administradores locales y flags de contraseñas regularmente.
3. Alerta sobre cambios en la pertenencia a Administrators y sobre creación de nuevos usuarios locales habilitados.
4. Rota credenciales privilegiadas con un sistema gestionado; no crees contraseñas compartidas entre hosts.
5. Realiza revisiones trimestrales de “cuentas inactivas” con evidencia de dependencias adjunta, no con sensaciones.

Preguntas frecuentes

1) ¿Debería usar New-LocalUser o net user?

Usa New-LocalUser cuando esté disponible; es más claro y los objetos son más fáciles de validar. Mantén net user para compatibilidad y diagnósticos rápidos.

2) ¿Puedo establecer complejidad por usuario local?

No en el sentido que la gente suele pensar. La complejidad normalmente forma parte de la política de máquina/dominio, no es un control por usuario para cuentas locales.
Puedes ajustar el comportamiento de expiración por usuario (p. ej., “nunca caduca”), pero la complejidad se aplica a nivel de política.

3) ¿Por qué mi cambio de política de contraseñas revierte?

Porque algo de mayor prioridad lo posee—normalmente Group Policy de dominio. Los cambios locales se sobrescriben durante el refresh de políticas.
Tu script no “falló”; perdió una pelea de gobernanza.

4) ¿Cuál es la forma más segura de manejar cuentas admin locales?

Contraseña única por host, rotada automáticamente y con pertenencia auditada. Si aún copias una sola contraseña entre máquinas, para.
Eso no es “operaciones”, es “incidente coleccionable.”

5) ¿Las cuentas de servicio deben tener contraseñas que expiran?

Si puedes rotar de forma segura con automatización y actualizar todos los consumidores, sí—la expiración está bien. Si no puedes, la expiración forzada generará outages.
En ese caso, establece “nunca caduca” solo con un mecanismo real de rotación y monitorización.

6) ¿Por qué deshabilitar un usuario local a veces no arregla el acceso?

Porque el acceso puede venir de un principal diferente (grupo de dominio, otra cuenta local, token en caché) o porque el problema real es
autorización (pertenencia a grupo) y no autenticación. Verifica quién está iniciando sesión y desde dónde.

7) ¿Cómo demuestro cuál es la política de contraseñas en un host?

Usa net accounts para la vista rápida, y secedit /export para un archivo que puedas adjuntar a un ticket y comparar entre máquinas.
La prueba vence a las discusiones.

8) ¿Está bien borrar cuentas locales tras el desmantelamiento de una app?

Usualmente sí, pero deshabilita primero y comprueba dependencias. Borrar puede huérfanos ACLs y romper tareas que nadie recordó.
Si necesitas un estado limpio, captura una instantánea de inventario antes de la eliminación.

9) ¿Cuál es la causa más común de bloqueos de cuentas tras un cambio de contraseña?

Una tarea programada o servicio aún configurado con la contraseña antigua. Los reintentos disparan bloqueos.
Actualiza consumidores primero cuando sea posible, o cambia contraseña y consumidor en una ventana controlada.

Conclusión: pasos prácticos siguientes

Las cuentas locales no son inherentemente malas. Simplemente vienen sin gestión por defecto, y lo por defecto es donde la fiabilidad sale golpeada.
Si quieres el camino operativo corto: inventaria, estandariza, automatiza, verifica y mantén un plan de rollback.

Pasos siguientes que puedes hacer esta semana:

• Ejecuta un inventario de Get-LocalUser y la pertenencia a Administrators en tu flota de servidores; almacena los resultados centralmente.
• Elige una postura de política para cuentas locales: cuáles están permitidas, cómo se nombran, cómo expiran y quién las posee.
• Implementa una alerta por cambios en la pertenencia a Administrators y por creación de nuevos usuarios locales habilitados.
• Para cualquier cuenta local privilegiada, pasa a gestión de contraseñas única-por-host y rotación con flujo de trabajo auditable.
• Escribe un runbook para rotación de contraseñas que incluya: descubrimiento de dependencias, pasos de actualización, reinicio de servicios y comprobaciones de validación.

Haz eso, y la próxima vez que alguien diga “es solo un usuario local”, tendrás datos, controles y menos outages sorpresa. Ese es todo el juego.