Meilleures pratiques de sécurité d'Active Directory

Active Directory se trouve au cœur de l'identité de l'entreprise : chaque compte utilisateur, objet de stratégie de groupe (GPO) et décision d'accès y transite.

Le rapport Netwrix 2025 sur les tendances en cybersécurité a révélé que 28 % des organisations ont subi une attaque ciblée sur leur infrastructure sur site en 2025, contre 19 % en 2023, faisant du renforcement d'Active Directory une priorité urgente.

Un seul compte à privilèges mal configuré ou un protocole hérité activé peut étendre l'accès d'un attaquant d'un simple terminal au contrôle complet du domaine.

Ce guide couvre les techniques d'attaque qui ciblent le plus fréquemment AD, les contrôles de renforcement qui éliminent les points d'ancrage les plus courants et la couverture de surveillance qui permet aux équipes de sécurité de détecter les abus avant qu'ils ne s'aggravent.

Qu'est-ce que la sécurité d'Active Directory ?

La sécurité d'Active Directory (AD) englobe les pratiques, les contrôles et la surveillance qui protègent le service d'annuaire chargé d'authentifier les utilisateurs, d'autoriser les accès et d'appliquer les stratégies dans les environnements Windows.

Cela couvre le renforcement de la configuration, la gestion des privilèges, les contrôles de protocole et la surveillance des changements, à la fois dans les environnements AD DS sur site et les environnements hybrides incluant Entra ID.

Chaque appartenance à un groupe, attribution de délégation, GPO et configuration de compte de service relève de son périmètre, car chacun peut créer un chemin d'escalade de privilèges en cas de mauvaise configuration.

Pourquoi vous devez protéger Active Directory

AD est à la fois l'un des systèmes les plus ciblés de l'entreprise et l'un des plus faciles à négliger lors des examens de sécurité de routine.

Il contrôle l'authentification et l'autorisation pour l'ensemble du réseau

Chaque compte utilisateur, stratégie de groupe, objet ordinateur et décision d'accès transite par Active Directory. Celui qui contrôle le domaine contrôle le réseau, pas seulement un système ou une application, mais la couche d'authentification sous-jacente à tous. Une compromission de domaine expose chaque ressource qui fait confiance à AD pour ses décisions d'identité.

Une seule compromission donne aux attaquants un contrôle étendu du domaine

Un acteur malveillant qui atteint le niveau d'administrateur de domaine peut émettre des tickets Kerberos falsifiés, diffuser des stratégies de groupe malveillantes vers chaque poste de travail, extraire des identifiants dans tout le domaine et désactiver les outils de sécurité. La récupération après une compromission complète d'AD nécessite souvent de reconstruire l'infrastructure d'annuaire centrale, ce qui confère au renforcement des identités un impact direct sur l'entreprise, et pas seulement technique.

La dette de privilèges s'accumule silencieusement au fil des années

Des comptes de service ajoutés aux Domain Admins par commodité, des autorisations déléguées jamais révoquées, des appartenances à des groupes qui survivent aux changements de rôle et aux départs : la plupart des équipes de sécurité sont incapables de produire une liste précise des personnes détenant un accès à privilèges. Cette accumulation persiste en silence jusqu'à ce qu'un examen ou un incident la mette en lumière.

Les protocoles hérités et les erreurs de configuration persistent dans les environnements

Server Message Block v1 (SMBv1), NTLMv1, la délégation sans contrainte et l'authentification WDigest persistent dans de nombreux environnements d'entreprise en tant que paramètres hérités.

Microsoft a officiellement annoncé la dépréciation de NTLM, pourtant des vulnérabilités critiques continuent d'apparaître, et ces configurations déclenchent rarement des alertes avant d'être exploitées.

AD se trouve au cœur de la chaîne d'attaque moderne par rançongiciel

Les opérateurs de ransomware utilisent Active Directory pour les déplacements latéraux, l'élévation de privilèges et le déploiement de charges utiles, propageant le chiffrement à chaque terminal rattaché au domaine via la stratégie de groupe en une seule opération.

CISA, Mandiant et Microsoft DART ont tous documenté la modification des GPO comme une technique utilisée dans les campagnes de ransomware et de wiper.

Techniques d'attaque courantes d'Active Directory

Les techniques ci-dessous exploitent principalement le comportement attendu d'AD et les faiblesses de configuration courantes plutôt que des défauts logiciels. La plupart ne nécessitent qu'un compte de domaine valide pour être lancées, et plusieurs ne génèrent aucune alerte utile avec les paramètres d'audit par défaut.

Kerberoasting et AS-REP Roasting

Tout utilisateur de domaine authentifié peut demander un TGS Kerberos pour n'importe quel compte doté d'un SPN enregistré et déchiffrer le ticket chiffré hors ligne à l'aide du hachage du mot de passe du compte de service. Le chiffrement RC4 (etype 0x17) rend cette opération plus rapide.

APT29, Wizard Spider et FIN7 ont tous utilisé cette technique. L'AS-REP Roasting applique la même approche aux comptes dont la pré-authentification est désactivée.

Pass-the-Hash et Pass-the-Ticket

Le protocole de défi-réponse NTLM utilise le hachage lui-même comme secret d'authentification. Un attaquant qui le capture depuis la mémoire LSASS ou le fichier NTDS.dit peut s'authentifier sans connaître le mot de passe en clair.

La technique « Overpass-the-Hash » convertit le hachage en un TGT valide, créant ainsi une passerelle vers Pass-the-Ticket. APT41 a utilisé ces deux techniques dans des campagnes documentées.

Attaques DCSync

DCSync exploite le protocole Directory Replication Service : un attaquant disposant des autorisations de réplication peut usurper l'identité d'un contrôleur de domaine et récupérer les hachages NTLM de n'importe quel compte, y compris krbtgt, sans toucher à NTDS.dit.

Tout membre du groupe Admins du domaine ou Administrateurs de l'entreprise dispose par défaut des autorisations suffisantes. APT29, Scattered Spider et LAPSUS$ ont tous utilisé cette technique.

Attaques Golden Ticket et Silver Ticket

Un Golden Ticket forge un TGT à l'aide du hash du compte krbtgt, offrant la possibilité de générer des tickets de service valides pour n'importe quel service en tant que n'importe quel utilisateur. Il reste valide jusqu'à ce que krbtgt soit réinitialisé deux fois.

Un Silver Ticket forge un TGS pour un service spécifique en utilisant le hachage du compte de ce service et, contrairement aux Golden Tickets, ne contacte jamais de contrôleur de domaine, ce qui le rend nettement plus difficile à détecter.

Meilleures pratiques de sécurité pour Active Directory

Les contrôles ci-dessous correspondent directement aux techniques d'attaque mentionnées plus haut. Chacun d'eux comble une faille d'ancrage ou de visibilité spécifique que les attaquants exploitent régulièrement.

Renforcer la configuration du contrôleur de domaine

Déployez les contrôleurs de domaine (DC) dans une unité d'organisation dédiée avec une GPO restrictive basée sur le Security Baseline de Windows Server 2025. Limitez le paramètre « Autoriser l'ouverture de session locale » aux seuls administrateurs et contrôleurs de domaine d'entreprise.

Désactivez le service de spouleur d'impression et le RDP là où ils ne sont pas nécessaires. Verrouillez SYSVOL et les autorisations de partage NETLOGON : utilisez le filtrage de sécurité des GPO au lieu d'accorder le contrôle total aux utilisateurs authentifiés, et ne stockez pas de mots de passe ou de scripts sensibles dans les préférences de stratégie de groupe. Isolez les contrôleurs de domaine virtuels au niveau de l'hyperviseur.

Traitez les contrôleurs de domaine et les services de domaine Active Directory (AD DS) comme des actifs de niveau 0 (Tier 0) avec un SLA de correctifs explicite, car les récentes vulnérabilités d'élévation de privilèges AD et d'exécution de code à distance ont montré que des contrôleurs de domaine non corrigés peuvent transformer des accès mineurs en compromissions complètes du domaine.

Supprimez également les membres du groupe Propriétaires créateurs de stratégie de groupe : les membres peuvent créer des GPO qu'ils contrôlent entièrement, créant ainsi une voie pour le déploiement non autorisé de GPO.

Appliquer l'accès au moindre privilège

Auditez les appartenances aux groupes Domain Admins, Enterprise Admins et Schema Admins et réduisez-les au minimum opérationnel.

Supprimez les utilisateurs qui n'ont plus besoin d'un accès élevé. Utilisez le contrôle d'accès basé sur les rôles (RBAC) au niveau de l'unité d'organisation.

N'ajoutez pas de comptes de service aux groupes privilégiés. Même une réduction modeste des privilèges améliore la résilience en supprimant les points de blocage partagés et en réduisant les chemins qui mènent aux actifs de niveau 0 (Tier 0).

Identifier et supprimer les comptes privilégiés inutilisés est l'un des gains les plus rapides possibles dans la plupart des environnements AD.

Mettre en œuvre un modèle d'accès à privilèges par niveaux

Microsoft recommande désormais l'Enterprise Access Model, qui remplace l'ancien modèle à trois niveaux.

Le principe fondamental demeure : les administrateurs du Tier 0 (plan de contrôle, couvrant les contrôleurs de domaine et l'infrastructure AD) ne doivent pas se connecter à des systèmes de niveau inférieur, car cela expose les informations d'identification via LSASS sur ces machines.

Utilisez des comptes distincts, non privilégiés et administratifs, pour chaque niveau de privilège : niveau 2 (postes de travail), niveau 1 (serveurs), niveau 0 (infrastructure de sécurité). Utilisez des postes de travail à accès privilégié (PAW) pour l'administration de niveau 0, avec des restrictions réseau sortantes qui n'autorisent la connectivité qu'aux services Microsoft requis.

Désactiver les protocoles d'authentification hérités

Désactivez SMBv1 via une stratégie de groupe ou PowerShell pour éliminer l'une des surfaces de protocole hérité les plus couramment exploitées :

      Set-SmbServerConfiguration -EnableSMB1Protocol $false
      

Restreignez NTLMv1 et imposez NTLMv2 au minimum en réglant le niveau d'authentification LAN Manager sur la valeur 5 (« Envoyer uniquement une réponse NTLMv2. Refuser LM et NTLM ») via une GPO.

Sur Windows Server 2025, vous pouvez bloquer NTLM sur SMB directement avec Set-SmbClientConfiguration -BlockNTLM $trueExpand.

Auditez l'utilisation de NTLM avant de la restreindre afin d'identifier les dépendances applicatives. Appliquez la signature SMB côté client et côté serveur avec RequireSecuritySignature $trueExpand de chaque côté.

Configurez des politiques de mots de passe robustes et déployez LAPS

Utilisez des stratégies de mot de passe affinées (PSO) pour les comptes privilégiés. Les PSO ne peuvent être attribuées qu'à des utilisateurs AD ou à des groupes de sécurité globaux, et non directement à des unités d'organisation (OU) :

      New-ADFineGrainedPasswordPolicy -Name "AdminPSO" -Precedence 10 `
  -MinPasswordLength 20 -PasswordHistoryCount 24 `
  -ComplexityEnabled $true -MaxPasswordAge "30.00:00:00" `
  -LockoutThreshold 5 -LockoutDuration "0.12:00:00"

Add-ADFineGrainedPasswordPolicySubject -Identity "AdminPSO" -Subjects "Domain Admins"
      

Déployez Microsoft Local Administrator Password Solution (LAPS) pour faire pivoter automatiquement les mots de passe administrateur local sur chaque terminal. LAPS élimine le chemin de déplacement latéral qui découle du partage des identifiants d'administrateur local.

Le déploiement nécessite d'étendre le schéma AD avec les attributs LAPS et de configurer la stratégie de groupe. Supprimez tout compte comportant les indicateurs « Le mot de passe n'expire jamais » ou « Mot de passe non requis ».

Sécurisez les comptes de service avec les MSA et gMSA

Remplacez les comptes de service autonomes par des comptes de service gérés de groupe (gMSA), qui prennent en charge la gestion automatique des mots de passe par le système d'exploitation et fonctionnent sur plusieurs serveurs :

      New-ADServiceAccount -Name "svc-webapp" -DNSHostName "webapp.domain.com" `
  -PrincipalsAllowedToRetrieveManagedPassword "WebServers-Group"
      

Windows Server 2025 introduit les Delegated MSAs (dMSAs), qui restreignent davantage l'utilisation des comptes à un appareil spécifique. Là où subsistent des comptes autonomes, appliquez des stratégies de mot de passe affinées et restreignez les droits d'ouverture de session. Auditez régulièrement vos SPN : les SPN orphelins sur des comptes inutilisés constituent une surface d'attaque directe pour le Kerberoasting.

Auditer et restreindre la délégation AD

Auditez les comptes configurés avec une délégation sans contrainte, qui permet à toute machine disposant de cet attribut d'usurper l'identité de tout utilisateur qui s'y authentifie :

      # Computers with unconstrained delegation (excludes DCs)
Get-ADComputer -Filter {TrustedForDelegation -eq $true -and primarygroupid -eq 515} `
  -Properties trustedfordelegation, serviceprincipalname, description

# Users with unconstrained delegation
Get-ADUser -Filter {TrustedForDelegation -eq $true} `
  -Properties TrustedForDelegation, ServicePrincipalName, Description
      

Reconfigurez tout objet découvert pour la délégation contrainte ou la délégation contrainte basée sur les ressources (RBCD). Marquez les comptes privilégiés sensibles comme « Le compte est sensible et ne peut pas être délégué. » Surveillez l'événement 5136 pour détecter les modifications de msDS-AllowedToActOnBehalfOfOtherIdentityExpand (abus de RBCD) et msDS-AllowedToDelegateToExpand (abus de délégation contrainte).

Protéger LSASS contre le vol d'identifiants

Appliquez une protection en couches contre l'extraction des identifiants depuis LSASS :

1. Protection LSA (RunAsPPL) : Configurez LSASS pour qu'il s'exécute en tant que Protected Process Light via le registre. Cela empêche les processus non protégés de lire la mémoire de LSASS ou d'y injecter du code. Appliquez un verrou UEFI au paramètre RunAsPPL via les variables Secure Boot, ce qui lie la protection au micrologiciel et nécessite un accès physique pour la désactiver.
2. Windows Defender Credential Guard : Activez-le sur les postes de travail et serveurs membres Windows 10/Server 2016+ via une GPO. Credential Guard isole les hachages NTLM et les TGT Kerberos dans la sécurité basée sur la virtualisation (VBS). Remarque : Credential Guard exclut explicitement les contrôleurs de domaine.
3. Règles ASR : Activez la règle de réduction de la surface d'attaque LSASS pour bloquer l'extraction des informations d'identification en mode utilisateur. Si la protection LSA est déjà activée, la règle ASR n'apporte aucune protection supplémentaire, mais utilisez-la comme couche de secours lorsque RunAsPPL ne peut pas être déployé.
4. Désactiver WDigest : Définissez UseLogonCredential = 0 dans HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\WDigestExpand pour empêcher la mise en cache des identifiants en texte clair. L'acteur malveillant Storm-1175 a été observé en train d'activer WDigest comme étape de vol d'identifiants dans les opérations de rançongiciel Medusa.

Supprimez les objets obsolètes et examinez les appartenances aux groupes

Examinez les comptes inactifs depuis 90 jours ou plus et désactivez-les avant de les supprimer :

      Get-ADUser -Filter {Enabled -eq $true -and LastLogonDate -lt [datetime]::Today.AddDays(-90)}
      

Examinez les appartenances aux groupes imbriqués : les groupes profondément imbriqués masquent les autorisations effectives et créent des voies d'escalade de privilèges que les audits de routine ne détectent pas. Les comptes obsolètes appartenant à des groupes privilégiés ne déclenchent jamais d'alertes basées sur l'activité. Flagler Bank a obtenu des résultats avec Netwrix Auditor en 30 minutes et a réduit les enquêtes AD de plusieurs heures à 10 minutes, démontrant comment des cycles d'examen plus rapides rendent durable une hygiène AD régulière.

Activez la MFA pour les accès privilégiés et distants

Exigez la MFA pour toutes les connexions d'administrateur de domaine et pour tout chemin d'accès à distance (VPN, passerelle RDP, appareils joints à Entra ID).

Microsoft a commencé à imposer la MFA obligatoire pour l'accès au portail Azure et au centre d'administration en octobre 2024, et l'a étendue au centre d'administration Microsoft 365 en février 2025.

La phase 2 (octobre 2025) a étendu l'application à Azure CLI, PowerShell, aux applications mobiles et aux outils d'infrastructure-as-code (IaC).

Pour les environnements hybrides, configurez des stratégies d'accès conditionnel Entra ID afin d'imposer une MFA résistante au phishing en fonction du rôle d'annuaire, de l'emplacement ou de l'état de l'appareil. Excluez toujours les comptes d'accès d'urgence pour éviter tout verrouillage administratif.

La MFA n'empêche pas le vol d'identifiants, mais elle met fin à la capacité de l'attaquant à réutiliser les identifiants volés pour obtenir un accès ultérieur.

Surveillance de la sécurité d'Active Directory

Le fait que Windows génère ou non les événements nécessaires pour détecter les attaques ci-dessus dépend des catégories de stratégie d'audit activées sur vos contrôleurs de domaine et vos serveurs membres. Les événements ci-dessous ne sont pas générés par les paramètres d'audit par défaut.

Plusieurs des signaux les plus importants nécessitent une configuration explicite de la stratégie d'audit et de la liste de contrôle d'accès système (SACL) sur l'objet racine du domaine avant que des événements n'apparaissent.

Identifiants d'événements critiques à surveiller

Remarque sur le volume : L'événement 4769 génère un volume élevé sur les contrôleurs de domaine. Filtrez sur TicketEncryptionType=0x17Expand (RC4) pour limiter le bruit. Évitez d'activer l'audit des échecs pour l'accès au service d'annuaire ; ces journaux peuvent se remplir à plus de 10 millions lorsqu'une seule erreur se produit.

Détecter les abus DCSync et Kerberos

La détection DCSync nécessite à la fois une stratégie d'audit avancée et une configuration SACL sur l'objet racine du domaine. Ajoutez une entrée d'audit de réussite sur la racine du domaine pour Tout le monde, couvrant Replicating Directory Changes, Replicating Directory Changes All et Replicating Directory Changes In Filtered Set. N'activez pas l'audit des échecs.

Alerte sur l'événement 4662 où AccessMask = 0x100 et où Properties contient l'un des GUID de réplication suivants provenant d'une source non-DC :

• 1131f6aa-9c07-11d1-f79f-00c04fc2dcd2Expand (DS-Replication-Get-Changes)
• 1131f6ad-9c07-11d1-f79f-00c04fc2dcd2Expand (DS-Replication-Get-Changes-All)
• 9923a32a-3607-11d2-b9be-0000f87a36b2 Expand(DS-Replication-Synchronize)
• 89e95b76-444d-4c62-991a-0facbeda640cExpand (DS-Replication-Get-Changes-In-Filtered-Set)

Excluez les comptes NT AUTHORITY/MSOL_ et les comptes d'ordinateur. Corrélez l'événement 4662 avec l'événement 4624 via LogonId pour extraire l'adresse IP source.

Surveillez l'Event ID 4769 comme principal indicateur du Kerberoasting.TicketOptions = 0x40810000Expand est le modèle de valeur le plus courant, mais les attaquants sophistiqués font varier les indicateurs d'options de ticket spécifiquement pour échapper à cette signature. Considérez-le comme un signal de départ fiable, et non comme un ensemble complet de règles de détection.

Alertez immédiatement en cas d'occurrence unique pour les comptes de service de grande valeur et en cas de 5 ServiceNames uniques ou plus en 10 minutes à partir du même Account_Name pour l'énumération en masse.

Insight Credit Union a réduit le temps de détection des ransomwares de plusieurs heures à quelques minutes en utilisant des alertes en temps réel pour les anomalies comportementales, démontrant comment un paramétrage affiné des alertes change le résultat concret de ces détections.

Surveiller les modifications des groupes et objets privilégiés

Recevez des alertes sur les modifications apportées aux groupes Admins du domaine, Admins de l'entreprise, Admins du schéma, Administrateurs, Opérateurs de compte et Opérateurs de sauvegarde via les événements 4728, 4732 et 4756 pour les ajouts de membres.

Alertez lors de la création, de la modification ou de la suppression d'objets d'annuaire liés aux GPO via les événements 5136, 5137 et 5141. Surveillez l'événement 5136 pour détecter les modifications des attributs suivants pertinents pour les attaques :

• msDS-AllowedToActOnBehalfOfOtherIdentity Expand(abus RBCD)
• msDS-AllowedToDelegateToExpand (abus de délégation contrainte)
• servicePrincipalName sur les objets utilisateurExpand (configuration de Kerberoasting ciblé)
• msDS-KeyCredentialLinkExpand (attaque Shadow Credentials)

Suivez les modifications apportées à l'objet AdminSDHolder : des changements ici peuvent accorder silencieusement des autorisations élevées persistantes. Toutes les modifications d'objets AD devraient capturer les valeurs avant et après, et pas seulement l'événement de modification, afin de soutenir la reconstruction forensique et de déterminer si une modification était autorisée.

Liste de contrôle de la sécurité d'Active Directory

1. Limitez les comptes Domain Admins, Enterprise Admins et Schema Admins au minimum opérationnel
2. Mettez en œuvre un modèle d'accès hiérarchisé ; utilisez des PAW pour l'administration de niveau 0
3. Déployer LAPS pour la rotation des mots de passe de l'administrateur local
4. Remplacez les comptes de service autonomes par des MSA ou des gMSA
5. Désactivez SMBv1 ; limitez NTLM ; imposez un niveau d'authentification LAN Manager de NTLMv2 au minimum
6. Auditez les comptes avec délégation non contrainte ; migrez vers la délégation contrainte
7. Activez Credential Guard sur les machines membres et RunAsPPL sur LSASS
8. Examinez régulièrement les comptes inactifs ; désactivez-les avant de les supprimer
9. Configurez l'audit SACL sur l'objet racine du domaine et activez la stratégie d'audit avancée
10. Surveillez les ID d'événements 4662, 4769 (tickets RC4) et 4728/4732/4756 via SIEM
11. Exiger la MFA pour toutes les connexions à privilèges et les accès distants
12. Testez régulièrement les procédures de sauvegarde et de récupération FSMO

Sécurisez Active Directory à grande échelle avec Netwrix

AD est le système le plus critique de votre environnement. Les pratiques de renforcement ci-dessus éliminent de nombreux points d'exposition courants, mais la dérive de configuration et l'accumulation de privilèges sont des processus continus.

Un compte de service ajouté aux administrateurs du domaine aujourd'hui, un paramètre de délégation modifié lors d'une urgence et jamais rétabli, un compte inactif laissé activé après le départ d'un employé : chacun rouvre une surface d'attaque qu'un travail antérieur avait fermée. Une sécurité AD durable exige une visibilité permanente sur chaque changement.

Netwrix Auditor enregistre les valeurs avant et après des événements d'accès et de modification dans les environnements Microsoft hybrides, fournissant aux équipes la piste d'audit nécessaire à la reconstruction forensique et aux rapports de conformité.

Netwrix PingCastle fournit une évaluation gratuite de la sécurité AD qui note les risques par rapport aux contrôles des frameworks MITRE ATT&CK et ANSSI, générant des résultats priorisés sans aucune connexion Internet requise.

Netwrix Threat Prevention bloque l'activité des attaques au niveau de la couche protocole avant que les déplacements latéraux ne commencent.

Demandez une démonstration pour découvrir comment Netwrix peut vous aider à détecter les modifications non autorisées dans l'AD, à surveiller l'activité des comptes à privilèges et à maintenir une couverture d'audit sur l'ensemble de votre environnement Active Directory.