Sécuriser Active Directory : modèle en tiers, LAPS, gMSA et audit

Sécuriser Active Directory, c'est empêcher qu'un attaquant qui a compromis un poste puisse, de proche en proche, obtenir un compte d'administration du domaine, et donc le contrôle de toutes les machines. Ce chapitre donne les mesures concrètes à mettre en place sur un domaine Windows Server : le modèle d'administration en tiers, la protection des comptes privilégiés, Windows LAPS pour les mots de passe des administrateurs locaux, les comptes de service gérés (gMSA et dMSA), la fermeture des protocoles anciens et l'audit de l'annuaire. Les notions d'authentification (Kerberos, NTLM, attaques contre l'annuaire) sont expliquées dans le chapitre Annuaire LDAP, Active Directory et Kerberos du cours Authentification, et le bastion d'administration dans le chapitre Comptes à privilèges et bastion.

Pourquoi l'annuaire est la cible prioritaire

Celui qui contrôle un compte membre des Admins du domaine peut se connecter à toutes les machines du domaine, lire tous les fichiers, créer des comptes, et pousser une GPO qui lance un programme sur tous les postes en même temps. C'est exactement ce que font les rançongiciels qui frappent les entreprises : ils ne chiffrent pas un poste, ils chiffrent tout le parc d'un coup depuis l'annuaire.

Le chemin type d'une attaque, tel qu'on le retrouve dans les rapports d'incident et les sujets d'examen :

1. accès initial : un courriel piégé ouvert sur un poste, ou un accès distant mal protégé ;
2. élévation locale : l'attaquant obtient les droits d'administrateur sur ce poste ;
3. vol d'identifiants : il récupère dans la mémoire du poste les empreintes des mots de passe des comptes qui s'y sont connectés ;
4. déplacement latéral : avec l'empreinte du mot de passe administrateur local, identique partout (pass-the-hash), il se connecte aux autres postes, jusqu'à en trouver un où un administrateur du domaine a ouvert une session ;
5. prise de contrôle du domaine : il vole les identifiants de cet administrateur, se connecte à un contrôleur de domaine, puis déploie sa charge.

Chaque mesure de ce chapitre coupe une étape de ce chemin.

Le modèle d'administration en tiers

Le principe, recommandé par l'ANSSI (et repris par Microsoft, qui l'a fait évoluer vers son modèle d'accès d'entreprise), classe les ressources en trois niveaux selon le contrôle qu'elles donnent, et interdit qu'un compte d'un niveau élevé s'expose sur un niveau inférieur.

La règle d'or : un compte d'administration ne se connecte jamais à une machine d'un tier inférieur. Un administrateur du domaine qui ouvre une session sur un poste ordinaire laisse ses identifiants dans la mémoire de ce poste : si le poste est compromis, le domaine l'est. Chaque administrateur a donc plusieurs comptes : un compte de bureautique sans privilège (messagerie, Internet), et un compte par tier qu'il administre. Les comptes de tier 0 s'utilisent depuis des postes d'administration dédiés (PAW), sans messagerie ni navigation, ou depuis un bastion.

La règle s'impose techniquement par GPO, avec les droits utilisateur : sur les postes (tier 2), une GPO liée à leur OU donne aux groupes d'administration du tier 0 et du tier 1 les droits Interdire l'ouverture d'une session locale, Interdire l'accès à cet ordinateur à partir du réseau et Interdire l'ouverture de session par les services Bureau à distance (Configuration ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateur).

Réduire et protéger les comptes privilégiés

• Moins de membres. Les groupes Administrateurs de l'entreprise et Administrateurs du schéma restent vides en temps normal ; Admins du domaine ne contient que deux ou trois comptes nominatifs dédiés. Les groupes intégrés Opérateurs de compte, Opérateurs de serveur, Opérateurs d'impression restent vides : on délègue finement à la place (chapitre 3).
• Le groupe Protected Users. Ses membres ne peuvent plus s'authentifier en NTLM, leurs identifiants ne sont pas mis en cache sur les postes, Kerberos n'utilise pour eux que AES et leurs tickets durent 4 heures au lieu de 10. On y place les comptes d'administration humains (jamais les comptes de service ni les comptes d'ordinateurs), après avoir vérifié qu'aucune application ne leur demande NTLM.
• La case « Le compte est sensible et ne peut pas être délégué » (onglet Compte) sur les comptes d'administration : aucun service ne pourra agir en leur nom.
• Le compte Administrateur intégré du domaine reçoit un mot de passe très long, rangé dans un coffre, et ne sert qu'en secours.
• Le compte krbtgt, qui signe tous les tickets Kerberos du domaine, voit son mot de passe changé régulièrement (et deux fois, à au moins dix heures d'intervalle, après un incident), pour invalider d'éventuels faux tickets fabriqués par un attaquant.
• Surveiller les ajouts aux groupes d'administration : les événements 4728, 4732 et 4756 du journal de sécurité des contrôleurs (chapitre 14).

L'authentification multifacteur des administrateurs, les solutions de gestion des accès à privilèges et le bastion sont traités dans le cours Authentification.

Windows LAPS : un mot de passe administrateur local unique

Sur beaucoup de parcs, le compte Administrateur local de chaque poste a le même mot de passe, défini une fois dans l'image d'installation. Un attaquant qui récupère son empreinte sur un poste se connecte à tous les autres : c'est l'étape 4 du chemin d'attaque.

Windows LAPS (Local Administrator Password Solution), intégré à Windows depuis la mise à jour d'avril 2023 (Windows 10, Windows 11, Windows Server 2019 et suivants), règle ce problème. Chaque machine :

• génère un mot de passe aléatoire et unique pour son compte d'administrateur local ;
• le renouvelle automatiquement (tous les 30 jours par défaut) ;
• le sauvegarde dans l'annuaire (ou dans Microsoft Entra ID), dans un attribut lisible seulement par les groupes autorisés, et chiffré si le domaine est au niveau fonctionnel 2016 ou plus.

Le technicien qui doit intervenir en local lit le mot de passe du poste, l'utilise, et une action après authentification peut le renouveler automatiquement quelques heures plus tard. Windows Server 2025 ajoute la gestion automatique du compte (LAPS crée et gère lui-même le compte, au nom personnalisable ou aléatoire), les phrases de passe plus faciles à taper, et la détection du retour d'une image (quand une machine revient à un ancien instantané, son mot de passe local ne correspond plus à celui de l'annuaire, et LAPS le détecte).

Le déploiement, étape par étape :

# 1. Étendre le schéma (une fois par forêt, membre des Administrateurs du schéma)
Update-LapsADSchema

# 2. Autoriser les ordinateurs d'une OU à écrire leur propre mot de passe
Set-LapsADComputerSelfPermission -Identity "OU=Ordinateurs,OU=Sorbier,DC=ad,DC=sorbier,DC=example"

# 3. Autoriser le support de niveau 2 à lire les mots de passe de cette OU
Set-LapsADReadPasswordPermission -Identity "OU=Ordinateurs,OU=Sorbier,DC=ad,DC=sorbier,DC=example" `
    -AllowedPrincipals "SORBIER\GG_Support_N2"

4. Une GPO liée à l'OU des ordinateurs, dans Configuration ordinateur > Stratégies > Modèles d'administration > Système > LAPS :

# Sur un poste : appliquer la stratégie LAPS tout de suite
Invoke-LapsPolicyProcessing

# Depuis le poste d'administration : lire le mot de passe d'un poste (droits requis, accès journalisé)
Get-LapsADPassword -Identity "PC-COMPTA-01" -AsPlainText

# Sur le poste : forcer le renouvellement après une intervention
Reset-LapsPassword

Comptes de service gérés : gMSA et dMSA

Un compte de service fait tourner un service ou une tâche planifiée : la sauvegarde, l'agent de supervision, une application métier. Créé comme un compte utilisateur ordinaire, il reçoit souvent un mot de passe simple, qui n'expire jamais, noté dans un document ou dans un script (chapitre 9). Pire : si ce compte a un nom de service Kerberos (SPN), n'importe quel utilisateur du domaine peut demander un ticket chiffré avec son mot de passe et tenter de le casser hors ligne. Cette attaque s'appelle le Kerberoasting ; elle réussit contre les mots de passe courts.

Le compte de service géré de groupe (gMSA, group Managed Service Account) supprime le problème : son mot de passe, de 240 octets aléatoires, est géré par l'annuaire et changé automatiquement tous les 30 jours. Aucun humain ne le connaît. Seuls les serveurs autorisés peuvent le récupérer pour lancer le service.

# 1. Une fois par forêt : la clé racine KDS qui sert à calculer les mots de passe
#    (elle n'est utilisable qu'après 10 heures, le temps qu'elle se réplique)
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 "svc-sauvegarde" -DNSHostName "svc-sauvegarde.ad.sorbier.example" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG_Serveurs_Sauvegarde"

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

Dans la configuration du service ou de la tâche planifiée, on indique le compte SORBIER\svc-sauvegarde$ (avec le $ final) et on laisse le mot de passe vide. Le compte ne reçoit que les droits nécessaires à son travail : jamais Admins du domaine.

Le compte de service géré délégué (dMSA), nouveau dans Windows Server 2025, permet de 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. Il exige au moins un contrôleur de domaine sous Windows Server 2025.

Fermer les vieilles portes

Plusieurs protocoles anciens, conservés pour la compatibilité, sont des portes d'entrée connues.

Auditer l'annuaire

Un annuaire en production depuis des années accumule les écarts : comptes inactifs restés membres de groupes d'administration, délégations oubliées, mots de passe qui n'expirent jamais, systèmes obsolètes, GPO incohérentes. L'audit les met au jour.

PingCastle est l'outil d'audit le plus utilisé en France : lancé depuis un poste du domaine avec un compte ordinaire, il lit l'annuaire et produit un rapport qui attribue un score de risque par catégorie (comptes privilégiés, objets obsolètes, anomalies, approbations) et décrit chaque règle en défaut avec la façon de la corriger. Les sujets d'écrit de cybersécurité en donnent des extraits à interpréter : on te demande alors d'expliquer un constat et de proposer une mesure. Les recommandations de l'ANSSI pour l'administration sécurisée des systèmes reposant sur Active Directory servent de référence pour prioriser.

Ce qu'un audit relève souvent, et la réponse attendue :

La détection complète l'audit : Microsoft Defender for Identity, un SIEM qui reçoit les journaux des contrôleurs ou un EDR repèrent les comportements d'attaque en cours (demandes de tickets massives, réplication demandée par un poste, connexions inhabituelles). C'est l'objet du chapitre suivant et du cours Réponse à incident.

Exercices

Add-KdsRootKey -EffectiveImmediately          # si la forêt n'a pas encore de clé KDS ; attendre 10 h
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$"
New-ADServiceAccount -Name "svc-sauvegarde" -DNSHostName "svc-sauvegarde.ad.sorbier.example" `
    -PrincipalsAllowedToRetrieveManagedPassword "GG_Serveurs_Sauvegarde"
# Sur srv-gestion, après redémarrage :
Install-ADServiceAccount -Identity "svc-sauvegarde"
Test-ADServiceAccount -Identity "svc-sauvegarde"