Migrer les comptes de service vers gMSA et dMSA

Un compte de service statique est un identifiant de longue durée auquel est attaché un SPN, avec un mot de passe que personne n'ose changer et des droits d'ouverture de session sur des serveurs de plusieurs niveaux. C'est la cible type du Kerberoasting et, lorsque son mot de passe finit dans un partage de scripts ou un fichier de configuration, il devient un chemin de mouvement latéral qui survit à tous les autres projets de durcissement. Le guide de référence sur le durcissement des comptes de service explique pourquoi les comptes gérés règlent ce problème ; ce guide en est la procédure de migration : comment inventorier l'existant, mettre en place correctement la clé racine KDS, restreindre étroitement la récupération des mots de passe, migrer les charges de travail courantes et utiliser le dMSA de Windows Server 2025 pour les comptes difficiles à rediriger.

La méthode suit celle du reste de ce site : mesurer le parc, auditer les dépendances de chaque compte, appliquer la nouvelle identité application par application, puis vérifier que plus rien n'utilise l'ancienne avant de la désactiver.

Mesurer : inventorier chaque identité de service

Commencez par les objets utilisateurs qui se comportent comme des services : SPN, mots de passe qui n'expirent jamais, mots de passe anciens et activité d'ouverture de session depuis des serveurs plutôt que depuis des postes de travail.

Get-ADUser -Filter 'ServicePrincipalName -like "*" -or PasswordNeverExpires -eq $true' `
    -Properties ServicePrincipalName, PasswordNeverExpires, PasswordLastSet, LastLogonTimestamp, Description, adminCount |
  Select-Object SamAccountName, adminCount, PasswordNeverExpires, PasswordLastSet,
    @{n='LastLogon';e={[datetime]::FromFileTime($_.LastLogonTimestamp)}},
    @{n='SPNs';e={$_.ServicePrincipalName -join ';'}}, Description |
  Export-Csv .\service-account-inventory.csv -NoTypeInformation

Déterminez ensuite où chaque compte s'exécute réellement. Sur les serveurs membres, le gestionnaire de contrôle des services et le Planificateur de tâches sont les consommateurs habituels :

# À exécuter sur une liste de serveurs depuis un hôte d'administration du niveau approprié
$servers = Get-Content .\servers.txt
Invoke-Command -ComputerName $servers -ScriptBlock {
    Get-CimInstance Win32_Service | Where-Object StartName -match '\\' |
        Select-Object @{n='Host';e={$env:COMPUTERNAME}}, Name, StartName
    Get-ScheduledTask | Where-Object { $_.Principal.UserId -match '\\' } |
        Select-Object @{n='Host';e={$env:COMPUTERNAME}}, TaskName, @{n='StartName';e={$_.Principal.UserId}}
}

Cela ne couvre pas les pools d'applications IIS, les applications COM+, les proxys de l'Agent SQL ni les identifiants stockés dans les applications. Complétez avec les événements d'ouverture de session : l'événement 4624 de type 5 (service) et de type 4 (batch) sur les serveurs membres, et l'événement 4769 sur les contrôleurs de domaine, qui montre quels SPN sont demandés et par qui. La référence des ID d'événements liste les champs utiles à extraire.

Auditer : choisir la cible compte par compte

Classez chaque compte dans l'une de quatre catégories :

1. Mort : aucune ouverture de session depuis plus de 90 jours et aucun consommateur identifié. Désactivez-le, attendez un cycle, supprimez-le.
2. Compatible gMSA : services Windows, tâches planifiées, pools d'applications IIS, moteur et Agent SQL Server, la plupart des produits serveur Microsoft. Migrez vers un gMSA.
3. Difficile à rediriger : le nom du compte est intégré dans de nombreux clients, dans une appliance d'éditeur ou dans des ACL difficiles à transposer. Candidat au dMSA si vous disposez de DC Windows Server 2025.
4. Incompatible : l'application a besoin d'un mot de passe saisissable, ou s'exécute sur une plateforme non Windows. Conservez un compte classique avec un mot de passe aléatoire de plus de 30 caractères, AES uniquement, et une stratégie de mot de passe affinée dédiée.

Notez aussi si le compte a besoin de délégation. Un gMSA prend en charge la délégation contrainte et la délégation contrainte basée sur les ressources comme n'importe quel autre principal ; ne reportez pas une délégation non contrainte lors de la migration.

Appliquer : poser une fois pour toutes les fondations gMSA

Clé racine KDS

Les mots de passe gMSA sont dérivés de la clé racine KDS de la forêt, du SID du gMSA et de l'intervalle de temps en cours. La clé doit exister et avoir été répliquée avant qu'un DC ne calcule un mot de passe.

Get-KdsRootKey | Select-Object KeyId, EffectiveTime, CreationTime

# Production : créer une seule fois, puis attendre la réplication (effective après 10 heures par défaut)
Add-KdsRootKey -EffectiveImmediately

Malgré son nom, -EffectiveImmediately attend en pratique le délai de sécurité de 10 heures ; antidater -EffectiveTime est réservé aux laboratoires à DC unique. La clé racine KDS réside dans la partition Configuration, et quiconque peut la lire (Domain Admins, Enterprise Admins, SYSTEM sur un DC) peut calculer hors ligne tous les mots de passe gMSA, attaque connue sous le nom de Golden gMSA. Traitez-la comme un élément Tier 0 et incluez-la dans votre plan de restauration de forêt.

Groupes de récupération

Créez un groupe de sécurité par gMSA ne contenant que les comptes d'ordinateur qui exécutent la charge de travail. Ce groupe est inscrit dans msDS-GroupMSAMembership, exposé sous le nom PrincipalsAllowedToRetrieveManagedPassword.

New-ADGroup -Name "gMSA-svc-sqlapp-Hosts" -GroupScope Global -GroupCategory Security `
    -Path "OU=gMSA Groups,OU=Tier1,DC=corp,DC=example,DC=com"
Add-ADGroupMember "gMSA-svc-sqlapp-Hosts" -Members "SQL01$","SQL02$"

New-ADServiceAccount -Name "gmsa-sqlapp" `
    -DNSHostName "gmsa-sqlapp.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "gMSA-svc-sqlapp-Hosts" `
    -KerberosEncryptionType AES128,AES256 `
    -ManagedPasswordIntervalInDays 30 `
    -Path "OU=Service Accounts,OU=Tier1,DC=corp,DC=example,DC=com"

ManagedPasswordIntervalInDays ne peut être défini qu'à la création. KerberosEncryptionType exclut RC4 du compte, ce qui compte si vous êtes en train de désactiver RC4. Déplacez les SPN de l'ancien compte vers le gMSA avec Set-ADServiceAccount -ServicePrincipalNames @{Add=...} après les avoir retirés de l'ancien compte, car les SPN en double cassent Kerberos.

Sur chaque hôte, actualisez l'appartenance aux groupes et testez :

klist -li 0x3e7 purge
Test-ADServiceAccount -Identity "gmsa-sqlapp"

Install-ADServiceAccount est facultatif pour les gMSA sur les versions actuelles de Windows ; le contrôle qui compte est que Test-ADServiceAccount renvoie True.

Protéger le gMSA lui-même

Un gMSA ne vaut que ce que vaut la liste des principaux autorisés à lire son mot de passe. Le DC renvoie le mot de passe actuel et le précédent dans l'attribut construit msDS-ManagedPassword à tout principal présent dans msDS-GroupMSAMembership : cette liste est donc de fait l'ACL d'un coffre d'identifiants. Trois règles la maintiennent saine :

• Hiérarchisez le gMSA avec ses hôtes. Un gMSA utilisé par un serveur d'applications Tier 1 ne doit pas être récupérable par une machine Tier 2, et un gMSA disposant de droits sur les DC ou l'infrastructure de sauvegarde relève du Tier 0, tout comme les groupes et UO qui le contrôlent.
• Contrôlez qui peut modifier la liste de récupération. Quiconque dispose d'un accès en écriture à msDS-GroupMSAMembership sur le gMSA, ou à l'appartenance au groupe de récupération, peut ajouter une machine qu'il contrôle et lire le mot de passe. Examinez ces ACL avec les mêmes outils que ceux de la gestion des chemins d'attaque.
• Auditez la récupération. Une SACL sur les objets gMSA pour les lectures de msDS-ManagedPassword produit l'événement 4662 sur les DC. Les lectures légitimes proviennent des hôtes du groupe de récupération, à peu près à chaque intervalle de mot de passe et au démarrage du service ; les lectures depuis tout autre compte méritent une alerte.

Notes par application

Services Windows et tâches planifiées

Les services prennent le compte avec un $ final et un mot de passe vide. Le compte a besoin du droit Log on as a service (ouvrir une session en tant que service), que sc.exe et la console Services accordent automatiquement sur l'hôte local ; si une GPO gère l'attribution des droits utilisateur, ajoutez le gMSA à cette GPO, sinon la prochaine actualisation le retirera.

sc.exe config "AppService" obj= "CORP\gmsa-sqlapp$" password= ""

$principal = New-ScheduledTaskPrincipal -UserId "CORP\gmsa-report$" -LogonType Password
Set-ScheduledTask -TaskName "NightlyReport" -Principal $principal

Les tâches planifiées ont besoin du droit Log on as a batch job (ouvrir une session en tant que tâche) au lieu du droit de service.

Pools d'applications IIS

Dans le Gestionnaire IIS, définissez l'identité du pool sur CORP\gmsa-web$ avec un mot de passe vide. Pour l'authentification Kerberos sur le site, enregistrez le SPN HTTP sur le gMSA et activez l'authentification en mode noyau avec useAppPoolCredentials, afin que les tickets soient déchiffrés avec les clés du gMSA. Les fermes web fonctionnent bien, puisque chaque nœud fait partie du groupe de récupération.

SQL Server

Modifiez les comptes du moteur et de l'Agent via le Gestionnaire de configuration SQL Server, et non via la console Services, afin que les autorisations sur le système de fichiers, le registre et les SPN soient mises à jour. Consultez la documentation de votre version de SQL Server pour les instances de cluster de basculement et les groupes de disponibilité : la prise en charge s'est élargie au fil des versions, et tous les réplicas doivent faire partie du groupe de récupération. Déplacez les SPN MSSQLSvc/ vers le gMSA.

Ce que le gMSA couvre mal

Les applications qui stockent le mot de passe du service dans leur propre base de données, les scénarios inter-forêts où l'hôte consommateur se trouve dans une autre forêt, et la plupart des plateformes non Windows. Ces cas restent dans la catégorie 4.

dMSA sous Windows Server 2025

Les comptes de service gérés délégués (dMSA) nécessitent au moins un contrôleur de domaine Windows Server 2025 et la clé racine KDS. La migration lie un nouveau dMSA à un compte classique existant ; pendant la migration, l'authentification Kerberos de l'ancien compte est redirigée vers le dMSA et, une fois la migration terminée, le mot de passe du compte d'origine n'est plus utilisé.

New-ADServiceAccount -Name "dmsa-legacyapp" -DNSHostName "dmsa-legacyapp.corp.example.com" `
    -CreateDelegatedServiceAccount -KerberosEncryptionType AES256 `
    -Path "OU=Service Accounts,OU=Tier1,DC=corp,DC=example,DC=com"

Start-ADServiceAccountMigration -Identity "dmsa-legacyapp" `
    -SupersededAccount "CN=svc_legacyapp,OU=Service Accounts,DC=corp,DC=example,DC=com"

# Une fois que l'hôte a pris en compte le dMSA et que l'application est validée
Complete-ADServiceAccountMigration -Identity "dmsa-legacyapp" `
    -SupersededAccount "CN=svc_legacyapp,OU=Service Accounts,DC=corp,DC=example,DC=com"

Undo-ADServiceAccountMigration et Reset-ADServiceAccountMigration existent pour le retour arrière. Les noms de paramètres ont évolué depuis la sortie : consultez Get-Help sur vos DC avant d'écrire vos scripts. Le lien est stocké dans msDS-ManagedAccountPrecededByLink sur le dMSA et dans msDS-SupersededManagedAccountLink sur l'ancien compte.

Note de sécurité : en 2025, des chercheurs ont publié « BadSuccessor », montrant qu'un principal capable de créer un dMSA dans n'importe quelle UO pouvait faire pointer ce lien vers un compte privilégié et hériter de ses autorisations. Microsoft l'a corrigé par une mise à jour de sécurité (CVE-2025-53779), mais la leçon de fond demeure : auditez qui détient le droit Create msDS-DelegatedManagedServiceAccount ou des droits génériques Create Child sur les UO, exactement comme pour toute autre ACL dangereuse.

Vérifier

Avant de désactiver un ancien compte, confirmez que la nouvelle identité fonctionne et que l'ancienne est muette.

# État des gMSA et périmètre de récupération
Get-ADServiceAccount -Filter * -Properties PrincipalsAllowedToRetrieveManagedPassword, msDS-SupportedEncryptionTypes, PasswordLastSet |
  Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes,
    @{n='Retrievers';e={$_.PrincipalsAllowedToRetrieveManagedPassword -join ';'}}

# Ancien compte : aucune authentification récente
Get-ADUser svc_legacyapp -Properties LastLogonTimestamp, ServicePrincipalName |
  Select-Object Name, @{n='LastLogon';e={[datetime]::FromFileTime($_.LastLogonTimestamp)}}, ServicePrincipalName

Signalez tout gMSA dont les récupérateurs incluent des comptes utilisateurs, Domain Computers ou des groupes imbriqués dont vous n'êtes pas propriétaire. Surveillez les demandes 4769 portant sur les anciens SPN et les échecs 4625 citant l'ancien compte pendant au moins un cycle d'activité complet (traitements de fin de mois), puis désactivez-le, laissez-le désactivé 30 jours et supprimez-le. Relancez l'inventaire de défense contre le Kerberoasting pour confirmer que le SPN a disparu des objets utilisateurs.

Ce que cela casse

• Les services qui démarrent avant que l'hôte n'ait un TGT à jour. Un hôte nouvellement ajouté échoue avec une erreur d'ouverture de session jusqu'à son redémarrage ou la purge de ses tickets. Intégrez cette étape au plan de changement.
• Les droits utilisateur gérés par GPO retirent au gMSA le droit Log on as a service ou Log on as a batch job à la prochaine actualisation si le gMSA ne figure pas dans la stratégie.
• Les identifiants codés en dur dans les chaînes de connexion, les scripts et les consoles d'éditeurs cessent de fonctionner, car il n'y a plus de mot de passe à saisir. Trouvez-les pendant l'audit, pas après la bascule.
• Les SPN en double pendant la migration provoquent des échecs Kerberos et un repli silencieux sur NTLM. Retirez avant d'ajouter.
• Les consommateurs inter-forêts et les clients non Windows ne peuvent pas récupérer les mots de passe gMSA ; ils restent sur des comptes classiques.
• Le dMSA nécessite des DC Windows Server 2025 et des hôtes Windows Server 2025 pour exécuter le service ; les hôtes plus anciens ne peuvent pas l'utiliser.

Pour aller plus loin : le thème Mots de passe et comptes de service regroupe ce guide avec le déploiement de Windows LAPS, et l'entrée de glossaire gMSA résume le modèle d'attributs.