Vérifier la sécurité de son Active Directory

Un attaquant qui entre dans un réseau Windows vise en priorité l'Active Directory. Qui le contrôle contrôle toutes les machines du domaine. Ce guide liste les points à vérifier, dans l'ordre où ils pèsent, avec les commandes PowerShell qui donnent la réponse.

Il faut le module ActiveDirectory (outils RSAT) et un compte qui lit l'annuaire. Les commandes de ce guide ne font que lire.

#1. Les comptes à privilèges

Commencez par compter les personnes qui peuvent tout faire. Les groupes à examiner sont Admins du domaine, Administrateurs de l'entreprise, Administrateurs du schéma, Administrateurs, Opérateurs de compte, Opérateurs de sauvegarde et Opérateurs de serveur. Leur nom change avec la langue du domaine, leur identifiant de sécurité (SID) ne change pas.

$sid = "$((Get-ADDomain).DomainSID)-512"
Get-ADGroupMember -Identity $sid -Recursive | Select-Object Name, SamAccountName

Ce qu'il faut regarder :

• le nombre : au-delà d'une dizaine d'administrateurs actifs, la plupart n'en ont pas besoin au quotidien ;
• les comptes de service membres d'un groupe à privilèges, dont le mot de passe est souvent ancien et partagé entre collègues ;
• les comptes nominatifs qui servent aussi à lire ses e-mails et à naviguer, alors qu'un administrateur devrait avoir un compte séparé pour l'administration ;
• les administrateurs hors du groupe Protected Users et sans l'option « Le compte est sensible et ne peut pas être délégué ».

Un compte qui a été membre d'un groupe protégé garde adminCount = 1 après sa sortie. Ces comptes restent à part dans l'annuaire et méritent une vérification.

Get-ADUser -Filter 'adminCount -eq 1' -Properties adminCount | Select-Object SamAccountName, Enabled

#2. Le compte krbtgt

Le mot de passe de krbtgt sert à signer tous les tickets Kerberos du domaine. Qui le connaît peut fabriquer un ticket valide pour n'importe quel compte (« golden ticket »). Dans beaucoup de domaines, il n'a pas changé depuis la création.

Get-ADUser krbtgt -Properties PasswordLastSet | Select-Object PasswordLastSet

Changez-le à intervalle régulier, et après tout incident où un contrôleur de domaine a pu être compromis. La procédure se fait en deux changements, car un seul laisse l'ancien mot de passe valide. Entre les deux, laissez la réplication atteindre tous les contrôleurs et attendez au moins la durée de vie maximale d'un ticket (10 heures par défaut). Deux changements trop rapprochés coupent des sessions en cours.

#3. Les délégations et les attaques Kerberos

• Délégation non contrainte. Une machine qui en bénéficie garde en mémoire les tickets des comptes qui s'y connectent. Hors contrôleurs de domaine, elle n'a pas lieu d'être.
• Comptes sans préauthentification Kerberos. N'importe qui peut demander un ticket pour eux et tenter de casser le mot de passe hors ligne (AS-REP roasting).
• Comptes utilisateurs avec un SPN. Leurs tickets de service se demandent librement et se cassent hors ligne (Kerberoasting). Un mot de passe long et renouvelé, ou un compte de service géré (gMSA), règle la question.

Get-ADComputer -Filter 'TrustedForDelegation -eq $true' | Select-Object Name
Get-ADUser -Filter 'DoesNotRequirePreAuth -eq $true' | Select-Object SamAccountName
Get-ADUser -Filter 'ServicePrincipalName -like "*"' -Properties PasswordLastSet | Select-Object SamAccountName, PasswordLastSet

La première commande liste aussi les contrôleurs de domaine. Pour eux, la délégation non contrainte est normale.

#4. LAPS, NTLMv1 et signature LDAP

LAPS. Sans LAPS ni Windows LAPS, le compte administrateur local a souvent le même mot de passe sur tous les postes, et un poste compromis ouvre alors tous les autres. Mesurez la part des machines dont le mot de passe local est géré. Avec Windows LAPS, l'attribut msLAPS-PasswordExpirationTime est renseigné sur l'objet ordinateur.

NTLMv1. Ce protocole est obsolète, et un échange capté suffit pour retrouver le secret du compte. Les contrôleurs de domaine notent la version de NTLM dans chaque événement de connexion 4624.

$xpath = "*[System[EventID=4624] and EventData[Data[@Name='LmPackageName']='NTLM V1']]"
Get-WinEvent -LogName Security -FilterXPath $xpath -MaxEvents 200 | Select-Object TimeCreated, @{n='Compte';e={$_.Properties[5].Value}}

Une fois les applications en cause corrigées, réglez LmCompatibilityLevel à 5 sur les contrôleurs de domaine. Seul NTLMv2 est alors accepté.

Signature LDAP. Sans signature exigée, une connexion LDAP peut être relayée ou modifiée en chemin. La valeur LDAPServerIntegrity à 2, sous HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, l'exige. Avant de l'imposer, regardez l'événement 2887 du journal Directory Service : il compte chaque jour les liaisons non signées, donc les clients qui restent à corriger.

#5. Les comptes oubliés

Comptes actifs sans connexion depuis des mois, mots de passe sans expiration, machines disparues du réseau, systèmes en fin de support : chacun est une porte que personne ne surveille.

Search-ADAccount -AccountInactive -TimeSpan 90.00:00:00 -UsersOnly | Where-Object Enabled | Select-Object SamAccountName, LastLogonDate

LastLogonDate est répliqué avec un retard qui peut atteindre 14 jours. Un compte affiché inactif depuis 80 jours peut donc s'être connecté la semaine dernière.

#6. Une vérification ponctuelle ne suffit pas

Un audit donne une photo. Entre deux audits, les écarts reviennent : un prestataire ajouté aux Admins du domaine pour une intervention puis oublié, une délégation posée pour un test. Deux habitudes changent la situation :

• relire chaque trimestre les membres des groupes sensibles, avec une décision écrite pour chacun ;
• être prévenu dès qu'un groupe à privilèges change, au lieu de l'apprendre au prochain audit.

Des outils publics dressent un état des lieux ponctuel, par exemple ORADAD, publié par l'ANSSI, ou PingCastle.

#Ce que FirstSI suit

Ouvrez SI-Tracer → Active Directory (#/sitracer/ad). Les points de ce guide y forment le Score de posture, une note sur 100 recalculée chaque jour et tracée sur 180 jours.

Points à traiter classe les écarts avec leur gravité, et Voir les … éléments affiche les comptes ou machines en cause.

Les gestes dangereux sont signalés en temps réel : ajout dans un groupe à privilèges, délégation posée, Kerberoasting, DCSync, stratégie de groupe modifiée, journal de sécurité effacé. Les 14 règles sont actives par défaut et ouvrent leurs incidents dans le SIEM.

L'onglet Revue des accès prépare la relecture trimestrielle et l'exporte en CSV, avec l'auteur et la date de chaque décision. FirstSI ne modifie rien dans l'annuaire, et chaque correction reste à faire par vos administrateurs.

L'agent doit tourner sur chaque contrôleur de domaine, avec le module SI-Tracer. L'audit Accès au service d'annuaire reste à activer vous-même, sans quoi la détection DCSync reste muette. Voir Active Directory : sécurité et santé.

#Pour aller plus loin

• Active Directory : sécurité et santé : les 14 règles d'alerte et leurs seuils.
• Revue des accès : la preuve à présenter lors d'un audit.
• SI-Tracer : authentifications Windows : qui s'est connecté où, en Kerberos ou en NTLM.
• Fiche compte et fiche d'adresse IP : l'historique d'un compte et l'origine de ses verrouillages.
• Durcir ses serveurs Windows : la suite, sur les serveurs membres.

Présentation : Sécurité Active Directory : surveillance et audit↗

Source : · Docs FirstSI · mis à jour le 11/10/2026