Sécuriser Active Directory : Le Guide Définitif 2026

Active Directory reste, en 2026, le socle d'identité de plus de 90 % des entreprises du Fortune 500. Conçu en 1999 pour Windows 2000 Server, ce service d'annuaire centralise l'authentification, les autorisations et la gestion des ressources de l'ensemble du système d'information. Or, cette centralisation constitue précisément sa plus grande faiblesse : compromettre Active Directory revient à obtenir les clés de l'ensemble du royaume numérique. Les rapports de réponse à incident de CrowdStrike, Mandiant et Microsoft convergent sur un constat alarmant — dans 80 % des attaques par rançongiciel abouties, l'attaquant a transité par Active Directory pour atteindre la domination du domaine. Les groupes APT comme FIN7, Conti ou LockBit ont industrialisé l'exploitation des faiblesses structurelles d'AD. Face à cette réalité, sécuriser Active Directory n'est plus un projet optionnel mais une obligation de survie. Ce guide de référence couvre l'intégralité des mesures de durcissement, de la théorie aux commandes PowerShell opérationnelles, en passant par un plan de remédiation actionnable en 90 jours.

État des lieux : pourquoi Active Directory est si vulnérable

Avant de déployer des mesures de protection, il faut comprendre pourquoi Active Directory accumule autant de faiblesses exploitables. Les raisons sont multiples, profondément ancrées dans l'histoire du produit et dans les pratiques d'administration qui se sont sédimentées au fil des décennies.

L'héritage d'une architecture conçue pour la compatibilité

Active Directory a été conçu à une époque où la priorité absolue était la compatibilité ascendante et la facilité d'administration. Le protocole NTLM, maintenu pour la rétrocompatibilité avec des applications parfois vieilles de vingt ans, utilise des mécanismes de hachage (MD4) dont la faiblesse cryptographique est documentée depuis les années 2000. Kerberos, bien que nettement plus robuste, supporte encore par défaut le chiffrement RC4-HMAC — qui n'est autre qu'un wrapper autour du hash NT, rendant possible des attaques comme le Kerberoasting. Les niveaux fonctionnels de domaine et de forêt permettent de maintenir des contrôleurs de domaine sous Windows Server 2012 R2, voire 2008 R2, dans un même environnement que des serveurs 2022. Cette cohabitation impose le maintien de protocoles obsolètes et empêche l'activation de fonctionnalités de sécurité modernes.

L'architecture plate : absence de segmentation par défaut

Par défaut, Active Directory ne propose aucune segmentation des privilèges. Un administrateur de domaine dispose des mêmes droits sur les postes de travail, les serveurs applicatifs et les contrôleurs de domaine. Cette architecture plate signifie qu'un attaquant qui compromet un poste de travail sur lequel un administrateur s'est récemment connecté peut récupérer ses identifiants en mémoire (via Mimikatz ou des techniques équivalentes) et pivoter directement vers les contrôleurs de domaine. Il n'existe aucun cloisonnement natif entre les différents niveaux de criticité de l'infrastructure. Le modèle de tiering, que nous détaillerons plus loin, n'est pas implémenté par défaut — c'est une surcouche architecturale que les organisations doivent construire manuellement.

La prolifération des comptes à privilèges

Les audits PingCastle révèlent systématiquement le même problème : une prolifération incontrôlée de comptes disposant de privilèges élevés. Dans un domaine typique de 5 000 utilisateurs, on trouve fréquemment entre 50 et 200 membres directs ou indirects du groupe Domain Admins, alors que ce nombre devrait idéalement rester inférieur à 5. Les comptes de service configurés avec des mots de passe faibles et des SPN (Service Principal Name) exposés constituent des cibles de choix pour le Kerberoasting. Les comptes intégrés comme Administrator, krbtgt ou les comptes MSOL_ de synchronisation Azure AD Connector disposent de privilèges considérables et sont rarement surveillés avec la rigueur nécessaire.

L'absence de monitoring natif efficace

Les journaux d'événements Windows, bien que riches en informations, ne sont pas exploités par défaut de manière à détecter les attaques. La politique d'audit par défaut d'un contrôleur de domaine ne journalise pas les événements critiques comme les modifications d'ACL sur les objets sensibles (event 5136), les demandes de tickets Kerberos suspectes (event 4769) ou les tentatives de réplication malveillantes (event 4662 avec les droits DS-Replication-Get-Changes-All). Sans SIEM correctement configuré, sans baseline comportementale, et sans alertes sur les indicateurs d'attaque, une compromission d'AD peut passer inaperçue pendant des mois — le temps médian de détection observé par Mandiant étant de 21 jours en 2025.

Les délégations de permissions non maîtrisées

La granularité du modèle de permissions d'Active Directory est à double tranchant. D'un côté, elle permet des délégations fines. De l'autre, elle crée une complexité qui rend l'audit quasi impossible sans outils spécialisés. Les ACE (Access Control Entries) héritées, les permissions accordées à des groupes imbriqués sur plusieurs niveaux, les droits GenericAll ou WriteDACL accordés par erreur à des comptes non privilégiés — tout cela constitue des chemins d'attaque que des outils comme BloodHound cartographient méthodiquement. Une étude de Specterops montre que dans 95 % des environnements AD audités, il existe au moins un chemin d'attaque permettant à un utilisateur standard d'atteindre Domain Admin sans exploiter la moindre vulnérabilité technique.

Les 10 attaques les plus courantes sur Active Directory

Comprendre les attaques est le prérequis indispensable à une défense efficace. Voici les dix techniques les plus fréquemment observées lors des tests d'intrusion et des incidents de sécurité, avec pour chacune le principe, l'impact et les mesures de mitigation essentielles.

1. Kerberoasting

Le Kerberoasting exploite le mécanisme de tickets de service Kerberos (TGS). Tout utilisateur authentifié du domaine — même un simple utilisateur sans aucun privilège — peut demander un ticket de service (TGS) pour n'importe quel compte disposant d'un SPN (Service Principal Name). La partie chiffrée de ce ticket est chiffrée avec le hash du mot de passe du compte de service. L'attaquant exporte ces tickets et les soumet à un cracking offline avec Hashcat ou John the Ripper. Si le mot de passe est faible (ce qui est fréquemment le cas pour les comptes de service configurés il y a des années et jamais modifiés depuis), l'attaquant obtient les identifiants en clair en quelques minutes — parfois en quelques secondes avec un GPU moderne.

L'impact du Kerberoasting est considérable car les comptes de service disposent souvent de privilèges élevés : accès aux bases de données SQL, aux serveurs Exchange, aux applications métier critiques, et parfois même membership dans le groupe Domain Admins (une pratique malheureusement courante dans les environnements legacy). Les statistiques de tests d'intrusion montrent que dans 60 % des environnements, au moins un compte de service Kerberoastable dispose d'un mot de passe crackable en moins d'une heure.

La mitigation repose sur plusieurs mesures complémentaires : l'utilisation de mots de passe de 25+ caractères générés aléatoirement pour tous les comptes de service, la migration vers les gMSA (Group Managed Service Accounts) qui utilisent des mots de passe de 240 caractères automatiquement rotés, la désactivation du chiffrement RC4 au profit d'AES256 (qui augmente le coût computationnel du cracking d'un facteur 10 000+), et le monitoring des demandes TGS anormales via l'événement 4769.

2. Golden Ticket

L'attaque Golden Ticket représente le Graal de la compromission AD et la forme ultime de persistance dans un environnement Active Directory. En obtenant le hash NTLM du compte krbtgt — ce qui est possible via une attaque DCSync, un accès physique à un contrôleur de domaine, ou l'extraction d'une sauvegarde ntds.dit — l'attaquant peut forger des TGT (Ticket-Granting Tickets) arbitraires. Ces TGT forgés peuvent être créés pour n'importe quel utilisateur (existant ou fictif), avec n'importe quels groupes de sécurité (incluant Domain Admins, Enterprise Admins, Schema Admins), et avec une durée de validité de 10 ans par défaut.

La puissance du Golden Ticket réside dans le fait que les tickets forgés sont indistinguables des tickets légitimes par les contrôleurs de domaine. Le KDC ne vérifie que la signature du TGT avec le hash krbtgt — si la signature est valide, le ticket est accepté sans question. L'attaquant peut donc accéder à n'importe quelle ressource du domaine, créer de nouveaux comptes admin, modifier les GPO, exfiltrer des données, et déployer des rançongiciels, le tout avec des tickets qui semblent parfaitement légitimes.

La remédiation contre les Golden Tickets est complexe et doit être exécutée avec précision. La mesure principale consiste à réinitialiser le mot de passe du compte krbtgt deux fois consécutivement (la seconde réinitialisation invalide l'historique des clés). Il faut également réduire la durée de vie maximale des tickets TGT de 10 heures (par défaut) à 4 heures via GPO, et monitorer les anomalies dans les événements 4769 (demandes TGS avec des TGT dont la durée de vie est anormalement longue). Microsoft Defender for Identity détecte les Golden Tickets en comparant les informations du PAC (Privilege Attribute Certificate) avec les données réelles dans AD.

3. DCSync

L'attaque DCSync abuse du protocole de réplication d'Active Directory (MS-DRSR, Microsoft Directory Replication Service Remote Protocol). Ce protocole est utilisé légitimement par les contrôleurs de domaine pour synchroniser les données AD entre eux. Un attaquant qui dispose des droits DS-Replication-Get-Changes et DS-Replication-Get-Changes-All sur l'objet racine du domaine peut simuler un contrôleur de domaine légitime et demander la réplication de tous les attributs sensibles — incluant les hashes NTLM de tous les comptes utilisateurs, les clés Kerberos, et le hash du compte krbtgt qui permet la création de Golden Tickets.

Par défaut, les groupes Domain Admins, Enterprise Admins, Administrators, et le compte SYSTEM des contrôleurs de domaine disposent de ces droits de réplication. Cependant, il n'est pas rare de trouver ces droits accordés à d'autres comptes : le compte Azure AD Connect (MSOL_), des comptes de service de sauvegarde AD, ou des comptes auxquels des droits ont été délégués par erreur. L'attaque DCSync est implémentée dans Mimikatz (commande lsadump::dcsync) et dans Impacket (secretsdump.py), ce qui la rend triviale à exécuter une fois les droits obtenus.

La détection de DCSync repose sur la surveillance de l'événement 4662 avec les GUID de propriétés de réplication spécifiques (1131f6aa-9c07-11d1-f79f-00c04fc2dcd2 pour DS-Replication-Get-Changes et 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2 pour DS-Replication-Get-Changes-All). L'alerte doit se déclencher lorsque ces événements sont émis depuis une machine qui n'est pas un contrôleur de domaine — c'est l'indicateur le plus fiable d'une attaque DCSync en cours. La prévention passe par l'audit régulier des ACL sur l'objet racine du domaine pour identifier tout compte non légitime disposant de ces droits.

4. Pass-the-Hash

Le Pass-the-Hash (PtH) est l'une des techniques de mouvement latéral les plus anciennes et les plus persistantes dans les environnements Windows. Elle exploite une caractéristique fondamentale du protocole NTLM : l'authentification ne nécessite pas le mot de passe en clair — le hash NT (MD4 du mot de passe Unicode) suffit. Un attaquant qui parvient à extraire le hash NT d'un compte (via un dump du processus LSASS avec Mimikatz, l'extraction de la base SAM locale, une attaque DCSync, ou la lecture d'un fichier NTDS.dit) peut s'authentifier sur n'importe quel service acceptant NTLM sans jamais connaître le mot de passe en clair.

La particularité du Pass-the-Hash est qu'il fonctionne même si le mot de passe est extrêmement complexe — la complexité du mot de passe n'a aucune importance puisque c'est le hash qui est directement utilisé pour l'authentification. L'attaquant injecte le hash dans un processus d'authentification NTLM via des outils comme Mimikatz (sekurlsa::pth), Impacket (psexec.py, wmiexec.py, smbexec.py), ou CrackMapExec. Si le compte compromis est un administrateur local sur d'autres postes (ce qui est le cas par défaut quand le mot de passe de l'administrateur local est le même partout — d'où l'importance critique de LAPS), l'attaquant peut pivoter latéralement de poste en poste jusqu'à atteindre un système où un administrateur de domaine a une session active.

La mitigation du Pass-the-Hash nécessite une approche multicouche : le déploiement de Credential Guard (qui protège le processus LSASS via la virtualisation et empêche l'extraction des hashes en mémoire), la restriction de l'authentification NTLM au profit de Kerberos, l'utilisation du groupe Protected Users (qui interdit l'authentification NTLM pour ses membres), le déploiement de LAPS (qui rend chaque mot de passe d'administrateur local unique), et la désactivation de WDigest (qui empêche le stockage de credentials en clair en mémoire). La combinaison de ces mesures réduit drastiquement la surface d'attaque du Pass-the-Hash.

5. NTLM Relay

Le NTLM Relay est une attaque man-in-the-middle qui intercepte une authentification NTLM légitime et la redirige en temps réel vers un service cible différent. Contrairement au Pass-the-Hash qui nécessite d'extraire le hash, le NTLM Relay travaille avec le flux d'authentification en cours — l'attaquant n'a pas besoin de connaître le hash, il se contente de relayer les messages d'authentification entre la victime et le service cible.

Des outils comme ntlmrelayx (du framework Impacket) et Responder automatisent l'intégralité de la chaîne d'attaque. Les variantes modernes sont particulièrement redoutables : le relay vers LDAP permet de modifier des objets AD (créer des comptes, modifier des ACL, configurer RBCD), le relay vers AD CS (ESC8) permet d'obtenir des certificats d'authentification, et le relay vers MSSQL permet l'exécution de commandes sur les serveurs de bases de données. Les techniques de coercion d'authentification comme PetitPotam (qui force un contrôleur de domaine à s'authentifier vers une machine contrôlée par l'attaquant) rendent cette attaque particulièrement dangereuse car elles permettent de relayer l'authentification d'un DC lui-même.

La protection contre le NTLM Relay exige l'activation du SMB signing sur tous les systèmes (pas seulement les DC), du LDAP signing et du LDAP channel binding sur les contrôleurs de domaine, et de l'EPA (Extended Protection for Authentication) sur tous les services web internes incluant IIS, Exchange, AD CS, et AD FS. La désactivation complète de NTLM, bien qu'idéale et recommandée par Microsoft, reste impossible dans de nombreux environnements à cause d'applications legacy — mais elle doit rester l'objectif à terme.

6. AS-REP Roasting

L'AS-REP Roasting cible les comptes pour lesquels la pré-authentification Kerberos est désactivée (attribut DONT_REQUIRE_PREAUTH dans userAccountControl). La pré-authentification est un mécanisme de sécurité qui oblige l'utilisateur à prouver son identité (en chiffrant un timestamp avec son hash) avant que le KDC ne lui délivre un TGT. Lorsque ce mécanisme est désactivé, le KDC répond directement avec un AS-REP contenant une partie chiffrée avec le hash du mot de passe de l'utilisateur — sans aucune vérification d'identité préalable.

Un attaquant peut donc demander un AS-REP pour n'importe quel compte avec DONT_REQUIRE_PREAUTH sans fournir la moindre preuve d'identité, puis soumettre la partie chiffrée à un cracking offline avec Hashcat (mode 18200) ou John the Ripper. Cette attaque est implémentée dans Rubeus (asreproast), Impacket (GetNPUsers.py), et de nombreux autres outils. Bien que moins fréquente que le Kerberoasting — car peu de comptes ont ce flag activé dans un environnement bien configuré — elle est triviale à exécuter et doit être systématiquement vérifiée lors de tout audit. Le correctif est simple et sans risque de régression : activer la pré-authentification Kerberos sur tous les comptes sans exception, puis monitorer toute tentative de désactivation via l'événement 4738 (modification de compte utilisateur).

7. AD CS Abuse (ESC1-ESC15)

Les attaques sur AD CS (Active Directory Certificate Services) représentent l'un des développements les plus significatifs en matière de sécurité AD depuis 2021. La recherche "Certified Pre-Owned" de SpecterOps a révélé un continent entier de vulnérabilités dans l'infrastructure PKI d'Active Directory. Les vulnérabilités ESC1 à ESC15 exploitent les misconfigurations des templates de certificats, des permissions sur les autorités de certification, et des mécanismes d'enrollment.

ESC1 est la plus dangereuse et la plus fréquemment exploitée : lorsqu'un template de certificat possède le flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT, l'utilisateur qui demande le certificat peut spécifier librement le Subject Alternative Name (SAN). Cela signifie qu'un utilisateur standard peut demander un certificat client pour le compte Administrator ou tout autre compte à privilèges, puis utiliser ce certificat pour s'authentifier en tant que cet utilisateur. L'opération prend moins de 30 secondes avec des outils comme Certipy.

ESC8 permet le relai d'une authentification NTLM vers le endpoint web d'enrollment de la CA. Un attaquant qui parvient à capturer une authentification NTLM (via un document Office piégé, un partage SMB malveillant, ou une attaque de type Coerced Authentication) peut la relayer vers le service web de la CA pour obtenir un certificat au nom de la victime. Si la victime est un contrôleur de domaine (via PetitPotam ou PrinterBug), l'attaquant obtient un certificat machine pour le DC, ce qui lui permet d'extraire le hash NTLM du compte machine du DC et, de là, d'exécuter une attaque DCSync.

La persistance via les certificats est particulièrement insidieuse : un certificat client a une durée de validité par défaut d'un an, et la réinitialisation du mot de passe de l'utilisateur n'invalide pas le certificat. L'attaquant peut donc maintenir son accès pendant des mois après la découverte de l'incident si les certificats compromis ne sont pas explicitement révoqués.

8. DCShadow

DCShadow est une technique de persistance avancée qui enregistre temporairement une machine compromise comme contrôleur de domaine légitime, injecte des modifications dans AD via le protocole de réplication, puis se désenregistre. Les modifications injectées (ajout d'un SIDHistory, modification d'ACL, création de backdoors) sont répliquées vers tous les vrais contrôleurs de domaine et deviennent indistinguables de modifications légitimes. La détection repose sur le monitoring des enregistrements SPN de type GC/ et E3514235-4B06-11D1-AB04-00C04FC2DCD2 sur des machines non-DC.

9. Skeleton Key

Skeleton Key est un malware injecté dans le processus LSASS des contrôleurs de domaine. Une fois actif, il ajoute un mot de passe maître (par défaut "mimikatz") qui fonctionne pour n'importe quel compte du domaine, en parallèle du mot de passe légitime. L'utilisateur continue de s'authentifier normalement avec son vrai mot de passe, mais l'attaquant peut utiliser le mot de passe squelette pour se connecter à n'importe quel compte. La mitigation inclut Credential Guard sur les DC (Windows Server 2016+), le monitoring de l'intégrité de LSASS, et la détection de patches en mémoire.

10. ACL Abuse

L'abus de listes de contrôle d'accès (ACL) exploite les permissions excessives accordées à des objets Active Directory. C'est l'une des techniques d'escalade de privilèges les plus redoutables car elle ne nécessite l'exploitation d'aucune vulnérabilité technique — elle se contente d'utiliser les mécanismes légitimes d'AD avec des permissions qui ont été mal configurées.

Les droits les plus dangereux sont les suivants. GenericAll accorde un contrôle total sur l'objet cible, permettant de réinitialiser son mot de passe, modifier ses attributs, ou l'ajouter à n'importe quel groupe. WriteDACL permet de modifier les permissions de l'objet et donc de s'accorder n'importe quel droit supplémentaire. WriteOwner permet de prendre la propriété de l'objet, ce qui donne ensuite le droit de modifier ses ACL. ForceChangePassword permet de réinitialiser le mot de passe d'un utilisateur sans connaître l'ancien. AddMember sur un groupe à privilèges (Domain Admins, Enterprise Admins) permet de s'y ajouter directement.

BloodHound excelle dans la cartographie de ces chemins d'attaque en construisant un graphe de toutes les relations entre objets AD. Il peut identifier des chaînes d'escalade complexes impliquant plusieurs sauts : l'utilisateur A possède WriteDACL sur le groupe B, le groupe B possède GenericAll sur le compte C, le compte C est membre du groupe D qui possède AddMember sur Domain Admins. Ces chaînes sont invisibles sans outil d'analyse spécialisé. La remédiation exige un audit complet des ACL avec des outils comme Adalanche ou BloodHound, suivi de la suppression méthodique des permissions excessives — un processus qui peut prendre des semaines dans les environnements complexes mais qui est absolument indispensable.

Le Tiering Model : fondation de la sécurité Active Directory

Le modèle de tiering (ou modèle de cloisonnement administratif) est la pierre angulaire de toute stratégie sérieuse de sécurisation d'Active Directory. Publié initialement par Microsoft sous le nom d'Enhanced Security Administrative Environment (ESAE), puis simplifié dans le cadre du Privileged Access Strategy, ce modèle divise l'infrastructure en trois niveaux de confiance avec des frontières strictes entre eux.

Les trois tiers

Tier	Périmètre	Exemples de ressources	Criticité
Tier 0	Identité et contrôle du domaine	Contrôleurs de domaine, AD CS, Azure AD Connect, PAM, serveurs PKI, ADFS	Critique — compromission = game over
Tier 1	Serveurs et applications	Serveurs de fichiers, SQL Server, Exchange, serveurs d'impression, serveurs applicatifs	Élevée — données métier sensibles
Tier 2	Postes de travail et utilisateurs	Postes Windows, laptops, périphériques, comptes utilisateurs standards	Standard — surface d'attaque la plus exposée

Le principe fondamental : les credentials ne descendent jamais

La règle cardinale du tiering est que les identifiants d'un tier supérieur ne doivent jamais être exposés à un tier inférieur. Un administrateur Tier 0 ne se connecte jamais à un serveur Tier 1 ou à un poste Tier 2 avec ses identifiants Tier 0. Un administrateur Tier 1 ne se connecte jamais à un poste Tier 2 avec ses identifiants Tier 1. Cette règle empêche le scénario classique où un attaquant compromet un poste utilisateur, extrait les identifiants d'un admin qui s'y est connecté, et pivote vers les contrôleurs de domaine.

Privileged Access Workstations (PAW)

Les PAW sont des postes d'administration dédiés, durcis, et réservés exclusivement à l'administration des ressources de leur tier. Une PAW Tier 0 ne sert qu'à administrer les contrôleurs de domaine et les systèmes d'identité. Elle n'a pas accès à Internet, ne reçoit pas d'email, et n'exécute aucune application métier. Le durcissement d'une PAW inclut :

• Installation minimale de Windows (pas d'Office, pas de navigateur sauf pour les consoles d'administration)
• Credential Guard activé pour protéger LSASS
• Application Whitelisting via AppLocker ou WDAC (Windows Defender Application Control)
• BitLocker avec TPM + PIN
• Accès réseau restreint aux seuls systèmes du tier correspondant
• Authentification multifacteur obligatoire (smart card ou FIDO2)
• Pas de droits d'administration locale pour l'utilisateur connecté (administration via un compte séparé)

Implémentation pratique du tiering avec les GPO

Le cloisonnement des tiers s'appuie sur des GPO restrictives qui contrôlent les types de logon autorisés pour chaque catégorie de comptes.

# Créer les groupes de tiering
New-ADGroup -Name "Tier0-Admins" -GroupScope Global -GroupCategory Security -Path "OU=Tier0,OU=Admin,DC=corp,DC=local"
New-ADGroup -Name "Tier1-Admins" -GroupScope Global -GroupCategory Security -Path "OU=Tier1,OU=Admin,DC=corp,DC=local"
New-ADGroup -Name "Tier2-Admins" -GroupScope Global -GroupCategory Security -Path "OU=Tier2,OU=Admin,DC=corp,DC=local"

# Créer les OU de tiering
New-ADOrganizationalUnit -Name "Tier0-Systems" -Path "DC=corp,DC=local"
New-ADOrganizationalUnit -Name "Tier1-Servers" -Path "DC=corp,DC=local"
New-ADOrganizationalUnit -Name "Tier2-Workstations" -Path "DC=corp,DC=local"

# Déplacer les contrôleurs de domaine dans l'OU Tier 0 (après vérification)
# Get-ADDomainController -Filter * | ForEach-Object { Move-ADObject $_.ComputerObjectDN -TargetPath "OU=Tier0-Systems,DC=corp,DC=local" }

Les GPO de restriction de logon doivent être configurées comme suit :

# GPO Tier0 — Deny logon pour Tier1 et Tier2 admins sur les DC
# Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > User Rights Assignment
# "Deny log on locally" : Tier1-Admins, Tier2-Admins
# "Deny log on through Remote Desktop Services" : Tier1-Admins, Tier2-Admins
# "Deny access to this computer from the network" : Tier2-Admins

# GPO Tier2 — Deny logon pour Tier0 et Tier1 admins sur les workstations
# "Deny log on locally" : Tier0-Admins, Tier1-Admins
# "Deny log on through Remote Desktop Services" : Tier0-Admins, Tier1-Admins
# "Deny log on as a batch job" : Tier0-Admins, Tier1-Admins
# "Deny log on as a service" : Tier0-Admins, Tier1-Admins

Red Forest (ESAE) et son évolution

Le modèle Red Forest, ou ESAE (Enhanced Security Administrative Environment), poussait le tiering à l'extrême en créant une forêt d'administration dédiée pour le Tier 0. Cette forêt isolée, sans trust bidirectionnel avec la forêt de production, hébergeait exclusivement les comptes d'administration Tier 0 et les PAW. La forêt ESAE disposait de ses propres contrôleurs de domaine, sa propre PKI, et son propre monitoring — complètement isolée du réseau de production. L'idée fondamentale était que même si l'attaquant compromettait intégralement la forêt de production, il ne pouvait pas atteindre les identifiants d'administration stockés dans la forêt ESAE.

Microsoft a officiellement déprécié ESAE en 2021, le jugeant trop complexe et coûteux à maintenir pour la majorité des organisations. Les retours d'expérience ont montré que le coût de gestion d'une deuxième forêt AD (infrastructure, licences, personnel, procédures) était prohibitif pour les entreprises de taille moyenne. De plus, les attaques ciblant les trusts entre forêts (même unidirectionnels) ont démontré que l'isolation n'était pas aussi hermétique qu'espéré dans la pratique.

Le modèle de remplacement, le Privileged Access Strategy publié par Microsoft en 2021, conserve les principes du tiering mais propose une implémentation plus pragmatique. Il s'appuie sur Entra ID (Azure AD) comme plan de contrôle, Conditional Access pour l'application contextuelle des politiques, et des solutions PAM (Privileged Access Management) comme Microsoft Identity Manager (MIM) avec PAM ou des solutions tierces (CyberArk, BeyondTrust, Delinea) pour le JIT Access. L'accent est mis sur la sécurisation des endpoints d'administration (PAW) et la réduction du temps d'exposition des privilèges plutôt que sur l'isolation physique des forêts. Cependant, les principes fondamentaux du tiering restent inchangés et pleinement pertinents — seule la méthode d'implémentation évolue.

Hardening des comptes à privilèges

Les comptes à privilèges sont les cibles prioritaires des attaquants. Chaque mesure de durcissement appliquée à ces comptes multiplie la difficulté pour l'adversaire. Voici les mécanismes de protection disponibles, du plus simple au plus avancé.

Le groupe Protected Users

Introduit avec Windows Server 2012 R2, le groupe Protected Users applique automatiquement des restrictions de sécurité aux comptes qui en sont membres :

• Interdiction d'authentification NTLM — seul Kerberos est autorisé
• Interdiction du chiffrement DES et RC4 dans la pré-authentification Kerberos — seul AES est utilisé
• Interdiction de la délégation Kerberos (unconstrained et constrained)
• Durée de vie du TGT réduite à 4 heures (non configurable, non renouvelable)
• Pas de mise en cache des credentials sur les postes (pas de hash en mémoire LSASS après déconnexion)

# Ajouter les comptes d'administration au groupe Protected Users
Add-ADGroupMember -Identity "Protected Users" -Members "admin-t0-dupont","admin-t0-martin","admin-t0-bernard"

# Vérifier les membres
Get-ADGroupMember -Identity "Protected Users" | Select-Object Name, SamAccountName, DistinguishedName

# Attention : ne pas ajouter les comptes de service (ils ne pourront plus s'authentifier via NTLM)
# Vérifier qu'aucun service ne dépend de NTLM avant l'ajout
Get-ADUser -Filter {MemberOf -eq (Get-ADGroup "Protected Users").DistinguishedName} |
    Select-Object Name, Enabled, LastLogonDate

Attention critique : N'ajoutez jamais le compte krbtgt, les comptes de service, ou les comptes d'ordinateur au groupe Protected Users. Les comptes de service qui dépendent de NTLM ou de la délégation Kerberos cesseront de fonctionner. Testez rigoureusement dans un environnement de pré-production.

AdminSDHolder et SDProp

AdminSDHolder est un mécanisme de protection automatique qui s'exécute toutes les 60 minutes (via le processus SDProp). Il réinitialise les ACL de tous les objets protégés (membres des groupes privilégiés) pour correspondre aux ACL définies sur l'objet CN=AdminSDHolder,CN=System. Ce mécanisme empêche les modifications non autorisées des permissions sur les comptes sensibles. Cependant, il peut devenir un vecteur d'attaque si un attaquant modifie l'objet AdminSDHolder lui-même — toute ACE ajoutée sera propagée à tous les comptes protégés.

# Lister les objets protégés par AdminSDHolder (adminCount = 1)
Get-ADObject -Filter {adminCount -eq 1} -Properties adminCount, whenChanged |
    Select-Object Name, ObjectClass, adminCount, whenChanged |
    Sort-Object ObjectClass

# Vérifier les ACL de l'objet AdminSDHolder
$adminSDHolder = "CN=AdminSDHolder,CN=System," + (Get-ADDomain).DistinguishedName
(Get-Acl "AD:\$adminSDHolder").Access |
    Where-Object { $_.IdentityReference -notlike "NT AUTHORITY\*" -and $_.IdentityReference -notlike "BUILTIN\*" } |
    Select-Object IdentityReference, ActiveDirectoryRights, AccessControlType

# Nettoyer les objets orphelins avec adminCount=1 (plus membres de groupes protégés)
$protectedGroups = @("Domain Admins","Enterprise Admins","Schema Admins","Administrators","Account Operators","Backup Operators","Print Operators","Server Operators","Replicator")
$allProtected = $protectedGroups | ForEach-Object { Get-ADGroupMember $_ -Recursive } | Select-Object -Unique -ExpandProperty DistinguishedName
Get-ADObject -Filter {adminCount -eq 1 -and ObjectClass -eq "user"} | Where-Object { $_.DistinguishedName -notin $allProtected } |
    ForEach-Object {
        Write-Host "Orphelin: $($_.Name) - adminCount=1 mais plus dans un groupe protégé"
        # Set-ADObject $_ -Clear adminCount  # Décommenter pour nettoyer
    }

LAPS (Local Administrator Password Solution)

LAPS résout le problème critique des mots de passe d'administrateur local identiques sur tous les postes. Sans LAPS, compromettre le mot de passe d'administrateur local d'un seul poste permet un mouvement latéral immédiat vers tous les postes du domaine. Windows LAPS (intégré à Windows Server 2025 et Windows 11 23H2+) remplace le LAPS legacy avec des améliorations significatives : chiffrement des mots de passe dans AD, support d'Azure AD/Entra ID, rotation automatique après utilisation, et historique des mots de passe.

# Vérifier si Windows LAPS est activé
Get-LapsADPasswordExpirationPolicy

# Configurer LAPS via GPO ou PowerShell
# 1. Mettre à jour le schéma AD pour Windows LAPS
Update-LapsADSchema

# 2. Configurer les permissions de lecture
Set-LapsADReadPasswordPermission -Identity "OU=Workstations,DC=corp,DC=local" -AllowedPrincipals "CORP\Tier2-HelpDesk"
Set-LapsADReadPasswordPermission -Identity "OU=Servers,DC=corp,DC=local" -AllowedPrincipals "CORP\Tier1-ServerAdmins"

# 3. Configurer les permissions de réinitialisation
Set-LapsADResetPasswordPermission -Identity "OU=Workstations,DC=corp,DC=local" -AllowedPrincipals "CORP\Tier2-HelpDesk"

# 4. GPO Settings (Computer Configuration > Administrative Templates > System > LAPS)
# - Configure password backup directory: Active Directory
# - Password Settings: Complexity=Large letters+small+numbers+specials, Length=20, Age=30
# - Enable password encryption: Enabled
# - Configure authorized password decryptors: CORP\Tier2-HelpDesk

# Récupérer le mot de passe LAPS d'un poste
Get-LapsADPassword -Identity "WORKSTATION01" -AsPlainText

Group Managed Service Accounts (gMSA)

Les gMSA sont la solution définitive au problème des comptes de service avec des mots de passe statiques. Le contrôleur de domaine génère et fait tourner automatiquement un mot de passe de 240 caractères aléatoires toutes les 30 jours. Les gMSA éliminent le risque de Kerberoasting sur des mots de passe faibles et suppriment la gestion manuelle des mots de passe de service.

# Prérequis : créer la clé racine KDS (attendre 10h en production, ou forcer immédiatement en lab)
Add-KdsRootKey -EffectiveImmediately  # Lab uniquement
# Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10))  # Production

# Créer un gMSA
New-ADServiceAccount -Name "gMSA-SQLService" `
    -DNSHostName "gmsa-sqlservice.corp.local" `
    -PrincipalsAllowedToRetrieveManagedPassword "SQL-Servers-Group" `
    -KerberosEncryptionType AES256 `
    -ServicePrincipalNames "MSSQLSvc/sql01.corp.local:1433","MSSQLSvc/sql01.corp.local"

# Installer le gMSA sur le serveur cible
Install-ADServiceAccount -Identity "gMSA-SQLService"

# Tester
Test-ADServiceAccount -Identity "gMSA-SQLService"
# Résultat attendu : True

# Configurer le service pour utiliser le gMSA
# Dans Services.msc : Log On As = CORP\gMSA-SQLService$ (avec le $ final, pas de mot de passe)

# Inventorier les comptes de service à migrer vers gMSA
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, PasswordLastSet, PasswordNeverExpires |
    Select-Object Name, @{N='SPN';E={$_.ServicePrincipalName -join ';'}}, PasswordLastSet, PasswordNeverExpires |
    Sort-Object PasswordLastSet

JEA (Just Enough Administration)

JEA permet de créer des endpoints PowerShell restreints qui n'exposent que les commandes strictement nécessaires à chaque rôle. Un administrateur de helpdesk peut réinitialiser des mots de passe et déverrouiller des comptes sans disposer de droits Domain Admin. JEA fonctionne via des fichiers de configuration de session (.pssc) et des fichiers de capacités de rôle (.psrc).

# Créer un fichier de capacités de rôle pour le helpdesk
$roleCapabilities = @{
    Path = "C:\JEA\RoleCapabilities\HelpDeskRole.psrc"
}
New-PSRoleCapabilityFile @roleCapabilities
# Éditer le fichier pour définir les commandes autorisées :
# VisibleCmdlets = @(
#     'Unlock-ADAccount',
#     @{ Name = 'Set-ADAccountPassword'; Parameters = @{ Name = 'Identity' }, @{ Name = 'Reset' }, @{ Name = 'NewPassword' } },
#     'Get-ADUser',
#     'Search-ADAccount'
# )
# VisibleFunctions = 'TabExpansion2'

# Créer la configuration de session
$sessionConfig = @{
    Path = "C:\JEA\HelpDeskEndpoint.pssc"
    SessionType = 'RestrictedRemoteServer'
    RunAsVirtualAccount = $true
    RoleDefinitions = @{
        'CORP\HelpDesk-Operators' = @{ RoleCapabilities = 'HelpDeskRole' }
    }
    TranscriptDirectory = 'C:\JEA\Transcripts'
}
New-PSSessionConfigurationFile @sessionConfig

# Enregistrer l'endpoint JEA
Register-PSSessionConfiguration -Name HelpDeskEndpoint -Path "C:\JEA\HelpDeskEndpoint.pssc" -Force

# Utilisation par le helpdesk
Enter-PSSession -ComputerName DC01 -ConfigurationName HelpDeskEndpoint

JIT Access (Just-In-Time)

Le JIT Access accorde les privilèges uniquement au moment où ils sont nécessaires, pour une durée limitée. Microsoft Identity Manager (MIM) PAM permet d'implémenter le JIT pour Active Directory : un administrateur demande une élévation temporaire, l'approbation est accordée (manuellement ou automatiquement), et l'appartenance au groupe privilégié est ajoutée avec une durée d'expiration (TTL de groupe, disponible à partir du niveau fonctionnel Windows Server 2016). À l'expiration du TTL, le membership est automatiquement supprimé.

# Vérifier le niveau fonctionnel de la forêt (2016 minimum requis pour les TTL de groupe)
(Get-ADForest).ForestMode

# Activer la fonctionnalité Privileged Access Management (PAM)
Enable-ADOptionalFeature -Identity "Privileged Access Management Feature" `
    -Scope ForestOrConfigurationSet -Target "corp.local" -Confirm:$false

# Ajouter un membre temporaire à un groupe (TTL de 4 heures)
$ttl = New-TimeSpan -Hours 4
Add-ADGroupMember -Identity "Domain Admins" -Members "admin-t0-dupont" -MemberTimeToLive $ttl

# Vérifier les memberships temporaires
Get-ADGroup "Domain Admins" -Properties member -ShowMemberTimeToLive

# Script de demande JIT simplifié
function Request-TemporaryAdmin {
    param(
        [string]$AdminAccount,
        [string]$TargetGroup = "Domain Admins",
        [int]$DurationMinutes = 60,
        [string]$Justification
    )

    # Logger la demande
    $logEntry = "[$(Get-Date)] JIT Request: $AdminAccount -> $TargetGroup for $DurationMinutes min. Justification: $Justification"
    Add-Content -Path "C:\Logs\JIT-Requests.log" -Value $logEntry

    # Ajouter avec TTL
    $ttl = New-TimeSpan -Minutes $DurationMinutes
    Add-ADGroupMember -Identity $TargetGroup -Members $AdminAccount -MemberTimeToLive $ttl

    Write-Host "Accès temporaire accordé à $AdminAccount dans $TargetGroup pour $DurationMinutes minutes."
    Write-Host "Expiration automatique à : $((Get-Date).AddMinutes($DurationMinutes))"
}

Sécurisation de Kerberos

Kerberos est le protocole d'authentification principal d'Active Directory depuis Windows 2000. Sa sécurité dépend de la robustesse de sa configuration — et les paramètres par défaut sont loin d'être optimaux. Voici les mesures de durcissement essentielles.

Forcer le chiffrement AES256 et désactiver RC4

Le chiffrement RC4-HMAC utilise directement le hash NT du mot de passe comme clé de chiffrement, ce qui rend le Kerberoasting trivial. AES256 utilise un dérivé cryptographique du mot de passe, rendant le cracking significativement plus coûteux en ressources (facteur 10 000+ selon les benchmarks Hashcat). La migration vers AES256 exclusif est l'une des mesures les plus impactantes pour la sécurité Kerberos.

# Étape 1 : Inventorier les comptes qui supportent uniquement RC4
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes | Where-Object {
    $_.'msDS-SupportedEncryptionTypes' -band 0x4 -and  # RC4 supporté
    -not ($_.'msDS-SupportedEncryptionTypes' -band 0x18)  # AES non supporté
} | Select-Object Name, SamAccountName, @{N='EncTypes';E={$_.'msDS-SupportedEncryptionTypes'}}

# Étape 2 : Configurer AES256 sur tous les comptes utilisateurs
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes | ForEach-Object {
    Set-ADUser $_ -KerberosEncryptionType AES128,AES256
}

# Étape 3 : Configurer AES256 sur tous les comptes de service
Get-ADUser -Filter {ServicePrincipalName -like "*"} | ForEach-Object {
    Set-ADUser $_ -KerberosEncryptionType AES256
    # Important : réinitialiser le mot de passe pour générer les clés AES
    # (les clés AES ne sont générées qu'au changement de mot de passe)
}

# Étape 4 : Configurer la GPO pour désactiver RC4
# Computer Configuration > Policies > Windows Settings > Security Settings >
# Local Policies > Security Options >
# "Network security: Configure encryption types allowed for Kerberos"
# Cocher uniquement : AES128_HMAC_SHA1, AES256_HMAC_SHA1, Future encryption types

# Étape 5 : Surveiller les échecs d'authentification post-migration
# Event 4771 (Kerberos pre-authentication failed) avec status 0x18 (KDC_ERR_PREAUTH_FAILED)
Get-WinEvent -FilterHashtable @{LogName='Security';ID=4771} -MaxEvents 100 |
    ForEach-Object { [xml]$xml = $_.ToXml(); $xml.Event.EventData.Data } |
    Where-Object { $_.Name -eq 'Status' -and $_.'#text' -eq '0x18' }

Point d'attention : La désactivation de RC4 peut casser des applications legacy qui ne supportent pas AES. Procédez par phases : d'abord activer AES sur tous les comptes, puis auditer pendant 2-4 semaines les authentifications RC4 restantes (événement 4768 avec le type de chiffrement 0x17), et enfin désactiver RC4 une fois que toutes les dépendances ont été migrées.

Contrôler la délégation Kerberos

La délégation Kerberos permet à un service d'agir au nom d'un utilisateur pour accéder à d'autres ressources. Trois types de délégation existent, avec des niveaux de risque très différents :

Type de délégation	Risque	Recommandation
Unconstrained Delegation	Critique — le service stocke les TGT des utilisateurs en mémoire	Éliminer complètement. Migrer vers constrained ou RBCD
Constrained Delegation	Modéré — limité à des services spécifiques, mais protocol transition peut être abusé	Acceptable avec contrôle strict des SPNs autorisés
Resource-Based Constrained Delegation (RBCD)	Modéré — configuré côté ressource, plus flexible	Préférer à la constrained delegation classique, mais surveiller les modifications

# Identifier tous les serveurs avec Unconstrained Delegation
Get-ADComputer -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation, ServicePrincipalName |
    Where-Object { $_.DistinguishedName -notlike "*Domain Controllers*" } |
    Select-Object Name, DNSHostName, @{N='SPNs';E={$_.ServicePrincipalName -join '; '}}

# Identifier les comptes utilisateurs avec Unconstrained Delegation
Get-ADUser -Filter {TrustedForDelegation -eq $true} -Properties TrustedForDelegation |
    Select-Object Name, SamAccountName, Enabled

# Identifier les comptes avec Constrained Delegation
Get-ADObject -Filter {msDS-AllowedToDelegateTo -like "*"} -Properties msDS-AllowedToDelegateTo |
    Select-Object Name, ObjectClass, @{N='DelegateTo';E={$_.'msDS-AllowedToDelegateTo' -join '; '}}

# Identifier les objets avec RBCD configuré
Get-ADComputer -Filter {PrincipalsAllowedToDelegateToAccount -like "*"} -Properties PrincipalsAllowedToDelegateToAccount |
    Select-Object Name, @{N='AllowedFrom';E={$_.PrincipalsAllowedToDelegateToAccount}}

# Marquer les comptes sensibles pour empêcher la délégation
# (les comptes Tier 0 ne doivent JAMAIS pouvoir être délégués)
Get-ADGroupMember "Domain Admins" -Recursive | ForEach-Object {
    Set-ADUser $_ -AccountNotDelegated $true
}
Set-ADUser "Administrator" -AccountNotDelegated $true

Durcir le compte krbtgt

Le compte krbtgt est le compte le plus critique d'Active Directory. Son hash NT sert à signer tous les TGT du domaine. Sa compromission permet la création de Golden Tickets. Le durcissement du krbtgt inclut :

# Vérifier l'ancienneté du mot de passe krbtgt
Get-ADUser krbtgt -Properties PasswordLastSet |
    Select-Object Name, PasswordLastSet, @{N='AgeDays';E={(New-TimeSpan -Start $_.PasswordLastSet).Days}}

# Réinitialiser le mot de passe krbtgt (DEUX FOIS, espacé de 12-24h)
# Première réinitialisation :
Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString (New-Guid).Guid -AsPlainText -Force)
Write-Host "Première réinitialisation krbtgt effectuée à $(Get-Date). Attendre 12-24h avant la seconde."

# ATTENDRE que la réplication AD soit complète + que les tickets existants expirent (10h par défaut)
# Puis seconde réinitialisation :
# Set-ADAccountPassword -Identity krbtgt -Reset -NewPassword (ConvertTo-SecureString (New-Guid).Guid -AsPlainText -Force)

# Fréquence recommandée : tous les 180 jours (ANSSI recommande 90 jours)
# Automatiser via une tâche planifiée avec alerting

Sécurisation NTLM

NTLM est le protocole d'authentification legacy d'Active Directory. Malgré les recommandations répétées de Microsoft pour le désactiver, il persiste dans la quasi-totalité des environnements à cause d'applications anciennes, de configurations incorrectes ou de méconnaissance. Chaque authentification NTLM est une opportunité pour l'attaquant — via Pass-the-Hash, NTLM Relay, ou credential theft.

Comprendre les versions de NTLM

Version	Sécurité	Hash utilisé	Vulnérabilité
LM	Inexistante	LM hash (DES)	Crackable en secondes, case insensitive, découpé en blocs de 7 chars
NTLMv1	Très faible	NT hash (MD4)	Vulnérable au relay, challenge prévisible, crackable rapidement
NTLMv2	Faible à modérée	NT hash + HMAC-MD5	Vulnérable au relay (sans EPA), résistant au cracking offline

Désactiver NTLMv1 et auditer NTLMv2

# Étape 1 : Configurer le niveau d'authentification LM minimal
# GPO : Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
# "Network security: LAN Manager authentication level" = "Send NTLMv2 response only. Refuse LM & NTLM"

# Étape 2 : Activer l'audit NTLM sur les DC
# GPO : Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
# "Network security: Restrict NTLM: Audit NTLM authentication in this domain" = "Enable all"
# "Network security: Restrict NTLM: Audit Incoming NTLM Traffic" = "Enable auditing for all accounts"

# Étape 3 : Analyser le trafic NTLM
# Événement 8004 dans le log "Microsoft-Windows-NTLM/Operational"
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 500 |
    Where-Object { $_.Id -eq 8004 } |
    ForEach-Object {
        [PSCustomObject]@{
            Time = $_.TimeCreated
            User = $_.Properties[0].Value
            Domain = $_.Properties[1].Value
            Workstation = $_.Properties[2].Value
            ServerName = $_.Properties[4].Value
        }
    } | Group-Object User, ServerName | Sort-Object Count -Descending | Select-Object -First 20

# Étape 4 : Créer une liste d'exceptions pour les applications legacy
# GPO : "Network security: Restrict NTLM: Add server exceptions in this domain"
# Ajouter les serveurs qui nécessitent encore NTLM

# Étape 5 : Bloquer NTLM progressivement
# "Network security: Restrict NTLM: NTLM authentication in this domain" = "Deny all accounts"
# (après validation que toutes les applications fonctionnent sans NTLM)

Extended Protection for Authentication (EPA)

L'EPA (aussi appelé Channel Binding) lie l'authentification NTLM au canal TLS sous-jacent, empêchant le NTLM Relay sur les services HTTPS. L'EPA doit être activée sur tous les services web internes : IIS, Exchange (OWA, EWS, ActiveSync), AD FS, et AD CS (le endpoint web d'enrollment est un vecteur ESC8 classique).

# Activer EPA sur IIS (Exchange, AD CS, etc.)
# Nécessite le module IISAdministration
Import-Module IISAdministration
$sites = Get-IISSite
foreach ($site in $sites) {
    # Set-IISConfigSection pour activer extendedProtection
    Write-Host "Site: $($site.Name) - Vérifier EPA manuellement via IIS Manager"
}

# Pour AD CS Web Enrollment (critique pour contrer ESC8)
# IIS Manager > Site > Authentication > Windows Authentication > Advanced Settings
# Extended Protection = "Required"
# Enable Kernel-mode authentication = Unchecked

# Pour Exchange (OWA, EWS, ActiveSync, Autodiscover, MAPI)
# Utiliser le script Microsoft : ExchangeExtendedProtectionManagement.ps1
# https://aka.ms/ExchangeEPDoc

LDAP Signing et Channel Binding

Le LDAP signing empêche l'interception et la modification des requêtes LDAP. Le LDAP channel binding empêche le NTLM relay vers LDAP/LDAPS. Ces deux protections doivent être activées sur tous les contrôleurs de domaine.

# Configurer LDAP Signing (requis)
# GPO sur les DC : Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options
# "Domain controller: LDAP server signing requirements" = "Require signing"

# Configurer LDAP Signing côté client
# "Network security: LDAP client signing requirements" = "Require signing"

# Configurer LDAP Channel Binding
# Registre sur chaque DC :
# HKLM\System\CurrentControlSet\Services\NTDS\Parameters
# LdapEnforceChannelBinding = 2 (Always)
Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\NTDS\Parameters" -Name "LdapEnforceChannelBinding" -Value 2 -Type DWord

# Vérifier le paramètre actuel
Get-ItemProperty -Path "HKLM:\System\CurrentControlSet\Services\NTDS\Parameters" -Name "LdapEnforceChannelBinding" -ErrorAction SilentlyContinue

# Surveiller les clients qui ne supportent pas le signing
# Événement 2889 dans le log Directory Service sur les DC
Get-WinEvent -FilterHashtable @{LogName='Directory Service';ID=2889} -MaxEvents 50 -ErrorAction SilentlyContinue |
    ForEach-Object {
        [xml]$xml = $_.ToXml()
        [PSCustomObject]@{
            Time = $_.TimeCreated
            ClientIP = ($xml.Event.EventData.Data | Where-Object Name -eq 'IPAddress').'#text'
            User = ($xml.Event.EventData.Data | Where-Object Name -eq 'Identity').'#text'
        }
    } | Group-Object ClientIP | Sort-Object Count -Descending

GPO de durcissement : Security Baselines et CIS Benchmarks

Les Group Policy Objects (GPO) sont le mécanisme principal de déploiement des paramètres de sécurité dans un environnement Active Directory. Plutôt que de réinventer la roue, les organisations doivent s'appuyer sur des baselines de sécurité éprouvées et les adapter à leur contexte.

Les référentiels de sécurité

Référentiel	Éditeur	Portée	Niveau de détail
Microsoft Security Baselines	Microsoft	Windows Server, Windows Client, Edge, Office	GPO pré-configurées, prêtes à l'emploi
CIS Benchmarks	Center for Internet Security	Tous OS, applications, cloud	Niveaux L1 (essentiels) et L2 (renforcés)
Guide ANSSI AD	ANSSI	Recommandations spécifiques AD	Points de contrôle avec niveaux de conformité

Politiques de mot de passe renforcées (Fine-Grained Password Policies)

Les Fine-Grained Password Policies (FGPP) permettent d'appliquer des politiques de mot de passe différentes selon les groupes d'utilisateurs, sans créer de domaines séparés.

# Créer une politique de mot de passe renforcée pour les admins Tier 0
New-ADFineGrainedPasswordPolicy -Name "Tier0-AdminPasswordPolicy" `
    -DisplayName "Politique mot de passe Tier 0" `
    -Precedence 10 `
    -ComplexityEnabled $true `
    -MinPasswordLength 20 `
    -MinPasswordAge "1.00:00:00" `
    -MaxPasswordAge "90.00:00:00" `
    -PasswordHistoryCount 24 `
    -LockoutThreshold 3 `
    -LockoutDuration "00:30:00" `
    -LockoutObservationWindow "00:30:00" `
    -ReversibleEncryptionEnabled $false

# Appliquer la politique au groupe Tier0-Admins
Add-ADFineGrainedPasswordPolicySubject -Identity "Tier0-AdminPasswordPolicy" -Subjects "Tier0-Admins"

# Créer une politique pour les comptes de service
New-ADFineGrainedPasswordPolicy -Name "ServiceAccount-PasswordPolicy" `
    -DisplayName "Politique mot de passe comptes de service" `
    -Precedence 20 `
    -ComplexityEnabled $true `
    -MinPasswordLength 30 `
    -MaxPasswordAge "180.00:00:00" `
    -PasswordHistoryCount 48 `
    -LockoutThreshold 0 `
    -ReversibleEncryptionEnabled $false

# Vérifier quelle politique s'applique à un utilisateur
Get-ADUserResultantPasswordPolicy -Identity "admin-t0-dupont"

# Lister toutes les FGPP
Get-ADFineGrainedPasswordPolicy -Filter * |
    Select-Object Name, Precedence, MinPasswordLength, MaxPasswordAge, LockoutThreshold |
    Sort-Object Precedence

Politiques d'audit avancées

Les politiques d'audit par défaut de Windows sont insuffisantes pour détecter les attaques AD. La configuration avancée (Advanced Audit Policy Configuration) permet un contrôle granulaire des événements journalisés. Voici la configuration recommandée pour les contrôleurs de domaine :

# Configurer via GPO : Computer Configuration > Windows Settings > Security Settings >
# Advanced Audit Policy Configuration > Audit Policies

# Catégorie : Account Logon
# - Audit Credential Validation : Success, Failure
# - Audit Kerberos Authentication Service : Success, Failure
# - Audit Kerberos Service Ticket Operations : Success, Failure

# Catégorie : Account Management
# - Audit Computer Account Management : Success, Failure
# - Audit Security Group Management : Success, Failure
# - Audit User Account Management : Success, Failure

# Catégorie : DS Access
# - Audit Directory Service Access : Success, Failure
# - Audit Directory Service Changes : Success, Failure

# Catégorie : Logon/Logoff
# - Audit Logon : Success, Failure
# - Audit Logoff : Success
# - Audit Special Logon : Success
# - Audit Other Logon/Logoff Events : Success, Failure

# Catégorie : Object Access
# - Audit SAM : Success, Failure
# - Audit Certification Services : Success, Failure

# Catégorie : Policy Change
# - Audit Audit Policy Change : Success, Failure
# - Audit Authentication Policy Change : Success

# Catégorie : Privilege Use
# - Audit Sensitive Privilege Use : Success, Failure

# Catégorie : System
# - Audit Security System Extension : Success, Failure
# - Audit System Integrity : Success, Failure

# Vérifier la configuration d'audit actuelle
auditpol /get /category:* | Out-File "C:\Audit\current-audit-policy.txt"

# Augmenter la taille des logs de sécurité
wevtutil sl Security /ms:4194304000  # 4 GB
wevtutil sl "Microsoft-Windows-NTLM/Operational" /ms:104857600  # 100 MB

Paramètres GPO critiques pour le durcissement

Au-delà des baselines, certains paramètres GPO spécifiques ont un impact direct sur la résistance aux attaques AD :

# 1. Désactiver le stockage LM hash
# "Network security: Do not store LAN Manager hash value on next password change" = Enabled

# 2. Empêcher l'énumération anonyme des comptes et partages
# "Network access: Do not allow anonymous enumeration of SAM accounts" = Enabled
# "Network access: Do not allow anonymous enumeration of SAM accounts and shares" = Enabled
# "Network access: Restrict anonymous access to Named Pipes and Shares" = Enabled

# 3. Activer SMB Signing
# "Microsoft network server: Digitally sign communications (always)" = Enabled
# "Microsoft network client: Digitally sign communications (always)" = Enabled

# 4. Désactiver LLMNR et NBT-NS (empêche le poisoning réseau)
# GPO : Computer Configuration > Administrative Templates > Network > DNS Client
# "Turn off multicast name resolution" = Enabled
# Désactiver NetBIOS via DHCP Option 001 ou registre :
# HKLM\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\*
# NetbiosOptions = 2 (Disable)

# 5. Activer Credential Guard sur les serveurs et PAW
# GPO : Computer Configuration > Administrative Templates > System > Device Guard
# "Turn On Virtualization Based Security" = Enabled
# "Credential Guard Configuration" = "Enabled with UEFI lock"

# 6. Restreindre le WDigest (empêche le stockage de credentials en clair en mémoire)
# Registre : HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest
# UseLogonCredential = 0
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigest" -Name "UseLogonCredential" -Value 0 -Type DWord

# 7. Configurer AppLocker ou WDAC sur les PAW et les DC
# Bloquer les binaires non signés, les scripts non autorisés, PowerShell constrained mode

Monitoring et détection : surveiller Active Directory en temps réel

La sécurité d'Active Directory ne se limite pas à la prévention. La détection rapide des attaques est tout aussi critique — le temps entre la compromission initiale et la détection détermine l'étendue des dégâts. Un monitoring efficace repose sur trois piliers : les événements critiques à collecter, les règles de corrélation SIEM, et les leurres (honey tokens).

Les événements Windows critiques pour la détection des attaques AD

Event ID	Source	Attaque détectée	Seuil d'alerte
4624	Security	Logon réussi — type 3 (réseau), type 10 (RDP) depuis des sources inhabituelles	Logon Tier 0 depuis un poste non-PAW
4625	Security	Échec de logon — brute force, password spraying	> 10 échecs/min pour un même compte ou > 5 comptes depuis la même IP
4672	Security	Attribution de privilèges spéciaux — logon admin	Tout logon admin sur un système non Tier 0
4768	Security	Demande TGT (AS-REQ) — type de chiffrement RC4 ou DES suspect	Encryption type 0x17 (RC4) quand AES est déployé
4769	Security	Demande TGS — Kerberoasting (multiples TGS pour des SPN différents)	> 5 demandes TGS depuis le même utilisateur en 1 minute
4771	Security	Échec pré-authentification Kerberos — AS-REP Roasting	Échecs pour des comptes sans PREAUTH requis
4662	Security	Opération sur objet AD — DCSync (GUID réplication)	Opérations DS-Replication-Get-Changes depuis une machine non-DC
5136	Security	Modification d'objet AD — changement d'ACL, modification SPN, AdminSDHolder tampering	Modification de groupes protégés, AdminSDHolder, GPO critiques
4720	Security	Création de compte utilisateur	Création hors processus RH normal
4728/4732/4756	Security	Ajout de membre à un groupe (global/local/universel)	Ajout à Domain Admins, Enterprise Admins, etc.
1102	Security	Suppression du log de sécurité — anti-forensics	Toute occurrence = alerte critique immédiate

Règles de détection SIEM

Voici les règles de corrélation essentielles à implémenter dans votre SIEM (Splunk, Microsoft Sentinel, Elastic Security, QRadar, etc.) :

# Règle 1 : Détection de Kerberoasting
# Logique : Multiple demandes TGS (4769) avec chiffrement RC4 (0x17) depuis le même utilisateur
# Splunk SPL :
# index=wineventlog EventCode=4769 Ticket_Encryption_Type=0x17 Service_Name!="krbtgt" Service_Name!="*$"
# | bin _time span=5m
# | stats count dc(Service_Name) as unique_services by _time, Account_Name, Client_Address
# | where unique_services > 3

# Règle 2 : Détection de DCSync
# Logique : Event 4662 avec droits de réplication depuis une IP non-DC
# Splunk SPL :
# index=wineventlog EventCode=4662
# (Properties="*1131f6aa-9c07-11d1-f79f-00c04fc2dcd2*" OR Properties="*1131f6ad-9c07-11d1-f79f-00c04fc2dcd2*")
# | where NOT match(SubjectUserName, "\$$")
# | lookup dc_list ip AS SubjectLogonId OUTPUT is_dc
# | where is_dc!="true"

# Règle 3 : Détection de Golden Ticket
# Logique : TGT avec durée de vie anormale ou émis sans AS-REQ correspondant
# Event 4769 avec Ticket_Encryption_Type=0x17 et sans 4768 précédent

# Règle 4 : Password Spraying
# Logique : Échecs 4625 avec status 0xC000006A (bad password) pour multiple comptes depuis la même source
# Splunk SPL :
# index=wineventlog EventCode=4625 Status=0xC000006A
# | bin _time span=10m
# | stats count dc(TargetUserName) as targeted_users by _time, IpAddress
# | where targeted_users > 10

# Règle 5 : Modification de groupe privilégié
# Logique : Event 4728/4732/4756 ciblant un groupe à haut privilège
# index=wineventlog (EventCode=4728 OR EventCode=4732 OR EventCode=4756)
# (TargetUserName="Domain Admins" OR TargetUserName="Enterprise Admins" OR TargetUserName="Administrators"
#  OR TargetUserName="Schema Admins" OR TargetUserName="Account Operators" OR TargetUserName="Backup Operators")
# | table _time, SubjectUserName, MemberName, TargetUserName, EventCode

Honey Tokens et Canary Objects

Les honey tokens sont des objets AD leurres conçus pour déclencher une alerte lorsqu'ils sont accédés ou utilisés. Aucun utilisateur légitime ne devrait jamais interagir avec ces objets — toute activité est donc un indicateur de compromission fiable avec un taux de faux positifs proche de zéro.

# Créer un compte honey token qui ressemble à un admin
New-ADUser -Name "svc_sqlbackup" -SamAccountName "svc_sqlbackup" `
    -UserPrincipalName "svc_sqlbackup@corp.local" `
    -DisplayName "SQL Backup Service Account" `
    -Description "Service account for SQL automated backups - DO NOT DISABLE" `
    -Path "OU=Service Accounts,DC=corp,DC=local" `
    -AccountPassword (ConvertTo-SecureString "H0n3yT0k3n!2026Complex#" -AsPlainText -Force) `
    -Enabled $true `
    -PasswordNeverExpires $true `
    -CannotChangePassword $true

# Ajouter un SPN attractif pour le Kerberoasting
Set-ADUser "svc_sqlbackup" -ServicePrincipalNames @{Add="MSSQLSvc/sql-backup.corp.local:1433"}

# Créer un faux objet ordinateur qui ressemble à un honeypot
New-ADComputer -Name "YOURDC03" -SamAccountName "YOURDC03$" `
    -Description "Domain Controller - Backup Site" `
    -Path "OU=Tier0-Systems,DC=corp,DC=local" `
    -Enabled $true

# Configurer l'audit SACL sur ces objets pour détecter tout accès
$honeyToken = Get-ADUser "svc_sqlbackup"
$acl = Get-Acl "AD:\$($honeyToken.DistinguishedName)"
$auditRule = New-Object System.DirectoryServices.ActiveDirectoryAuditRule(
    [System.Security.Principal.SecurityIdentifier]"S-1-1-0",  # Everyone
    [System.DirectoryServices.ActiveDirectoryRights]::ReadProperty,
    [System.Security.AccessControl.AuditFlags]::Success,
    [System.DirectoryServices.ActiveDirectorySecurityInheritance]::None
)
$acl.AddAuditRule($auditRule)
Set-Acl "AD:\$($honeyToken.DistinguishedName)" $acl

# Alerte SIEM sur toute interaction avec les honey tokens
# Event 4624 (logon) ou 4769 (TGS request) pour svc_sqlbackup
# Event 4662 (DS Access) pour l'objet YOURDC03

Les honey tokens les plus efficaces sont ceux qui imitent des cibles attractives pour les attaquants : comptes de service avec SPN (pour piéger le Kerberoasting), faux comptes d'administration avec des noms crédibles, fichiers leurres dans des partages réseau (passwords.xlsx dans un partage IT), et entrées DNS pointant vers des honeypots. Le secret est de les rendre suffisamment réalistes pour être tentants, tout en s'assurant qu'aucun processus légitime ne les touche.

Microsoft Defender for Identity (MDI)

Microsoft Defender for Identity (anciennement Azure ATP) est la solution de détection d'attaques AD la plus avancée du marché. Déployé sous forme de capteurs installés directement sur les contrôleurs de domaine, MDI analyse le trafic réseau et les logs Windows en temps réel pour détecter les techniques d'attaque connues : Kerberoasting, DCSync, Pass-the-Hash, Golden Ticket, reconnaissance LDAP, password spraying, et de nombreuses autres. MDI utilise le machine learning pour établir des baselines comportementales et détecter les anomalies — par exemple, un utilisateur qui se connecte soudainement à un serveur qu'il n'a jamais accédé auparavant, ou un volume anormal de requêtes Kerberos.

Les alertes MDI sont classées par sévérité (faible, moyenne, élevée) et regroupées en phases de la kill chain : reconnaissance, mouvement latéral, persistance, et exfiltration. L'intégration native avec Microsoft Sentinel permet la corrélation avec d'autres sources de données (endpoints, email, cloud) pour une détection holistique. Pour les organisations qui utilisent la suite Microsoft 365 Defender, MDI s'intègre dans le portail unifié Microsoft Defender XDR, offrant une vue consolidée de toutes les menaces d'identité.

Les alternatives à MDI incluent CrowdStrike Falcon Identity Protection, Tenable Identity Exposure (anciennement Alsid), et Semperis Directory Services Protector. Chacune offre des capacités de détection et de réponse spécifiques aux attaques AD, avec des approches architecturales différentes (agent-based vs agentless, cloud vs on-premises). L'important est de déployer au moins une solution de détection spécialisée AD — les SIEM génériques, même bien configurés, ne disposent pas de la logique métier nécessaire pour détecter les attaques AD les plus sophistiquées.

Outils d'audit Active Directory

L'audit régulier est indispensable pour identifier les faiblesses avant que les attaquants ne les exploitent. Plusieurs outils d'audit Active Directory se distinguent par leur efficacité et leur complémentarité.

PingCastle

PingCastle est l'outil de référence pour l'évaluation rapide de la sécurité AD. Développé par Vincent Le Toux, il produit un rapport HTML complet avec un score de risque global, détaillé en quatre catégories : Stale Objects, Privileged Accounts, Trusts, et Anomalies. Son exécution ne nécessite pas de privilèges d'administration — un compte utilisateur standard suffit pour la majorité des vérifications.

# Exécuter PingCastle en mode healthcheck
.\PingCastle.exe --healthcheck --server corp.local

# Exécuter en mode scanner pour des vérifications spécifiques
.\PingCastle.exe --scanner aclcheck --server corp.local
.\PingCastle.exe --scanner antivirus --server corp.local
.\PingCastle.exe --scanner laps_bitlocker --server corp.local
.\PingCastle.exe --scanner smb --server corp.local
.\PingCastle.exe --scanner spooler --server corp.local  # Print Spooler (PrintNightmare)
.\PingCastle.exe --scanner zerologon --server corp.local

# Exécuter un rapport de consolidation multi-domaines
.\PingCastle.exe --healthcheck --server corp.local --level Full
.\PingCastle.exe --healthcheck --server child.corp.local --level Full
.\PingCastle.exe --hc-conso  # Consolide les rapports

Les points clés évalués par PingCastle incluent : l'ancienneté du mot de passe krbtgt, les comptes avec pré-authentification désactivée, les comptes avec mots de passe qui n'expirent jamais, les ACL excessives, les trusts dangereux, les objets obsolètes, les GPO mal configurées, la présence de LAPS, le niveau fonctionnel du domaine, et des dizaines d'autres indicateurs. L'objectif est d'atteindre un score de 0 — chaque point représente un risque concret.

Purple Knight

Purple Knight, développé par Semperis, est un outil gratuit d'évaluation de la sécurité AD qui exécute plus de 150 indicateurs de sécurité regroupés en catégories : Account Security, AD Delegation, AD Infrastructure, Group Policy, et Kerberos. Il se distingue par sa capacité à détecter les indicateurs d'exposition (IOE) et les indicateurs de compromission (IOC).

# Purple Knight s'exécute via une interface graphique ou en ligne de commande
.\PurpleKnight.exe -DomainName corp.local -OutputPath C:\Audits\PK-Report
# Nécessite un compte avec des droits de lecture AD (pas d'admin requis)

BloodHound

BloodHound cartographie les chemins d'attaque dans Active Directory en analysant les relations entre les objets : appartenances aux groupes, sessions actives, ACL, délégations, et relations de confiance. Sa base de données Neo4j (ou la nouvelle version avec PostgreSQL dans BloodHound CE) permet des requêtes Cypher puissantes pour identifier les chemins les plus courts vers Domain Admin.

# Collecte des données avec SharpHound (le collecteur officiel de BloodHound)
.\SharpHound.exe -c All --zipfilename bloodhound-corp.zip

# Ou avec le collecteur Python (depuis une machine Linux)
# bloodhound-python -c All -d corp.local -u audit-user -p 'AuditP@ss2026!' -ns 10.0.0.1

# Requêtes Cypher utiles dans BloodHound
# Chemin le plus court vers Domain Admin
# MATCH p=shortestPath((u:User {name:"JDUPONT@CORP.LOCAL"})-[*1..]->(g:Group {name:"DOMAIN ADMINS@CORP.LOCAL"})) RETURN p

# Tous les utilisateurs Kerberoastables
# MATCH (u:User) WHERE u.hasspn=true RETURN u.name, u.serviceprincipalnames

# Comptes avec Unconstrained Delegation (hors DC)
# MATCH (c:Computer {unconstraineddelegation:true}) WHERE NOT c.name CONTAINS "DC" RETURN c.name

# Sessions actives sur les DC (danger si un utilisateur non-admin a une session)
# MATCH (c:Computer)-[:MemberOf*1..]->(g:Group {name:"DOMAIN CONTROLLERS@CORP.LOCAL"})
# MATCH (u:User)-[:HasSession]->(c) RETURN u.name, c.name

Adalanche

Adalanche est un outil open source qui analyse les permissions et les chemins d'attaque dans AD, avec une interface web interactive. Il se distingue par sa facilité d'utilisation et sa capacité à visualiser graphiquement les chemins d'escalade de privilèges sans nécessiter de base de données externe.

# Collecte des données
.\adalanche.exe collect -d corp.local

# Lancer l'interface web d'analyse
.\adalanche.exe analyze
# Ouvrir http://localhost:8080 dans le navigateur

# Adalanche identifie automatiquement :
# - Les chemins d'attaque vers Domain Admin
# - Les ACL dangereuses
# - Les délégations excessives
# - Les comptes de service vulnérables

ADRecon

ADRecon génère un rapport Excel complet de la configuration AD, incluant les utilisateurs, groupes, ordinateurs, GPO, DNS, trusts, ACL, et bien plus. C'est un outil d'inventaire exhaustif plutôt qu'un analyseur de risques, mais il fournit la matière première indispensable à tout audit.

# Exécuter ADRecon avec sortie Excel
.\ADRecon.ps1 -OutputType XLSX -DomainController dc01.corp.local

# Exécuter avec des modules spécifiques
.\ADRecon.ps1 -Collect Users,Groups,Computers,GPOs,LAPS -OutputType XLSX

Testimo

Testimo est un module PowerShell qui exécute une batterie de tests automatisés sur Active Directory et génère un rapport HTML. Il vérifie la réplication, la santé DNS, la configuration des DC, les bonnes pratiques de sécurité, et la conformité aux standards.

# Installer Testimo
Install-Module -Name Testimo -Force

# Exécuter tous les tests
Invoke-Testimo -ReturnResults | Out-File C:\Audits\testimo-results.txt

# Exécuter des catégories spécifiques
Invoke-Testimo -Sources DCDiag, DnsForwarding, DnsScavengingForPrimaryZones, DnsZonesAging, SysVolDFSR

# Tests de réplication AD
Invoke-Testimo -Sources DCDiag -TestName Replications

Outil	Type	Licence	Points forts	Fréquence recommandée
PingCastle	Évaluation de risque	Gratuit (usage interne)	Score global, rapport actionnable, exécution rapide	Mensuel
Purple Knight	Évaluation de sécurité	Gratuit	150+ indicateurs, détection IOC/IOE	Trimestriel
BloodHound	Chemins d'attaque	Open source (CE) / Commercial (Enterprise)	Cartographie visuelle, requêtes Cypher	Trimestriel
Adalanche	Analyse des permissions	Open source	Interface web, pas de dépendance externe	Mensuel
ADRecon	Inventaire	Open source	Rapport Excel exhaustif	Trimestriel
Testimo	Tests de santé	Open source	Tests automatisés, intégration CI/CD	Hebdomadaire

AD CS : sécuriser les services de certificats Active Directory

Active Directory Certificate Services (AD CS) est devenu l'un des vecteurs d'attaque les plus exploités depuis la publication de la recherche "Certified Pre-Owned" par SpecterOps en 2021. Les vulnérabilités ESC1 à ESC15 permettent, dans de nombreux environnements, d'obtenir un certificat client pour n'importe quel utilisateur du domaine, y compris Domain Admin, en quelques secondes. La sécurisation d'AD CS est devenue une priorité absolue.

Les vulnérabilités ESC critiques

ESC	Vecteur	Impact	Remédiation
ESC1	Template avec SAN libre (CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT)	Certificat pour n'importe quel utilisateur	Retirer le flag, exiger l'approbation du CA Manager
ESC2	Template avec EKU Any Purpose ou SubCA	Certificat universel, création de CA subordonnée rogue	Restreindre les EKU aux usages nécessaires
ESC3	Template d'enrollment agent mal configuré	Enrollment au nom d'un autre utilisateur	Restreindre les permissions d'enrollment agent
ESC4	Permissions excessives sur les templates	Modification du template pour introduire ESC1/ESC2	Auditer et restreindre les ACL sur tous les templates
ESC6	Flag EDITF_ATTRIBUTESUBJECTALTNAME2 sur la CA	Tout certificat peut inclure un SAN arbitraire	Retirer le flag sur la CA
ESC7	Permissions excessives sur la CA elle-même	Gestion complète de la CA	Restreindre ManageCA et ManageCertificates
ESC8	NTLM relay vers le web enrollment HTTP	Certificat via relay NTLM	Activer EPA, désactiver HTTP, forcer HTTPS

Audit des templates AD CS

# Lister tous les templates de certificats publiés
Get-ADObject -SearchBase "CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local" `
    -Filter {objectClass -eq "pKICertificateTemplate"} -Properties * |
    Select-Object Name, @{N='Flags';E={$_.'msPKI-Certificate-Name-Flag'}},
    @{N='EnrollmentFlag';E={$_.'msPKI-Enrollment-Flag'}},
    @{N='EKU';E={$_.'pKIExtendedKeyUsage' -join '; '}}

# Identifier les templates vulnérables ESC1
# Flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT = 1 dans msPKI-Certificate-Name-Flag
Get-ADObject -SearchBase "CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local" `
    -Filter {objectClass -eq "pKICertificateTemplate"} -Properties * |
    Where-Object { $_.'msPKI-Certificate-Name-Flag' -band 1 } |
    Select-Object Name, @{N='NameFlag';E={$_.'msPKI-Certificate-Name-Flag'}}

# Vérifier le flag EDITF_ATTRIBUTESUBJECTALTNAME2 sur la CA (ESC6)
certutil -getreg policy\EditFlags
# Si le flag inclut EDITF_ATTRIBUTESUBJECTALTNAME2 (0x00040000) → vulnérable

# Retirer le flag EDITF_ATTRIBUTESUBJECTALTNAME2
certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
# Redémarrer le service CertSvc
Restart-Service CertSvc

# Auditer les permissions sur les templates
$templates = Get-ADObject -SearchBase "CN=Public Key Services,CN=Services,CN=Configuration,DC=corp,DC=local" `
    -Filter {objectClass -eq "pKICertificateTemplate"} -Properties nTSecurityDescriptor
foreach ($template in $templates) {
    $acl = $template.nTSecurityDescriptor
    $dangerousACEs = $acl.Access | Where-Object {
        ($_.ActiveDirectoryRights -match "GenericAll|WriteDacl|WriteOwner|WriteProperty") -and
        ($_.IdentityReference -notlike "NT AUTHORITY\*") -and
        ($_.IdentityReference -notlike "BUILTIN\Administrators") -and
        ($_.IdentityReference -notlike "*Enterprise Admins*") -and
        ($_.IdentityReference -notlike "*Domain Admins*")
    }
    if ($dangerousACEs) {
        Write-Host "TEMPLATE VULNERABLE: $($template.Name)" -ForegroundColor Red
        $dangerousACEs | ForEach-Object {
            Write-Host "  $($_.IdentityReference) : $($_.ActiveDirectoryRights)" -ForegroundColor Yellow
        }
    }
}

# Utiliser Certify.exe (ou Certipy en Python) pour un audit complet
.\Certify.exe find /vulnerable
# ou depuis Linux :
# certipy find -u audit@corp.local -p 'password' -dc-ip 10.0.0.1 -vulnerable

Hardening des templates et de la CA

# 1. Désactiver le flag SAN libre sur les templates vulnérables
# Via la console certtmpl.msc : Properties > Subject Name >
# Sélectionner "Build from this Active Directory information" au lieu de "Supply in the request"

# 2. Exiger l'approbation du CA Manager pour les templates sensibles
# Via certtmpl.msc : Properties > Issuance Requirements >
# Cocher "CA certificate manager approval"

# 3. Restreindre les permissions d'enrollment
# Retirer "Authenticated Users" des permissions Enroll sur les templates sensibles
# N'autoriser que les groupes spécifiques qui ont besoin de certificats

# 4. Activer l'audit sur la CA
# certutil -setreg CA\AuditFilter 127
# Cela active l'audit complet : Start/Stop, Backup/Restore, Issue/Deny, Revoke, Change settings

# 5. Monitorer les certificats émis
# Event 4887 (Certificate Services approved a certificate request) dans Security log
# Event 4886 (Certificate Services received a certificate request)
# Alerter sur les certificats émis pour des comptes à hauts privilèges

# 6. Protéger la clé privée de la CA
# La CA Tier 0 doit utiliser un HSM (Hardware Security Module) pour stocker sa clé privée
# Si pas de HSM : activer la protection renforcée de la clé privée, sauvegardes chiffrées hors-ligne

Migration vers Entra ID : sécurité de l'identité hybride

La migration vers Entra ID (anciennement Azure AD) est une réalité pour la majorité des organisations. L'identité hybride — où les utilisateurs s'authentifient à la fois sur AD on-premises et Entra ID — introduit de nouveaux vecteurs d'attaque mais aussi de nouvelles opportunités de sécurisation. La clé est de ne pas affaiblir la sécurité AD on-premises en ajoutant la couche cloud, et de tirer parti des capacités avancées d'Entra ID pour renforcer la posture globale.

Les trois méthodes de synchronisation

Méthode	Fonctionnement	Risques	Recommandation
Password Hash Sync (PHS)	Les hashes des mots de passe AD sont synchronisés vers Entra ID	Les hashes sont stockés dans le cloud (chiffrés). Si Entra ID est compromis, les hashes sont exposés	Recommandé par Microsoft. Permet la détection de credentials leakés
Pass-Through Auth (PTA)	L'authentification est relayée vers un agent on-premises en temps réel	L'agent PTA est une cible Tier 0. Si compromis, l'attaquant peut valider n'importe quel mot de passe	Acceptable si PHS n'est pas souhaité. Protéger les agents PTA comme des DC
ADFS (Federation)	Serveur ADFS on-premises émet des tokens SAML pour Entra ID	ADFS est une cible Tier 0 critique (Golden SAML attack). Surface d'attaque importante	En voie de dépréciation. Migrer vers PHS + Seamless SSO

Sécuriser Azure AD Connect / Entra Connect Sync

Le serveur Azure AD Connect (renommé Entra Connect Sync) est l'un des actifs les plus critiques de l'infrastructure — il dispose de permissions de lecture sur tous les objets AD (incluant les hashes de mots de passe avec PHS) et de permissions d'écriture sur Entra ID. Sa compromission permet une attaque de type AADInternals pour pivoter entre on-prem et cloud.

# 1. Le serveur Azure AD Connect doit être traité comme Tier 0
# - Membre du même OU que les DC
# - Accessible uniquement depuis les PAW Tier 0
# - Credential Guard activé
# - Pas de navigation Internet
# - Antivirus/EDR avec monitoring renforcé

# 2. Vérifier les comptes créés par Azure AD Connect
# Compte AD : MSOL_XXXXXXXXXX (permissions de réplication sur AD)
Get-ADUser -Filter {Name -like "MSOL_*"} -Properties * |
    Select-Object Name, Created, PasswordLastSet, Enabled

# 3. Restreindre les permissions du compte MSOL
# Par défaut, il a des permissions de réplication (DS-Replication-Get-Changes-All)
# Ce sont les permissions de DCSync — ce compte est aussi critique que krbtgt

# 4. Monitorer les modifications du connecteur
# Événements Azure AD Connect dans le journal Application
# Alerter sur tout changement de configuration

# 5. Activer la synchronisation sélective
# Ne synchroniser que les OU nécessaires (pas les comptes admin Tier 0, pas les comptes de service)
# Via Azure AD Connect wizard : Customize synchronization > OU-based filtering

Conditional Access : le nouveau périmètre de sécurité

Conditional Access dans Entra ID permet d'appliquer des politiques d'accès granulaires basées sur l'identité, le device, la localisation, le risque et l'application. C'est le mécanisme de sécurité le plus puissant disponible dans l'écosystème Microsoft et il doit être déployé systématiquement.

# Politiques Conditional Access essentielles (via le portail Entra ID ou Graph API)

# Politique 1 : MFA obligatoire pour tous les utilisateurs
# Conditions : All users (excl. break-glass accounts), All cloud apps
# Grant : Require multifactor authentication

# Politique 2 : Bloquer les authentifications legacy
# Conditions : All users, All cloud apps, Client apps = "Exchange ActiveSync clients" + "Other clients"
# Grant : Block access

# Politique 3 : Exiger un device conforme pour les admins
# Conditions : Directory role = Global Administrator, Privileged Role Administrator, etc.
# Grant : Require device to be marked as compliant + Require MFA

# Politique 4 : Bloquer l'accès depuis les pays à risque
# Conditions : All users, All cloud apps, Locations = Named locations (pays à risque)
# Grant : Block access

# Politique 5 : Exiger une force d'authentification renforcée pour les actions critiques
# Conditions : Admin roles, Actions = All cloud apps
# Grant : Require authentication strength = Phishing-resistant MFA (FIDO2, Windows Hello, Certificate)

# Vérifier les politiques via Microsoft Graph PowerShell
Connect-MgGraph -Scopes "Policy.Read.All"
Get-MgIdentityConditionalAccessPolicy | Select-Object DisplayName, State, CreatedDateTime

Comptes Break-Glass

Les comptes break-glass (ou emergency access) sont des comptes d'administration cloud-only (pas synchronisés depuis AD) conçus pour les scénarios catastrophe où Conditional Access, MFA, ou une panne de la fédération bloquent tout accès légitime aux portails d'administration. Sans ces comptes, une erreur de configuration Conditional Access pourrait verrouiller l'intégralité des administrateurs hors d'Entra ID — un scénario qui s'est produit dans de nombreuses organisations.

Les bonnes pratiques pour les comptes break-glass sont strictes : créez minimum deux comptes avec des mots de passe de 30+ caractères générés aléatoirement, stockez les mots de passe dans un coffre physique sécurisé (pas dans un gestionnaire de mots de passe en ligne qui pourrait être inaccessible pendant l'urgence), excluez ces comptes de toutes les politiques Conditional Access (c'est leur raison d'être), n'assignez pas de MFA (ou utilisez un FIDO2 key stockée dans le coffre physique), assignez le rôle Global Administrator en permanent (pas de PIM pour ces comptes — ils doivent fonctionner immédiatement en cas d'urgence), et configurez des alertes Azure Monitor immédiates sur toute connexion avec ces comptes. Testez ces comptes trimestriellement pour vérifier qu'ils fonctionnent toujours. Documentez la procédure d'accès au coffre physique et assurez-vous qu'au moins deux personnes de confiance connaissent la procédure.

Plan de remédiation en 90 jours

La sécurisation d'Active Directory est un marathon, pas un sprint. Cependant, les mesures les plus impactantes peuvent et doivent être déployées rapidement. Voici un plan de remédiation structuré en trois phases.

Phase 1 : Quick Wins (Semaines 1-2)

Ces mesures réduisent immédiatement la surface d'attaque avec un effort minimal et un risque de régression faible.

#	Action	Impact	Effort	Commande / Vérification
1	Réinitialiser le mot de passe krbtgt (2x)	Critique	1h	Set-ADAccountPassword -Identity krbtgt -Reset
2	Identifier et désactiver les comptes avec DONT_REQUIRE_PREAUTH	Élevé	30min	Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true}
3	Ajouter les admins Tier 0 au groupe Protected Users	Élevé	1h	Add-ADGroupMember "Protected Users" -Members $tier0Admins
4	Activer le SMB Signing sur tous les DC	Élevé	1h	GPO : Digitally sign communications (always)
5	Désactiver LLMNR et NBT-NS	Modéré	30min	GPO : Turn off multicast name resolution
6	Désactiver le Print Spooler sur les DC	Modéré	15min	Stop-Service Spooler; Set-Service Spooler -StartupType Disabled
7	Exécuter PingCastle et documenter le score initial	Informatif	1h	.\PingCastle.exe --healthcheck
8	Activer l'audit avancé sur les DC	Élevé	2h	GPO : Advanced Audit Policy Configuration
9	Retirer le flag EDITF_ATTRIBUTESUBJECTALTNAME2 de la CA	Critique	15min	certutil -setreg policy\EditFlags -EDITF_ATTRIBUTESUBJECTALTNAME2
10	Créer 3-5 honey tokens	Modéré	2h	Comptes leurres + SACL audit

Phase 2 : Fondations (Mois 1)

Ces mesures requièrent plus de planification mais constituent les fondations d'une sécurité AD durable.

#	Action	Impact	Effort
1	Implémenter le tiering model (OU, groupes, GPO de restriction de logon)	Critique	5 jours
2	Déployer LAPS sur tous les postes et serveurs	Élevé	3 jours
3	Migrer les 10 comptes de service les plus critiques vers gMSA	Élevé	5 jours
4	Activer AES256 sur tous les comptes et auditer les dépendances RC4	Élevé	3 jours
5	Identifier et supprimer toutes les Unconstrained Delegations (hors DC)	Élevé	3 jours
6	Auditer et corriger les templates AD CS vulnérables (ESC1, ESC4, ESC6)	Critique	3 jours
7	Déployer une PAW pour l'administration Tier 0 (même une seule VM dédiée)	Élevé	3 jours
8	Configurer LDAP Signing et Channel Binding sur les DC	Élevé	2 jours
9	Configurer les Fine-Grained Password Policies pour les comptes admin	Modéré	1 jour
10	Déployer les règles de détection SIEM (Kerberoasting, DCSync, spray)	Élevé	5 jours

Phase 3 : Consolidation (Mois 2-3)

Ces mesures renforcent et pérennisent la posture de sécurité établie dans les phases précédentes.

#	Action	Impact	Effort
1	Déployer Credential Guard sur tous les serveurs Tier 0 et Tier 1	Élevé	5 jours
2	Implémenter JIT Access (TTL de groupe ou solution PAM)	Élevé	10 jours
3	Désactiver RC4 après migration complète vers AES	Élevé	2 jours
4	Auditer et corriger les ACL AD avec BloodHound/Adalanche	Élevé	10 jours
5	Migrer tous les comptes de service restants vers gMSA	Modéré	10 jours
6	Implémenter JEA pour les tâches helpdesk et opérations courantes	Modéré	5 jours
7	Auditer NTLMv2 et bloquer NTLM sur les systèmes non legacy	Élevé	10 jours
8	Déployer Conditional Access dans Entra ID (si hybride)	Élevé	5 jours
9	Exécuter un test d'intrusion AD pour valider les mesures	Critique	5 jours
10	Documenter les procédures et former les équipes	Modéré	5 jours

# Script de suivi de progression du plan de remédiation
$remediation = @(
    @{Phase="Quick Wins"; Item="Rotation krbtgt"; Status="Done"; Date="2026-04-20"; Owner="Security Team"}
    @{Phase="Quick Wins"; Item="Protected Users"; Status="In Progress"; Date=""; Owner="AD Team"}
    @{Phase="Quick Wins"; Item="SMB Signing"; Status="Planned"; Date=""; Owner="Infrastructure"}
    # ... ajouter les 30 items
)

$remediation | ForEach-Object { [PSCustomObject]$_ } |
    Format-Table Phase, Item, Status, Date, Owner -AutoSize

# Calculer la progression
$total = $remediation.Count
$done = ($remediation | Where-Object { $_.Status -eq "Done" }).Count
$progress = [math]::Round(($done / $total) * 100, 1)
Write-Host "Progression globale: $done/$total ($progress%)"

Checklist complète de sécurisation Active Directory

Cette checklist synthétise l'ensemble des mesures de durcissement recommandées. Utilisez-la comme outil de suivi pour évaluer votre niveau de maturité et planifier les actions correctives.

Comptes et authentification

Mesure	Priorité	Statut
Nombre de Domain Admins réduit au strict minimum (< 5)	Critique	☐
Comptes d'administration séparés (T0/T1/T2) avec convention de nommage	Critique	☐
Comptes admin Tier 0 dans le groupe Protected Users	Critique	☐
Mot de passe krbtgt réinitialisé dans les 90 derniers jours	Critique	☐
Aucun compte avec DONT_REQUIRE_PREAUTH actif	Élevé	☐
LAPS déployé sur 100% des postes et serveurs	Élevé	☐
Comptes de service migrés vers gMSA	Élevé	☐
Fine-Grained Password Policies configurées (admin ≥ 20 chars, service ≥ 30 chars)	Élevé	☐
Comptes inactifs (> 90 jours) désactivés ou supprimés	Modéré	☐
Flag "Account is sensitive and cannot be delegated" sur tous les comptes Tier 0	Élevé	☐
Comptes break-glass cloud-only configurés (si hybride)	Élevé	☐

Protocoles et chiffrement

Mesure	Priorité	Statut
AES256 activé sur tous les comptes	Critique	☐
RC4 désactivé (ou en cours de migration avec audit)	Élevé	☐
NTLMv1 désactivé (LM authentication level ≥ 3)	Critique	☐
Audit NTLM activé sur les DC	Élevé	☐
SMB Signing requis sur tous les systèmes	Critique	☐
LDAP Signing requis sur les DC	Élevé	☐
LDAP Channel Binding activé sur les DC	Élevé	☐
EPA activée sur AD CS, Exchange, AD FS	Élevé	☐
LM hash storage désactivé	Critique	☐
WDigest UseLogonCredential = 0	Élevé	☐

Architecture et segmentation

Mesure	Priorité	Statut
Tiering model implémenté (OU, groupes, GPO de restriction)	Critique	☐
PAW déployées pour l'administration Tier 0	Critique	☐
Credential Guard activé sur les PAW et les DC (2016+)	Élevé	☐
Aucune Unconstrained Delegation (hors DC)	Critique	☐
Constrained Delegation auditée et minimisée	Élevé	☐
Print Spooler désactivé sur les DC	Élevé	☐
LLMNR et NBT-NS désactivés	Élevé	☐
Niveau fonctionnel de domaine et forêt ≥ 2016	Modéré	☐
JIT Access implémenté pour les privilèges élevés	Élevé	☐

Monitoring et audit

Mesure	Priorité	Statut
Advanced Audit Policy configurée sur les DC	Critique	☐
Logs de sécurité centralisés dans un SIEM	Critique	☐
Règles de détection Kerberoasting, DCSync, Password Spraying	Critique	☐
Honey tokens déployés (≥ 3)	Élevé	☐
PingCastle exécuté mensuellement	Élevé	☐
BloodHound/Adalanche exécuté trimestriellement	Élevé	☐
Alerte sur ajout aux groupes privilégiés (4728/4732/4756)	Critique	☐
Alerte sur suppression de logs (1102)	Critique	☐
Taille des logs de sécurité ≥ 4 GB sur les DC	Modéré	☐

AD CS (Certificate Services)

Mesure	Priorité	Statut
Flag EDITF_ATTRIBUTESUBJECTALTNAME2 retiré (ESC6)	Critique	☐
Templates avec SAN libre corrigés ou supprimés (ESC1)	Critique	☐
Permissions sur les templates auditées (ESC4)	Élevé	☐
Web Enrollment protégé par EPA ou désactivé (ESC8)	Élevé	☐
Audit activé sur la CA (AuditFilter = 127)	Élevé	☐
Permissions ManageCA et ManageCertificates restreintes (ESC7)	Élevé	☐

FAQ : questions fréquentes sur la sécurisation d'Active Directory

Quel est le coût réel d'une compromission Active Directory pour une entreprise ?

Le coût direct d'une compromission AD varie considérablement selon la taille de l'organisation et la nature de l'attaque, mais les chiffres sont systématiquement élevés. Selon le rapport IBM Cost of a Data Breach 2025, le coût moyen d'une violation de données impliquant une compromission d'identité est de 4,8 millions de dollars. Dans les cas de rançongiciel avec compromission AD, les coûts incluent la rançon elle-même (médiane de 1,5 million de dollars pour les entreprises de taille moyenne), l'arrêt de production (en moyenne 23 jours d'interruption), la reconstruction complète d'AD (2 à 6 semaines de travail d'équipes spécialisées), les frais de réponse à incident et d'investigation forensique, les pénalités réglementaires (RGPD, NIS2), et l'atteinte à la réputation. Pour une entreprise de 1 000 employés, le coût total d'une compromission AD ayant conduit à un déploiement de rançongiciel se situe typiquement entre 2 et 10 millions d'euros.

Combien de temps faut-il pour sécuriser Active Directory correctement ?

La réponse dépend du point de départ et de la maturité de l'organisation. Les quick wins (phase 1 du plan de remédiation) peuvent être déployés en 2 semaines et réduisent immédiatement les risques les plus critiques. Une sécurisation fondamentale (tiering model, LAPS, gMSA, audit avancé) nécessite 2 à 3 mois de travail soutenu pour une équipe de 2-3 personnes. L'atteinte d'un niveau de maturité élevé (JIT, PAW complètes, NTLM désactivé, monitoring avancé) prend 6 à 12 mois. La sécurité AD n'est jamais "finie" — c'est un processus continu d'audit, de correction et d'amélioration. Le plus important est de commencer immédiatement par les mesures les plus impactantes.

Peut-on sécuriser AD sans budget dédié ?

Oui, significativement. La majorité des mesures les plus efficaces sont gratuites : le tiering model repose sur des GPO natives, le groupe Protected Users est intégré à AD, LAPS est gratuit (Windows LAPS est intégré à Windows 11/Server 2025), les gMSA sont une fonctionnalité native, l'audit avancé est une configuration GPO, PingCastle est gratuit pour usage interne, BloodHound CE est open source, et Adalanche est open source. Les investissements qui nécessitent un budget concernent principalement le SIEM (Elastic Security est open source, Microsoft Sentinel est payant), les PAW (matériel dédié ou VMs avec licences), les solutions PAM (CyberArk, BeyondTrust — mais les TTL de groupe sont gratifs), et les tests d'intrusion (2 000 à 15 000 euros selon le scope). Une organisation motivée peut atteindre un score PingCastle excellent sans dépenser un euro en licences logicielles.

Faut-il désactiver complètement NTLM ?

La désactivation complète de NTLM est l'objectif idéal, mais elle est rarement réalisable à court terme. Les applications legacy, les périphériques réseau (imprimantes, scanners), les partages de fichiers entre domaines sans trust Kerberos, et certains scénarios d'authentification locale dépendent encore de NTLM. L'approche recommandée est progressive : d'abord désactiver NTLMv1 (immédiatement, aucune application moderne ne devrait le nécessiter), puis activer l'audit NTLM sur tous les DC pour identifier les dépendances, puis créer une liste d'exceptions pour les applications legacy tout en bloquant NTLM partout ailleurs, et enfin migrer progressivement les applications legacy vers Kerberos ou des protocoles modernes. Microsoft a annoncé la dépréciation complète de NTLM dans Windows Server vNext, ce qui rend cette migration inévitable.

BloodHound est-il un outil offensif ou défensif ?

BloodHound est un outil dual-use qui sert autant aux attaquants qu'aux défenseurs. Les red teams et les testeurs d'intrusion l'utilisent pour identifier les chemins d'attaque les plus courts vers Domain Admin. Les blue teams l'utilisent pour identifier et corriger ces mêmes chemins avant qu'un attaquant ne les exploite. La version communautaire (BloodHound CE) et la version entreprise offrent des fonctionnalités de reporting et de suivi de la remédiation. L'utiliser défensivement est non seulement légitime mais vivement recommandé — ne pas utiliser BloodHound revient à laisser aux attaquants un avantage informationnel considérable. Exécutez SharpHound trimestriellement, importez les données dans BloodHound, et traitez systématiquement les chemins d'attaque identifiés en priorité.

Quelle est la différence entre PingCastle et Purple Knight ?

PingCastle et Purple Knight sont complémentaires. PingCastle se concentre sur un score de risque global avec des recommandations actionnables et priorisées. Il est rapide à exécuter (quelques minutes), produit un rapport HTML clair, et est idéal pour un suivi mensuel de la posture de sécurité. Purple Knight est plus exhaustif dans ses vérifications (150+ indicateurs), catégorise les résultats en IOE (Indicators of Exposure) et IOC (Indicators of Compromise), et fournit des détails plus granulaires sur certaines misconfiguration. Utilisez PingCastle mensuellement pour le suivi continu et Purple Knight trimestriellement pour un audit plus approfondi. Les deux outils sont gratuits pour un usage interne.

Comment détecter si mon AD a déjà été compromis ?

Plusieurs indicateurs peuvent révéler une compromission passée ou en cours. Vérifiez l'ancienneté du mot de passe krbtgt (s'il n'a pas été changé depuis plus de 180 jours, un Golden Ticket pourrait être actif). Recherchez les comptes avec SIDHistory non vide (potentiel indicateur de DCShadow ou de migration malveillante). Analysez les membres des groupes privilégiés pour détecter des ajouts non autorisés. Vérifiez les ACL sur AdminSDHolder pour détecter des backdoors. Recherchez les Constrained Delegation et RBCD suspectes. Exécutez BloodHound pour identifier des chemins d'attaque anormaux. Vérifiez les templates AD CS pour des modifications récentes. Analysez les logs de sécurité pour des patterns de Kerberoasting, DCSync ou spray. En cas de doute, engagez une équipe de réponse à incident spécialisée en AD forensics.

Le passage à Entra ID rend-il AD on-premises moins critique ?

Non, et c'est une erreur fréquente. Tant que l'identité hybride est en place — ce qui est le cas pour la majorité des organisations en transition — AD on-premises reste le maillon critique. Le serveur Azure AD Connect / Entra Connect Sync synchronise les identités et (avec PHS) les hashes de mots de passe. Compromettre AD on-premises permet de pivoter vers Entra ID via le compte MSOL ou des techniques comme Golden SAML (si ADFS est utilisé). Inversement, compromettre Entra ID peut parfois permettre de pivoter vers l'on-premises via password writeback ou PTA agent abuse. La sécurisation doit couvrir les deux environnements simultanément. L'identité hybride double la surface d'attaque — elle ne la divise pas.

Quelle est la fréquence recommandée pour les audits AD ?

La fréquence dépend du type d'audit. Les vérifications automatisées (Testimo, scripts de conformité) doivent être hebdomadaires, idéalement intégrées à un pipeline CI/CD. PingCastle doit être exécuté mensuellement, avec un suivi de l'évolution du score. BloodHound et les outils d'analyse des chemins d'attaque doivent être exécutés trimestriellement. Un audit complet par un prestataire externe (test d'intrusion AD dédié) doit être réalisé annuellement. Les audits ad hoc doivent être déclenchés après chaque changement majeur (mise à jour de DC, modification de trusts, ajout de templates AD CS, déploiement Azure AD Connect) et après tout incident de sécurité. L'ANSSI recommande un audit complet tous les 12 à 18 mois pour les organisations soumises à la réglementation NIS2.

Comment convaincre la direction d'investir dans la sécurité AD ?

Le langage de la direction est celui du risque financier et de la conformité réglementaire, pas celui des CVE et des techniques d'attaque. Plusieurs approches ont fait leurs preuves pour obtenir le budget nécessaire à la sécurisation d'AD.

Premièrement, présentez le coût moyen d'une compromission AD (4 à 10 millions d'euros selon la taille de l'organisation) et la probabilité d'occurrence — les rapports convergent sur le fait que 70 % des organisations subiront une tentative de compromission AD dans les 24 prochains mois. Calculez le ratio coût/bénéfice des mesures de protection : les quick wins de la phase 1 coûtent moins de 10 000 euros en temps de travail interne pour réduire de 80 % la surface d'attaque. C'est un retour sur investissement imbattable par rapport à n'importe quel autre projet de sécurité.

Deuxièmement, utilisez le rapport PingCastle comme outil de communication exécutive. Un score de 85/100 en risque est un message visuel que tout COMEX comprend immédiatement. Montrez l'évolution du score au fil des trimestres pour démontrer la progression. Troisièmement, référencez les exigences réglementaires : NIS2 impose des mesures de sécurité sur les systèmes d'identité avec des sanctions financières significatives, DORA exige des tests de résilience numérique pour les entités financières, et le RGPD rend l'organisation responsable des violations de données résultant d'un manque de mesures techniques appropriées. Proposez le plan de 90 jours avec des jalons mesurables, des indicateurs de progression, et un budget détaillé poste par poste. Le test d'intrusion AD est souvent le déclencheur le plus efficace — quand le pentester obtient Domain Admin en 4 heures à partir d'un poste utilisateur standard, le message passe auprès de n'importe quel décideur.

Aspects réglementaires et conformité

La sécurisation d'Active Directory n'est pas seulement une bonne pratique technique — c'est une exigence réglementaire de plus en plus explicite. Plusieurs cadres réglementaires européens et internationaux imposent des mesures de sécurité directement applicables aux systèmes d'identité.

NIS2 et Active Directory

La directive NIS2, entrée en application en octobre 2024, élargit considérablement le périmètre des organisations soumises à des obligations de cybersécurité. Les "entités essentielles" et "entités importantes" doivent mettre en oeuvre des mesures de gestion des risques cyber qui incluent explicitement la gestion des identités et des accès, la sécurité de la chaîne d'approvisionnement numérique, et la notification d'incidents dans les 24 heures. Active Directory, en tant que système central d'identité, est directement concerné par ces exigences. Les organisations qui ne peuvent pas démontrer un durcissement adéquat d'AD s'exposent à des sanctions pouvant atteindre 10 millions d'euros ou 2 % du chiffre d'affaires mondial.

DORA et les services financiers

Le règlement DORA (Digital Operational Resilience Act), applicable depuis janvier 2025 aux entités financières européennes, impose des tests de résilience numérique incluant des tests de pénétration avancés (TLPT — Threat-Led Penetration Testing). Ces tests ciblent systématiquement Active Directory comme vecteur d'attaque privilégié. Les entités financières doivent démontrer leur capacité à résister à une compromission AD et à restaurer les services d'identité dans des délais définis. La sauvegarde et la restauration d'AD sont des exigences explicites de DORA.

RGPD et protection des données

Le RGPD impose la mise en oeuvre de mesures techniques et organisationnelles appropriées pour protéger les données personnelles. Active Directory contient des données personnelles (noms, adresses email, numéros de téléphone, structures organisationnelles) et contrôle l'accès à toutes les ressources contenant des données personnelles. Une compromission d'AD constitue une violation de données personnelles au sens du RGPD, déclenchant l'obligation de notification à la CNIL dans les 72 heures et potentiellement aux personnes concernées. Le durcissement d'AD est donc une mesure technique "appropriée" au sens de l'article 32 du RGPD.

Sauvegarde et restauration d'Active Directory

La capacité à restaurer Active Directory après une compromission est un aspect critique souvent négligé. Un plan de restauration AD doit couvrir plusieurs scénarios : la restauration d'objets individuels supprimés (via la Corbeille AD ou les sauvegardes authoritatives), la restauration d'un contrôleur de domaine compromis (réinstallation complète et re-promotion), et la restauration complète de la forêt après une compromission totale (le scénario le plus redouté). Microsoft publie un guide détaillé de restauration de forêt AD qui doit être testé au minimum annuellement.

# Vérifier que la Corbeille AD est activée
Get-ADOptionalFeature -Filter {Name -eq "Recycle Bin Feature"}

# Activer la Corbeille AD (irréversible, niveau fonctionnel 2008 R2+ requis)
Enable-ADOptionalFeature -Identity "Recycle Bin Feature" -Scope ForestOrConfigurationSet `
    -Target "corp.local" -Confirm:$false

# Vérifier l'état des sauvegardes AD (System State)
wbadmin get versions -backupTarget:E: -machine:DC01

# Idéalement, sauvegarder au minimum 2 DC par domaine
# Conserver les sauvegardes pendant au moins 180 jours (durée de vie du tombstone par défaut)
# Stocker au moins une copie offline (air-gapped) pour résister aux rançongiciels

# Tester la restauration régulièrement dans un environnement isolé
# La restauration d'une forêt complète prend typiquement 4 à 12 heures

Conclusion : la sécurité AD comme processus continu

Sécuriser Active Directory est un défi technique et organisationnel majeur, mais c'est aussi l'investissement en sécurité avec le meilleur retour possible. Un Active Directory correctement durci réduit drastiquement le risque de rançongiciel, empêche les mouvements latéraux, et limite l'impact de toute compromission initiale. Les mesures présentées dans ce guide — tiering model, hardening des comptes à privilèges, sécurisation Kerberos et NTLM, audit continu, monitoring en temps réel — forment un ensemble cohérent qui, déployé méthodiquement, transforme AD d'un maillon faible en un bastion défensif.

Les points clés à retenir sont les suivants. Premièrement, commencez par les quick wins : rotation krbtgt, Protected Users, SMB Signing, LLMNR/NBT-NS, audit avancé. Ces mesures prennent quelques heures et bloquent les attaques les plus courantes. Deuxièmement, le tiering model est la mesure architecturale la plus impactante. Séparer les identifiants Tier 0 des postes de travail élimine le scénario de compromission le plus fréquent. Troisièmement, les outils d'audit gratuits (PingCastle, BloodHound, Adalanche) fournissent une visibilité remarquable sur la posture de sécurité — il n'y a aucune excuse pour ne pas les utiliser. Quatrièmement, le monitoring n'est pas optionnel. Sans détection, une compromission reste invisible pendant des semaines. Les honey tokens, les règles SIEM et les outils comme Microsoft Defender for Identity constituent la deuxième ligne de défense. Cinquièmement, AD CS est devenu le nouveau vecteur d'attaque critique. L'audit des templates et de la configuration de la CA doit être une priorité immédiate.

La sécurité d'Active Directory n'est pas un état statique — c'est un processus continu d'amélioration et d'adaptation. Les attaquants innovent constamment : les techniques d'attaque sur AD CS n'existaient pas avant 2021, les attaques RBCD sont apparues en 2019, et de nouvelles escalades de privilèges via les permissions AD sont découvertes chaque trimestre. Simultanément, les configurations dérivent au fil du temps à mesure que des modifications sont apportées par différentes équipes sans considération sécuritaire — un nouveau compte de service créé avec un SPN et un mot de passe faible, une délégation Kerberos ajoutée pour résoudre un problème applicatif en urgence, des permissions WriteDACL accordées à un groupe IT pour faciliter une migration.

L'audit régulier est le seul rempart contre cette dérive. Exécutez PingCastle mensuellement et traitez chaque nouveau point identifié comme un incident. Exécutez BloodHound trimestriellement et éliminez systématiquement les chemins d'attaque. Formez vos équipes d'administration AD aux techniques d'attaque — un administrateur qui comprend comment fonctionne le Kerberoasting ne créera plus jamais de compte de service avec un mot de passe de 8 caractères. Intégrez la sécurité AD dans les processus de changement : chaque modification d'AD (nouvelle OU, nouveau groupe, nouveau template de certificat, nouvelle délégation) doit passer par une revue de sécurité.

Le cadre réglementaire renforce cette exigence de vigilance permanente. NIS2, DORA et le RGPD imposent des obligations de sécurité dont la non-conformité entraîne des sanctions financières croissantes. La question n'est plus de savoir si votre organisation sera auditée sur sa sécurité AD, mais quand. Le plan de remédiation en 90 jours proposé dans ce guide constitue un point de départ solide et actionnable. Les quick wins de la phase 1 peuvent être déployés dès demain matin. Les fondations de la phase 2 protègent contre les attaques les plus fréquentes. La consolidation de la phase 3 élève votre posture au niveau des organisations les plus matures. À vous de transformer ce plan en programme de sécurité permanent et de faire d'Active Directory un bastion plutôt qu'un maillon faible.