🛡️ Guía independiente de formación en ciberseguridad · Certificaciones, itinerarios y cursos
Inicio › Cursos › Curso de Defensa y Bastionado de Active Directory
Módulo 6 de 13

Módulo 6: Protección de cuentas privilegiadas y credenciales (Protected Users, LAPS, gMSA)

Módulo 6: Protección de cuentas privilegiadas y credenciales (Protected Users, LAPS, gMSA)

Aviso ético y legal: las técnicas, comandos y configuraciones de este módulo se explican con fines exclusivamente educativos y de defensa de infraestructuras Active Directory. Despliégalos únicamente en tu propio laboratorio o en entornos corporativos con autorización explícita y documentada. Modificar la configuración de seguridad de un dominio sin autorización, aunque la intención sea defensiva, puede constituir delito conforme a los arts. 197 y 264 del Código Penal español, y es en todo caso una negligencia profesional grave sin cambio controlado ni backup previo. Prueba siempre primero en laboratorio: un fallo en Protected Users o en un silo de autenticación puede bloquear el acceso de administradores legítimos a producción.

Qué aprenderás

  • Por qué la higiene de credenciales privilegiadas —no el perímetro— es el control que más reduce el riesgo de compromiso total de un dominio Active Directory.
  • Qué hace exactamente el grupo Protected Users a nivel de protocolo (NTLM, delegación, RC4/DES, caché de credenciales) y qué requisitos y efectos secundarios trae consigo.
  • Cómo restringir desde qué equipos puede autenticarse una cuenta privilegiada con Authentication Policies y Authentication Policy Silos, y qué es el armouring FAST que los sostiene.
  • La diferencia real entre LAPS legacy (atributo ms-Mcs-AdmPwd) y Windows LAPS (nativo, con historial, cifrado y respaldo de la contraseña DSRM), y por qué la contraseña de administrador local compartida es «pass-the-hash como servicio».
  • Cómo desplegar gMSA y cuándo usar sMSA, con su contraseña de 128 caracteres rotada automáticamente cada 30 días y su dependencia de la KdsRootKey.
  • Higiene de credenciales en memoria: LSASS como objetivo número uno, Credential Guard, RunAsPPL y por qué WDigest debe estar siempre a 0.
  • Higiene de cuentas de servicio «de toda la vida» (SPN, contraseñas largas, mínimo privilegio) como paso intermedio realista cuando gMSA no es viable.
  • Gestión correcta de la cuenta de Administrador integrada y de la contraseña DSRM de cada controlador de dominio.
  • El contraste legacy vs. objetivo: «misma contraseña de admin local en todos los equipos = paraíso del pass-the-hash lateral» frente a «LAPS + gMSA + Protected Users + silos = superficie de movimiento lateral drásticamente reducida».

1. El problema que resuelve este módulo

Los módulos anteriores han cubierto cómo se compromete un Active Directory: reconocimiento, Kerberoasting, ataques a delegación, DCSync, Golden/Silver Tickets. Casi todas esas técnicas comparten un mismo punto de apalancamiento: una credencial privilegiada mal protegida. Un atacante que obtiene el hash NTLM del administrador local de un equipo, o el TGT de una cuenta de Domain Admin cacheado en un servidor de salto, no necesita romper ninguna criptografía: reutiliza la credencial tal cual.

Este módulo cubre el lado defensivo: cómo hacer que las credenciales de alto valor dejen de ser una llave maestra reutilizable, mediante una pila de mecanismos complementarios en capas distintas:

  • Protected Users actúa en el protocolo de autenticación: elimina los métodos débiles (NTLM, RC4, DES) y el cacheo de credenciales.
  • Authentication Policies / Silos actúan en la topología: restringen desde qué equipos y hacia qué servicios puede autenticarse una cuenta, aunque la credencial sea correcta.
  • LAPS actúa sobre la contraseña de administrador local: única por equipo, rotada automáticamente, matando el pass-the-hash lateral masivo.
  • gMSA/sMSA actúan sobre las cuentas de servicio: sustituyen la contraseña estática por una de 128 caracteres rotada cada 30 días y gestionada por AD.
  • Credential Guard, RunAsPPL, WDigest=0 actúan en memoria: dificultan que un volcado de LSASS entregue credenciales reutilizables.

Ningún control es suficiente por sí solo. El objetivo es entender cada mecanismo con precisión técnica —requisitos de versión, efectos secundarios, comandos reales— para desplegarlos de forma progresiva sin romper producción.

2. Tabla comparativa de mecanismos

Mecanismo Qué protege Versión mínima Efecto secundario / riesgo
Protected Users (grupo) Cuentas de alto privilegio: fuerza Kerberos AES, prohíbe NTLM/RC4/DES como origen, prohíbe delegación (constrained/unconstrained) y credential caching en el equipo donde se inicia sesión. DC en Windows Server 2012 R2+; clientes Windows 8.1/Server 2012 R2 o superiores para beneficio completo. Cuentas que dependan de NTLM, RC4 o delegación dejan de funcionar al añadirlas; sin conectividad al DC no hay inicio de sesión posible; TGT limitado a 4 horas.
Authentication Policies / Silos Restringe desde qué hosts (Authenticating From) puede autenticarse una cuenta y a qué servicios accede (Authenticating To), vía claims y armouring FAST. Nivel funcional de dominio Windows Server 2012 R2; requiere Kerberos armouring (FAST), que a su vez requiere clientes Windows 8.1/Server 2012 R2+. Configuración incorrecta del TGT lifetime o de las condiciones de acceso puede bloquear a administradores legítimos si no están en la lista permitida; requiere planificación antes de «enforce».
LAPS legacy (Microsoft LAPS clásico) Contraseña del administrador local, aleatoria y única por equipo, en el atributo ms-Mcs-AdmPwd del objeto de equipo, con rotación periódica. Cliente desde Windows Vista/Server 2003; requiere extensión de esquema AD y CSE instalado en cada equipo. Contraseña sin cifrado propio (solo ACL de AD); sin historial nativo ni respaldo de DSRM; en soporte extendido, sin nuevas funcionalidades.
Windows LAPS (nativo) Igual que legacy, con cifrado del atributo (msLAPS-EncryptedPassword), historial, gestión también en Entra ID, y respaldo automatizable de la contraseña DSRM. Nativo desde Windows Server 2022 (abril 2023) y Windows 11 22H2; funcionalidad completa en Server 2025; extensión de esquema propia, distinta a la de LAPS legacy. Requiere extender de nuevo el esquema aunque ya hubiera LAPS legacy; migración exige plan explícito; delegación de lectura mal configurada expone la contraseña.
gMSA (Group Managed Service Account) Cuentas de servicio: contraseña de 128 caracteres rotada automáticamente por AD cada 30 días (configurable), sin gestión humana; usable en múltiples hosts autorizados a la vez. Al menos un DC en Windows Server 2012 (para la KdsRootKey); hosts consumidores en Windows Server 2012/Windows 8+. La contraseña inicial no está disponible hasta 10 horas tras crear la KdsRootKey (salvo -EffectiveTime forzado, solo en laboratorio); incompatible con servicios que exigen contraseña estática configurada manualmente.
sMSA (standalone Managed Service Account) Igual que gMSA pero limitada a un único host; sin capacidad de compartirse entre servidores. Windows Server 2008 R2+. En desuso frente a gMSA salvo host único sin previsión de escalado; sin soporte de alta disponibilidad multi-servidor.

3. Protected Users: qué hace realmente a nivel de protocolo

3.1 El mecanismo

Protected Users no es una ACL ni una delegación de permisos: es un grupo especial cuya sola membresía cambia el comportamiento de autenticación del Local Security Authority (LSA), tanto en el DC como en el equipo donde la cuenta inicia sesión. Desde Windows Server 2012 R2, ser miembro implica:

  • Sin NTLM: la cuenta no puede autenticarse por NTLM en absoluto, ni como origen. Fuerza Kerberos con cifrado AES; si el servicio destino no soporta Kerberos, la autenticación falla.
  • Sin DES ni RC4 en la preautenticación Kerberos: el KDC rechaza tickets con esos algoritmos para esa cuenta, forzando AES128/AES256 desde el primer intercambio.
  • Sin delegación: ni no restringida ni restringida (constrained), ni clásica ni basada en recursos (RBCD). Corta una de las rutas de escalada más usadas contra cuentas de administrador.
  • Sin credential caching local: sin conectividad con un DC, la cuenta no puede iniciar sesión, ni con la última contraseña usada.
  • TGT limitado a 4 horas (frente a las 10 por defecto), techo impuesto específicamente por el mecanismo.

Efecto combinado: un atacante que compromete un equipo donde ha iniciado sesión una cuenta protegida no encuentra hash NTLM reutilizable, no puede forjar Silver Tickets con RC4, no puede abusar de delegación, y el TGT expira antes.

3.2 Requisitos y comando de aplicación

El grupo existe de forma nativa desde un dominio con al menos un DC en Windows Server 2012 R2 (se crea al elevar el esquema con adprep /forestprep). El beneficio completo depende de que los DC que atienden la autenticación sean 2012 R2+ y los clientes Windows 8.1/Server 2012 R2+: un cliente más antiguo no aplica las restricciones aunque la cuenta sea miembro.

REM Añadir una cuenta administrativa al grupo Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members "admin_juan"

REM Verificar la membresía actual del grupo
Get-ADGroupMember -Identity "Protected Users" | Select-Object Name, SamAccountName

REM Comprobar si una cuenta concreta es miembro (directo o anidado)
Get-ADUser -Identity "admin_juan" -Properties MemberOf |
    Select-Object -ExpandProperty MemberOf |
    Where-Object { $_ -like "*Protected Users*" }

3.3 Requisitos previos antes de añadir cuentas

Antes de meter una cuenta en Protected Users hay que verificar de forma explícita:

  1. Que la cuenta no depende de NTLM en ningún flujo actual (aplicaciones legacy, recursos sin Kerberos, escenarios cross-forest sin confianza Kerberos completa).
  2. Que la cuenta no está configurada como cuenta de servicio con delegación (constrained o unconstrained) necesaria para su función.
  3. Que todos los equipos desde los que inicia sesión son Windows 8.1/Server 2012 R2 o superiores, parcheados y con AES habilitado.
  4. Que la cuenta acepta perder el credential caching: en portátiles con conectividad intermitente al dominio, Protected Users la bloqueará en desconexión.

La recomendación estándar (Microsoft, reforzada por la práctica de red teams como parte de Tier 0 hardening) es limitar Protected Users a cuentas humanas de más alto privilegio —Domain Admins, Enterprise Admins, Tier 0— y nunca a cuentas de servicio, que casi siempre incumplen alguno de los cuatro requisitos.

4. Authentication Policies y Authentication Policy Silos

4.1 El problema que resuelven

Protected Users endurece cómo se autentica una cuenta, pero no restringe desde dónde. Una cuenta de Domain Admin protegida sigue pudiendo iniciar sesión desde cualquier equipo del dominio: una estación de usuario final comprometida, un servidor de bajo privilegio, cualquier host. Ese es el vector que explota un atacante que espera a que un administrador haga RDP a un servidor comprometido con credenciales de Domain Admin.

Las Authentication Policies definen reglas de control de acceso condicional: Authenticating From (desde qué dispositivos puede obtenerse un TGT para esa cuenta) y Authenticating To (a qué servicios puede accederse con el TGS resultante). Los Authentication Policy Silos agrupan cuentas de usuario, equipo y servicio bajo una misma política, de forma que «todas las cuentas Tier 0» comparten una única política de origen/destino administrada centralizadamente.

4.2 El sustrato técnico: Kerberos armouring (FAST)

Estas políticas no serían aplicables sin FAST (Flexible Authentication Secure Tunneling), o Kerberos armouring: envuelve la preautenticación Kerberos en un túnel cifrado y autenticado usando la sesión del propio equipo cliente como «armadura». Permite al KDC evaluar claims sobre el dispositivo de origen (por ejemplo, «es miembro de un silo autorizado») antes de emitir el TGT, y protege la preautenticación de fuerza bruta offline. Requiere nivel funcional de dominio 2012 R2 y se activa con la directiva «Support Dynamic Access Control and Kerberos armoring» en Configuración de equipo → Plantillas administrativas → Sistema → Kerberos, en DC y clientes.

4.3 Comandos: crear política y silo

REM 1. Crear una Authentication Policy que restringe el TGT de las cuentas
REM    Tier 0 a poder obtenerse solo desde el grupo de equipos "T0-Admin-Hosts"
New-ADAuthenticationPolicy -Name "T0-Restrict-Auth" `
    -Description "Cuentas Tier0: solo autenticacion desde hosts administrativos" `
    -UserTGTLifetimeMins 240 `
    -UserAllowedToAuthenticateFrom `
        '@{OR="member of {SID(T0-Admin-Hosts)}"}'

REM 2. Crear el Authentication Policy Silo y asociarle la politica anterior
New-ADAuthenticationPolicySilo -Name "Tier0-Silo" `
    -Description "Silo de autenticacion para cuentas administrativas Tier 0" `
    -UserAuthenticationPolicy "T0-Restrict-Auth" `
    -ComputerAuthenticationPolicy "T0-Restrict-Auth" `
    -ServiceAuthenticationPolicy "T0-Restrict-Auth"

REM 3. Anadir miembros permitidos al silo (cuentas y equipos)
Grant-ADAuthenticationPolicySiloAccess -Identity "Tier0-Silo" `
    -Account "admin_juan"

REM 4. Asignar el silo a la cuenta de usuario (paso obligatorio: el silo
REM    no aplica hasta que el atributo del usuario lo referencia)
Set-ADAccountAuthenticationPolicySilo -Identity "admin_juan" `
    -AuthenticationPolicySilo "Tier0-Silo"

REM 5. Verificar en modo de solo auditoria antes de forzar el enforcement
REM    (revisar eventos 4820/4821/4824 en el DC durante varios dias)
Get-ADAuthenticationPolicySilo -Identity "Tier0-Silo" -Properties *

4.4 Enforce vs. Audit: la fase obligatoria de validación

Tanto las Authentication Policies como los Silos soportan modo de auditoría (el KDC registra qué habría bloqueado, eventos 4820/4821/4824, sin bloquear nada) y modo de enforcement (bloqueo real). La práctica obligatoria es desplegar primero en auditoría una a dos semanas —cubriendo ciclos completos, incluidas tareas administrativas mensuales que podrían no aparecer en una semana normal— y revisar los eventos antes de pasar a enforcement. Saltarse esta fase es la causa número uno de bloqueos de administradores legítimos fuera de sus propios sistemas.

5. LAPS: matando el pass-the-hash lateral del administrador local

5.1 El problema legacy: la misma contraseña de admin local en todos los equipos

Antes de LAPS, la práctica habitual —heredada de despliegues por imagen y GPO— era que la cuenta de Administrador local integrada tuviera la misma contraseña en todos los equipos del dominio, fijada en la imagen base o mediante Group Policy Preferences (GPP), método trivialmente inseguro: cifrada con una clave AES estática y públicamente conocida (cpassword en GPP), descifrable en segundos con herramientas públicas.

El efecto es el escenario de pesadilla del pass-the-hash: un atacante que compromete un solo equipo de usuario final extrae el hash NTLM del Administrador local con cualquier herramienta de volcado de LSASS o SAM, y ese hash es válido en todos los demás equipos del dominio, sin conocer la contraseña en claro. El movimiento lateral es prácticamente instantáneo hasta encontrar un equipo con credenciales de dominio de mayor privilegio cacheadas.

5.2 LAPS legacy (Microsoft LAPS clásico)

Microsoft LAPS (2015) resuelve exactamente ese problema: cada equipo tiene una contraseña de administrador local aleatoria y distinta, generada localmente por el cliente LAPS y almacenada en el atributo ms-Mcs-AdmPwd del objeto de equipo en AD, con rotación automática periódica (por defecto, 30 días). El acceso de lectura se restringe por ACL a los grupos que se decida (soporte de Tier 2, Domain Admins, etc.).

REM Extender el esquema de AD para LAPS legacy (una sola vez, requiere
REM privilegios de Schema Admins, ejecutar en un DC o con RSAT)
Import-Module AdmPwd.PS
Update-AdmPwdADSchema

REM Delegar permiso de LECTURA de la contraseña a un grupo de soporte
Set-AdmPwdReadPasswordPermission -OrgUnit "OU=Equipos,DC=corp,DC=local" `
    -AllowedPrincipals "CORPSoporte-T2"

REM Delegar permiso de RESETEO/rotacion forzada
Set-AdmPwdResetPasswordPermission -OrgUnit "OU=Equipos,DC=corp,DC=local" `
    -AllowedPrincipals "CORPSoporte-T2"

REM Consultar la contraseña actual de un equipo concreto
Get-AdmPwdPassword -ComputerName "PC-CONTA-014"

LAPS legacy sigue en soporte extendido, pero Microsoft lo considera predecesor funcional de Windows LAPS, sin desarrollo de nuevas capacidades. Limitaciones más relevantes: el atributo se almacena sin cifrado propio (protegido solo por la ACL de AD, aunque el tráfico LDAP puede ir cifrado con LDAPS), sin historial nativo de contraseñas anteriores, y sin mecanismo de respaldo de la contraseña DSRM.

5.3 Windows LAPS: la evolución nativa

Windows LAPS, integrado de forma nativa en el sistema operativo (Windows Server 2022 desde la actualización de abril de 2023, Windows 11 22H2 con el parche correspondiente, y capacidades completas en Windows Server 2025), sustituye al cliente LAPS legacy por una funcionalidad incorporada al propio Windows, sin CSE independiente. Mejoras principales:

  • Cifrado del atributo en AD (msLAPS-EncryptedPassword y msLAPS-EncryptedPasswordHistory), en vez de texto claro protegido solo por ACL.
  • Historial de contraseñas nativo, configurable en versiones retenidas.
  • Gestión también en Entra ID y dispositivos híbridos, no solo AD on-premises.
  • Respaldo automatizable de la contraseña DSRM de los DC (sección 8), algo que LAPS legacy nunca ofreció.
  • Rotación post-autenticación configurable: rotación inmediata tras recuperarse y usarse la contraseña, reduciendo la ventana de validez.
REM Extender el esquema de AD especificamente para Windows LAPS
REM (distinto de la extension de LAPS legacy; requiere Schema Admins)
Update-LapsADSchema -Confirm:$false

REM Conceder a los equipos de una OU permiso de auto-actualizacion
REM de su propia contraseña (equivalente al rol de "cliente" LAPS)
Set-LapsADComputerSelfPermission -Identity "OU=Equipos,DC=corp,DC=local"

REM Aplicar la configuracion de politica via GPO o localmente (ejemplo
REM de configuracion minima recomendada, en el equipo o via Directiva
REM de grupo "Configure password backup directory")
Set-LapsADPasswordExpirationProtectionEnabled -Identity "PC-CONTA-014" `
    -Enabled $true

REM Consultar la contraseña actual (descifrada, respetando la ACL
REM de lectura del solicitante) de un equipo concreto
Get-LapsADPassword -Identity "PC-CONTA-014" -AsPlainText

REM Consultar el historial de contraseñas de un equipo
Get-LapsADPassword -Identity "PC-CONTA-014" -AsPlainText -Newest 5

REM Forzar la rotacion inmediata de la contraseña de un equipo
Reset-LapsPassword -ComputerName "PC-CONTA-014"

5.4 Migración de LAPS legacy a Windows LAPS

Windows LAPS usa atributos de esquema distintos a los de LAPS legacy (msLAPS-* frente a ms-Mcs-AdmPwd): no hay migración automática. Ambos pueden convivir temporalmente, pero requiere un plan de corte explícito —desactivar el CSE legacy en las GPO, activar Windows LAPS, verificar que los equipos poblan los nuevos atributos, y solo entonces retirar la extensión legacy—. Microsoft documenta un modo de compatibilidad para la transición gradual.

6. gMSA y sMSA: cuentas de servicio sin contraseña gestionada por humanos

6.1 El problema que resuelven

Las cuentas de servicio tradicionales tienen un problema estructural: alguien tiene que conocer y gestionar su contraseña. En la práctica, eso suele significar contraseñas que no rotan nunca (rotarlas implica coordinar una ventana de mantenimiento en todos los servicios que la usan), reutilizadas entre cuentas, o guardadas en texto claro en scripts y configuraciones. Son, con frecuencia, objetivo de Kerberoasting: cualquier cuenta con SPN registrado es solicitable por cualquier usuario autenticado, y su hash —si es débil— se crackea offline sin generar alertas.

6.2 gMSA: contraseña de 128 caracteres, rotación automática, multi-host

Una Group Managed Service Account (gMSA) es una cuenta de AD cuya contraseña —128 caracteres, criptográficamente aleatoria— es generada y rotada automáticamente por Active Directory, sin gestión humana. Rotación por defecto cada 30 días, configurable con msDS-ManagedPasswordInterval. A diferencia de sMSA, una gMSA puede usarse simultáneamente en múltiples servidores autorizados —todos los nodos de un clúster o un farm de IIS—, imposible con una cuenta tradicional sin sincronizar contraseñas manualmente.

El mecanismo depende de la KDS Root Key (KdsRootKey), clave raíz de bosque que el Key Distribution Service usa, junto con el SID de la cuenta y un contador temporal, para derivar de forma determinista la contraseña vigente en cada intervalo. Cualquier DC del bosque recalcula la contraseña actual sin sincronización adicional: la derivación es matemática, no un valor almacenado que replicar.

REM 1. Crear la KDS Root Key (una sola vez por bosque). En produccion,
REM    -EffectiveTime NO se fuerza al pasado: hay que esperar el tiempo
REM    de replicacion. En LABORATORIO con un unico DC puede forzarse
REM    10 horas atras para pruebas inmediatas.
Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

REM 2. Verificar que la clave existe y está disponible
Get-KdsRootKey

REM 3. Crear la gMSA, autorizando que hosts concretos puedan recuperar
REM    su contraseña gestionada (aqui, un grupo de equipos "SRV-Web-Farm")
New-ADServiceAccount -Name "svc-webapp" `
    -DNSHostName "svc-webapp.corp.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "SRV-Web-Farm" `
    -ServicePrincipalNames "HTTP/webapp.corp.local"

REM 4. Instalar la gMSA en cada host autorizado (ejecutar EN el host,
REM    con el modulo RSAT AD PowerShell instalado)
Install-ADServiceAccount -Identity "svc-webapp"

REM 5. Verificar que el host puede efectivamente recuperar la
REM    contraseña gestionada (prueba de conectividad, no expone la clave)
Test-ADServiceAccount -Identity "svc-webapp"

REM 6. Configurar el servicio de Windows para ejecutarse con la gMSA
REM    (sin contraseña: se indica solo el nombre, con "$" final)
sc.exe config "MiServicioWeb" obj= "CORPsvc-webapp$"

6.3 sMSA: la variante de host único

Las standalone Managed Service Accounts (sMSA) son la generación anterior a gMSA (desde Windows Server 2008 R2), mismo principio de contraseña autogestionada por AD, pero limitadas a un único host: no pueden compartirse entre servidores. gMSA ha sustituido casi por completo a sMSA salvo en escenarios muy concretos de servicio en un único servidor sin previsión de escalado o clúster futuro.

6.4 Requisitos y limitaciones prácticas

  • El bosque necesita al menos un DC en Windows Server 2012 para crear la KdsRootKey y generar gMSA.
  • Los hosts que consuman la gMSA deben ser Windows Server 2012/Windows 8 o superiores.
  • En un bosque de producción recién creado, tras Add-KdsRootKey sin forzar -EffectiveTime, la contraseña gestionada no está disponible hasta pasadas unas 10 horas, para garantizar que la clave se ha replicado a todos los DC. Forzar el tiempo hacia atrás es válido únicamente en laboratorio de un solo DC.
  • gMSA no es compatible con servicios de terceros que exigan configurar la contraseña manualmente en su propia interfaz. Para esos casos, la alternativa realista sigue siendo una cuenta de servicio tradicional bien gestionada (sección 8).

7. Higiene de credenciales en memoria: LSASS, Credential Guard, RunAsPPL, WDigest

7.1 Por qué LSASS es el objetivo número uno

El proceso LSASS (Local Security Authority Subsystem Service) mantiene en memoria, para cualquier sesión iniciada en el equipo, credenciales o material derivado: hashes NTLM, claves Kerberos y, en configuraciones vulnerables, contraseñas en texto claro. Herramientas de post-explotación ampliamente conocidas extraen ese material directamente de la memoria de LSASS con privilegios de administrador local, sin conocer contraseña alguna de antemano. Es, con diferencia, la técnica de obtención de credenciales más usada tras obtener privilegios administrativos locales, porque no depende de fuerza bruta ni de vulnerabilidades adicionales.

7.2 Los tres controles complementarios

Control Qué hace Consideración práctica
Credential Guard Aísla el proceso que gestiona los secretos de LSA en un contenedor virtualizado (VBS) separado del kernel, de forma que un atacante con privilegios SYSTEM no puede leer directamente los secretos derivados del LSASS normal. Requiere hardware con virtualización (VT-x/AMD-V, IOMMU) y Secure Boot habilitado; puede requerir cambios de firmware; incompatible con ciertos controladores de terceros que interactúan directamente con LSASS.
RunAsPPL (LSA como proceso protegido) Ejecuta LSASS como Protected Process Light (PPL): impide que procesos no firmados con confianza suficiente —incluida la mayoría de herramientas de volcado de memoria genéricas— abran un handle de lectura sobre él, aunque se ejecuten como administrador. Se activa con RunAsPPL en HKLMSYSTEMCurrentControlSetControlLsa; controladores de terceros (antivirus, DLP) no certificados para LSASS protegido pueden dejar de funcionar.
WDigest a 0 Si está habilitado, WDigest hace que LSASS mantenga en memoria una copia reversible a texto claro de la contraseña de la sesión. Deshabilitarlo la elimina por completo. Deshabilitado por defecto desde Windows 8.1/Server 2012 R2, pero equipos actualizados desde versiones anteriores pueden heredarlo activo; forzar UseLogonCredential = 0 en HKLMSYSTEMCurrentControlSetControlSecurityProvidersWDigest. 
REM Verificar el estado de WDigest en un equipo remoto (via PowerShell
REM remoto/WinRM, requiere privilegios administrativos en el destino)
Invoke-Command -ComputerName "PC-CONTA-014" -ScriptBlock {
    Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlSecurityProvidersWDigest" `
        -Name "UseLogonCredential" -ErrorAction SilentlyContinue
}

REM Forzar WDigest a 0 (ideal via GPO centralizada, no host a host)
Invoke-Command -ComputerName "PC-CONTA-014" -ScriptBlock {
    Set-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlSecurityProvidersWDigest" `
        -Name "UseLogonCredential" -Value 0 -Type DWord
}

REM Verificar si RunAsPPL esta activo
Get-ItemProperty -Path "HKLM:SYSTEMCurrentControlSetControlLsa" `
    -Name "RunAsPPL" -ErrorAction SilentlyContinue

REM Verificar el estado de Credential Guard (requiere el modulo de
REM diagnostico de seguridad del dispositivo, ejecutar EN el equipo)
Get-CimInstance -ClassName Win32_DeviceGuard -Namespace rootMicrosoftWindowsDeviceGuard |
    Select-Object SecurityServicesRunning

La aplicación centralizada de estos tres controles debe hacerse vía GPO o Intune/MDM, no host a host: los comandos anteriores son útiles para verificación puntual y laboratorio, pero en producción a escala se gestionan de forma centralizada para garantizar cobertura completa y consistente.

8. Higiene de cuentas de servicio tradicionales y gestión de Administrador/DSRM

8.1 Cuando gMSA no es viable: higiene mínima de una cuenta de servicio clásica

No todos los servicios admiten gMSA (ver limitaciones en 6.4). Para esos casos, la higiene mínima aceptable de una cuenta de servicio tradicional incluye:

  • Contraseña larga y aleatoria (25+ caracteres, nunca memorizable ni reutilizada): cualquier cuenta con SPN es Kerberoasteable y su resistencia depende de la fuerza de esa contraseña frente a crackeo offline.
  • Un SPN por servicio, sin duplicados entre cuentas, lo que además de higiene evita errores de autenticación Kerberos difíciles de diagnosticar.
  • Mínimo privilegio estricto: nunca Domain Admin para un servicio de aplicación; delegar solo los permisos concretos que necesita.
  • Rotación programada, aunque sea manual, con calendario explícito.
  • Nunca en Protected Users salvo verificación exhaustiva previa (sección 10, error más común del módulo).

8.2 La cuenta de Administrador integrada

La cuenta de Administrador integrada (RID 500) de cada equipo y de cada DC merece gestión diferenciada: en equipos miembro, Windows LAPS (o LAPS legacy) resuelve su rotación y unicidad, como se ha visto en la sección 5. En los propios controladores de dominio, la cuenta de Administrador de dominio integrada debería estar deshabilitada para uso diario, con cuentas administrativas nominales e individuales en su lugar (trazabilidad de auditoría), reservando la integrada solo para emergencias, con contraseña gestionada con el mismo rigor que el DSRM.

8.3 La contraseña DSRM: la olvidada

El Directory Services Restore Mode (DSRM) es el modo de arranque de un DC que permite operar sin el servicio de Active Directory activo —necesario para ciertas operaciones de recuperación y mantenimiento de la base de datos NTDS—. Cada DC tiene su propia contraseña de administrador local de DSRM, establecida en la promoción y, en muchísimas organizaciones, nunca vuelta a rotar desde entonces.

Esa contraseña es, de facto, una credencial de máximo privilegio sobre el propio DC a nivel offline, y suele quedar fuera del radar de cualquier programa de rotación por no ser una cuenta de AD «normal». Windows LAPS incorpora la capacidad de respaldar y rotarla de forma gestionada, cerrando ese punto ciego histórico.

REM Consultar si el respaldo de la contraseña DSRM esta habilitado
REM para Windows LAPS (requiere el modulo LAPS de Windows Server 2025/
REM Windows LAPS con soporte DSRM)
Get-LapsADPassword -Identity "DC01" -AsPlainText

REM Resetear manualmente la contraseña DSRM de un controlador de dominio
REM concreto (metodo clasico, sin Windows LAPS, ejecutar EN el DC)
ntdsutil "set dsrm password" "reset password on server null" q q

9. Laboratorio: desplegar Windows LAPS y crear una gMSA

Entorno recomendado: bosque de laboratorio aislado con al menos un DC en Windows Server 2022/2025 y un equipo miembro Windows 10/11 o Server 2019+. No usar un bosque de producción.

  1. Extender el esquema para Windows LAPS con Update-LapsADSchema -Confirm:$false (Schema Admins), y confirmar que aparecen los atributos msLAPS-* con Get-ADObject -Identity (Get-ADComputer PC-LAB01) -Properties msLAPS-Password.
  2. Delegar auto-actualización a la OU de prueba con Set-LapsADComputerSelfPermission -Identity "OU=Lab,DC=lab,DC=local", y configurar la política (GPO «LAPS» en Configuración de equipo → Plantillas administrativas → Sistema → LAPS): gestión, complejidad y periodo de rotación.
  3. Forzar gpupdate /force en el equipo de prueba y verificar en el visor de eventos que LAPS ha rotado.
  4. Recuperar la contraseña con Get-LapsADPassword -Identity "PC-LAB01" -AsPlainText y confirmar que cambia al forzar Reset-LapsPassword.
  5. Crear la KDS Root Key con Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10)) (forzado al pasado, solo válido en laboratorio de un único DC).
  6. Crear una gMSA de prueba con New-ADServiceAccount -Name "svc-lab-test" -DNSHostName "svc-lab-test.lab.local" -PrincipalsAllowedToRetrieveManagedPassword "PC-LAB01$", instalarla con Install-ADServiceAccount -Identity "svc-lab-test" y validar con Test-ADServiceAccount -Identity "svc-lab-test" (debe devolver True).
  7. Configurar un servicio de prueba para ejecutarse con la gMSA vía sc.exe config y confirmar que arranca sin pedir contraseña.
  8. Documentar pasos, capturas de los atributos poblados y el resultado de Test-ADServiceAccount como evidencia.

10. Errores comunes

  • Meter una cuenta de servicio en Protected Users sin verificación previa: el error más frecuente y disruptivo del módulo. Como se explica en 3.3, Protected Users prohíbe NTLM, delegación y credential caching de forma absoluta; una cuenta de servicio dependiente de alguno de esos mecanismos deja de funcionar al instante, a menudo sin mensaje de error claro. Limitar el grupo a cuentas humanas de alto privilegio, tras confirmar los cuatro requisitos de 3.3.
  • No proteger (ni respaldar) la contraseña del DSRM: como se ha visto en 8.3, es una credencial de máximo privilegio offline sobre cada DC que suele quedar fuera de cualquier programa de rotación por no gestionarse como cuenta de AD convencional. No incorporarla al alcance de Windows LAPS deja una puerta trasera de administrador local permanente y casi siempre olvidada.
  • Aplicar Authentication Policy Silos directamente en modo enforce, sin la fase previa de auditoría de 4.4, bloqueando a administradores legítimos fuera de sus propios sistemas.
  • Migrar de LAPS legacy a Windows LAPS sin plan de convivencia, dando por hecho que los atributos se traducen automáticamente cuando son de esquema distinto (5.4).
  • Forzar -EffectiveTime de la KdsRootKey al pasado en producción para «tener la gMSA ya», sin respetar el tiempo de replicación real entre DC, dejando hosts sin poder recuperar la contraseña gestionada de forma consistente.
  • Confundir el respaldo de Windows LAPS con un control de acceso por sí solo: la contraseña queda protegida en tránsito y reposo, pero si las ACL de lectura se delegan demasiado ampliamente (por ejemplo a «Authenticated Users» por error), cualquier usuario del dominio puede leer la contraseña de administrador local de cualquier equipo, anulando el propósito del control.

11. Ejercicio

Una organización con 400 equipos y 60 servidores tiene el escenario legacy típico: misma contraseña de Administrador local en todos los equipos, fijada hace años en la imagen base; 12 cuentas de servicio con SPN registrado y contraseñas que no han rotado nunca, 5 de ellas —por comodidad histórica— miembros de Domain Admins; y 8 administradores de TI que inician sesión con sus cuentas de Domain Admin indistintamente desde su portátil, servidores de salto y, en algún caso documentado, equipos de usuario final durante soporte de escritorio.

Diseña, en no más de 500 palabras, un plan de despliegue en cuatro fases ordenadas con los mecanismos de este módulo, justificando el orden elegido (qué se despliega primero y por qué, según el riesgo de romper producción de cada mecanismo) y qué verificación harías al final de cada fase. Cubre: resolución de la contraseña compartida de administrador local; reducción de cuentas en Domain Admins/creación de cuentas de servicio gestionadas donde sea viable; restricción de origen de autenticación de las cuentas administrativas; y endurecimiento del protocolo de autenticación para esas cuentas. Indica también qué harías con las 5 cuentas de servicio Domain Admins si ninguna es candidata viable a gMSA por depender de un producto de terceros que exige contraseña configurada manualmente.

Preguntas frecuentes

¿Puedo añadir directamente todas mis cuentas de Domain Admins a Protected Users sin más comprobación?

No es recomendable. Aunque Domain Admins es el tipo de grupo candidato, cada cuenta individual puede tener dependencias distintas: usarse también como cuenta de servicio de facto, depender de delegación para alguna tarea programada, o iniciar sesión desde un sistema legacy sin Kerberos AES. Audita cuenta por cuenta contra los cuatro requisitos de 3.3, empezando por las de menor riesgo de disrupción, antes de generalizar la membresía.

¿Windows LAPS sustituye por completo a Protected Users y a los silos de autenticación?

No, son controles complementarios en capas distintas. Windows LAPS resuelve la contraseña del administrador local por equipo; Protected Users endurece el protocolo de autenticación de una cuenta de dominio; los silos restringen desde dónde puede usarse esa cuenta. Un despliegue maduro de Tier 0 combina los tres a la vez.

¿Qué pasa con las contraseñas gestionadas por LAPS si el equipo se queda sin conectividad con el dominio durante mucho tiempo?

El cliente LAPS no puede rotar la contraseña sin conectividad con un DC, así que la vigente deja de rotar hasta restablecerse la conexión; no expira ni bloquea el acceso local. Al recuperar conectividad, el ciclo se reanuda según la política configurada. No es un fallo grave en sí mismo, pero conviene monitorizar equipos con desconexiones prolongadas como posible punto ciego.

¿Es obligatorio tener Credential Guard activo para que RunAsPPL o WDigest=0 sirvan de algo?

No, son independientes. WDigest a 0 y RunAsPPL pueden desplegarse sin Credential Guard y ya reducen el material extraíble de LSASS con herramientas convencionales. Credential Guard añade aislamiento de virtualización que resiste incluso a atacantes SYSTEM que sorteen RunAsPPL con un driver vulnerable firmado («bring your own vulnerable driver»). Se recomiendan los tres juntos, pero no son mutuamente dependientes.

¿Por qué gMSA especifica una rotación cada 30 días si la contraseña ya tiene 128 caracteres aleatorios?

La longitud y aleatoriedad hacen la contraseña inviable de crackear por fuerza bruta en cualquier plazo razonable, pero la rotación periódica aporta defensa en profundidad: limita la ventana de utilidad de una contraseña expuesta por otra vía (un volcado de memoria de un proceso que la tuviera cargada, o un host que ya no debería estar en PrincipalsAllowedToRetrieveManagedPassword). El intervalo es configurable con msDS-ManagedPasswordInterval si el criterio de riesgo exige un ciclo distinto a los 30 días por defecto.

«Members of the Protected Users group automatically have non-configurable protection applied to their accounts… Credentials are not cached… Kerberos does not use the weaker DES or RC4 encryption types… The user’s account cannot be delegated with constrained or unconstrained delegation… The default Kerberos ticket-granting ticket (TGT) lifetime setting of four hours is used.» — Microsoft Learn, «Protected Users Security Group», Windows Server security documentation.