Audit Active Directory 2026 : Méthodes, Outils et Checklist Complète

L'Active Directory est la colonne vertébrale de l'infrastructure informatique de la quasi-totalité des entreprises françaises. C'est aussi, sans conteste, la cible n°1 des attaquants. Selon les données publiées par l'ANSSI dans son rapport sur la menace 2025, plus de 90 % des intrusions réussies en environnement Windows s'appuient sur une compromission partielle ou totale de l'AD. Des groupes de ransomware comme LockBit, BlackBasta et Play ont systématisé l'attaque de l'Active Directory comme vecteur de propagation latérale et d'escalade de privilèges. Un seul compte de service mal configuré, une délégation non contrainte oubliée ou un KRBTGT jamais renouvelé suffisent à transformer un accès initial limité en compromission totale du domaine en moins de 48 heures. Dans ce guide expert, Ayi NEDJIMI vous présente les méthodes, outils et une checklist de 14 points de contrôle critiques pour réaliser un audit Active Directory complet et structuré en 2026, que vous soyez RSSI, administrateur système ou consultant en cybersécurité.

Pourquoi auditer votre Active Directory est devenu prioritaire

La compromission d'un Active Directory représente l'événement le plus redouté dans un scénario de cyberattaque avancée. Ce n'est pas un hasard : l'AD concentre l'authentification, les autorisations, les politiques de sécurité et la confiance entre les systèmes. Un attaquant qui contrôle l'AD contrôle, de facto, l'ensemble du parc informatique.

Selon le CERT-FR, les attaques par rançongiciel ciblant des entreprises françaises ont quasi-systématiquement impliqué une phase d'élévation de privilèges dans l'AD avant le déclenchement du chiffrement. Les attaquants utilisent des techniques bien documentées : Kerberoasting, Pass-the-Hash, Pass-the-Ticket, DCSync, Golden Ticket. Ces techniques exploitent des faiblesses de configuration souvent présentes depuis des années dans des AD jamais audités.

Le problème fondamental est que les Active Directory accumulent de la dette technique et sécuritaire sur des années. Un compte créé en 2015 pour un prestataire parti depuis, une délégation Kerberos configurée en urgence et jamais révisée, un mot de passe de compte de service vieux de 8 ans — voilà le quotidien que je rencontre lors de mes interventions. Ces configurations ne sont pas malveillantes à l'origine, elles sont le résultat d'une accumulation de compromis opérationnels sans révision de sécurité.

La réglementation impose également une surveillance accrue. La directive NIS2, transposée en droit français, exige des opérateurs d'entités essentielles (OEE) et importantes (OEI) une capacité à démontrer la sécurité de leur annuaire. Un audit AD documenté est un prérequis pour toute démarche de conformité sérieuse.

L'audit Active Directory n'est pas un exercice ponctuel : il doit devenir un processus récurrent, idéalement trimestriel pour les indicateurs critiques et annuel pour un audit complet. Les environnements évoluent, les comptes s'accumulent, les délégations prolifèrent. Un instantané de sécurité pris il y a 18 mois ne reflète plus la réalité d'aujourd'hui.

Préparation et cadrage de l'audit

Un audit Active Directory ne s'improvise pas. Une préparation rigoureuse est indispensable pour garantir l'exhaustivité des contrôles et la légalité de l'intervention. Cette phase préparatoire est souvent sous-estimée, alors qu'elle conditionne directement la qualité des résultats obtenus.

Périmètre et autorisation écrite : Avant toute action technique, obtenez une autorisation écrite signée par le représentant légal de l'organisation ou le propriétaire du système. Ce document doit préciser le périmètre exact (domaines, forêts AD concernées), les plages horaires autorisées pour les collectes, les systèmes exclus et les points de contact en cas d'incident. En l'absence de cette autorisation, l'audit constitue un accès frauduleux à un système informatique au sens de l'article 323-1 du Code pénal.

Comptes de test nécessaires : Pour un audit complet, vous aurez besoin d'au minimum deux niveaux d'accès. Un compte utilisateur standard (sans privilèges) permet de tester les informations accessibles à n'importe quel employé via LDAP. Un compte avec droits de lecture étendue sur l'AD (typiquement membre du groupe "Domain Users" avec lecture des attributs sensibles activée) permet d'aller plus loin. Certains contrôles nécessitent des droits Domain Admin — discutez de ce point avec le client et documentez chaque accès.

Accès LDAP et connectivité : Vérifiez la connectivité sur les ports 389 (LDAP), 636 (LDAPS), 3268 (Global Catalog), 88 (Kerberos), 445 (SMB) et 135/49152+ (RPC). La plupart des outils d'audit nécessitent une visibilité réseau directe sur les contrôleurs de domaine. Si vous intervenez en télétravail ou depuis l'extérieur, un accès VPN avec routage vers le réseau AD est indispensable.

Documentation préalable à collecter : Demandez au client la liste des domaines et des forêts AD, le nombre approximatif d'utilisateurs et de machines, le schéma de nommage des OU, la liste des applications qui utilisent des comptes de service, et tout audit précédent disponible. Ces informations permettent de cibler les contrôles et d'éviter les faux positifs.

Reconnaissance passive : énumération sans outil spécialisé

Avant de déployer BloodHound ou PingCastle, une phase de reconnaissance manuelle permet de comprendre la structure de l'AD et d'identifier rapidement les premières anomalies. Cette étape est précieuse car elle reproduit exactement ce qu'un attaquant effectue lors des premières heures d'une compromission.

Énumération LDAP avec ldapsearch : La commande ldapsearch -x -H ldap://[DC_IP] -D "[user]@[domain]" -W -b "DC=[domain],DC=[tld]" permet d'interroger directement l'annuaire. Filtrez sur les attributs sensibles : userAccountControl (pour identifier les comptes désactivés, avec mot de passe immuable, etc.), servicePrincipalName (comptes Kerberoastables), msDS-AllowedToDelegateTo (délégations contraintes), pwdLastSet (ancienneté des mots de passe).

Résolution DNS et topologie : Interrogez le DNS interne pour cartographier les contrôleurs de domaine (nslookup -type=srv _ldap._tcp.[domain]), les sites AD et les relations d'approbation. La liste des sites AD reflète la topologie réseau et peut révéler des sites oubliés avec des politiques de sécurité moins strictes.

Énumération SMB : Le protocole SMB expose des informations précieuses sans authentification sur les anciens systèmes. La session nulle (null session) est normalement désactivée sur les AD modernes, mais vérifiez-le explicitement. L'outil enum4linux permet d'automatiser cette vérification : groupes, utilisateurs, politiques de mots de passe, partages exposés.

rpcclient pour les informations de domaine : rpcclient -U "[user]%[password]" [DC_IP] puis les commandes enumdomusers, enumdomgroups, querydominfo fournissent des informations structurées sur le domaine, dont la politique de mots de passe effective (longueur minimale, historique, verrouillage).

BloodHound et SharpHound : cartographie des chemins d'attaque

BloodHound est l'outil de référence pour l'analyse des chemins d'attaque dans un Active Directory. Développé initialement pour le pentest, il est aujourd'hui utilisé par les équipes défensives pour identifier les chemins de compromission avant les attaquants. Il s'appuie sur Neo4j, une base de données orientée graphe, pour modéliser les relations entre objets AD et calculer les plus courts chemins vers les cibles à haute valeur (Domain Admins, contrôleurs de domaine).

Collecte avec SharpHound : SharpHound est le collecteur officiel de BloodHound. L'exécution SharpHound.exe -c all --zipfilename bloodhound_collecte.zip effectue une collecte complète incluant les sessions actives, les membres de groupes, les ACL, les GPO, les relations de confiance et les données Kerberos. La collecte complète génère entre quelques Mo et plusieurs Go selon la taille de l'AD. Pour les grands environnements, privilégiez -c DCOnly dans un premier temps pour limiter l'impact réseau.

Alternatives : BloodHound.py (version Python, idéale depuis une machine Linux), AzureHound pour les environnements hybrides Azure AD / Entra ID, et RustHound pour les environnements où l'exécution de binaires .NET est restreinte.

Import et analyse dans BloodHound : Après import des fichiers JSON générés par SharpHound, exploitez les requêtes prédéfinies :

• Find All Domain Admins : liste exhaustive des membres directs et indirects du groupe Domain Admins.
• Find Shortest Paths to Domain Admins : identifie les chemins les plus courts depuis n'importe quel utilisateur vers le groupe Domain Admins. C'est souvent ici que les surprises arrivent.
• Find Kerberoastable Users : tous les comptes avec un SPN configuré et un mot de passe potentiellement craquable hors ligne.
• Find AS-REP Roastable Users : comptes avec la pré-authentification Kerberos désactivée.
• Find Computers with Unconstrained Delegation : machines configurées avec délégation non contrainte, vecteur d'élévation de privilèges puissant.

Requêtes Cypher personnalisées : Pour aller plus loin, BloodHound accepte des requêtes Cypher directes. Par exemple, pour identifier tous les utilisateurs ayant des droits GenericWrite sur un objet de groupe critique : MATCH (u:User)-[:GenericWrite]->(g:Group {name:"DOMAIN ADMINS@DOMAIN.LOCAL"}) RETURN u.name. Ces requêtes personnalisées permettent de répondre à des questions d'audit spécifiques non couvertes par les analyses prédéfinies.

Interprétation des résultats : Un graphe BloodHound dense avec de nombreux chemins vers les Domain Admins signale un AD mal géré. En règle générale, le nombre de chemins distincts vers les Domain Admins ne devrait pas dépasser 3 à 5 dans un AD bien configuré suivant le Tiering Model. J'ai régulièrement vu des AD où des centaines de chemins existaient, réduisant l'effort d'escalade de privilèges à quelques minutes pour un attaquant.

PingCastle : score de risque et rapport d'audit automatisé

PingCastle est l'outil d'audit AD le plus utilisé par les équipes internes et les consultants en France. Développé par Vincent LE TOUX, il génère un rapport HTML complet avec un score de risque de 0 à 100 (100 = risque maximal) et classe les findings en quatre niveaux : Critical, High, Medium, Informational.

Exécution : PingCastle.exe --healthcheck --server [domain] pour un audit complet du domaine courant. L'exécution ne nécessite que des droits utilisateur standard pour la majorité des contrôles. La génération du rapport prend généralement entre 2 et 15 minutes selon la taille de l'AD.

Contrôles critiques couverts par PingCastle :

• Comptes inactifs : utilisateurs et ordinateurs non connectés depuis plus de 90 jours. Un AD sain devrait avoir moins de 5 % de comptes inactifs.
• SID History non vidée : attribut sIDHistory rempli sur des comptes — vecteur d'escalade de privilèges souvent ignoré lors des migrations.
• Délégations non contraintes : serveurs ou comptes configurés avec TRUSTED_FOR_DELEGATION — permet à un attaquant contrôlant la machine de capturer des tickets Kerberos de n'importe quel compte s'y connectant, y compris les Domain Admins.
• LAPS absent : Local Administrator Password Solution non déployée sur les machines du domaine — permet les attaques Pass-the-Hash latérales si le mot de passe administrateur local est identique sur toutes les machines.
• Niveau fonctionnel du domaine : un niveau fonctionnel Windows 2008 ou inférieur signale un AD vieillissant avec des fonctionnalités de sécurité modernes indisponibles.
• Politique de mots de passe : longueur minimale inférieure à 12 caractères, durée de vie supérieure à 365 jours, absence de Fine-Grained Password Policies pour les comptes privilégiés.

Le score PingCastle comme KPI : Lors d'un audit, je considère qu'un score inférieur à 25 est acceptable pour un AD en production, entre 25 et 50 nécessite un plan de remédiation à 3 mois, et au-delà de 50 indique un risque critique nécessitant des actions immédiates. J'ai vu des AD avec des scores de 85 ou 90 — des organisations qui n'avaient jamais réalisé d'audit sécurité de leur annuaire.

PingCastle en mode consolidation : Pour les grandes organisations avec plusieurs domaines, PingCastle.exe --consolidation agrège les résultats de plusieurs audits en un tableau de bord unique — très utile pour les groupes avec des filiales ayant des AD distincts.

Purple Knight (Semperis) : indicateurs de compromission AD

Purple Knight est l'outil de Semperis dédié à la détection d'indicateurs de compromission (IoC) et d'indicateurs d'exposition (IoE) dans l'Active Directory. Contrairement à PingCastle qui se concentre sur les mauvaises configurations, Purple Knight cherche activement les traces d'une compromission passée ou en cours.

Indicateurs de compromission couverts : Purple Knight vérifie notamment la présence de portes dérobées connues dans l'AD, les modifications anormales du groupe AdminSDHolder, les changements récents sur le compte KRBTGT, les objets avec des attributs inhabituels (msDS-KeyCredentialLink pour les attaques Shadow Credentials), les ACL modifiées sur les objets critiques, et les délégations Kerberos suspectes.

Catégories d'analyse : L'outil couvre cinq domaines : Account Security (sécurité des comptes), Active Directory Infrastructure, Group Policy, Kerberos, et Microsoft Entra ID (pour les environnements hybrides). Chaque catégorie produit un score et une liste de findings détaillés.

Valeur ajoutée par rapport à PingCastle : Là où PingCastle est excellent pour l'inventaire des mauvaises configurations, Purple Knight excelle dans la détection de manipulations récentes. Si un attaquant a modifié des ACL sur un objet critique il y a 6 mois et que personne n'a fait de vérification depuis, Purple Knight le détectera là où PingCastle peut passer à côté. C'est pour cette raison que les deux outils sont complémentaires et doivent être utilisés conjointement dans un audit sérieux.

Exportation et intégration : Les résultats Purple Knight s'exportent en JSON et CSV, facilement intégrables dans un rapport d'audit ou dans un SIEM pour le suivi dans le temps.

Checklist des 14 points de contrôle critiques

Cette checklist constitue le cœur de tout audit Active Directory. Elle couvre les vecteurs d'attaque les plus fréquemment exploités par les groupes de menaces ciblant les entreprises françaises.

1. Comptes administrateurs de domaine : Identifiez le nombre exact de membres directs et indirects du groupe Domain Admins et Enterprise Admins. La règle d'or est de ne pas dépasser 5 membres dans Domain Admins pour un AD standard. Vérifiez la dernière connexion de chaque compte (lastLogonTimestamp) — un compte DA inactif depuis 90 jours est un compte à désactiver immédiatement. Contrôlez que ces comptes ne sont jamais utilisés pour des tâches administratives courantes (navigation web, lecture d'emails).

2. Comptes de service avec SPN (Kerberoasting) : Listez tous les comptes avec un servicePrincipalName configuré qui ne sont pas des comptes machine. Ces comptes sont vulnérables au Kerberoasting : n'importe quel utilisateur du domaine peut demander un ticket de service chiffré avec le mot de passe du compte et tenter de le craquer hors ligne. Vérifiez l'ancienneté du mot de passe de chaque compte de service — un mot de passe de plus de 180 jours sur un compte avec SPN est un finding de niveau High. Migrez vers des gMSA (group Managed Service Accounts) quand c'est possible.

3. Délégation non contrainte (Unconstrained Delegation) : Identifiez tous les comptes et ordinateurs avec le flag TRUSTED_FOR_DELEGATION (bit 0x80000 de userAccountControl). Les contrôleurs de domaine ont ce flag par conception — tout autre objet avec cette configuration est suspect. La délégation non contrainte permet à un attaquant contrôlant une telle machine de capturer des TGT Kerberos de n'importe quel compte s'y authentifiant, y compris des Domain Admins.

4. Délégation contrainte avec Protocol Transition (S4U2Self) : La délégation contrainte avec Protocol Transition (TRUSTED_TO_AUTH_FOR_DELEGATION) est moins dangereuse que la délégation non contrainte, mais représente quand même un vecteur d'escalade si mal configurée. Vérifiez que les services autorisés (msDS-AllowedToDelegateTo) sont limités au strict nécessaire et que les comptes concernés ont des mots de passe forts et récents.

5. AS-REP Roasting (DONT_REQ_PREAUTH) : Les comptes avec la pré-authentification Kerberos désactivée (DONT_REQ_PREAUTH dans userAccountControl) permettent à n'importe qui de demander un AS-REP chiffré avec le mot de passe du compte et de le craquer hors ligne. Contrairement au Kerberoasting, cette attaque ne nécessite même pas d'être authentifié. Ces comptes doivent être identifiés et ce flag supprimé immédiatement sauf justification opérationnelle documentée.

6. Ancienneté des mots de passe : Requêtez les comptes utilisateurs actifs avec pwdLastSet antérieur à 180 jours. Pour les comptes de service, appliquez un seuil de 90 jours. L'absence de politique de rotation automatique des mots de passe est un finding récurrent. Les Fine-Grained Password Policies permettent d'appliquer des politiques différenciées selon la criticité des comptes.

7. GPO avec droits d'écriture non restreints : BloodHound détecte les utilisateurs ayant des droits GenericWrite, WriteDacl ou WriteOwner sur des GPO liées à des OU sensibles (Domain Controllers, Tier 0). Ces droits permettent une élévation de privilèges immédiate. Vérifiez également les GPO orphelines (liées mais plus appliquées) et les GPO avec des scripts de démarrage/connexion pointant vers des partages modifiables.

8. AdminSDHolder et protection SDProp : AdminSDHolder est un objet AD dont les ACL sont propagées automatiquement (toutes les 60 minutes par défaut via le processus SDProp) vers tous les membres des groupes protégés. Des ACL anormales sur AdminSDHolder se propagent donc silencieusement à tous les comptes privilégiés. Auditez les ACL d'AdminSDHolder et comparez-les à un référentiel propre. Vérifiez également les comptes avec le flag adminCount=1 qui ne devraient plus être dans des groupes protégés — leur ACL reste sous contrôle SDProp sans qu'on s'en rende compte.

9. SID History non vidée : L'attribut sIDHistory conserve les anciens SID d'un compte après migration entre domaines. Un compte avec un SID History correspondant à un groupe à privilèges de l'ancien domaine (ou pire, Domain Admins) hérite silencieusement de ces privilèges dans le domaine cible. Identifiez tous les comptes avec un sIDHistory non vide et évaluez si ces anciens SID confèrent des privilèges indésirables.

10. Rotation du KRBTGT : Le compte KRBTGT est utilisé pour chiffrer tous les tickets Kerberos du domaine. Sa compromission permet la création de Golden Tickets — des tickets forgés valides pour 10 ans. Vérifiez la date de dernière modification du mot de passe KRBTGT (pwdLastSet sur le compte CN=krbtgt). Un KRBTGT jamais renouvelé depuis la création du domaine est un finding critique. La rotation doit être effectuée deux fois de suite (pour invalider les tickets existants) avec un intervalle minimum de 10 heures entre les deux rotations.

11. Membres des groupes Domain Admins et Enterprise Admins : Auditez non seulement les membres directs mais aussi les membres imbriqués. Un groupe "IT-Admins" ajouté dans Domain Admins avec 50 membres n'est pas équivalent à 50 Domain Admins en apparence, mais l'est en pratique. Utilisez la récursion dans vos requêtes LDAP ou BloodHound pour obtenir le compte réel de comptes avec privilèges Domain Admin effectifs.

12. LAPS déployé sur les postes admin : Local Administrator Password Solution (LAPS ou Windows LAPS sur les systèmes récents) génère un mot de passe aléatoire unique pour le compte administrateur local de chaque machine. Sans LAPS, si un attaquant compromet une machine avec un mot de passe administrateur local partagé, il peut immédiatement se déplacer latéralement vers toutes les machines utilisant le même mot de passe. Vérifiez le taux de couverture LAPS (ms-Mcs-AdmPwdExpirationTime rempli) — l'objectif est 100 % des machines du domaine.

13. Tiering Model Active Directory respecté : Le Tiering Model segmente l'administration en trois niveaux d'isolation : Tier 0 (contrôleurs de domaine, AD), Tier 1 (serveurs applicatifs), Tier 2 (postes utilisateurs). Un compte Tier 0 ne doit jamais s'authentifier sur une machine Tier 1 ou 2, et réciproquement. Vérifiez que des politiques d'authentification (Authentication Policies, Silos) ou des GPO de restriction d'ouverture de session sont en place pour faire respecter cette segmentation. Un Tier 0 qui se connecte à des postes utilisateurs est un vecteur de compromission direct.

14. Comptes avec "Password Never Expires" : Listez tous les comptes actifs avec le flag DONT_EXPIRE_PASSWORD. Ces comptes échappent aux politiques de rotation et peuvent avoir des mots de passe vieux de plusieurs décennies. Pour les comptes humains, ce flag est généralement injustifié. Pour les comptes de service, chaque exception doit être documentée et compensée par une surveillance accrue.

Outils complémentaires pour un audit approfondi

Au-delà de BloodHound et PingCastle, plusieurs outils complètent la palette d'un auditeur AD.

ldapdomaindump : Cet outil Python génère des fichiers JSON et HTML structurés à partir d'une requête LDAP authentifiée. Il est particulièrement utile pour obtenir rapidement un inventaire de tous les utilisateurs, groupes, ordinateurs, GPO et relations de domaine dans un format lisible. La commande ldapdomaindump -u '[domain]\[user]' -p '[password]' [DC_IP] génère une série de fichiers exploitables immédiatement dans un navigateur web.

enum4linux-ng : Version modernisée de enum4linux, compatible avec les AD récents. Teste les sessions nulles, énumère les utilisateurs, groupes, partages, et politique de mots de passe. Utile en phase de reconnaissance pour confirmer les vecteurs d'attaque potentiels.

rpcclient : Outil du projet Samba permettant d'interagir avec les pipes RPC Windows. Commandes utiles : lsaenumsid (SID connus), lookupnames (résolution nom→SID), enumprivs (privilèges du compte courant). Particulièrement utile pour valider les informations obtenues par d'autres vecteurs.

Impacket (secretsdump.py) : Nécessite des privilèges Domain Admin. Permet d'extraire les hashs NTLM depuis le NTDS.dit (via DCSync) ou directement depuis la mémoire d'un DC. À utiliser uniquement dans le cadre d'un audit avec autorisation explicite pour tester la capacité de détection et valider la robustesse des mots de passe extraits. L'utilisation de secretsdump.py -just-dc [domain]/[admin]@[DC_IP] simule exactement ce qu'un attaquant ayant compromis un compte DA effectuerait.

ADRecon : Script PowerShell qui génère un rapport Excel complet de l'AD, couvrant les utilisateurs, groupes, machines, GPO, délégations, droits d'accès et bien plus. Très apprécié par les équipes internes pour sa lisibilité et son exhaustivité.

Invoke-ADSecurityAssessment (PSGallery) : Module PowerShell complémentaire couvrant des contrôles spécifiques non traités par PingCastle, notamment la configuration de Windows Defender Credential Guard, les paramètres LSA Protection, et l'audit des partages SYSVOL/NETLOGON.

Pour l'intégration de l'audit AD dans un SOC existant, la remontée des événements critiques vers un Wazuh SIEM/XDR permet une surveillance continue entre les audits ponctuels. Les Event IDs 4624, 4625, 4648, 4672, 4768, 4769 et 4771 sont particulièrement précieux pour la détection d'activités anormales Kerberos.

Structure du rapport d'audit

Un rapport d'audit AD de qualité professionnelle doit permettre à la fois à la direction générale de comprendre les risques en 5 minutes et à l'équipe technique de les corriger avec des instructions précises. Cette double lecture exige une structure rigoureuse.

Résumé exécutif (1-2 pages) : Score de risque global, nombre de findings par criticité, comparaison avec les standards de l'industrie (score PingCastle moyen observé sur des AD similaires), et les 3 actions prioritaires à mener dans les 30 jours. Pas de jargon technique, des métriques et des impacts business concrets ("Un attaquant ayant accès au réseau interne pourrait compromettre le domaine en moins de 2 heures via les 3 chemins BloodHound identifiés").

Tableau de findings (criticité CVSS) : Pour chaque finding, documentez l'identifiant unique, la description technique, la preuve (commande exécutée + résultat anonymisé), le score CVSS v3.1, le niveau de criticité (Critical/High/Medium/Low), et la référence MITRE ATT&CK si applicable. Le scoring CVSS permet une priorisation objective indépendante des perceptions subjectives.

Recommandations priorisées : Classez les recommandations en trois horizons temporels : actions immédiates (0-30 jours, Critiques et Highs), plan à moyen terme (30-90 jours, Mediums), et roadmap structurelle (90-365 jours, refonte du Tiering Model, LAPS, gMSA). Chaque recommandation doit inclure le niveau d'effort estimé, les prérequis techniques et les risques de la remédiation elle-même (certaines corrections AD peuvent casser des applications si mal exécutées).

Annexes techniques : Listez en annexe toutes les commandes exécutées, les horodatages, les comptes utilisés et les systèmes interrogés. Cette traçabilité est indispensable pour démontrer la portée exacte de l'audit et permettre sa reproduction lors d'un audit de suivi.

Remédiation prioritaire : les actions à impact immédiat

Face à un AD présentant de nombreuses vulnérabilités, la question de la priorisation est cruciale. Voici les actions à déclencher en priorité, classées par rapport risque/effort.

Rotation du KRBTGT (priorité absolue) : Si le KRBTGT n'a pas été renouvelé depuis plus d'un an, planifiez une double rotation dans les 72 heures. L'impact opérationnel est faible si bien planifié : informez les équipes, prévoyez une fenêtre de maintenance de 2 heures et exécutez la première rotation, attendez 10 heures minimum, puis exécutez la seconde rotation. Surveillez les authentifications Kerberos pendant 48 heures après. Cette action invalide tout Golden Ticket potentiellement en circulation.

Vidage du SID History : Sur les comptes identifiés avec un sIDHistory contenant des SID à privilèges, exécutez Set-ADUser [compte] -Remove @{sIDHistory=[ancien-SID]} après avoir validé qu'aucune application ne dépend de cet accès. Testez en environnement de pré-production si disponible, ou sur des comptes peu actifs en premier.

Déploiement de LAPS : Le déploiement de Windows LAPS (intégré à Windows depuis la mise à jour d'avril 2023) est désormais simplifié. Il ne nécessite plus d'agent supplémentaire sur les machines Windows 10/11 et Windows Server 2019+. La configuration se fait via GPO et Active Directory Schema (extension de schéma requise une seule fois). Priorisez le déploiement sur les machines Tier 0 et Tier 1 en premier.

Réduction du groupe Domain Admins : Identifiez et supprimez immédiatement les comptes inactifs ou injustifiés du groupe Domain Admins. Pour les comptes de service qui auraient été ajoutés "par facilité" à Domain Admins, créez des rôles avec délégation granulaire limitée aux seules permissions nécessaires. Cette opération nécessite une validation applicative soigneuse pour ne pas casser des services en production.

Activation du Tiering Model : Le Tiering Model Active Directory est la mesure structurelle la plus efficace à long terme. Son implémentation complète prend généralement 3 à 6 mois pour une organisation de taille moyenne, mais ses effets les plus critiques (isolation des comptes Tier 0) peuvent être déployés en quelques semaines. Commencez par créer des comptes administrateurs dédiés Tier 0 distincts des comptes Tier 1 et Tier 2, et interdire les connexions croisées via GPO.

Migration vers gMSA pour les comptes de service : Les group Managed Service Accounts gèrent automatiquement la rotation des mots de passe (tous les 30 jours par défaut) et ne permettent pas de connexions interactives. La migration nécessite que l'application supporte les gMSA (la majorité des applications Microsoft et des services Windows modernes le font). Cette migration élimine définitivement le risque Kerberoasting pour les comptes concernés.

Questions fréquentes sur l'audit Active Directory