Mots de passe, stratégies affinées et comptes de service gérés (gMSA)

Dans un domaine, les mots de passe se règlent à trois endroits : la politique du domaine, qui s'applique à tous les comptes, les stratégies de mot de passe affinées (PSO), qui imposent des règles plus strictes à certains comptes comme les administrateurs, et les comptes de service gérés (gMSA), dont le mot de passe est généré et renouvelé par l'annuaire lui-même. Ce chapitre règle les trois chez Sorbier, puis traite le cas du compte krbtgt, dont le mot de passe ne change jamais tout seul.

La politique de mots de passe du domaine

La politique des comptes du domaine se règle dans la GPO liée au domaine, en pratique la Default Domain Policy, sous Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies de comptes. Il n'en existe qu'une par domaine : une politique placée dans une GPO liée à une OU ne règle que les comptes locaux des machines de cette OU. Le cours Windows Server donne la liste des réglages et leurs valeurs par défaut ; on retient ici les choix de sécurité.

Le constat D de Sorbier : 7 caractères, aucun verrouillage. Les recommandations de la CNIL (délibération 2022-100) et de l'ANSSI raisonnent en force du mot de passe et en mesures complémentaires ; le chapitre Politique de mots de passe du cours Authentification les détaille. Pour un mot de passe seul facteur d'authentification, la CNIL demande au moins 12 caractères de quatre types, ou 14 caractères de trois types. La politique retenue chez Sorbier :

Refuser les mots de passe prévisibles. La complexité de Windows accepte Sorbier2026! : douze caractères, quatre types, et pourtant le premier mot de passe qu'un attaquant essaiera. Active Directory seul ne sait pas interdire une liste de mots. Les solutions : Microsoft Entra Password Protection, qui installe un agent sur les contrôleurs et refuse les mots de passe d'une liste mondiale et d'une liste propre à l'organisation (il demande une licence Microsoft Entra ID P1 et un lien avec le cloud) ; des filtres de mots de passe tiers ; à défaut, la sensibilisation et l'audit périodique de la robustesse des mots de passe, mené sur mandat par l'équipe sécurité.

Les stratégies de mot de passe affinées (PSO)

Les comptes d'administration méritent des règles plus strictes que ceux des salariés. Les stratégies de mot de passe affinées (FGPP, fine-grained password policies), stockées sous forme d'objets PSO (Password Settings Object), le permettent. Elles s'appliquent à des utilisateurs ou à des groupes de sécurité globaux, jamais à des OU, et demandent un niveau fonctionnel de domaine Windows Server 2008 au moins.

# Stratégie des comptes d'administration de Sorbier
New-ADFineGrainedPasswordPolicy -Name "PSO-Administrateurs" -Precedence 10 `
    -MinPasswordLength 16 -ComplexityEnabled $true -PasswordHistoryCount 24 `
    -LockoutThreshold 5 -LockoutDuration "00:30:00" -LockoutObservationWindow "00:30:00" `
    -MaxPasswordAge "180.00:00:00" -MinPasswordAge "1.00:00:00" -ReversibleEncryptionEnabled $false

Add-ADFineGrainedPasswordPolicySubject -Identity "PSO-Administrateurs" `
    -Subjects "GG_Admins_T0", "GG_Admins_T1_Serveurs", "GG_Admins_T2_Postes"

# Quelle stratégie s'applique réellement à un compte ?
Get-ADUserResultantPasswordPolicy -Identity "adm0-amercier"

Quand plusieurs PSO concernent un même compte, celle qui a la plus petite priorité (Precedence) l'emporte, et une PSO appliquée directement au compte l'emporte sur celles qui viennent de ses groupes. Un compte sans PSO suit la politique du domaine. Dans l'interface graphique, les PSO se gèrent dans le Centre d'administration Active Directory (dsac.exe), sous le domaine, System > Password Settings Container.

Le problème des comptes de service

Un compte de service fait tourner un service, une tâche planifiée ou une application : le logiciel de sauvegarde, l'agent de supervision, le pool d'applications d'un intranet, une instance SQL Server. Créé comme un compte utilisateur ordinaire, il cumule souvent les défauts :

• un mot de passe choisi par un humain, court, qui n'expire jamais pour éviter les pannes ;
• un mot de passe connu de plusieurs personnes, écrit dans une procédure, un script, parfois dans le champ Description du compte, lisible par tous les utilisateurs du domaine ;
• des droits excessifs (Admins du domaine « parce que ça ne marchait pas autrement ») ;
• un SPN, qui rend son mot de passe attaquable hors ligne par Kerberoasting (chapitre 3).

C'est exactement le constat C de Sorbier : svc-sauvegarde, membre de Admins du domaine, avec un SPN et un mot de passe de 2021.

Les comptes de service gérés de groupe (gMSA)

Un compte de service géré de groupe (gMSA, group Managed Service Account) est un compte dont le mot de passe, de 240 octets aléatoires, est calculé et renouvelé automatiquement tous les 30 jours par les contrôleurs de domaine. Aucun humain ne le connaît. Seules les machines explicitement autorisées peuvent le récupérer pour lancer le service. Le Kerberoasting devient inutile : le ticket est aussi incassable que celui d'un compte d'ordinateur.

Remplacer svc-sauvegarde par un gMSA. Chez Sorbier, le logiciel de sauvegarde tourne sur srv-gestion et ne sauvegarde que les serveurs membres (fichiers, applications) : c'est pour cela que srv-gestion reste un serveur de tier 1. La sauvegarde de l'état du système des contrôleurs passe, elle, par Windows Server Backup sur les contrôleurs eux-mêmes, vers un stockage de tier 0 (chapitre 10). Le compte de service n'a donc aucune raison d'être administrateur du domaine.

# 1. Une fois par forêt : la clé racine KDS, qui sert à calculer les mots de passe.
#    Elle n'est utilisable par les contrôleurs qu'après un délai de 10 heures.
Add-KdsRootKey -EffectiveImmediately

# 2. Le groupe des serveurs autorisés à utiliser le compte
New-ADGroup -Name "GG_Serveurs_Sauvegarde" -GroupScope Global -GroupCategory Security `
    -Path "OU=Groupes,OU=Sorbier,DC=ad,DC=sorbier,DC=example"
Add-ADGroupMember -Identity "GG_Serveurs_Sauvegarde" -Members "srv-gestion$"

# 3. Le compte de service géré
New-ADServiceAccount -Name "gmsa-sauvegarde" -DNSHostName "gmsa-sauvegarde.ad.sorbier.example" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG_Serveurs_Sauvegarde" `
    -KerberosEncryptionType AES128, AES256

# 4. Sur srv-gestion, après un redémarrage (pour que le serveur ait son nouveau groupe)
Install-ADServiceAccount -Identity "gmsa-sauvegarde"
Test-ADServiceAccount -Identity "gmsa-sauvegarde"     # doit répondre True

Dans la configuration du service (console Services, onglet Connexion) ou de la tâche planifiée, on indique SORBIER\gmsa-sauvegarde$ (avec le $ final) et on laisse le mot de passe vide. On donne au gMSA uniquement les droits nécessaires : membre du groupe local Opérateurs de sauvegarde de chaque serveur membre qu'il sauvegarde (srv-fichiers, srv-gestion), et droits de lecture sur les dossiers à sauvegarder, jamais Admins du domaine. Une fois le service validé, on désactive l'ancien compte svc-sauvegarde, après avoir changé son mot de passe, puis on le supprime quelques semaines plus tard.

Tous les logiciels ne savent pas tourner sous un gMSA. La plupart des services Windows, des tâches planifiées, des pools d'applications IIS et SQL Server le permettent ; certains logiciels anciens exigent un mot de passe saisi. Dans ce cas, on garde un compte classique avec un mot de passe aléatoire de 30 caractères au moins, rangé dans un coffre, le chiffrement AES seulement, aucun droit superflu, et une surveillance de son utilisation.

Le compte de service géré délégué (dMSA) de Windows Server 2025

Windows Server 2025 introduit le compte de service géré délégué (dMSA). Il sert à migrer un ancien compte de service à mot de passe fixe vers un compte géré sans reconfigurer l'application : l'ancien compte est désactivé et le dMSA prend sa place, avec un mot de passe géré comme celui d'un gMSA. Il exige au moins un contrôleur de domaine sous Windows Server 2025.

Les autres réglages des comptes à vérifier

Le compte krbtgt : le changer, et deux fois après un incident

Le mot de passe du compte krbtgt chiffre et signe tous les TGT du domaine (chapitre 2). Il ne change jamais automatiquement. Si quelqu'un a pu l'obtenir un jour (ancien prestataire, ancienne sauvegarde de contrôleur volée, attaque passée inaperçue), il peut fabriquer des tickets valides pour n'importe quel compte tant que ce mot de passe n'a pas changé. Le point de contrôle de l'ANSSI signale un mot de passe de krbtgt inchangé depuis plus d'un an ; Microsoft Defender for Identity signale un mot de passe de krbtgt de plus de 180 jours, et les guides de durcissement de Windows Server 2025 demandent de le renouveler au moins tous les 180 jours.

Pourquoi deux fois ? Le compte garde son mot de passe actuel et le précédent, pour que les tickets émis juste avant un changement restent valides. Un seul changement laisse donc l'ancienne clé utilisable. En routine, un changement suffit (l'ancienne clé disparaît au changement suivant). Après une compromission, on le change deux fois, en laissant entre les deux au moins la durée de vie maximale d'un ticket (10 heures par défaut) et le temps que la réplication se termine sur tous les contrôleurs.

La procédure, chez Sorbier :

1. Vérifier la réplication entre srv-ad et srv-ad2 : repadmin /replsummary ne doit montrer aucune erreur. Un contrôleur qui ne réplique pas au moment du changement provoquera des échecs d'authentification.
2. Changer le mot de passe de krbtgt une première fois. On utilise de préférence le script de Microsoft prévu à cet effet (New-KrbtgtKeys.ps1, publié par Microsoft sur GitHub, dans un dépôt aujourd'hui archivé), qui vérifie la réplication, propose un mode de simulation et génère un mot de passe aléatoire ; à défaut, la console Utilisateurs et ordinateurs Active Directory, clic droit sur krbtgt > Réinitialiser le mot de passe (le mot de passe saisi est remplacé par un mot de passe aléatoire géré par le système).
3. Attendre la réplication complète et au moins 10 heures, en surveillant les journaux à la recherche d'erreurs Kerberos.
4. Changer le mot de passe une seconde fois (après un incident seulement).
5. Noter la date et planifier le prochain changement (tous les 180 jours chez Sorbier).

# Date du dernier changement, et état de la réplication
Get-ADUser -Identity krbtgt -Properties PasswordLastSet | Select-Object PasswordLastSet
repadmin /replsummary

Exercices