Piloto de primer despliegue gMSA: validar KDS antes del cambio

Un objeto gMSA no es un servicio migrado

Un piloto de primer despliegue gMSA debe terminar con un servicio que funcione bajo su nueva identidad, una decisión de reversión aprobada y pruebas procedentes de los hosts que realmente lo ejecutan. Crear una cuenta de servicio administrada de grupo en Active Directory establece una cuenta. No demuestra que una carga de trabajo de producción utilice esa cuenta, que todos los hosts necesarios puedan recuperar sus credenciales ni que la carga conserve los accesos adecuados tras el cambio.

Esta distinción importa cuando una auditoría informa de que no se utilizan gMSA. Trate ese resultado como una señal para investigar el inventario del directorio y el conjunto de servicios. Un objeto nuevo puede hacer desaparecer una señal de inventario mientras todos los servicios siguen funcionando con su identidad anterior. A la inversa, una recopilación incompleta puede pasar por alto un objeto existente. Ninguno de estos resultados responde a la pregunta operativa: ¿qué servicio se ha migrado correctamente?

Mantenga tres registros separados: objetos del directorio, preparación de los hosts y adopción por los servicios. El primero identifica las cuentas; el segundo registra si un host concreto puede utilizar la cuenta seleccionada; el tercero documenta una carga de trabajo probada que la utiliza. Este artículo propone un control previo a la primera adopción, con un servicio y un plan de recuperación explícito. No presupone que todos los usuarios con SPN representen servicios compatibles y activos.

Cómo funciona un piloto de primer despliegue gMSA

Comience con un responsable del servicio y un inventario de la carga de trabajo, en lugar de una solicitud de creación de cuenta. Registre el nombre del servicio, su identidad actual, la lista de hosts, la versión de la aplicación, la configuración de inicio, los clientes y los recursos utilizados posteriormente. Pregunte al responsable qué funciones deben seguir disponibles y qué pruebas demostrarían que el cambio funcionó. Un proceso que se inicia pero no puede escribir su salida programada ha fallado en el piloto.

Microsoft documenta la compatibilidad con gMSA para servicios configurados mediante Service Control Manager, grupos de aplicaciones de IIS, el Programador de tareas y productos compatibles con las API de cuentas administradas. El propio servicio Cluster no admite gMSA; los servicios compatibles que se ejecutan sobre él sí pueden hacerlo. Confirme el producto exacto y la topología de despliegue con su responsable antes de seleccionar el piloto. Microsoft Learn — Administrar cuentas de servicio administradas de grupo.

Organice el registro del cambio en torno a estos controles independientes:

Son controles propuestos para el piloto, no resultados ya medidos en su entorno. Asigne un responsable a cada control. El responsable de AD se ocupa de la dependencia del bosque; el del servicio acepta el comportamiento de la carga de trabajo; quien aprueba el cambio autoriza la transición y la recuperación. Registre quién puede detener el piloto si estas valoraciones difieren.

Detección: inspeccionar los objetos, la preparación de KDS y cada host

Conciliar un inventario del directorio basado en la clase

Utilice una búsqueda independiente por clase para comprobar qué significa el inventario del recopilador. El siguiente ejemplo es de solo lectura y combina los parámetros documentados de Get-ADServiceAccount. Sustituya el DC y el DN de dominio ilustrativos por el alcance aprobado; repítalo para cada dominio incluido en el piloto. No se ha ejecutado contra su directorio.

Get-ADServiceAccount -LDAPFilter '(objectClass=msDS-GroupManagedServiceAccount)' -SearchBase 'DC=example,DC=com' -SearchScope Subtree -Server 'dc01.example.com' -ResultSetSize $null

-LDAPFilter selecciona la clase estructural independientemente de la heurística del recopilador basada en el atributo de pertenencia. -SearchBase, -SearchScope y -Server hacen explícito el límite previsto; -ResultSetSize $null evita imponer un límite al total de resultados. En usos más generales, el cmdlet devuelve tanto cuentas administradas independientes como cuentas administradas de grupo, por lo que debe conservar la restricción de clase para este inventario. Microsoft Learn — Get-ADServiceAccount.

Registre las identidades devueltas y su estado habilitado, junto con el alcance y el resultado de la consulta. Si esta búsqueda encuentra un gMSA que el recopilador no reconoció, investigue los permisos, los atributos solicitados, los límites de búsqueda y de resultados. No resuelva la discrepancia creando otra cuenta. Si la búsqueda falla, conserve el error como un fallo de recopilación; una consulta correcta sin resultados y una consulta fallida constituyen pruebas diferentes.

A continuación, relacione cada objeto pertinente con las configuraciones reales de los servicios. Determine si no se utiliza, está en preparación, se ha retirado o lo utiliza una carga de trabajo probada. Mantenga como no relacionado cualquier objeto sin correspondencia. El nombre de una cuenta del directorio por sí solo no permite identificar al responsable de un servicio ni demostrar que algún host la utilice.

Inspeccionar las claves KDS existentes antes de solicitar una nueva

Desde un contexto administrativo autorizado con el módulo KDS, utilice el comando de lectura documentado:

Get-KdsRootKey

Recupera la lista de claves raíz existentes, incluidos sus valores. Inspecciónela en el entorno administrativo y conserve en el registro del cambio solo los identificadores necesarios y la decisión sobre la preparación; no pegue material de claves sin procesar en un ticket de uso general. Este comando es un paso de inventario, no una prueba de replicación. Microsoft Learn — Get-KdsRootKey.

Microsoft describe una espera de hasta diez horas tras crear la clave raíz para que la replicación de los DC pueda converger antes de utilizar el gMSA. Los horarios de replicación limitados o los problemas de replicación aún pueden provocar fallos de recuperación. Pida al responsable de AD que verifique la disponibilidad de la clave y el estado de la replicación para los DC que atienden a los hosts del piloto; el tiempo transcurrido por sí solo no constituye esa prueba. Microsoft Learn — Crear una clave raíz KDS.

Si ya existe una clave adecuada, el procedimiento de administración indica que se omita su creación. Si no existe ninguna, establezca como requisito previo el proceso documentado de creación de claves y replicación del responsable de AD, con sus propios plazos y autorización. No integre una dependencia del bosque en un cambio de cuenta de servicio sin revisar.

Probar la preparación en los hosts realmente autorizados

Revise las entidades aprobadas para recuperar la contraseña y confirme que coinciden con el conjunto de hosts previsto. Las instrucciones de administración de Microsoft también exigen SPN adecuados, DNS, acceso a la red, sincronización de relojes y tipos de cifrado Kerberos compatibles. Trátelos como requisitos previos que deben investigarse, sin dar por hecho que una búsqueda correcta en el directorio los verifica.

Ejecute localmente la prueba de cuenta documentada en cada host previsto, sustituyendo el nombre de cuenta ilustrativo:

Test-ADServiceAccount -Identity 'svc-pilot'

Microsoft define una prueba correcta como la preparación para autenticarse y acceder al dominio con las credenciales actuales de la cuenta. Registre el host, la hora, la cuenta y el resultado real. No ejercita las consultas de base de datos de su aplicación, sus escrituras de archivos, la autenticación de clientes ni su comportamiento al reiniciarse. Microsoft Learn — Test-ADServiceAccount.

Un fallo suspende el cambio. Investigue con los responsables correspondientes la autorización prevista del host, el acceso al directorio y la dependencia de KDS/replicación. Ampliar el acceso de recuperación a un grupo amplio no es un atajo aceptable. La revisión de permisos de recuperación de contraseñas gMSA explica por qué el conjunto de lectores constituye un límite de seguridad que merece una revisión independiente.

Remediación: probar un servicio con una reversión utilizable (Remediation)

1. Acordar las pruebas de aceptación y la vía de recuperación

Elija una carga de trabajo compatible cuyo responsable pueda observar tanto el funcionamiento normal como los fallos. Antes de cambiar su identidad, conserve su configuración aprobada, sus permisos existentes, su comportamiento al iniciarse y los resultados de referencia de la carga. Anote la ventana de mantenimiento, la persona que aprueba el cambio, quien ejecuta la recuperación y las condiciones que la desencadenan.

Defina condiciones específicas para el servicio: un cliente necesario no puede autenticarse, falla una operación programada, un recurso esperado resulta inaccesible o un reinicio no restablece el servicio. Defina el periodo de observación con el responsable en lugar de inventar una duración universal. Una carga que solo se ejecuta en un momento programado necesita que la decisión de aceptación cubra esa ejecución.

2. Preparar el host autorizado y los permisos de la cuenta

Revise los derechos locales de servicio del candidato y sus permisos sobre los recursos posteriores antes del cambio. Solicite los permisos necesarios para las operaciones previstas de la carga de trabajo; conserve las dependencias de la identidad anterior durante la ventana de recuperación. Mantenga separada la autorización para recuperar contraseñas de la autorización para acceder a los datos de la aplicación. Superar la prueba de la cuenta no demuestra ni el conjunto completo de permisos de la aplicación ni que su configuración sea correcta.

Tras superar los controles de directorio y autorización, el procedimiento de Microsoft instala la cuenta en cada host donde se ejecuta el servicio. Ejecútelo localmente en una sesión elevada de PowerShell dentro del cambio aprobado:

Install-ADServiceAccount -Identity 'svc-pilot'

El cmdlet prepara la cuenta administrada existente en el equipo local. No cambia la identidad configurada de la aplicación. Su referencia exige que se configure la autorización de recuperación para un gMSA. Microsoft Learn — Install-ADServiceAccount.

Repita la prueba de preparación de la cuenta en ese host y conserve el resultado. Si falla la instalación o la prueba, deténgase en este control e investigue. No registre la finalización de un comando administrativo como una migración de servicio correcta.

3. Realizar el cambio mediante la configuración admitida por el servicio

Utilice el procedimiento de configuración de identidad compatible con el producto para migrar el servicio seleccionado. Un comando genérico no puede describir de forma segura todos los servicios de Windows, grupos de aplicaciones, tareas y aplicaciones. Conserve ese procedimiento específico del producto y sus pasos inversos en el registro del cambio aprobado.

Verifique la identidad configurada y, después, inicie o reinicie la carga de trabajo según lo acordado. Pida al responsable que ejecute operaciones representativas de los clientes y lecturas o escrituras en los recursos posteriores. Compare los resultados con la referencia e inspeccione los errores reales de la aplicación. Cuando la autenticación sea relevante, confirme el comportamiento esperado de la autenticación de clientes y recursos mediante los diagnósticos establecidos por la organización. Un único resultado de inicio no sustituye estas pruebas.

Si no se cumplen los criterios de aceptación, siga esos pasos y documente tanto el fallo que los desencadenó como el comportamiento del servicio restablecido. Conserve las pruebas para investigar. Dejar un objeto de cuenta en AD mientras se recupera la carga de trabajo no significa que el piloto haya tenido éxito.

4. Cerrar el piloto y seguir el resto del entorno

Después de la aceptación, registre el servicio, los hosts, la nueva identidad, las pruebas, las marcas de tiempo, quien aprueba y las limitaciones pendientes. Revise todos los consumidores restantes de la identidad anterior antes de retirarla. Elimine esa identidad solo tras la validación y el periodo de recuperación aprobado; que su nombre desaparezca de una configuración de servicio no demuestra que ninguna otra carga dependa de ella.

La remediación de cuentas de servicio que recomienda migrar a gMSA establece una razón para migrar. Este piloto aporta las pruebas operativas de esa recomendación. Siga por separado los candidatos posteriores: la aceptación de un primer servicio supone un avance, mientras que la adopción en todo el entorno sigue requiriendo un inventario y una decisión servicio por servicio.

Cómo detecta EtcSec esta situación

El control pertinente de EtcSec es GMSA_NOT_IN_USE. En la implementación revisada de etc-collector, cuenta los usuarios reconocidos como gMSA y los usuarios habilitados con al menos un SPN. Devuelve un hallazgo de gravedad Low con Count = 1 solo cuando el número de gMSA reconocidos es cero y el de usuarios habilitados con SPN es positivo. En caso contrario, devuelve Count = 0.

El reconocimiento es más restringido que un inventario por clase estructural: User.IsGMSA se establece cuando el atributo binario msDS-GroupMSAMembership no está vacío. El filtro de usuarios LDAP incluye msDS-GroupManagedServiceAccount, pero el analizador no utiliza esa clase para establecer este indicador del usuario. Por tanto, un atributo de pertenencia ausente o ilegible puede afectar al reconocimiento; un límite LDAP incompleto o el límite MaxUsers pueden afectar al inventario. Un error de GetUsers detiene el motor en lugar de producir un inventario vacío correcto.

Cada gMSA reconocido contribuye al recuento, incluidos los objetos deshabilitados. Basta un objeto reconocido para que esta señal sea cero, aunque no se haya migrado ningún servicio. También es cero cuando no se han recopilado usuarios habilitados con SPN. Este control no inspecciona las claves KDS, la preparación de la replicación, la instalación en los hosts, la configuración de los servicios, la compatibilidad de las aplicaciones ni los inicios de sesión reales de los servicios. No mide la proporción de servicios que utilizan gMSA ni el éxito del piloto.