Pilote de premier déploiement gMSA : valider KDS avant la bascule

Un objet gMSA n'est pas un service migré

Un pilote de premier déploiement gMSA doit se conclure par un service fonctionnel sous sa nouvelle identité, une décision de retour arrière approuvée et des preuves issues des hôtes qui l'exécutent réellement. Créer un compte de service administré de groupe dans Active Directory établit l'existence d'un compte. Cela ne démontre pas qu'une charge de travail de production utilise ce compte, que tous les hôtes nécessaires peuvent récupérer ses informations d'identification, ni que la charge de travail conserve les accès appropriés après la bascule.

Cette distinction est importante lorsqu'un audit indique que les gMSA ne sont pas utilisés. Considérez ce résultat comme une invitation à examiner l'inventaire de l'annuaire et le parc de services. Un nouvel objet peut faire disparaître un signal d'inventaire alors que tous les services continuent de fonctionner sous leur ancienne identité. À l'inverse, une collecte incomplète peut manquer un objet existant. Aucun de ces résultats ne répond à la question opérationnelle : quel service a effectivement migré ?

Conservez trois ensembles de preuves distincts : les objets de l'annuaire, la préparation des hôtes et l'adoption par les services. Le premier identifie les comptes ; le deuxième indique si un hôte précis peut utiliser le compte sélectionné ; le troisième documente une charge de travail testée qui l'utilise. Cet article propose un contrôle préalable à la première adoption, avec un seul service et un plan de reprise explicite. Il ne suppose pas que tous les utilisateurs portant des SPN représentent des services compatibles et actifs.

Fonctionnement d'un pilote de premier déploiement gMSA

Commencez par identifier un responsable du service et dresser l'inventaire de la charge de travail, plutôt que par une demande de création de compte. Consignez le nom du service, son identité actuelle, la liste des hôtes, la version de l'application, la configuration de démarrage, les clients et les ressources utilisées en aval. Demandez au responsable quelles fonctions doivent rester disponibles et quelles preuves démontreraient la réussite du changement. Un processus qui démarre mais ne peut pas écrire sa sortie planifiée a échoué au pilote.

Microsoft documente la prise en charge des gMSA pour les services configurés via Service Control Manager, les pools d'applications IIS, le Planificateur de tâches et les produits prenant en charge les API des comptes administrés. Le service Cluster lui-même ne prend pas en charge les gMSA ; des services compatibles exécutés au-dessus peuvent les utiliser. Confirmez le produit exact et la topologie de déploiement avec son responsable avant de sélectionner le pilote. Microsoft Learn — Gérer les comptes de service administrés de groupe.

Structurez le dossier de changement autour de ces contrôles indépendants :

Il s'agit de contrôles proposés pour le pilote, pas de résultats déjà mesurés dans votre environnement. Attribuez un responsable à chaque contrôle. Le responsable AD gère la dépendance à l'échelle de la forêt ; le responsable du service accepte le comportement de la charge de travail ; l'approbateur du changement autorise la bascule et la reprise. Consignez qui peut interrompre le pilote lorsque ces appréciations divergent.

Détection : examiner les objets, la préparation KDS et chaque hôte

Rapprocher un inventaire d'annuaire fondé sur la classe

Utilisez une recherche indépendante par classe pour vérifier ce que signifie l'inventaire du collecteur. L'exemple suivant est en lecture seule et combine les paramètres documentés de Get-ADServiceAccount. Remplacez le DC et le DN de domaine illustratifs par le périmètre approuvé ; répétez l'opération pour chaque domaine inclus dans le pilote. Il n'a pas été exécuté dans votre annuaire.

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

-LDAPFilter sélectionne la classe structurelle indépendamment de l'heuristique du collecteur fondée sur l'attribut d'appartenance. -SearchBase, -SearchScope et -Server rendent explicite la limite souhaitée ; -ResultSetSize $null évite d'imposer une limite au nombre total de résultats. Dans un usage plus général, la cmdlet renvoie aussi bien des comptes administrés autonomes que des comptes administrés de groupe : conservez donc la restriction de classe pour cet inventaire. Microsoft Learn — Get-ADServiceAccount.

Consignez les identités renvoyées et leur état d'activation, ainsi que le périmètre et le résultat de la requête. Si cette recherche trouve un gMSA que le collecteur n'a pas reconnu, examinez les permissions, les attributs demandés, les limites de recherche et les plafonds de résultats. Ne résolvez pas cet écart en créant un autre compte. Si la recherche échoue, conservez l'erreur comme un échec de collecte ; une requête réussie sans résultat et une requête en échec constituent des preuves différentes.

Associez ensuite chaque objet pertinent aux configurations réelles des services. Déterminez s'il est inutilisé, en préparation, retiré ou utilisé par une charge de travail testée. Conservez comme non associé un objet sans correspondance. Le seul nom d'un compte d'annuaire ne permet pas d'identifier le responsable d'un service ni de prouver qu'un hôte l'utilise.

Examiner les clés KDS existantes avant d'en demander une nouvelle

Depuis un contexte administratif autorisé disposant du module KDS, utilisez la commande de lecture documentée :

Get-KdsRootKey

Elle récupère la liste des clés racines existantes, y compris leurs valeurs. Examinez-la dans l'environnement administratif et ne conservez dans le dossier de changement que les identifiants nécessaires et la décision sur l'état de préparation ; ne collez pas de clés brutes dans un ticket généraliste. Cette commande est une étape d'inventaire, pas un test de réplication. Microsoft Learn — Get-KdsRootKey.

Microsoft décrit une attente pouvant aller jusqu'à dix heures après la création de la clé racine pour permettre à la réplication des DC de converger avant l'utilisation du gMSA. Des plages de réplication limitées ou des défauts de réplication peuvent malgré tout provoquer des échecs de récupération. Demandez au responsable AD de vérifier la disponibilité de la clé et la santé de la réplication pour les DC desservant les hôtes du pilote ; le seul temps écoulé ne constitue pas cette preuve. Microsoft Learn — Créer une clé racine KDS.

Si une clé appropriée existe déjà, la procédure de gestion indique de passer l'étape de création. Si aucune clé n'existe, faites du processus documenté de création de clé et de réplication du responsable AD un prérequis, avec son calendrier et ses autorisations propres. N'intégrez pas une dépendance de forêt à un changement de compte de service non examiné.

Tester la préparation sur les hôtes réellement autorisés

Examinez les principaux approuvés pour la récupération du mot de passe et confirmez qu'ils correspondent à la population d'hôtes prévue. Les consignes de gestion Microsoft exigent également des SPN appropriés, le DNS, l'accès réseau, la synchronisation des horloges et des types de chiffrement Kerberos pris en charge. Traitez ces points comme des prérequis à examiner, sans supposer qu'une recherche d'annuaire réussie les vérifie.

Exécutez localement le test de compte documenté sur chaque hôte prévu, en remplaçant le nom de compte illustratif :

Test-ADServiceAccount -Identity 'svc-pilot'

Microsoft définit la réussite du test comme la capacité à s'authentifier et à accéder au domaine avec les informations d'identification actuelles du compte. Consignez l'hôte, l'heure, le compte et le résultat réel. Ce test n'exerce pas les requêtes de base de données de votre application, ses écritures de fichiers, l'authentification des clients ni son comportement au redémarrage. Microsoft Learn — Test-ADServiceAccount.

Un échec suspend la bascule. Examinez avec les responsables concernés l'autorisation prévue pour l'hôte, l'accès à l'annuaire et la dépendance KDS/réplication. Élargir l'accès de récupération à un groupe étendu n'est pas un raccourci acceptable. L'examen des permissions de récupération du mot de passe gMSA explique pourquoi la population autorisée à le lire constitue une frontière de sécurité à examiner séparément.

Remédiation : piloter un service avec un retour arrière utilisable (Remediation)

1. Convenir des tests d'acceptation et du chemin de reprise

Choisissez une charge de travail compatible dont le responsable peut observer le fonctionnement normal comme les défaillances. Avant de changer son identité, conservez sa configuration approuvée, ses permissions existantes, son comportement au démarrage et les résultats de référence de la charge de travail. Consignez la fenêtre de maintenance, la personne qui approuve le changement, celle qui exécute la reprise et les conditions qui la déclenchent.

Définissez des conditions propres au service : un client requis ne peut pas s'authentifier, une opération planifiée échoue, une ressource attendue est inaccessible ou un redémarrage ne rétablit pas le service. Définissez la période d'observation avec le responsable, sans inventer de durée universelle. Pour une charge de travail qui ne s'exécute qu'à une heure planifiée, la décision d'acceptation doit couvrir cette exécution.

2. Préparer l'hôte autorisé et les permissions du compte

Examinez les droits de service locaux du candidat et ses permissions en aval avant le changement. Demandez les permissions nécessaires aux opérations attendues de la charge de travail ; conservez les dépendances de l'ancienne identité pendant la fenêtre de reprise. Distinguez l'autorisation de récupérer le mot de passe de celle d'accéder aux données de l'application. Réussir le test du compte ne démontre ni l'exhaustivité des permissions de l'application ni la justesse de sa configuration.

Une fois les contrôles d'annuaire et d'autorisation validés, la procédure Microsoft installe le compte sur chaque hôte exécutant le service. Exécutez la commande localement dans une session PowerShell élevée, dans le cadre du changement approuvé :

Install-ADServiceAccount -Identity 'svc-pilot'

La cmdlet prépare le compte administré existant sur l'ordinateur local. Elle ne modifie pas l'identité configurée de l'application. Sa référence exige que l'autorisation de récupération soit définie pour un gMSA. Microsoft Learn — Install-ADServiceAccount.

Répétez le test de préparation du compte sur cet hôte et conservez le résultat. Si l'installation ou le test échoue, arrêtez-vous à ce contrôle et examinez la cause. Ne consignez pas l'achèvement d'une commande administrative comme une migration de service réussie.

3. Basculer via la configuration prise en charge par le service

Utilisez la procédure de configuration d'identité prise en charge par le produit pour migrer le service sélectionné. Une commande générique ne peut pas décrire de manière sûre tous les services Windows, pools d'applications, tâches et applications. Conservez cette procédure propre au produit et les étapes inverses dans le dossier de changement approuvé.

Vérifiez l'identité configurée, puis démarrez ou redémarrez la charge de travail comme convenu. Faites exécuter par le responsable des opérations clientes représentatives et des lectures ou écritures en aval. Comparez les résultats à la référence et examinez les erreurs réelles de l'application. Lorsque l'authentification importe, confirmez le comportement attendu de l'authentification des clients et des ressources avec les diagnostics établis par l'organisation. Un seul résultat de démarrage ne remplace pas ces tests.

Si les critères d'acceptation ne sont pas satisfaits, suivez ces étapes et documentez à la fois l'échec déclencheur et le comportement du service rétabli. Conservez les preuves pour l'investigation. Laisser un objet de compte dans AD pendant la reprise de la charge de travail ne signifie pas que le pilote a réussi.

4. Clore le pilote et suivre le reste du parc

Après acceptation, consignez le service, les hôtes, la nouvelle identité, les tests, les horodatages, l'approbateur et les limites non résolues. Examinez tous les consommateurs restants de l'ancienne identité avant de la retirer. Ne supprimez cette identité qu'après validation et expiration de la période de reprise approuvée ; sa disparition d'une configuration de service ne prouve pas qu'aucune autre charge de travail n'en dépend.

La remédiation des comptes de service qui recommande la migration vers gMSA établit une raison de migrer. Ce pilote apporte les preuves opérationnelles pour cette recommandation. Suivez séparément les candidats suivants : l'acceptation d'un premier service constitue un progrès, tandis que l'adoption à l'échelle du parc exige encore un inventaire et une décision service par service.

Comment EtcSec détecte cette situation

Le contrôle EtcSec pertinent est GMSA_NOT_IN_USE. Dans l'implémentation etc-collector examinée, il compte les utilisateurs reconnus comme gMSA et les utilisateurs activés possédant au moins un SPN. Il renvoie un résultat de sévérité Low avec Count = 1 uniquement lorsque le nombre de gMSA reconnus est nul et que le nombre d'utilisateurs activés portant des SPN est positif. Sinon, il renvoie Count = 0.

La reconnaissance est plus étroite qu'un inventaire par classe structurelle : User.IsGMSA est défini lorsque l'attribut binaire msDS-GroupMSAMembership n'est pas vide. Le filtre LDAP des utilisateurs inclut msDS-GroupManagedServiceAccount, mais le parseur n'utilise pas cette classe pour définir cet indicateur utilisateur. Un attribut d'appartenance absent ou illisible peut donc affecter la reconnaissance ; une limite LDAP incomplète ou le plafond MaxUsers peuvent affecter l'inventaire. Une erreur GetUsers arrête le moteur au lieu de produire un inventaire vide réussi.

Tous les gMSA reconnus contribuent au compteur, y compris les objets désactivés. Un seul objet reconnu suffit à rendre ce signal nul, même si aucun service n'a migré. Le résultat est également nul lorsqu'aucun utilisateur activé portant des SPN n'a été collecté. Ce contrôle n'examine pas les clés KDS, la préparation de la réplication, l'installation sur les hôtes, la configuration des services, la compatibilité des applications ni les connexions réelles des services. Il ne mesure ni la proportion de services utilisant des gMSA ni la réussite du pilote.