Objectif
Créer un group Managed Service Account (gMSA), limiter les serveurs autorisés à récupérer son mot de passe et valider le compte sur un serveur pilote avant de basculer un service Windows en production.
Prérequis
- Active Directory opérationnel et module ActiveDirectory PowerShell disponible.
- Droits de création d’un gMSA ou délégation correspondante.
- Groupe de sécurité contenant les serveurs hôtes autorisés, par exemple GG-gMSA-App-HOSTS.
- Inventaire du service cible, de son compte actuel, de ses SPN et de ses dépendances réseau.
Procédure pas à pas
Vérifier la clé racine KDS
La distribution automatique du mot de passe gMSA dépend du Key Distribution Service. Vérifiez d’abord si une clé racine existe déjà. Dans une forêt existante qui utilise déjà des gMSA, n’en ajoutez pas une nouvelle sans raison documentée.
Get-KdsRootKey- Au moins une clé racine valide est visible si des gMSA sont déjà en service.
Créer la clé KDS uniquement si nécessaire
S’il n’existe aucune clé KDS, créez-la une seule fois pour la forêt. En production multi-DC, prévoyez le délai de réplication nécessaire avant d’utiliser le premier gMSA. Évitez les astuces consistant à antidater la clé dans un environnement réel.
Add-KdsRootKey- La clé est créée et devient utilisable après convergence de la réplication.
Note : Dans un laboratoire à DC unique, les méthodes accélérant l’effet peuvent avoir un intérêt de test ; ne transposez pas ce raccourci sans comprendre son impact en production.
Créer le groupe d’hôtes autorisés
Utilisez un groupe de sécurité dédié par gMSA ou par service homogène. Ajoutez uniquement les comptes ordinateurs des serveurs qui doivent récupérer le mot de passe géré.
New-ADGroup -Name "GG-gMSA-App-HOSTS" -GroupScope Global -GroupCategory Security -Path "OU=Groupes,DC=contoso,DC=local"Add-ADGroupMember -Identity "GG-gMSA-App-HOSTS" -Members "SRV-APP01$","SRV-APP02$"- Le groupe contient exclusivement les hôtes attendus.
Créer le gMSA
Créez le compte avec un nom unique dans la forêt et autorisez le groupe d’hôtes à récupérer le mot de passe géré. Adaptez le DNSHostName au nom de service prévu. Si un SPN spécifique est nécessaire, documentez-le et évitez les doublons.
New-ADServiceAccount -Name "gmsa-App" -DNSHostName "gmsa-app.contoso.local" -PrincipalsAllowedToRetrieveManagedPassword "GG-gMSA-App-HOSTS"Get-ADServiceAccount -Identity "gmsa-App" -Properties PrincipalsAllowedToRetrieveManagedPassword,ServicePrincipalNames | Format-List- L’objet gMSA existe et le groupe d’hôtes autorisés est correct.
Installer et tester le gMSA sur un serveur pilote
Sur le serveur qui exécutera le service, installez la fonctionnalité RSAT Active Directory PowerShell si nécessaire, puis installez/testez le compte. Le test doit retourner True avant toute bascule du service.
Install-ADServiceAccount -Identity "gmsa-App"Test-ADServiceAccount -Identity "gmsa-App"- Test-ADServiceAccount retourne True.
Préparer les droits applicatifs
Accordez au gMSA les mêmes droits strictement nécessaires que l’ancien compte : ACL de dossiers, partages, base de données, certificats privés, droits locaux et autorisations applicatives. Ne copiez pas automatiquement les groupes d’un ancien compte de service sur-privilégié.
- Le gMSA peut atteindre chaque dépendance requise sans appartenir à un groupe administratif générique.
Basculer le service en fenêtre pilote
Configurez le service ou l’application pour utiliser CONTOSOgmsa-App$. Pour un gMSA, le mot de passe est géré par Windows et ne doit pas être stocké dans un coffre applicatif comme un secret statique. Redémarrez le service et observez immédiatement les journaux système, applicatifs et de sécurité.
Get-Service -Name "NomDuService"Get-WinEvent -FilterHashtable @{LogName="System";StartTime=(Get-Date).AddMinutes(-15)} | Select-Object TimeCreated,Id,ProviderName,Message- Le service démarre sous le gMSA et ses accès réseau fonctionnent.
Valider puis étendre
Testez les fonctions métier, Kerberos si applicable, tâches planifiées et accès distants. Si plusieurs hôtes utilisent le même gMSA, ajoutez-les progressivement au groupe autorisé et validez Test-ADServiceAccount sur chacun.
Test-ADServiceAccount -Identity "gmsa-App"Get-KdsRootKey- Tous les hôtes cibles testent le gMSA avec succès et aucune authentification n’échoue après la bascule.
Validation
La procédure est validée lorsque :
- Test-ADServiceAccount retourne True sur chaque serveur autorisé.
- Le service démarre et réalise ses opérations réseau avec le gMSA.
- Le groupe PrincipalsAllowedToRetrieveManagedPassword ne contient aucun serveur inutile.
- Les SPN sont uniques et les journaux ne montrent pas d’échecs Kerberos ou de connexion liés au nouveau compte.
Retour arrière
- Reconfigurer le service avec l’ancien compte documenté et redémarrer le service.
- Retirer temporairement le serveur du groupe d’hôtes autorisés si le pilote est abandonné.
- Ne supprimez le gMSA qu’après avoir vérifié qu’aucun autre service ou serveur ne l’utilise.
Dépannage / erreurs fréquentes
- Test-ADServiceAccount = False : contrôler l’appartenance du compte ordinateur au groupe autorisé, la réplication AD et redémarrer/actualiser le jeton du serveur après changement de groupe.
- Échec d’authentification après des changements de clés KDS : inventorier Get-KdsRootKey et vérifier le niveau de correctif des DC avant toute action destructive.
- Kerberos ne fonctionne pas : rechercher les SPN dupliqués et vérifier que le nom réellement utilisé par les clients correspond au SPN du service.
- Le service démarre mais n’accède plus aux ressources : comparer les ACL et droits applicatifs de l’ancien compte sans réintroduire des privilèges excessifs.