Comptes de service : migrer vers les gMSA et les dMSA, sans ouvrir de nouvelles failles
Les comptes de service classiques sont l'un des constats les plus fréquents de nos audits Active Directory : mots de passe jamais changés, souvent faibles, parfois connus de plusieurs prestataires, et comptes membres de groupes privilégiés « pour que ça marche ». Les comptes de service gérés règlent une grande partie du problème, à condition de comprendre qui peut lire leur mot de passe.
Pourquoi les comptes de service classiques posent problème
Un compte de service ordinaire est un compte utilisateur dont le mot de passe est saisi dans la configuration d'un service, d'une tâche planifiée ou d'une application. Le changer suppose de mettre à jour chaque serveur, donc on ne le change pas. S'il porte un nom de principal de service, n'importe quel utilisateur du domaine peut demander un ticket chiffré avec ce mot de passe et tenter de le casser hors ligne : c'est le Kerberoasting. Un mot de passe ancien et faible sur un compte privilégié est alors une porte ouverte.
Les gMSA : principe et bénéfices
Un compte de service géré de groupe (gMSA) est un compte dont le mot de passe, long et aléatoire, est généré et renouvelé automatiquement par les contrôleurs de domaine, par défaut tous les 30 jours. Personne n'a besoin de le connaître. Les serveurs autorisés le récupèrent eux-mêmes. Les bénéfices sont directs :
- le Kerberoasting devient inopérant en pratique, le mot de passe étant impossible à casser ;
- la rotation est automatique, sans intervention sur les serveurs ;
- le compte ne peut pas servir à une ouverture de session interactive.
Prérequis : une clé racine KDS dans la forêt, créée une fois, puis la création du compte en précisant les ordinateurs ou le groupe autorisés à récupérer le mot de passe.
Qui peut récupérer le mot de passe
C'est le point que les audits examinent en priorité. L'attribut PrincipalsAllowedToRetrieveManagedPassword désigne les comptes autorisés à lire le mot de passe. Toute personne qui contrôle l'un de ces comptes (un serveur compromis, un membre du groupe autorisé, ou quelqu'un capable de modifier ce groupe) obtient le mot de passe du gMSA, et donc ses privilèges. Un gMSA membre d'un groupe privilégié, dont le mot de passe est lisible par un groupe de serveurs mal protégés, recrée exactement le problème qu'on voulait résoudre. Les principaux autorisés doivent appartenir au même niveau que le compte.
Limites et étapes de migration
Toutes les applications ne prennent pas en charge les gMSA : les services Windows, les tâches planifiées, les pools d'applications IIS et SQL Server le permettent, mais une application qui exige un mot de passe saisi dans son propre fichier de configuration ne le pourra pas. Une migration se déroule ainsi :
- inventorier les comptes de service, les serveurs qui les utilisent et leurs privilèges réels ;
- vérifier la compatibilité de chaque application ;
- créer le gMSA avec les seuls droits nécessaires, en profitant de l'occasion pour sortir le compte des groupes privilégiés ;
- installer et tester le compte sur les serveurs autorisés, puis basculer le service ;
- désactiver l'ancien compte, observer, puis le supprimer.
Les dMSA de Windows Server 2025, et l'alerte « BadSuccessor »
Windows Server 2025 introduit les comptes de service gérés délégués (dMSA). Ils permettent de migrer un compte de service existant vers un compte géré en le liant à l'ancien compte, dont les droits sont repris, puis en désactivant l'usage de l'ancien mot de passe. Leur authentification est par ailleurs liée à l'identité des machines autorisées.
En 2025, des chercheurs d'Akamai ont publié la technique « BadSuccessor » : un utilisateur capable de créer un dMSA dans une OU quelconque pouvait le déclarer successeur de n'importe quel compte, y compris un administrateur du domaine, et obtenir ses privilèges. Il suffisait d'un contrôleur de domaine sous Windows Server 2025, même si l'organisation n'utilisait pas les dMSA. Microsoft a publié un correctif ; vérifiez que vos contrôleurs de domaine sont à jour et consultez l'état actuel des recommandations.
Restreindre la création de dMSA. Indépendamment du correctif, identifiez qui peut créer des objets enfants, en général ou de type dMSA, dans vos OU. Ces droits sont souvent accordés largement par d'anciennes délégations. Ils doivent être réservés aux administrateurs du Tier 0, et toute création de dMSA doit être surveillée.
Ce qu'un audit vérifie
- L'inventaire des comptes de service classiques, l'âge de leur mot de passe et leur appartenance à des groupes privilégiés.
- Les comptes avec un nom de principal de service exposés au Kerberoasting.
- Pour chaque gMSA, les principaux autorisés à récupérer le mot de passe et leur niveau de protection.
- Les droits de création d'objets enfants sur les OU, notamment pour les dMSA, et le niveau de correctifs des contrôleurs de domaine sous Windows Server 2025.
- La désactivation effective des anciens comptes après migration.