Dans de nombreux environnements Windows Server, les comptes de service sont encore gérés de manière traditionnelle : un compte utilisateur dans Active Directory avec un mot de passe fixe, rarement changé, et souvent enregistré en clair dans un script ou un fichier de configuration.
Ce modèle, hérité des débuts de Windows Server, est une source de vulnérabilités importantes.
Il complique aussi la gestion dans les environnements distribués ou en cluster, où un même compte doit fonctionner sur plusieurs serveurs.
Les Group Managed Service Accounts, ou gMSA, ont été introduits avec Windows Server 2012 pour répondre à ces problématiques.
Ils permettent de déléguer entièrement la gestion du mot de passe à Active Directory, qui le génère, le stocke et le renouvelle automatiquement, tout en s’assurant qu’il ne puisse être utilisé que par les serveurs autorisés.
Cela signifie qu’aucun administrateur n’a besoin de connaître ou de manipuler ce mot de passe ; le service Windows ou l’application s’authentifie directement auprès d’AD de manière sécurisée.
Préparer l’infrastructure
L’utilisation d’un gMSA suppose que le domaine Active Directory fonctionne au niveau fonctionnel Windows Server 2012 ou supérieur.
Les serveurs qui utiliseront le gMSA doivent être membres du domaine, et il faut disposer du module PowerShell Active Directory.
Avant de créer un premier gMSA, il est nécessaire de générer une clé racine KDS, qui servira à chiffrer les mots de passe.
Cette opération est à réaliser une seule fois dans le domaine :
Add-KdsRootKey -EffectiveImmediately
En environnement de test, il est possible d’utiliser l’option -EffectiveTime ((Get-Date).AddHours(-10)) pour rendre la clé immédiatement utilisable sans attendre la réplication.
Créer un gMSA
Imaginons un scénario concret : un cluster SQL Server Always On avec deux nœuds.
Plutôt que de créer un compte de service classique, on définit un gMSA utilisable uniquement par ces deux serveurs.
La commande PowerShell suivante crée ce compte, en associant un groupe Active Directory contenant les deux nœuds autorisés :
New-ADServiceAccount -Name gMSA-SQL01 -DNSHostName sql01.lab.local -PrincipalsAllowedToRetrieveManagedPassword "SQLSERVERS"
Une fois le gMSA créé, il faut l’installer sur chaque serveur qui l’utilisera.
Cette étape se fait avec :
Install-ADServiceAccount gMSA-SQL01
Test-ADServiceAccount gMSA-SQL01
La commande Test-ADServiceAccount permet de confirmer que le serveur peut récupérer et utiliser le mot de passe auprès d’Active Directory.
Utiliser le gMSA dans un service
Lors de la configuration du service Windows, on spécifie le compte de service sous la forme DOMAIN\gMSA-SQL01$ et on laisse le champ mot de passe vide.
C’est Active Directory qui fournit automatiquement le secret au service au moment de son démarrage.
Aucune rotation manuelle du mot de passe n’est nécessaire ; le renouvellement est automatique et totalement transparent.
Contrôle et maintenance
Pour vérifier quels serveurs sont autorisés à utiliser un gMSA, la commande suivante interroge Active Directory :
Get-ADServiceAccount gMSA-SQL01 -Properties PrincipalsAllowedToRetrieveManagedPassword
En pratique, les gMSA simplifient énormément l’administration.
Ils éliminent le risque d’oubli de changement de mot de passe, protègent contre les fuites dans les scripts, et permettent un déploiement homogène dans les environnements à grande échelle.
Dans des contextes comme SQL Server, IIS en ferme web, Hyper-V en cluster ou encore des scripts PowerShell automatisés, le gain est immédiat : moins de gestion manuelle, plus de sécurité, et une conformité renforcée.
Conclusion
Les Group Managed Service Accounts restent encore largement sous-utilisés malgré leur efficacité.
Ils offrent un moyen fiable et sécurisé d’exécuter des services et applications critiques sans les contraintes et les risques liés aux comptes de service traditionnels.
Dans une stratégie globale de sécurisation et d’automatisation, leur adoption devrait être envisagée dès la conception d’une infrastructure Windows Server moderne.
