Windows Server: servicios y tareas programadas con cuentas de servicio administradas (gMSA) y un servicio que no arranca tras un cambio de contraseña

Qué vas a conseguir

Sacar los servicios y las tareas programadas de las cuentas svc- con una contraseña que alguien apuntó en una hoja hace años, y pasarlos a cuentas de servicio administradas de grupo (gMSA): Active Directory genera y cambia la contraseña solo, y solo los servidores autorizados pueden usarla. Y, mientras quede alguna cuenta antigua, resolver en diez minutos el ticket del servicio que no arranca porque alguien le cambió la contraseña.

Antes de empezar

• Un dominio con controladores de dominio Windows Server 2012 o posterior (cualquier versión con soporte lo cumple).
• Permisos para crear objetos en OU=Cuentas de servicio,DC=contoso,DC=local y, una vez por bosque, alguien de Administradores de empresa o Administradores del dominio para la clave KDS.
• En cada servidor que use la gMSA, el módulo de AD: Install-WindowsFeature RSAT-AD-PowerShell.
• El inventario de lo que corre con cuentas de dominio. Empieza por aquí:

›Get-CimInstance Win32_Service | Where-Object StartName -like 'CONTOSO\*' | Select-Object Name, StartName, State, StartModeName             StartName              State   StartMode----             ---------              -----   ---------ContosoFacturas  CONTOSO\svc-facturas   Running Auto›Get-ScheduledTask | Where-Object { $_.Principal.UserId -like '*svc-*' } | Select-Object TaskPath, TaskName, @{n='Cuenta';e={$_.Principal.UserId}}TaskPath   TaskName             Cuenta--------   --------             ------\Contoso\  Exportar facturas    CONTOSO\svc-facturas

1. Qué cuenta usar

Una gMSA por aplicación, no una para todo: si alguien la usa mal, el alcance es una aplicación.

2. La clave raíz KDS (una vez por bosque)

Los controladores de dominio calculan las contraseñas de las gMSA a partir de una clave raíz KDS. Comprueba si ya existe:

›Get-KdsRootKey›Add-KdsRootKey -EffectiveImmediatelyGuid----4e1b5c3a-8d2f-4b6e-9a71-0c3d5e7f9b12

• Con -EffectiveImmediately, la clave no se puede usar hasta 10 horas después: es el margen para que replique a todos los controladores. Créala la víspera.
• En un laboratorio con un solo controlador se salta la espera con Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10)). En producción, no.

3. Crear la gMSA

Primero un grupo con los servidores que podrán usarla; después la cuenta:

›New-ADGroup -Name 'GG-gMSA-Informes' -GroupScope Global -Path 'OU=Cuentas de servicio,DC=contoso,DC=local'›Add-ADGroupMember -Identity 'GG-gMSA-Informes' -Members 'SRV-GESTION01$'›New-ADServiceAccount -Name 'gmsa-informes' -DNSHostName 'gmsa-informes.contoso.local' -PrincipalsAllowedToRetrieveManagedPassword 'GG-gMSA-Informes' -Path 'OU=Cuentas de servicio,DC=contoso,DC=local'›Get-ADServiceAccount gmsa-informes -Properties PrincipalsAllowedToRetrieveManagedPassword, ManagedPasswordIntervalInDays | Select-Object Name, ManagedPasswordIntervalInDays, PrincipalsAllowedToRetrieveManagedPasswordName          ManagedPasswordIntervalInDays PrincipalsAllowedToRetrieveManagedPassword----          ----------------------------- ------------------------------------------gmsa-informes                            30 {CN=GG-gMSA-Informes,OU=Cuentas de servicio,DC=contoso,DC=local}

• El nombre tiene un máximo de 15 caracteres: es el sAMAccountName, al que AD añade el $.
• Un servidor que acabas de añadir al grupo no lo sabe hasta que renueva su ticket de Kerberos: reinícialo o, sin reiniciar, klist -li 0x3e7 purge en ese servidor.

4. Instalar y probar en el servidor

›Install-ADServiceAccount gmsa-informes›Test-ADServiceAccount gmsa-informesTrue

True significa que este servidor puede pedir la contraseña a AD. False casi siempre es uno de tres: el servidor no está en el grupo, no ha renovado su ticket desde que lo añadiste o la clave KDS todavía no es efectiva.

5. Asignarla a un servicio

En services.msc, el servicio › Propiedades › Iniciar sesión:

Desde la línea de comandos, en una consola cmd (en Windows PowerShell 5.1 las comillas vacías no llegan a sc.exe):

›sc.exe config ContosoInformes obj= "CONTOSO\gmsa-informes$" password= ""[SC] ChangeServiceConfig CORRECTO›sc.exe stop ContosoInformes && sc.exe start ContosoInformes

• sc.exe no concede el derecho Iniciar sesión como servicio: si lo usas, dalo por GPO en Asignación de derechos de usuario o el servicio no arrancará (evento 7041).
• Después, los permisos que la aplicación necesita, a la gMSA y nada más: su base de datos en SQL Server (CREATE LOGIN [CONTOSO\gmsa-informes$] FROM WINDOWS), su carpeta compartida, su OU.

6. Asignarla a una tarea programada

La interfaz del Programador de tareas pide una contraseña y no sirve para una gMSA. Con PowerShell:

›$quien = New-ScheduledTaskPrincipal -UserId 'CONTOSO\gmsa-informes$' -LogonType Password›Set-ScheduledTask -TaskName 'Exportar informes' -TaskPath '\Contoso\' -Principal $quien›(Get-ScheduledTask -TaskName 'Exportar informes' -TaskPath '\Contoso\').Principal | Select-Object UserId, LogonTypeUserId          LogonType------          ---------gmsa-informes$  Password

La gMSA necesita el derecho Iniciar sesión como proceso por lotes en el servidor. Un ejemplo completo de tarea con gMSA, con el script y sus comprobaciones, está en el informe semanal de Active Directory con PowerShell.

7. El ticket: "el servicio no arranca después del cambio de contraseña"

Lunes, 7:50. La aplicación de facturación no responde. En srv-app02, el servicio ContosoFacturas está detenido y al arrancarlo: Error 1069: El servicio no se inició debido a un error de inicio de sesión.

›Get-WinEvent -FilterHashtable @{LogName='System'; ProviderName='Service Control Manager'; Id=7000,7038,7041; StartTime=(Get-Date).AddDays(-3)} | Select-Object TimeCreated, Id, Message -First 2 | Format-ListTimeCreated : 03/11/2026 7:52:10Id          : 7038Message     : El servicio ContosoFacturas no pudo iniciar sesión como CONTOSO\svc-facturas con la contraseña configurada actualmente debido al siguiente error: El nombre de usuario o la contraseña no son correctos.TimeCreated : 03/11/2026 7:52:10Id          : 7000Message     : El servicio ContosoFacturas no pudo iniciarse debido al siguiente error: El servicio no se ha iniciado debido a un error de inicio de sesión.

• 7038 + 7000: la contraseña guardada en el servicio ya no es la de AD.
• 7041: la contraseña es buena, pero a la cuenta le falta el derecho Iniciar sesión como servicio (una GPO de seguridad lo ha sobrescrito).

Después, la cuenta en AD:

›Get-ADUser svc-facturas -Properties PasswordLastSet, LockedOut, Enabled, AccountExpirationDate | Select-Object Enabled, LockedOut, PasswordLastSet, AccountExpirationDateEnabled LockedOut PasswordLastSet      AccountExpirationDate------- --------- ---------------      ---------------------   True      True 31/10/2026 18:04:33

La contraseña se cambió el viernes (PasswordLastSet) y la cuenta está bloqueada: el servicio, y probablemente otros servidores con la misma cuenta, siguen probando la contraseña vieja. Por eso el inventario del principio importa: hay que cambiarla en todos los sitios donde se usa, o la cuenta se vuelve a bloquear en minutos.

1. La contraseña nueva, del gestor de contraseñas del equipo (o la pide el responsable de la aplicación).
2. En cada servidor y en cada tarea que usa svc-facturas: Propiedades › Iniciar sesión con la contraseña nueva (o sc.exe config ContosoFacturas obj= "CONTOSO\svc-facturas" password= "..." desde cmd).
3. Unlock-ADAccount svc-facturas y Start-Service ContosoFacturas. Comprueba que la aplicación responde y que no hay nuevos 7038.
4. El arreglo de verdad, en un cambio planificado: una gMSA gmsa-facturas con los puntos 3 a 6, permisos en SQL Server y la cuenta svc-facturas deshabilitada tras dos semanas sin uso.

Si el servicio ya corría con una gMSA y da 7000, la causa es otra: Test-ADServiceAccount en ese servidor. Casi siempre es un servidor nuevo o reinstalado que nadie añadió al grupo GG-gMSA-....

En el ticket: servicio, eventos, estado de la cuenta, dónde se cambió la contraseña y la propuesta de pasar a gMSA.

Siguientes pasos

• La guía de IIS tiene el mismo problema en un grupo de aplicaciones (el evento 5021 de WAS) y la misma solución.
• La primera guía de Windows Server explica cómo leer el visor de eventos con filtros como los de aquí.
• Las cuentas de servicio que no pueden ser gMSA son candidatas a un gestor de acceso privilegiado con rotación automática, como el de la guía de CyberArk del Nivel 4.

¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.