Hardening de cuentas de servicio: gMSA, SPN y LAPS

Las cuentas de servicio estándar son uno de los puntos débiles más persistentes de Active Directory: contraseñas estáticas que rara vez se rotan, credenciales incrustadas en scripts y archivos de configuración, y nombres de entidad de seguridad de servicio (SPN) que convierten cuentas de usuario corrientes en objetivos para descifrar contraseñas sin conexión. La mayor parte de este riesgo tiene una solución directa y compatible en las versiones modernas de Windows Server; el obstáculo suele ser el esfuerzo de migración, no la falta de herramientas. Esta guía recorre el camino práctico de las cuentas de servicio estándar a las administradas, junto con los controles de directiva de contraseñas y de administrador local que completan el cuadro.

Por qué las cuentas de servicio estándar son un pasivo

Una cuenta de servicio heredada típica es un objeto de usuario normal con Password never expires activado, una contraseña elegida una vez durante el aprovisionamiento y que rara vez se cambia, y a menudo reutilizada en varias aplicaciones porque rotarla implica coordinar una parada con cada consumidor. Si esa cuenta tiene además registrado un nombre de entidad de seguridad de servicio (SPN), se convierte en objetivo de Kerberoasting: cualquier usuario autenticado del dominio puede solicitar un ticket de servicio Kerberos para ella e intentar descifrar sin conexión la parte cifrada del ticket, sin ningún intento de inicio de sesión y sin activar ningún bloqueo.

Las cuentas de servicio administradas de grupo (gMSA) y, en Windows Server 2025, las cuentas de servicio administradas delegadas (dMSA) resuelven el problema de fondo: AD genera y rota automáticamente una contraseña aleatoria de 240 bytes (120 caracteres), ningún humano la conoce y no puede reutilizarse en otro sitio, porque nunca la eligió una persona.

Migrar a gMSA

Requisitos previos

• gMSA necesita el esquema de Windows Server 2012 (o posterior) y al menos un DC con Windows Server 2012 o posterior; no hay requisito de nivel funcional. dMSA requiere controladores de dominio con Windows Server 2025.
• La KDS root key debe existir antes de poder crear la primera gMSA.

# Configuración única del bosque: comprobar si ya existe una KDS root key
Get-KdsRootKey

# Si no existe, crearla. En producción, respete la ventana de seguridad
# de replicación de 10 horas en lugar de retrotraer la fecha:
Add-KdsRootKey -EffectiveImmediately
# Solo laboratorio (un único DC): Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Crear y desplegar una gMSA

# Crear una gMSA limitada a los hosts autorizados a usarla
New-ADServiceAccount -Name "svc-sqlapp" `
    -DNSHostName "svc-sqlapp.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "SQLAppServers" `
    -Enabled $true

# En cada host autorizado, instalar la gMSA
Install-ADServiceAccount -Identity "svc-sqlapp"

# Verificar que el host puede obtener la contraseña administrada
Test-ADServiceAccount -Identity "svc-sqlapp"

Configure el servicio consumidor (por ejemplo, un servicio de Windows, un grupo de aplicaciones de IIS o una tarea programada) para que se ejecute como CORP\svc-sqlapp$ sin contraseña: el sistema operativo la obtiene y la rota de forma transparente.

# Asignar la gMSA a un servicio de Windows existente
sc.exe config "MyAppService" obj= "CORP\svc-sqlapp$"

dMSA para cuentas difíciles de migrar (Server 2025)

dMSA está pensada específicamente para las cuentas que no se pueden redirigir limpiamente a una identidad nueva: Windows puede vincular una dMSA a la cuenta de servicio estándar original y redirigir de forma transparente la autenticación Kerberos, lo que facilita la migración de servicios que tienen el nombre de cuenta codificado de forma fija.

# Crear una dMSA vinculada a una cuenta de servicio estándar existente para la migración
New-ADServiceAccount -Name "svc-sqlapp-dmsa" -DNSHostName "svc-sqlapp-dmsa.corp.example.com" `
    -CreateDelegatedServiceAccount -KerberosEncryptionType AES256

# Vincularla a la cuenta heredada e iniciar la migración
Start-ADServiceAccountMigration -Identity "svc-sqlapp-dmsa" `
    -SupersededAccount "CN=svc-sqlapp,OU=Service Accounts,DC=corp,DC=example,DC=com"

La secuencia completa de migración (iniciar, dejar que los hosts adopten la dMSA y, después, completar) se trata en Migrar cuentas de servicio a gMSA y dMSA. Pruébela en un laboratorio antes de tocar las cuentas de servicio de producción.

Higiene de SPN

Audite todos los SPN registrados en un objeto de usuario (no de equipo ni de gMSA): ese es el conjunto vulnerable a Kerberoasting:

Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName |
    Select-Object SamAccountName, ServicePrincipalName

Para cada resultado:

1. Identifique el servicio y el equipo responsable.
2. Migre el servicio para que se ejecute como gMSA/dMSA cuando la aplicación admita cuentas de servicio administradas de grupo (la mayoría de los escenarios modernos de SQL Server, IIS y servicios de Windows lo admiten).
3. Cuando la migración aún no sea posible, imponga una contraseña larga (25 caracteres o más) y aleatoria mediante una directiva de contraseñas específica dedicada (ver más abajo), y rótela.
4. Elimine por completo el SPN de toda cuenta cuyo servicio asociado ya no exista: los SPN obsoletos son habituales tras retirar aplicaciones.

# Eliminar un SPN obsoleto
Set-ADUser -Identity "svc_oldapp" -ServicePrincipalNames @{Remove="MSSQLSvc/oldapp.corp.example.com:1433"}

Directivas de contraseñas específicas (PSO)

La única directiva de contraseñas predeterminada del dominio suele ser demasiado débil para las cuentas privilegiadas y de servicio, pero demasiado estricta para imponerla a todos los usuarios. Las directivas de contraseñas específicas (Fine-Grained Password Policies) permiten añadir requisitos más estrictos a grupos concretos sin cambiar el valor predeterminado del dominio.

New-ADFineGrainedPasswordPolicy -Name "PSO-ServiceAccounts" `
    -Precedence 10 `
    -MinPasswordLength 32 `
    -PasswordHistoryCount 24 `
    -MaxPasswordAge "180.00:00:00" `
    -MinPasswordAge "1.00:00:00" `
    -ComplexityEnabled $true `
    -ReversibleEncryptionEnabled $false

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-ServiceAccounts" -Subjects "SVC-Accounts-NonMigrated"

New-ADFineGrainedPasswordPolicy -Name "PSO-Tier0Admins" `
    -Precedence 5 `
    -MinPasswordLength 20 `
    -MaxPasswordAge "60.00:00:00" `
    -ComplexityEnabled $true

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-Tier0Admins" -Subjects "Tier 0 Admins"

Cuando a una cuenta se le aplican varias PSO, gana el valor de Precedence más bajo. Verifique la directiva efectiva de cada cuenta:

Get-ADUserResultantPasswordPolicy -Identity "svc_oldapp"

Plantéese también un enfoque de contraseñas prohibidas, ya sea una DLL de filtro de contraseñas de terceros o el agente local de Entra Password Protection, para que tanto las contraseñas de las personas como las de las cuentas de servicio que aún fije una persona se comprueben en el momento de establecerlas contra una lista de contraseñas comprometidas o comunes, y no solo contra una expresión regular de complejidad.

Windows LAPS para las contraseñas de administrador local

Las contraseñas de administrador local compartidas en un parque de equipos multiplican el movimiento lateral: una sola contraseña de administrador local filtrada puede abrir todos los equipos que la comparten. Windows LAPS (integrado en Windows Server 2019 y posteriores y en Windows 10/11 con la actualización correspondiente, en sustitución de la CSE de LAPS heredado) aleatoriza y rota la contraseña del administrador local de cada equipo y la almacena cifrada en AD.

# Extender el esquema (una sola vez, en el maestro de esquema)
Update-LapsADSchema

# Configurar por GPO: Computer Configuration → Policies → Administrative Templates → System → LAPS
# Establecer "Configure password backup directory" en Active Directory (no ocurre nada hasta configurarlo),
# después "Password Settings" y, en los DC si procede, "Enable password backup for DSRM accounts"

# Establecer los permisos de la OU para que solo los administradores autorizados puedan leer la contraseña cifrada
Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=corp,DC=example,DC=com" -AllowedPrincipals "Tier2-Helpdesk-Admins"

# Verificar que un equipo está notificando su contraseña de LAPS
Get-LapsADPassword -Identity "WKS-01" -AsPlainText

Nota: la gestión de las credenciales de DSRM y del administrador local de los DC es un tema distinto. Windows LAPS puede gestionar la contraseña de DSRM de los controladores de dominio, como se describe en la implementación de Windows LAPS; consulte también las recomendaciones específicas para DC en lugar de aplicar a los controladores de dominio los supuestos de alcance de LAPS para estaciones de trabajo.

Lista de verificación

# Confirmar que ninguna cuenta de usuario tiene SPN fuera de una lista de excepciones aprobada
Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName

# Confirmar que los hosts previstos pueden obtener las cuentas gMSA
Test-ADServiceAccount -Identity "svc-sqlapp"

# Confirmar que la PSO se aplica al grupo previsto
Get-ADFineGrainedPasswordPolicySubject -Identity "PSO-ServiceAccounts"

# Confirmar que LAPS está rotando activamente en una muestra de equipos
Get-LapsADPassword -Identity "WKS-01" | Select-Object PasswordUpdateTime, ExpirationTimestamp

Qué se rompe

• Aplicaciones que no admiten gMSA. Algunos programas heredados o de terceros exigen una cuenta de tipo interactivo con una contraseña configurable y no pueden usar una identidad de tipo cuenta de equipo. Estas se quedan en cuentas estándar, aisladas tras la PSO más estricta que pueda aplicar, hasta que el fabricante añada compatibilidad.
• El uso de servicios entre bosques o entre dominios puede complicar el despliegue de gMSA, ya que la obtención de la contraseña depende de la replicación de la KDS root key y de la resolución de la pertenencia a grupos dentro del ámbito.
• Las credenciales codificadas en scripts o archivos de configuración que hacen referencia a la contraseña de la cuenta antigua dejarán de funcionar en cuanto se cambie a una gMSA sin contraseña estática: búsquelas antes del cambio, no después.
• Los flujos de trabajo del soporte técnico basados en contraseñas de administrador local compartidas tendrán que cambiar cuando Windows LAPS imponga una contraseña única por equipo; documente el nuevo proceso de consulta (Get-LapsADPassword) para el personal de soporte.

Esta guía no trata deliberadamente la rotación de la contraseña de krbtgt: tiene su propia cadencia y sus propias consideraciones de impacto, y se aborda en una guía específica. Consulte también hardening de Kerberos para la configuración más amplia de Kerberos con la que se complementa.