L'Active Directory reste, en 2026, la cible n°1 dans la majorité des incidents post-intrusion observés en France. Du coup, un audit AD bien mené est l'un des chantiers à plus fort ROI sur une PME 100-500 postes.
Voici la checklist en 7 étapes que nous appliquons en mission, alignée sur le référentiel ANSSI ADS et le tier model Microsoft.
Étape 1 — Inventaire des comptes privilégiés
Le point de départ. Concrètement :
- Liste exhaustive des comptes Domain Admins, Enterprise Admins, Schema Admins, Account Operators, Server Operators, Backup Operators, Print Operators.
- Pour chaque compte : date de dernière utilisation, propriétaire, justification métier, MFA en place oui/non.
- Identification des comptes admins dormants (>90 jours sans usage). Cible : zéro compte dormant avec privilèges élevés.
- Comptes avec attribut
adminCount=1(gérés par AdminSDHolder) : revue exhaustive.
Outil : PingCastle catégorie "Privileged accounts" + script PowerShell custom.
Étape 2 — Tier model et séparation Tier 0/1/2
Le tier model Microsoft sépare les comptes en 3 niveaux :
- Tier 0 : Domain Controllers, comptes admins de domaine, schema admins. Le cœur du royaume.
- Tier 1 : serveurs métier, applications.
- Tier 2 : postes utilisateurs.
Règle absolue : un compte Tier 0 ne se connecte jamais à un poste Tier 2. Sinon, credential theft propagé via mimikatz / lsass dump. C'est le pattern dominant dans les compromissions full-domain qu'on voit en post-incident.
À auditer :
- Présence d'un tier model documenté et appliqué.
- PAW (Privileged Access Workstations) déployées pour les admins.
- LAPS (Local Administrator Password Solution) sur tous les postes.
- Logon restrictions :
Deny logon locally/Deny logon as servicesur les comptes Tier 0 pour les postes Tier 1/2.
Étape 3 — Tests post-exploitation contrôlés
Avec votre accord explicite, en lecture seule, sans modification de l'environnement :
- Kerberoasting : énumération des SPN exposés, identification des comptes de service avec mots de passe faibles ou anciens. Outil : Rubeus, GetUserSPNs.py.
- ASREProast : énumération des comptes sans pré-authentification Kerberos. Très souvent oublié sur des comptes legacy.
- BloodHound (en mode collect read-only) : cartographie des chemins d'attaque (qui peut compromettre Domain Admins via quel chaînage). Le rapport BloodHound est très utile pour la priorisation.
Cible : zéro chemin de compromission Domain Admins en moins de 4 hops depuis un user lambda.
Étape 4 — GPO et politiques
Les Group Policy Objects accumulent la dette technique. Revue ciblée sur :
- Politique de mot de passe : longueur, complexité, historique, lockout. Cible 2026 : 14+ caractères, MFA obligatoire pour les admins.
- Privileges (User Rights Assignment) :
SeDebugPrivilege,SeImpersonatePrivilege,SeBackupPrivilege,SeRestorePrivilege. Tout compte hors admins déclarés = à investiguer. - Restricted Groups : surveillance des appartenances aux groupes admin.
- AllowReversiblePasswordEncryption : doit être désactivé partout.
- GPO obsolètes : suppression des GPO orphelines (souvent 30-60% des GPO d'un environnement legacy).
Étape 5 — Délégations et ACL
L'angle mort le plus fréquent. À chercher :
- AdminSDHolder hijack : ACL non-standard sur le conteneur AdminSDHolder (qui propage aux comptes protégés).
- GenericAll / GenericWrite / WriteDACL / WriteOwner sur des objets sensibles (DC, comptes admin, OU stratégiques) attribués à des comptes inattendus.
- DCSync attribué hors Domain Admins : oversight très classique. Permet l'extraction de toutes les credentials du domaine.
- Propriétaires d'objets : un changement de propriétaire = potentiel de prise de contrôle.
Outil : BloodHound, ADExplorer, PowerView.
Étape 6 — Hardening des contrôleurs de domaine
Les DC sont la cible ultime. À auditer :
- OS : version, patch level, durcissement (CIS Benchmark Windows Server).
- Services exposés : RDP, WMI, WinRM. RDP doit être restreint à des PAW.
- Audit log centralisé : Sysmon + forwarder vers SIEM. Sans log centralisé, post-incident impossible.
- BitLocker sur les DC.
- Comptes locaux : DSRM password rotaté.
- Microsoft Defender for Identity activé si licences disponibles (très utile sur la détection de behavior anormal type DCSync).
Étape 7 — Hygiène et processus
Le maillon humain et organisationnel :
- Provisioning et offboarding : procédure documentée, exécution tracée. Délai d'offboarding cible : <24h après le dernier jour.
- Rotation des mots de passe service : tous les 90 jours minimum, automatisée si possible (gMSA — group Managed Service Accounts).
- Tests de continuité : restauration AD à blanc une fois par an. La majorité des PME ont une sauvegarde, peu ont vérifié qu'elles fonctionnent.
- Formation et sensibilisation : les admins comprennent-ils le tier model ? Savent-ils identifier un kerberoasting attempt ?
Outils recommandés
Stack 2026 efficace pour un audit AD complet :
- PingCastle (Vincent Le Toux) — référence audit AD défensif. Open source, exécution non-intrusive, scoring par catégorie.
- PurpleKnight (Semperis) — alternative complémentaire.
- BloodHound — cartographie des chemins d'attaque (en mode read-only avec accord).
- Microsoft Defender for Identity — détection runtime.
- Référentiel ANSSI ADS si vous y êtes éligible (entités essentielles NIS2, OIV, OSE, secteur public).
Combien de temps
Pour une PME 100-500 postes, 1 forêt, 1-3 domaines : 5 jours d'audit + 2 jours de rédaction + 1 jour de restitution. Pour un environnement complexe (multi-forêts, M&A, intégration Azure AD / Entra ID) : 10-15 jours.
Que faire après
Le rapport produit typiquement 30 à 80 findings. Les critiques (5-15) sont à traiter sous 30 jours. Les chantiers structurants (tier model, PAW, LAPS) sur 6 à 12 mois. WeeSec accompagne la mise en œuvre opérationnelle si besoin.
L'AD ne se sécurise pas en une fois. Audit annuel récurrent recommandé pour les environnements critiques — la dérive est rapide en équipe sysadmin réduite.
