Migrar cuentas de servicio a gMSA y dMSA

Una cuenta de servicio estática es una credencial de larga duración con un SPN asociado, una contraseña que nadie se atreve a cambiar y derechos de inicio de sesión en servidores de varios niveles. Es el objetivo de manual del Kerberoasting y, cuando su contraseña acaba en un recurso compartido de scripts o en un archivo de configuración, se convierte en una ruta de movimiento lateral que sobrevive a cualquier otro proyecto de hardening. La guía principal sobre hardening de cuentas de servicio explica por qué las cuentas administradas resuelven esto; esta guía es el runbook de migración: cómo inventariar lo que tiene, crear correctamente la KDS root key, acotar al máximo la obtención de contraseñas, trasladar las cargas de trabajo habituales y usar dMSA en Windows Server 2025 para las cuentas que no puede redirigir fácilmente.

El método es el mismo que en el resto de este sitio: medir el entorno, auditar las dependencias de cada cuenta, aplicar la nueva identidad aplicación por aplicación y verificar que nada sigue usando la antigua antes de deshabilitarla.

Medir: inventariar todas las identidades de servicio

Empiece por los objetos de usuario que se comportan como servicios: SPN, contraseñas que no caducan, contraseñas antiguas y actividad de inicio de sesión desde servidores en lugar de estaciones de trabajo.

Get-ADUser -Filter 'ServicePrincipalName -like "*" -or PasswordNeverExpires -eq $true' `
    -Properties ServicePrincipalName, PasswordNeverExpires, PasswordLastSet, LastLogonTimestamp, Description, adminCount |
  Select-Object SamAccountName, adminCount, PasswordNeverExpires, PasswordLastSet,
    @{n='LastLogon';e={[datetime]::FromFileTime($_.LastLogonTimestamp)}},
    @{n='SPNs';e={$_.ServicePrincipalName -join ';'}}, Description |
  Export-Csv .\service-account-inventory.csv -NoTypeInformation

Después, averigüe dónde se ejecuta realmente cada cuenta. En los servidores miembro, los consumidores habituales son el Administrador de control de servicios y el Programador de tareas:

# Ejecutar contra una lista de servidores desde un host de administración del nivel adecuado
$servers = Get-Content .\servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-CimInstance Win32_Service | Where-Object StartName -match '\\' |
        Select-Object @{n='Host';e={$env:COMPUTERNAME}}, Name, StartName
    Get-ScheduledTask | Where-Object { $_.Principal.UserId -match '\\' } |
        Select-Object @{n='Host';e={$env:COMPUTERNAME}}, TaskName, @{n='StartName';e={$_.Principal.UserId}}
}

Esto no detecta los grupos de aplicaciones de IIS, las aplicaciones COM+, los proxies del Agente SQL ni las credenciales almacenadas dentro de las aplicaciones. Compleméntelo con los eventos de inicio de sesión: el evento 4624 con tipo de inicio de sesión 5 (servicio) y 4 (lote) en los servidores miembro, y el evento 4769 en los controladores de dominio, que muestra qué SPN se solicitan y quién lo hace. La referencia de ID de eventos enumera los campos que conviene extraer.

Auditar: decidir el destino de cada cuenta

Clasifique cada cuenta en uno de estos cuatro grupos:

1. Muerta: sin inicios de sesión en 90 días o más y sin consumidor identificado. Deshabilítela, espere un ciclo y elimínela.
2. Compatible con gMSA: servicios de Windows, tareas programadas, grupos de aplicaciones de IIS, motor y Agente de SQL Server, la mayoría de los productos de servidor de Microsoft. Migre a gMSA.
3. Difícil de redirigir: el nombre de la cuenta está incrustado en muchos clientes, en un dispositivo de un fabricante o en ACL que no puede traducir fácilmente. Candidata a dMSA si dispone de DC con Windows Server 2025.
4. Incompatible: la aplicación necesita una contraseña que pueda escribir, o se ejecuta en una plataforma que no es Windows. Mantenga una cuenta estándar con una contraseña aleatoria de más de 30 caracteres, solo AES, y una directiva de contraseñas específica dedicada.

Anote también si la cuenta necesita delegación. Una gMSA admite la delegación restringida y la delegación restringida basada en recursos como cualquier otra entidad de seguridad; no arrastre la delegación sin restricciones durante el traslado.

Aplicar: construir la base de gMSA una sola vez

KDS root key

Las contraseñas de gMSA se derivan de la KDS root key del bosque, del SID de la gMSA y del intervalo de tiempo actual. La clave debe existir y haberse replicado antes de que cualquier DC calcule una contraseña.

Get-KdsRootKey | Select-Object KeyId, EffectiveTime, CreationTime

# Producción: crearla una vez y esperar a la replicación (efectiva a las 10 horas de forma predeterminada)
Add-KdsRootKey -EffectiveImmediately

Pese a su nombre, -EffectiveImmediately sigue esperando en la práctica la ventana de seguridad de 10 horas; retrotraer -EffectiveTime solo es para laboratorios con un único DC. La KDS root key reside en la partición de configuración, y cualquiera que pueda leerla (Domain Admins, Enterprise Admins, SYSTEM en un DC) puede calcular sin conexión todas las contraseñas de gMSA, el ataque conocido como Golden gMSA. Trátela como material de Tier 0 e inclúyala en su plan de recuperación del bosque.

Grupos de obtención

Cree un grupo de seguridad por cada gMSA que contenga únicamente las cuentas de equipo que ejecutan la carga de trabajo. Ese grupo se escribe en msDS-GroupMSAMembership, expuesto como PrincipalsAllowedToRetrieveManagedPassword.

New-ADGroup -Name "gMSA-svc-sqlapp-Hosts" -GroupScope Global -GroupCategory Security `
    -Path "OU=gMSA Groups,OU=Tier1,DC=corp,DC=example,DC=com"
Add-ADGroupMember "gMSA-svc-sqlapp-Hosts" -Members "SQL01$","SQL02$"

New-ADServiceAccount -Name "gmsa-sqlapp" `
    -DNSHostName "gmsa-sqlapp.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "gMSA-svc-sqlapp-Hosts" `
    -KerberosEncryptionType AES128,AES256 `
    -ManagedPasswordIntervalInDays 30 `
    -Path "OU=Service Accounts,OU=Tier1,DC=corp,DC=example,DC=com"

ManagedPasswordIntervalInDays solo puede establecerse en la creación. KerberosEncryptionType mantiene RC4 fuera de la cuenta, lo que importa si está trabajando en deshabilitar RC4. Traslade los SPN de la cuenta antigua a la gMSA con Set-ADServiceAccount -ServicePrincipalNames @{Add=...} después de quitarlos de la cuenta antigua, porque los SPN duplicados rompen Kerberos.

En cada host, renueve su pertenencia a grupos y haga la prueba:

klist -li 0x3e7 purge
Test-ADServiceAccount -Identity "gmsa-sqlapp"

Install-ADServiceAccount es opcional para gMSA en las versiones actuales de Windows; la comprobación que importa es que Test-ADServiceAccount devuelva True.

Proteger la propia gMSA

Una gMSA es tan fuerte como la lista de entidades autorizadas a leer su contraseña. El DC devuelve la contraseña actual y la anterior en el atributo construido msDS-ManagedPassword a cualquier entidad incluida en msDS-GroupMSAMembership, así que esa lista es, en la práctica, la ACL de un almacén de credenciales. Tres reglas la mantienen bajo control:

• Asigne a la gMSA el mismo nivel que sus hosts. Una gMSA usada por un servidor de aplicaciones de Tier 1 no debe poder obtenerla un equipo de Tier 2, y una gMSA con derechos sobre los DC o sobre la infraestructura de copia de seguridad es Tier 0, igual que los grupos y las OU que la controlan.
• Controle quién puede cambiar la lista de obtención. Cualquiera con acceso de escritura a msDS-GroupMSAMembership en la gMSA, o a la pertenencia al grupo de obtención, puede añadir un equipo que controle y leer la contraseña. Revise esas ACL con las mismas herramientas que usa para la gestión de rutas de ataque.
• Audite la obtención. Una SACL en los objetos gMSA para las lecturas de msDS-ManagedPassword genera el evento 4662 en los DC. Las lecturas legítimas proceden de los hosts del grupo de obtención, aproximadamente en cada intervalo de contraseña y al iniciar el servicio; las lecturas desde cualquier otra cuenta merecen una alerta.

Notas por aplicación

Servicios de Windows y tareas programadas

Los servicios usan la cuenta con un $ final y una contraseña vacía. La cuenta necesita Log on as a service, que sc.exe y la consola Servicios conceden automáticamente en el host local; si la asignación de derechos de usuario se gestiona por GPO, añada la gMSA a ese GPO o la siguiente actualización se lo quitará.

sc.exe config "AppService" obj= "CORP\gmsa-sqlapp$" password= ""

$principal = New-ScheduledTaskPrincipal -UserId "CORP\gmsa-report$" -LogonType Password
Set-ScheduledTask -TaskName "NightlyReport" -Principal $principal

Las tareas programadas necesitan Log on as a batch job en lugar del derecho de servicio.

Grupos de aplicaciones de IIS

En el Administrador de IIS, establezca la identidad del grupo en CORP\gmsa-web$ con la contraseña en blanco. Para la autenticación Kerberos en el sitio, registre el SPN HTTP en la gMSA y habilite la autenticación en modo kernel con useAppPoolCredentials, para que los tickets se descifren con las claves de la gMSA. Las granjas web funcionan bien porque todos los nodos están en el grupo de obtención.

SQL Server

Cambie las cuentas del motor y del Agente mediante el Administrador de configuración de SQL Server, no desde la consola Servicios, para que se actualicen los permisos del sistema de archivos, del Registro y de los SPN. Consulte la documentación de su versión de SQL Server para las instancias de clúster de conmutación por error y los grupos de disponibilidad: la compatibilidad se ha ido ampliando con las versiones, y todas las réplicas deben estar en el grupo de obtención. Traslade los SPN MSSQLSvc/ a la gMSA.

Lo que gMSA no cubre bien

Las aplicaciones que almacenan la contraseña del servicio en su propia base de datos, los escenarios entre bosques en los que el host consumidor está en otro bosque y la mayoría de las plataformas que no son Windows. Estos casos se quedan en el grupo 4.

dMSA en Windows Server 2025

Las cuentas de servicio administradas delegadas (dMSA) requieren al menos un controlador de dominio con Windows Server 2025 y la KDS root key. La migración vincula una dMSA nueva a una cuenta estándar existente; durante la migración, la autenticación Kerberos de la cuenta antigua se redirige a la dMSA y, al completarse, la contraseña de la cuenta original deja de usarse.

New-ADServiceAccount -Name "dmsa-legacyapp" -DNSHostName "dmsa-legacyapp.corp.example.com" `
    -CreateDelegatedServiceAccount -KerberosEncryptionType AES256 `
    -Path "OU=Service Accounts,OU=Tier1,DC=corp,DC=example,DC=com"

Start-ADServiceAccountMigration -Identity "dmsa-legacyapp" `
    -SupersededAccount "CN=svc_legacyapp,OU=Service Accounts,DC=corp,DC=example,DC=com"

# Cuando el host haya adoptado la dMSA y la aplicación esté validada
Complete-ADServiceAccountMigration -Identity "dmsa-legacyapp" `
    -SupersededAccount "CN=svc_legacyapp,OU=Service Accounts,DC=corp,DC=example,DC=com"

Para revertir existen Undo-ADServiceAccountMigration y Reset-ADServiceAccountMigration. Los nombres de los parámetros se han ajustado desde el lanzamiento, así que consulte Get-Help en sus DC antes de escribir scripts. El vínculo se almacena en msDS-ManagedAccountPrecededByLink en la dMSA y en msDS-SupersededManagedAccountLink en la cuenta antigua.

Nota de seguridad: en 2025, unos investigadores publicaron «BadSuccessor», que demostraba que una entidad capaz de crear una dMSA en cualquier OU podía hacer que ese vínculo apuntara a una cuenta privilegiada y heredar sus permisos. Microsoft lo corrigió en una actualización de seguridad (CVE-2025-53779), pero la lección de fondo sigue vigente: audite quién tiene Create msDS-DelegatedManagedServiceAccount o derechos genéricos de creación de objetos secundarios (Create Child) en las OU, exactamente igual que haría con cualquier otra ACL peligrosa.

Verificar

Antes de deshabilitar una cuenta antigua, confirme que la nueva identidad funciona y que la antigua no tiene actividad.

# Estado de las gMSA y alcance de la obtención
Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword, msDS-SupportedEncryptionTypes, PasswordLastSet |
  Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes,
    @{n='Retrievers';e={$_.PrincipalsAllowedToRetrieveManagedPassword -join ';'}}

# Cuenta antigua: sin autenticaciones recientes
Get-ADUser svc_legacyapp -Properties LastLogonTimestamp, ServicePrincipalName |
  Select-Object Name, @{n='LastLogon';e={[datetime]::FromFileTime($_.LastLogonTimestamp)}}, ServicePrincipalName

Marque toda gMSA cuyos entidades de obtención incluyan cuentas de usuario, Domain Computers o grupos anidados que no controle. Vigile las solicitudes 4769 contra los SPN antiguos y los errores 4625 que mencionen la cuenta antigua durante al menos un ciclo de negocio completo (procesos de cierre de mes); después, deshabilítela, manténgala deshabilitada 30 días y elimínela. Vuelva a ejecutar el inventario de defensa contra Kerberoasting para confirmar que el SPN ya no está en objetos de usuario.

Qué se rompe

• Servicios que arrancan antes de que el host tenga un TGT nuevo. Un host recién añadido falla con un error de inicio de sesión hasta que se reinicie o se purguen sus tickets. Incluya ese paso en el plan de cambio.
• Los derechos de usuario gestionados por GPO quitan a la gMSA el derecho Log on as a service o de lote en la siguiente actualización si la gMSA no está en la directiva.
• Las credenciales codificadas en cadenas de conexión, scripts y consolas de fabricantes dejan de funcionar porque no hay contraseña que escribir. Encuéntrelas durante la auditoría, no después del cambio.
• Los SPN duplicados durante el traslado provocan errores de Kerberos y una recurrencia silenciosa a NTLM. Quite antes de añadir.
• Los consumidores de otros bosques y los clientes no Windows no pueden obtener contraseñas de gMSA; se quedan con cuentas estándar.
• dMSA requiere DC con Windows Server 2025 y que los hosts que ejecutan el servicio sean también Windows Server 2025; los hosts más antiguos no pueden usarla.

Lecturas relacionadas: el tema Contraseñas y cuentas de servicio agrupa esta guía con el despliegue de Windows LAPS, y la entrada de glosario sobre gMSA resume el modelo de atributos.