What Is Windows LAPS no implementado?
Windows LAPS no implementado significa que el entorno todavía no dispone de un proceso gestionado para establecer, rotar, guardar y recuperar la contraseña del administrador local en puestos Windows y servidores. Windows Local Administrator Password Solution existe para resolver un problema muy concreto: la cuenta de administrador local suele mantenerse por soporte, build o escenarios de emergencia, pero si su contraseña es estática o se reutiliza, la intrusión en una sola máquina puede abrir el mismo secreto en muchas otras.
La recomendación actual de Microsoft es usar Windows LAPS y no depender de rotación manual. Windows LAPS puede guardar la contraseña en Active Directory o en Microsoft Entra ID, y aporta políticas nativas, cmdlets PowerShell y auditoría. Si la función no se ha desplegado, está mal acotada o nunca se empujó de forma consistente por GPO, Intune o CSP, el riesgo sigue siendo real aunque la organización crea que el acceso admin local se usa poco.
Por eso Windows LAPS no implementado suele aparecer junto a Mala configuración de GPO: cuando Group Policy se convierte en vector de ataque y Cuentas obsoletas y con privilegios excesivos en Active Directory. En ambos casos, el problema no es solo quién tiene privilegios, sino si el ciclo de vida del secreto sigue bajo control después de una intrusión.
How Windows LAPS no implementado Works
Windows LAPS viene integrado en versiones modernas de Windows y puede gestionar una cuenta de administrador local definida por dispositivo. Microsoft documenta dos destinos de backup compatibles:
- Active Directory en Windows Server
- Microsoft Entra ID
En el cliente se definen la cuenta gestionada, la complejidad de contraseña, la antigüedad máxima, las acciones posteriores a autenticación y el directorio de copia. Del lado administrativo se controla quién puede leer la contraseña, quién puede forzar una rotación y cómo se audita su recuperación.
Para Entra ID, Microsoft también fija prerequisitos importantes:
- el dispositivo debe estar unido a Entra ID o híbrido
- los dispositivos solo registrados no son compatibles
- LAPS debe estar habilitado en el tenant y la política cliente debe establecer
BackupDirectoryen Microsoft Entra ID
Para Active Directory, Windows LAPS se apoya en extensiones de esquema y en derechos delegados para almacenar el secreto de forma segura. Microsoft entrega cmdlets específicos para actualizar el esquema, consultar contraseñas, identificar derechos de lectura y forzar nuevas rotaciones.
| Área LAPS | Función que aporta Microsoft | Por qué importa |
|---|---|---|
| Política cliente | Ajustes integrados de Windows LAPS | Impone edad, longitud, complejidad y cuenta gestionada |
| Destino de backup | AD o Entra ID | Hace recuperable la contraseña sin hojas manuales |
| Control de acceso | Roles o derechos delegados | Evita que una necesidad de helpdesk abra demasiado acceso |
| Herramientas PowerShell | Get-LapsADPassword, Get-LapsAADPassword, Find-LapsADExtendedRights, Reset-LapsPassword | Permite medir despliegue y recuperación |
Microsoft también documenta la migración desde el antiguo Microsoft LAPS. Ese punto importa porque muchas organizaciones creen que “ya tienen LAPS” cuando en realidad solo tienen un despliegue histórico, parcial o nunca normalizado.
The Attack Chain
Paso 1 - Comprometer un equipo con contraseña local reutilizable
Los atacantes no necesitan Domain Admin para aprovechar una mala higiene de contraseñas locales. Les basta con una máquina donde la cuenta de administrador local siga activa y su contraseña pueda adivinarse, recuperarse o capturarse. Si ese mismo secreto funciona en otros equipos, la intrusión deja de ser local muy rápido.
Paso 2 - Reutilizar el secreto para movimiento lateral
En cuanto la contraseña o el hash NTLM valen en varios dispositivos, los canales de administración remota se convierten en un multiplicador. El problema central no es solo la existencia de la cuenta local, sino que su secreto no sea único por equipo ni rote con rapidez después de una exposición.
# Revisar si un dispositivo registra actividad reciente de Windows LAPS
Get-WinEvent -LogName 'Microsoft-Windows-LAPS/Operational' -MaxEvents 20 |
Select-Object TimeCreated, Id, LevelDisplayName, Message
Si este log está vacío en equipos que deberían estar cubiertos, o si no aparecen rotaciones ni recuperaciones en la ruta de gestión esperada, el despliegue es incompleto.
Paso 3 - Ampliar el acceso antes de que la rotación manual responda
Sin Windows LAPS, muchas organizaciones dependen en incidente de scripts de emergencia, tickets o cambios manuales. Eso ralentiza la contención y alarga la ventana en la que la misma contraseña local puede seguir reutilizándose. Por eso el tema encaja directamente con Rutas de ataque de Active Directory hacia Domain Admin: LAPS no elimina toda escalada, pero su ausencia entrega un excelente punto de apoyo para moverse lateralmente.
Por qué un despliegue parcial sigue siendo peligroso
La situación más engañosa no es “LAPS no existe”, sino “LAPS existe a medias”. Si las estaciones estándar están cubiertas pero los jump hosts, servidores antiguos o puestos administrativos quedan fuera, el control pierde una gran parte de su valor. Los atacantes buscan precisamente los sistemas donde la contraseña local sigue siendo predecible o compartida. Un despliegue parcial crea una sensación de madurez que no resiste una intrusión real.
Por eso la revisión no debe limitarse a ver si la política existe. Hay que comprobar grupos objetivo, excepciones, derechos de lectura y, sobre todo, qué máquinas están protegidas de verdad. Una GPO visible en consola no equivale a una contraseña local que esté rotando y almacenándose donde debe.
Detection
La mejor detección combina cobertura de políticas, validación del backup y revisión de permisos.
| Indicador | Fuente | Qué comprobar |
|---|---|---|
| No hay política Windows LAPS efectiva | GPO, Intune, CSP o política local | ¿Los equipos gestionados reciben realmente configuración LAPS? |
| No hay backup reciente en AD o Entra ID | Get-LapsADPassword o Get-LapsAADPassword | ¿La contraseña se guarda y rota donde debería? |
| No hay actividad LAPS en el endpoint | Microsoft-Windows-LAPS/Operational | ¿El cliente procesa correctamente la política? |
| Hay demasiados lectores del secreto | Find-LapsADExtendedRights o revisión de roles Entra | ¿Demasiadas identidades pueden recuperar contraseñas? |
# Revisar quién puede leer contraseñas LAPS en AD
Find-LapsADExtendedRights -Identity 'OU=Workstations,DC=corp,DC=local'
# Validar recuperación de una contraseña guardada en AD
Get-LapsADPassword -Identity WS-001 -AsPlainText
Para despliegues respaldados en Entra ID, Microsoft también documenta Get-LapsAADPassword y recuperación basada en roles. Una revisión seria debe confirmar ambos lados: que la contraseña exista y que solo los roles correctos puedan verla.
Remediation
💡 Quick Win: elija primero un modelo de backup compatible. Un entorno a medio camino entre gestión manual, antiguo Microsoft LAPS y Windows LAPS suele crear más confusión que seguridad.
Una secuencia de remediación pragmática suele seguir este orden:
- Elegir la autoridad de backup. Use Active Directory o Microsoft Entra ID según el tipo de unión y gestión del dispositivo.
- Preparar directorio y permisos. Para AD, amplíe esquema y revise permisos de lectura y reset. Para Entra, active LAPS en el tenant y valide roles de recuperación.
- Configurar la política cliente. Defina la cuenta gestionada, complejidad, edad, destino de backup y acciones posteriores a autenticación.
- Validar el procesamiento correcto. Use el log de Windows LAPS y los cmdlets de recuperación para confirmar que las contraseñas rotan y se almacenan.
- Eliminar deriva. Limpie scripts antiguos, contraseñas compartidas y restos del Microsoft LAPS heredado.
- Auditar permisos de recuperación. Verifique que solo los equipos adecuados puedan leer o reiniciar contraseñas.
# Ejemplo de secuencia de despliegue y validación en AD
Update-LapsADSchema
Get-LapsADPassword -Identity WS-001
Reset-LapsPassword
Validate Before You Close the Finding
Un despliegue no está terminado porque exista una política. Lo está cuando equipos representativos rotan sus contraseñas, el backend de backup contiene secretos recientes y la ruta de recuperación ha sido validada de extremo a extremo por el rol previsto. La validación mínima debería cubrir un equipo estándar, un puesto administrativo si aplica, una clase de servidor relevante y una prueba real de recuperación.
Esa validación también debe dejar claro quién puede leer contraseñas y quién puede forzar rotaciones. De lo contrario, el entorno solo sustituye una contraseña compartida por una superficie de recuperación demasiado amplia.
Qué validar por separado en despliegues con AD y Entra ID
Muchos proyectos LAPS no fallan por falta de tecnología, sino por mezclar modelos operativos. Microsoft separa claramente Windows LAPS para Active Directory y para Microsoft Entra ID. En despliegues respaldados en AD no basta con ampliar el esquema; también conviene comprobar que los permisos delegados de lectura están limitados a la OU o al grupo correcto, que Get-LapsADPassword devuelve valores actuales en equipos representativos y que Reset-LapsPassword desencadena una nueva rotación. Solo así se confirma que la vía de recuperación funcionará durante un incidente y no solo en documentación.
En despliegues con Entra ID, los controles críticos son otros. Microsoft solo admite dispositivos Entra joined o hybrid joined; los dispositivos únicamente registrados no están soportados. Además, LAPS debe habilitarse a nivel de tenant y la política cliente debe establecer BackupDirectory en Microsoft Entra ID. Los permisos de recuperación también deben revisarse por separado, porque Microsoft distingue entre permisos para leer la contraseña y permisos para leer los metadatos. Un despliegue solo es sólido cuando el equipo previsto prueba ambos caminos: el backup correcto del secreto y una recuperación auditable en el momento en que realmente se necesita.
Otro error frecuente es pensar que “algún LAPS ya existe” y eso basta. Microsoft documenta un camino explícito de migración desde el antiguo Microsoft LAPS. Por eso la aceptación del despliegue debería aclarar si siguen existiendo GPO antiguas, scripts heredados o procedimientos paralelos. Mientras coexistan varios modelos de gestión, aparecen excepciones, dobles propietarios y huecos de recuperación. Un piloto sólido valida por separado AD y Entra, confirma qué dispositivos están realmente cubiertos y mide cuánto tarda una nueva rotación en quedar visible después de un uso o un reset.
También conviene revisar estaciones administrativas, jump hosts y servidores privilegiados como una ola específica del piloto. En esos sistemas importa aún más comprobar las Post-Authentication-Actions y confirmar que Windows LAPS solo gestiona la cuenta local prevista por dispositivo, sin dejar cuentas antiguas fuera del control de rotación.
How EtcSec Detects This
EtcSec vincula este hallazgo con LAPS_NOT_DEPLOYED y GPO_LAPS_NOT_DEPLOYED. La diferencia útil es saber si Windows LAPS falta por completo o si la organización cree tenerlo desplegado aunque ninguna política duradera llegue a los endpoints correctos.
ℹ️ Note: EtcSec comprueba automáticamente la ausencia o el despliegue incoherente de LAPS durante auditorías de Active Directory para separar “funcionalidad disponible” de “control realmente aplicado”.
Official References
- Microsoft Learn: What is Windows LAPS?
- Microsoft Learn: Windows LAPS PowerShell Cmdlets Overview
- Microsoft Learn: Use Windows Local Administrator Password Solution with Microsoft Entra ID
- Microsoft Learn: Prepare for Windows LAPS deployment and migration
Related Reading
Para priorizar bien este tema, revíselo junto con Mala configuración de GPO: cuando Group Policy se convierte en vector de ataque, Cuentas obsoletas y con privilegios excesivos en Active Directory, Seguridad de contraseñas en Active Directory: configuraciones erróneas que sí importan, Cómo auditar la seguridad de Active Directory: guía práctica para equipos internos y Monitorización de seguridad de Active Directory: eventos que importan. Todos estos temas explican por qué la rotación de contraseñas locales solo funciona cuando alcance, permisos y auditabilidad están alineados.
