Durcir les comptes de service : gMSA, SPN et LAPS

Les comptes de service classiques sont l'un des points faibles les plus tenaces d'Active Directory : des mots de passe statiques rarement renouvelés, des identifiants intégrés dans des scripts et des fichiers de configuration, et des Service Principal Names qui transforment des comptes utilisateurs ordinaires en cibles de cassage de mots de passe hors ligne. L'essentiel de ce risque dispose d'une correction directe et prise en charge dans les versions modernes de Windows Server : l'obstacle est généralement l'effort de migration, pas l'absence d'outils. Ce guide décrit le chemin pratique qui mène des comptes de service classiques aux comptes gérés, ainsi que les contrôles de stratégie de mot de passe et d'administrateur local qui complètent le tableau.

Pourquoi les comptes de service classiques sont un passif

Un compte de service historique typique est un objet utilisateur normal avec l'option Le mot de passe n'expire jamais activée, un mot de passe choisi une fois lors du provisionnement et rarement modifié, et souvent réutilisé par plusieurs applications, car le changer implique de coordonner une interruption avec chaque consommateur. Si ce compte possède aussi un Service Principal Name (SPN) enregistré, il devient une cible de Kerberoasting : n'importe quel utilisateur authentifié du domaine peut demander un ticket de service Kerberos pour ce compte et tenter de casser hors ligne la partie chiffrée du ticket, sans tentative d'ouverture de session ni déclenchement de verrouillage.

Les comptes de service gérés de groupe (gMSA) et, dans Windows Server 2025, les comptes de service gérés délégués (dMSA) règlent le problème de fond : AD génère et renouvelle automatiquement un mot de passe aléatoire de 240 octets (120 caractères), aucun humain ne le connaît, et il ne peut pas être réutilisé ailleurs puisqu'il n'a jamais été choisi par une personne.

Migrer vers les gMSA

Prérequis

• Les gMSA nécessitent le schéma Windows Server 2012 (ou ultérieur) et au moins un DC sous Windows Server 2012 ou ultérieur ; aucun niveau fonctionnel n'est exigé. Les dMSA nécessitent des contrôleurs de domaine Windows Server 2025.
• La KDS Root Key doit exister avant la création du premier gMSA.

# Configuration unique de la forêt : vérifier si une clé racine KDS existe déjà
Get-KdsRootKey

# S'il n'en existe aucune, en créer une. En production, laisser s'écouler le délai
# de sécurité de réplication de 10 heures plutôt que d'antidater la clé :
Add-KdsRootKey -EffectiveImmediately
# Laboratoire uniquement (DC unique) : Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))

Créer et déployer un gMSA

# Créer un gMSA limité aux hôtes autorisés à l'utiliser
New-ADServiceAccount -Name "svc-sqlapp" `
    -DNSHostName "svc-sqlapp.corp.example.com" `
    -PrincipalsAllowedToRetrieveManagedPassword "SQLAppServers" `
    -Enabled $true

# Sur chaque hôte autorisé, installer le gMSA
Install-ADServiceAccount -Identity "svc-sqlapp"

# Vérifier que l'hôte peut récupérer le mot de passe géré
Test-ADServiceAccount -Identity "svc-sqlapp"

Configurez le service consommateur (par exemple un service Windows, un pool d'applications IIS ou une tâche planifiée) pour qu'il s'exécute sous CORP\svc-sqlapp$ sans mot de passe : le système d'exploitation le récupère et le renouvelle de manière transparente.

# Faire pointer un service Windows existant vers le gMSA
sc.exe config "MyAppService" obj= "CORP\svc-sqlapp$"

dMSA pour les comptes difficiles à migrer (Server 2025)

Le dMSA est conçu spécifiquement pour les comptes que l'on ne peut pas proprement rediriger vers une nouvelle identité : Windows peut lier un dMSA au compte de service classique d'origine et rediriger de manière transparente l'authentification Kerberos, ce qui facilite la migration des services qui codent en dur un nom de compte.

# Créer un dMSA lié à un compte de service classique existant pour la migration
New-ADServiceAccount -Name "svc-sqlapp-dmsa" -DNSHostName "svc-sqlapp-dmsa.corp.example.com" `
    -CreateDelegatedServiceAccount -KerberosEncryptionType AES256

# Le lier à l'ancien compte et démarrer la migration
Start-ADServiceAccountMigration -Identity "svc-sqlapp-dmsa" `
    -SupersededAccount "CN=svc-sqlapp,OU=Service Accounts,DC=corp,DC=example,DC=com"

La séquence de migration complète (démarrage, prise en compte du dMSA par les hôtes, puis finalisation) est décrite dans Migrer les comptes de service vers gMSA et dMSA. Testez-la en laboratoire avant de toucher aux comptes de service de production.

Hygiène des SPN

Auditez chaque SPN enregistré sur un objet utilisateur (et non sur un objet ordinateur ou gMSA) : c'est l'ensemble exposé au Kerberoasting :

Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName |
    Select-Object SamAccountName, ServicePrincipalName

Pour chaque résultat :

1. Identifiez le service et l'équipe propriétaire.
2. Migrez le service pour qu'il s'exécute sous un gMSA/dMSA lorsque l'application prend en charge les comptes de service gérés de groupe (c'est le cas de la plupart des scénarios modernes d'hébergement SQL Server, IIS et services Windows).
3. Lorsque la migration n'est pas encore possible, imposez un mot de passe long (25 caractères ou plus) et aléatoire via une stratégie de mot de passe affinée dédiée (voir ci-dessous), et renouvelez-le.
4. Supprimez entièrement le SPN de tout compte dont le service associé n'existe plus : les SPN obsolètes sont fréquents après le décommissionnement d'applications.

# Supprimer un SPN obsolète
Set-ADUser -Identity "svc_oldapp" -ServicePrincipalNames @{Remove="MSSQLSvc/oldapp.corp.example.com:1433"}

Stratégies de mot de passe affinées (PSO)

L'unique stratégie de mot de passe par défaut du domaine est généralement trop faible pour les comptes privilégiés et de service, mais trop stricte pour être imposée à tous les utilisateurs. Les stratégies de mot de passe affinées permettent d'ajouter des exigences plus strictes pour des groupes précis sans modifier la stratégie par défaut du domaine.

New-ADFineGrainedPasswordPolicy -Name "PSO-ServiceAccounts" `
    -Precedence 10 `
    -MinPasswordLength 32 `
    -PasswordHistoryCount 24 `
    -MaxPasswordAge "180.00:00:00" `
    -MinPasswordAge "1.00:00:00" `
    -ComplexityEnabled $true `
    -ReversibleEncryptionEnabled $false

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-ServiceAccounts" -Subjects "SVC-Accounts-NonMigrated"

New-ADFineGrainedPasswordPolicy -Name "PSO-Tier0Admins" `
    -Precedence 5 `
    -MinPasswordLength 20 `
    -MaxPasswordAge "60.00:00:00" `
    -ComplexityEnabled $true

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-Tier0Admins" -Subjects "Tier 0 Admins"

Les valeurs de Precedence les plus basses l'emportent lorsqu'un compte est soumis à plusieurs PSO. Vérifiez la stratégie effective compte par compte :

Get-ADUserResultantPasswordPolicy -Identity "svc_oldapp"

Envisagez aussi une approche par mots de passe interdits, soit via une DLL de filtre de mots de passe tierce, soit via l'agent local d'Entra Password Protection, afin que les mots de passe humains, ainsi que les éventuels mots de passe de comptes de service encore définis par des humains, soient comparés à une liste de mots de passe compromis ou courants au moment de leur définition, et pas seulement à une expression régulière de complexité.

Windows LAPS pour les mots de passe d'administrateur local

Les mots de passe d'administrateur local partagés sur un parc de machines démultiplient le mouvement latéral : un seul mot de passe d'administrateur local divulgué peut ouvrir toutes les machines qui le partagent. Windows LAPS (intégré à Windows Server 2019 et ultérieur ainsi qu'à Windows 10/11 avec la mise à jour correspondante, en remplacement de l'extension côté client de l'ancien LAPS) rend aléatoire et renouvelle le mot de passe d'administrateur local de chaque machine, et le stocke chiffré dans AD.

# Étendre le schéma (opération unique, à exécuter sur le maître de schéma)
Update-LapsADSchema

# Configurer par GPO : Computer Configuration → Policies → Administrative Templates → System → LAPS
# Définir "Configure password backup directory" sur Active Directory (rien ne se passe tant que ce n'est pas fait),
# puis "Password Settings", et "Enable password backup for DSRM accounts" sur les DC si nécessaire

# Définir les autorisations sur l'UO pour que seuls les administrateurs autorisés puissent lire le mot de passe chiffré
Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=corp,DC=example,DC=com" -AllowedPrincipals "Tier2-Helpdesk-Admins"

# Vérifier qu'une machine remonte bien son mot de passe LAPS
Get-LapsADPassword -Identity "WKS-01" -AsPlainText

Remarque : la gestion des identifiants DSRM et d'administrateur local des DC est un sujet distinct. Windows LAPS peut gérer le mot de passe DSRM des contrôleurs de domaine, comme décrit dans le déploiement de Windows LAPS ; reportez-vous aussi aux recommandations propres aux DC plutôt que d'appliquer aux contrôleurs de domaine les hypothèses de périmètre de LAPS pour les postes de travail.

Checklist de vérification

# Confirmer qu'aucun compte utilisateur ne détient de SPN hors d'une liste d'exceptions approuvée
Get-ADUser -Filter { ServicePrincipalName -like "*" } -Properties ServicePrincipalName

# Confirmer que les gMSA sont récupérables par les hôtes prévus
Test-ADServiceAccount -Identity "svc-sqlapp"

# Confirmer que la PSO est appliquée au groupe prévu
Get-ADFineGrainedPasswordPolicySubject -Identity "PSO-ServiceAccounts"

# Confirmer que LAPS renouvelle activement les mots de passe sur un échantillon de machines
Get-LapsADPassword -Identity "WKS-01" | Select-Object PasswordUpdateTime, ExpirationTimestamp

Ce que cela casse

• Les applications qui ne prennent pas en charge les gMSA. Certains logiciels historiques ou tiers exigent un compte de type interactif avec un mot de passe modifiable et ne savent pas utiliser une identité de type compte d'ordinateur. Ils restent sur des comptes classiques, isolés derrière la PSO la plus stricte possible, jusqu'à ce que l'éditeur ajoute la prise en charge.
• L'utilisation de services entre forêts ou entre domaines peut compliquer le déploiement des gMSA, puisque la récupération dépend de la réplication de la clé racine KDS et de la résolution des appartenances aux groupes dans le périmètre concerné.
• Les identifiants codés en dur dans des scripts ou des fichiers de configuration qui référencent le mot de passe de l'ancien compte cesseront purement et simplement de fonctionner une fois le passage à un gMSA sans mot de passe statique effectué : recherchez-les avant la bascule, pas après.
• Les processus du support fondés sur des mots de passe d'administrateur local partagés devront changer dès que Windows LAPS imposera l'unicité par machine ; documentez la nouvelle procédure de récupération (Get-LapsADPassword) pour le personnel du support.

Ce guide ne traite volontairement pas de la rotation du mot de passe krbtgt : elle a son propre rythme et ses propres considérations d'impact, et fait l'objet d'un guide dédié. Voir aussi Durcissement de Kerberos pour la configuration Kerberos plus large dans laquelle ce travail s'inscrit.