Auditer son Active Directory en 2026 : checklist en 7 étapes

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 service sur 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.