Comptes de service administrés de groupe (gMSA) : en finir avec les mots de passe statiques

Pourquoi les comptes de service classiques posent problème

Un compte de service traditionnel est un compte utilisateur ordinaire, doté d'un mot de passe choisi par un humain, souvent configuré pour ne jamais expirer. Ce mot de passe est saisi dans la console des services, dans des tâches planifiées, parfois dans des scripts ou des fichiers de configuration. Il est rarement changé, car personne ne sait précisément où il est utilisé et chacun craint de casser une application.

Ces comptes cumulent les faiblesses : ils portent souvent un nom de principal de service (SPN), ce qui les expose au Kerberoasting ; ils disposent fréquemment de droits excessifs, parfois d'une appartenance aux Admins du domaine « pour que ça marche » ; et leur mot de passe, faible ou ancien, peut être cassé hors ligne ou retrouvé dans un partage.

Le principe d'un gMSA

Un compte de service administré de groupe est un objet de type msDS-GroupManagedServiceAccount. Son mot de passe est calculé par les contrôleurs de domaine à partir de la clé racine du service de distribution de clés (KDS). Il est long, aléatoire, et renouvelé automatiquement selon un intervalle défini à la création (30 jours par défaut, et non modifiable ensuite). Aucun humain n'a besoin de le connaître : les serveurs autorisés le récupèrent auprès d'un contrôleur de domaine et le service Windows l'utilise directement.

Un gMSA peut être utilisé par plusieurs serveurs à la fois, ce qui le rend adapté aux fermes web, aux clusters et aux applications réparties. Il fonctionne pour les services Windows, les pools d'applications IIS, les tâches planifiées et de nombreux produits Microsoft ; pour les logiciels tiers, vérifiez la compatibilité auprès de l'éditeur.

La clé racine KDS, un secret de niveau 0

La création de la clé racine KDS est un prérequis unique par forêt. Elle est stockée dans la partition de configuration et doit avoir été répliquée sur les contrôleurs de domaine avant de pouvoir servir ; Microsoft documente un délai d'effet à respecter en production.

Point essentiel : quiconque peut lire les attributs de cette clé et quelques informations publiques sur un gMSA est en mesure de calculer ses mots de passe passés et futurs, hors ligne. Ce scénario, parfois appelé « Golden gMSA », signifie que la clé KDS doit être protégée au même niveau que la base de l'annuaire. Par défaut, seuls des groupes très privilégiés y ont accès ; un audit vérifie qu'aucune délégation n'a élargi ce périmètre.

Contrôler PrincipalsAllowedToRetrieveManagedPassword

La liste des comptes autorisés à récupérer le mot de passe est stockée dans l'attribut msDS-GroupMSAMembership, exposé en PowerShell sous le nom PrincipalsAllowedToRetrieveManagedPassword. Tout compte présent dans cette liste peut lire le secret et donc agir avec l'identité du gMSA.

• Autorisez un groupe de sécurité ne contenant que les comptes d'ordinateur des serveurs concernés, jamais des utilisateurs ou des groupes larges.
• Traitez l'appartenance à ce groupe comme sensible : ajouter un ordinateur revient à lui confier l'identité du service.
• Surveillez aussi qui peut modifier l'attribut lui-même : un droit d'écriture sur l'objet gMSA permet de s'ajouter à la liste.

Si le gMSA dispose de droits élevés, les serveurs qui l'utilisent héritent de fait de ce niveau. Un gMSA d'administration ne doit donc être utilisé que depuis des serveurs du même niveau.

Les comptes de service administrés délégués (dMSA)

Windows Server 2025 introduit les dMSA, conçus pour faciliter la migration d'un compte de service existant vers un compte administré en reprenant ses droits. Des travaux de recherche publiés en 2025 ont montré qu'un utilisateur autorisé à créer des objets dans une unité d'organisation pouvait, dans certaines conditions, abuser de ce mécanisme pour hériter des privilèges d'autres comptes. Microsoft a publié des correctifs ; avant tout déploiement, appliquez les dernières mises à jour, consultez la documentation Microsoft à jour et contrôlez qui peut créer des objets dans vos OU, même sans utiliser les dMSA.

Ce qu'un audit vérifie

• la présence de la clé racine KDS et la liste des comptes pouvant la lire ;
• les comptes de service classiques restants, leur SPN et l'ancienneté de leur mot de passe ;
• pour chaque gMSA, le contenu de PrincipalsAllowedToRetrieveManagedPassword et les droits d'écriture sur l'objet ;
• les privilèges accordés aux gMSA et le niveau des serveurs qui les utilisent ;
• les droits de création d'objets dans les OU, notamment au regard des dMSA.