Qu'est-ce que NTLM ? Risques de sécurité NTLM sous Windows & guide de migration

NTLM est un protocole d'authentification Windows présentant des vulnérabilités critiques. Découvrez les attaques Pass-the-Hash, les risques de relais et la migration avant octobre 2026.

Qu'est-ce que NTLM ?

NTLM (NT LAN Manager) est un protocole d’authentification Windows qui valide les utilisateurs via une authentification par défi-réponse sans transmettre les mots de passe sur le réseau. Selon la documentation officielle de Microsoft, NTLM englobe plusieurs versions de protocole, dont l’ancien LAN Manager, NTLMv1 et la norme actuelle NTLMv2. Bien que Kerberos ait remplacé NTLM comme  mécanisme d’authentification privilégié pour les environnements Active Directory il y a plus de vingt ans, NTLM reste actif dans les réseaux d’entreprise pour l’authentification en groupe de travail, les connexions locales sur des contrôleurs non-domaine, et dans les scénarios où la négociation Kerberos échoue.

Le processus de défi-réponse fonctionne via un échange simple. Lorsque vous vous connectez à une ressource réseau, le serveur envoie à votre client un défi de 16 octets. Votre système chiffre ce défi à l’aide du hachage de votre mot de passe et renvoie la réponse au serveur, qui valide ces informations d’identification auprès de la base de données Security Accounts Manager ou d’Active Directory. L’authentification s’effectue avec uniquement des hachages chiffrés transmis, jamais votre mot de passe réel. Ce choix de conception, traitant les hachages comme preuve d’identité, a créé les vulnérabilités de sécurité exploitées aujourd’hui par les attaquants.

Pourquoi NTLM est un risque de sécurité

Les statistiques sur le vol d’identifiants montrent que 31 % de toutes les violations au cours de la dernière décennie impliquaient un vol d’identifiants, selon le  Verizon 2025 Data Breach Investigations Report. Les attaques NTLM représentent une part importante de cette menace persistante car le protocole stocke des hachages de mots de passe que les attaquants peuvent voler et réutiliser sans jamais casser le mot de passe réel.

Les attaquants extraient les hachages NTLM de la mémoire ou du trafic réseau, puis s’authentifient auprès des serveurs de fichiers et des contrôleurs de domaine en passant directement les hachages volés à Windows. Vos contrôles de sécurité voient une authentification NTLM légitime alors que l’attaque se déroule de manière invisible.

La CISA a ajouté la CVE-2025-24054, une vulnérabilité de divulgation de hachage NTLM sous Windows, à son  catalogue des vulnérabilités exploitées connues en mars 2025 après une exploitation active confirmée. Bien que Microsoft ait corrigé la vulnérabilité en mars 2025, la surface d’attaque persiste car la dépréciation de NTLM nécessite une migration coordonnée de l’infrastructure d’identité, des applications et des services réseau. Ce calendrier est particulièrement important compte tenu de la date limite d’octobre 2026 fixée par Microsoft pour l’application automatique de NTLMv1.

Comment fonctionne l’authentification NTLM

L’architecture de NTLM explique pourquoi les attaquants réussissent à compromettre votre environnement et pourquoi la migration présente une complexité importante.

• Package d’authentification et stockage des hachages : Le package d’authentification MSV1_0 gère toute l’authentification NTLM via le composant Msv1_0.dll. En compromettant la mémoire LSASS, les attaquants extraient directement les hachages de mots de passe. Votre environnement stocke deux types de hachages : le hachage LM utilise un chiffrement DES obsolète sans sensibilité à la casse, permettant des attaques par tables arc-en-ciel triviales, tandis que le hachage NT utilise MD4 avec sensibilité à la casse. Les deux résident dans SAM ou Active Directory et servent eux-mêmes d’informations d’identification : aucun cassage de mot de passe requis.
• Mécanisme de défi-réponse : Le serveur génère un défi aléatoire de 16 octets, votre poste de travail le chiffre à l’aide du hachage de votre mot de passe, et le serveur valide la réponse via l’API LsaLogonUser. NTLMv2 utilise un calcul de réponse basé sur HMAC-MD5 avec des données aléatoires supplémentaires, offrant une protection cryptographique renforcée. Les deux protocoles partagent une vulnérabilité fondamentale : les hachages de mots de passe servent eux-mêmes d’informations d’identification (MITRE ATT&CK T1550.002).
• Niveaux d’authentification LAN Manager : La clé de registre HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel détermine quelles versions de NTLM vos systèmes acceptent. La plupart des entreprises fonctionnent au niveau 3 (envoyer uniquement la réponse NTLMv2) contre le niveau 5 recommandé par le NIST (refuser LM et NTLM entièrement), créant des failles exploitables.

Ces composants architecturaux, en particulier le stockage des hachages dans la mémoire LSASS et le mécanisme d’authentification pass-through, offrent aux attaquants de multiples opportunités d’intercepter ou d’extraire des identifiants.

Outils et techniques d’attaque NTLM

Les attaquants utilisent des outils spécialisés pour exploiter les vulnérabilités NTLM à des fins de vol d’identifiants et de  mouvement latéral. Comprendre ces outils aide les défenseurs à reconnaître les schémas d’attaque et à mettre en œuvre les contrôles appropriés.

• Outils d’extraction d’identifiants ciblent la mémoire LSASS où Windows stocke les hachages de mots de passe lors des sessions actives.  Mimikatz reste l’outil le plus reconnu, utilisant des techniques comme sekurlsa::logonpasswords pour extraire les identifiants de la mémoire. Les attaquants utilisent également des méthodes natives Windows, notamment les commandes reg save pour exporter les hives de registre SAM et SYSTEM afin d’extraire les hachages hors ligne. Les outils de forensic mémoire comme WCE (Windows Credentials Editor) offrent des capacités d’extraction supplémentaires qui échappent à certaines solutions de détection des endpoints.
• Frameworks Pass-the-Hash permettent l’authentification à l’aide de hachages volés sans nécessiter de cassage de mot de passe. La boîte à outils Python d’Impacket inclut les modules psexec.py et wmiexec.py qui acceptent directement les hachages NTLM pour l’exécution de commandes à distance sur des systèmes Windows. CrackMapExec automatise les attaques Pass-the-Hash sur plusieurs cibles simultanément, permettant un mouvement latéral rapide dans les réseaux d’entreprise tout en enregistrant les authentifications réussies pour une exploitation ultérieure. Ces frameworks intègrent des capacités de hash spraying pour identifier les systèmes acceptant les identifiants compromis.
• Kits d’outils de relais NTLM interceptent et transmettent les demandes d’authentification vers des systèmes cibles non autorisés. Responder capture l’authentification NTLM en empoisonnant les réponses de résolution de noms LLMNR, NBT-NS et MDNS sur les segments réseau locaux. Lorsque les systèmes tentent de résoudre des noms d’hôtes, Responder répond avec des adresses IP contrôlées par l’attaquant, capturant les tentatives d’authentification. Le module ntlmrelayx d’Impacket relaie l’authentification capturée vers les services SMB, LDAP, HTTP et MSSQL, permettant une élévation de privilèges lorsque l’Extended Protection for Authentication n’est pas activée sur les services critiques.
• Techniques de coercition forcent les systèmes cibles à initier une authentification vers des serveurs contrôlés par l’attaquant sans interaction utilisateur. PetitPotam exploite l’interface MS-EFSRPC pour contraindre les contrôleurs de domaine à s’authentifier vers des destinations arbitraires, permettant la capture directe d’identifiants ou des attaques de relais contre les Active Directory Certificate Services. PrinterBug (également appelé SpoolSample) abuse de l’interface distante du service Print Spooler pour obtenir une authentification contrainte similaire. Ces techniques contournent totalement les exigences traditionnelles de phishing, permettant le vol d’identifiants à partir de systèmes qui n’interagissent jamais avec du contenu malveillant.

La détection défensive se concentre sur la surveillance des signatures d’outils en mémoire, des accès anormaux à LSASS, des flux d’authentification inattendus et du trafic réseau indiquant des tentatives de relais. Cependant, la détection seule ne peut pas résoudre les faiblesses fondamentales du protocole qui rendent ces attaques possibles.

Vulnérabilités NTLM

Les faiblesses architecturales du protocole créent des failles de sécurité persistantes que les contrôles côté défenseur ne peuvent pas entièrement combler sans protections complémentaires au niveau réseau et identité.

• Attaques Pass-the-Hash (MITRE ATT&CK T1550.002) exploitent la dépendance de NTLM aux hachages de mots de passe comme informations d’identification. Une fois que les attaquants extraient votre hachage de la mémoire LSASS, de la base SAM ou de captures réseau, ils s’authentifient en votre nom sans connaître votre mot de passe. Credential Guard offre une protection partielle via la sécurité basée sur la virtualisation sur Windows 10 Enterprise ou Windows 11 avec matériel TPM 2.0. Les protections réseau telles que la signature SMB, la signature LDAP et l’Extended Protection for Authentication stoppent les attaques de relais NTLM.
• Attaques de relais NTLM manipulent le mécanisme de défi-réponse en interceptant l’authentification entre le client et le serveur. L’attaquant reçoit votre tentative d’authentification, la relaie vers un système cible de son choix et obtient un accès non autorisé en utilisant vos identifiants en temps réel. L’Extended Protection for Authentication arrête les attaques de relais via le channel binding, mais nécessite une configuration explicite sur Exchange Server, Active Directory Certificate Services et LDAP. La plupart des entreprises exécutent ces services critiques sans EPA activé car Microsoft a historiquement livré les produits avec EPA désactivé par défaut.
• Faiblesses cryptographiques dans les versions héritées persistent dans les environnements de production. Les hachages LM utilisent le chiffrement DES, un algorithme cryptographiquement cassé, tout en convertissant les mots de passe en majuscules et en les divisant en segments de 7 caractères. NTLMv1 améliore la robustesse cryptographique mais reste vulnérable aux attaques par force brute hors ligne. Seul NTLMv2 offre des  protections cryptographiques modernes, mais de nombreuses organisations fonctionnent dans des environnements mixtes acceptant NTLMv1 pour la rétrocompatibilité.

La date limite d’application d’octobre 2026 crée un risque opérationnel pour les organisations ayant retardé la migration. Microsoft a établi un calendrier en trois phases :

1. Phase 1 (décembre 2024) : Dépréciation initiée
2. Phase 2 (septembre 2025) : Activation du mode audit par défaut
3. Phase 3 (octobre 2026) : Transition automatique de la clé de registre BlockNtlmv1SSO en mode application sans intervention de l’administrateur

Les organisations n’ayant pas commencé la planification de la migration s’exposent à un risque important de perturbation de l’authentification lors de l’application de la mesure.

Comment migrer hors de NTLM

La migration NTLM en entreprise nécessite une exécution structurée par phases avec un parrainage exécutif. La mise en œuvre complète s’étend généralement sur 18 à 22 mois selon la complexité de l’environnement et les dépendances applicatives héritées.

Phase 1 : Découverte et audit (mois 1-3)

Activez l’audit NTLM complet sur tous les contrôleurs de domaine et serveurs membres avant toute tentative de migration ou de blocage. Configurez Network security: Restrict NTLM: Audit NTLM authentication in this domain sur « Audit all » plutôt que sur blocage. Windows 11 24H2 et Windows Server 2025 fournissent des événements d’audit enrichis capturant les noms de processus, codes de raison, nom d’utilisateur et domaine, et version NTLM. Collectez les journaux d’audit pendant au moins 30 à 90 jours pour capturer les services périodiques, tâches planifiées et processus mensuels. Analysez les journaux pour établir un inventaire complet des dépendances, catégorisé par type de système, application et complexité de remédiation.

Phase 2 : Planification de la remédiation (mois 4-6)

Catégorisez les dépendances NTLM par approche et complexité de remédiation. Les systèmes en groupe de travail peuvent nécessiter une jonction au domaine, une inscription Azure AD ou une exception maintenue avec segmentation réseau. Les applications héritées nécessitent l’engagement du fournisseur pour des délais de prise en charge Kerberos ou une planification de remplacement si le fournisseur ne propose pas de chemin de migration. Les équipements réseau avec limitations de firmware nécessitent une planification de mise à niveau, un renouvellement ou des stratégies de segmentation réseau isolant le trafic NTLM.

Phase 3 : Déploiements pilotes Kerberos (mois 7-9)

Sélectionnez des unités organisationnelles à faible risque avec peu de dépendances héritées pour une première application Kerberos uniquement. Configurez Network security: Restrict NTLM: NTLM authentication in this domain sur « Deny all » uniquement dans le périmètre pilote. Surveillez de près les échecs d’authentification et les problèmes applicatifs, en documentant toutes les procédures de remédiation pour référence lors du déploiement en production. Validez que les systèmes pilotes conservent l’intégralité des fonctionnalités sans authentification NTLM.

Phase 4 : Déploiement en production (mois 10-18)

Étendez l’application Kerberos de manière systématique par unité organisationnelle selon les enseignements du pilote. Priorisez les environnements à haute sécurité contenant des données sensibles et des systèmes à accès privilégié. Maintenez des listes d’exceptions documentées pour les dépendances héritées avec des contrôles compensatoires incluant la segmentation réseau, la surveillance renforcée et une portée d’accès restreinte. Mettez en œuvre la segmentation réseau pour les systèmes nécessitant un accès NTLM continu afin de limiter l’exposition au mouvement latéral.

Phase 5 : Application (mois 19-22)

Activez BlockNtlmv1SSO avant la date limite d’application automatique d’octobre 2026 fixée par Microsoft. Validez la migration complète par un examen approfondi des journaux d’audit confirmant l’absence d’authentification NTLM dans le périmètre de production. Documentez les exceptions restantes avec acceptation formelle du risque et contrôles compensatoires à des fins de conformité et d’audit.

Pendant la planification de la migration, les organisations doivent également traiter les failles défensives immédiates. De nombreuses équipes de sécurité laissent involontairement leur environnement exposé en raison de protections incomplètes ou mal configurées.

Erreurs courantes de défense NTLM

Ne pas mettre en œuvre des défenses NTLM en couches crée des failles de sécurité exploitables.

1. Activer la signature SMB sans l’exiger. Vous configurez la stratégie de groupe pour activer le paramètre « Microsoft network server: Digitally sign communications » sur vos serveurs de fichiers tout en négligeant l’exigence complémentaire côté client. L’audit de configuration indique la conformité sur les serveurs, mais votre testeur d’intrusion démontre des attaques de relais NTLM réussies car « enable » permet une rétrogradation vers des connexions non signées lorsque les clients ne demandent pas la signature. Les deux configurations doivent être définies sur « Enabled » simultanément : côté serveur (Microsoft network server: Digitally sign communications (always)) ET côté client (Microsoft network client: Digitally sign communications (always)). Selon les  recommandations de sécurité SMB de Microsoft, configurer uniquement les serveurs crée une faille exploitable où les attaquants relaient via des clients mal configurés.
2. Supposer que Credential Guard arrête les attaques de relais NTLM. Vous déployez Credential Guard sur les postes administratifs à haute valeur et les contrôleurs de domaine, puis présentez la couverture Credential Guard à la direction comme une protection complète contre les attaques NTLM. Un attaquant compromet votre environnement via un relais NTLM contre un service LDAP non protégé sur un contrôleur de domaine. Credential Guard protège les identifiants au repos dans la mémoire LSASS via la sécurité basée sur la virtualisation, empêchant le vol d’identifiants sur les systèmes compromis, mais n’offre aucune protection contre les attaques de relais NTLM au niveau réseau. Les organisations doivent mettre en œuvre à la fois la protection des identifiants sur les endpoints et la prévention des relais au niveau réseau simultanément.
3. Implémenter EPA de manière incohérente sur les services critiques. Votre équipe sécurité a activé l’Extended Protection for Authentication sur Active Directory Certificate Services suite à PetitPotam en 2021, mais les attaquants relaient l’authentification NTLM vers votre service LDAP, qui fonctionne sans EPA activé. EPA doit être configuré sur tous les services compatibles NTLM, y compris AD CS, LDAP, Exchange Server et toute application personnalisée utilisant l’authentification intégrée Windows.

Éviter ces erreurs nécessite une approche systématique de la défense NTLM qui traite tous les vecteurs d’attaque simultanément.

Bonnes pratiques de défense NTLM

Stoppez le mouvement latéral basé sur les identifiants grâce à des contrôles en couches qui traitent les faiblesses du protocole aux niveaux réseau, endpoint et identité.

• Mettez en œuvre immédiatement l’audit complet des journaux NTLM. Activez les stratégies d’audit NTLM sur tous les contrôleurs de domaine et serveurs membres avant toute tentative de migration ou de blocage. Configurez Network security: Restrict NTLM: Audit NTLM authentication in this domain sur « Audit all » plutôt que sur blocage. Collectez les journaux d’audit pendant au moins 30 à 90 jours pour capturer les services périodiques et tâches planifiées, puis analysez-les pour établir un inventaire complet des dépendances.
• Appliquez la signature SMB de manière universelle dans votre environnement. Configurez les exigences de stratégie de groupe double dans Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options. Définissez à la fois Microsoft network server: Digitally sign communications (always) et Microsoft network client: Digitally sign communications (always) sur Enabled. La double configuration empêche les attaques de rétrogradation où clients et serveurs utilisent des paramètres de signature différents.
• Configurez l’Extended Protection for Authentication sur tous les services critiques. EPA ajoute le channel binding à l’authentification NTLM, empêchant le relais d’identifiants en liant l’authentification à la session TLS. La priorité de mise en œuvre EPA doit porter sur Active Directory Certificate Services, LDAP sur tous les contrôleurs de domaine et Exchange Server. Windows Server 2025 active EPA par défaut pour ces services.
• Déployez Credential Guard sur les systèmes à haute valeur. Implémentez Credential Guard sur les contrôleurs de domaine, postes administratifs et systèmes traitant des données sensibles. Credential Guard nécessite TPM 2.0, UEFI Secure Boot, extensions de virtualisation processeur et prise en charge Hyper-V.
• Exigez la signature LDAP sur tous les contrôleurs de domaine. Configurez Domain controller: LDAP server signing requirements sur « Require signing » via la stratégie de groupe appliquée à l’unité organisationnelle Domain Controllers. Windows Server 2025 ajoute le channel binding LDAP par défaut.
• Implémentez la corrélation d’événements pour l’identification Pass-the-Hash. Configurez votre  SIEM pour corréler les Event IDs de sécurité Windows sur plusieurs contrôleurs de domaine et serveurs membres. Alertez sur l’Event ID 4624 (connexion réussie) avec Logon Type 3 (connexion réseau) et package d’authentification « NTLM » pour les comptes privilégiés SANS Event ID 4624 Logon Type 2 (connexion interactive) correspondant dans les 10 heures précédentes depuis la même adresse IP source.

Ces contrôles manuels offrent une protection essentielle, mais les attaques basées sur les identifiants progressent souvent plus vite que les cycles d’investigation humaine. L’IA comportementale peut identifier et stopper l’activité Pass-the-Hash en temps réel.

Stoppez les attaques NTLM avec SentinelOne

Votre temps de réponse détermine si vous stoppez le mouvement latéral ou si vous enquêtez sur les conséquences d’une compromission. SentinelOne détecte les attaques basées sur les identifiants grâce à une IA comportementale qui reconnaît les techniques Pass-the-Hash classifiées MITRE ATT&CK T1550.002.

Singularity™ Identity offre également une visibilité de bout en bout sur les environnements hybrides pour détecter les expositions et stopper l’abus d’identifiants. Il réduit les risques liés à l’identité et propose une protection de l’identité en temps réel. Vous pouvez corréler l’activité endpoint et identité pour une détection contextuelle et un triage plus rapide. Il élimine également les angles morts dans les environnements cloisonnés et peut renforcer Active Directory et les fournisseurs d’identité cloud, y compris Okta, Ping, SecureAuth, Duo et Entra ID. Il peut recueillir des informations à partir de tentatives d’attaque pour stopper les compromissions répétées et prévenir l’élévation de privilèges.

SentinelOne est reconnu comme Leader du Magic Quadrant Gartner pour les plateformes de protection des endpoints depuis cinq années consécutives. Lors des évaluations MITRE ATT&CK, SentinelOne n’a généré que 12 alertes tandis qu’un concurrent majeur en a généré 178 000, soit 88 % d’alertes en moins. Cette réduction du bruit consolide des milliers d’événements de sécurité en incidents exploitables uniques, transformant l’investigation des abus d’identifiants d’un examen de milliers d’événements d’authentification à l’analyse d’un contexte forensique complet en quelques secondes.

La Singularity Platform offre des  capacités XDR unifiées via un agent et une console uniques, consolidant la sécurité endpoint, cloud et identité dans un seul data lake. La technologie brevetée Storyline surveille, suit et contextualise automatiquement les données d’événements sur l’ensemble de votre environnement d’entreprise pour reconstituer les attaques en temps réel.

Purple AI accélère les investigations sur les menaces grâce à des requêtes en langage naturel qui corrèlent les événements d’authentification dans votre environnement. Avec jusqu’à 80 % de rapidité supplémentaire dans la chasse aux menaces selon les premiers utilisateurs, les analystes sécurité peuvent rechercher dans les journaux sans connaître les langages de requête et recevoir un contexte d’attaque complet avec des suggestions d’étapes suivantes.

Demandez une démo pour voir comment l’IA comportementale de SentinelOne stoppe les attaques basées sur les identifiants avant l’élévation de privilèges.

Points clés à retenir

Les attaques NTLM exploitent le vol d’identifiants pour permettre le mouvement latéral avant que la réponse traditionnelle ne puisse les arrêter. La date limite d’application d’octobre 2026 impose une planification immédiate de la migration : Microsoft appliquera automatiquement le blocage de NTLMv1 en modifiant la clé de registre BlockNtlmv1SSO du mode audit au mode application sans intervention de l’administrateur.

Une défense efficace exige des contrôles en couches complémentaires : signature SMB sur les serveurs et clients, Extended Protection for Authentication sur les services critiques dont AD CS, LDAP et Exchange Server, Credential Guard pour la protection des identifiants sur les endpoints (en notant qu’il protège les identifiants au repos mais n’arrête PAS les attaques de relais réseau), et un audit complet pour identifier les dépendances avant l’application.

L’IA comportementale qui corrèle les schémas d’authentification sur les endpoints et l’infrastructure d’identité détecte l’abus d’identifiants avant qu’une élévation de privilèges ne se produise.

FAQ

Qu'est-ce que NTLM ?

NTLM (NT LAN Manager) est un protocole d’authentification Windows qui valide les utilisateurs via un mécanisme de défi-réponse sans transmettre les mots de passe sur le réseau. Le serveur envoie un défi aléatoire, le client le chiffre avec le hachage du mot de passe de l’utilisateur, et le serveur valide la réponse. 

Bien que Kerberos ait remplacé NTLM comme méthode d’authentification privilégiée pour Active Directory, NTLM reste actif dans les environnements de groupe de travail, les connexions locales et les scénarios d’applications héritées.

Quelle est la différence entre NTLMv1 et NTLMv2 ?

NTLMv1 utilise une cryptographie plus faible, vulnérable aux attaques par force brute hors ligne et aux attaques par texte en clair connu. NTLMv2 intègre un calcul de réponse basé sur HMAC-MD5 avec des données aléatoires et des capacités de liaison de canal, offrant une protection cryptographique nettement plus robuste. 

Microsoft appliquera automatiquement le blocage de NTLMv1 en octobre 2026, exigeant que tous les systèmes utilisent au minimum NTLMv2 ou migrent vers Kerberos.

Peut-on désactiver complètement NTLM dans les environnements d'entreprise ?

L'élimination complète de NTLM reste difficile en raison des dépendances avec les systèmes joints à un groupe de travail, des applications héritées sans prise en charge de Kerberos, des équipements réseau avec des limitations de firmware et des scénarios d'authentification inter-forêts. 

Windows Server 2025 introduit la possibilité de désactiver totalement SMB NTLM pour les connexions sortantes à distance. La suppression complète nécessite la correction des applications, le remplacement du matériel et des tests approfondis sur des périodes de migration de 18 à 22 mois.

Comment fonctionnent les attaques Pass-the-Hash ?

Les attaquants utilisent des outils comme Mimikatz pour extraire les hachages NTLM de la mémoire LSASS. Le hachage, une représentation MD4 de 16 octets de votre mot de passe, fonctionne comme un identifiant d’authentification à part entière. Lorsque Windows s’authentifie via NTLM, il compare les réponses chiffrées au défi, et non les mots de passe. 

Puisque l’attaquant possède le hachage permettant de générer des réponses valides, Windows ne peut pas distinguer une authentification légitime d’une attaque Pass-the-Hash sans contrôles supplémentaires comme Credential Guard ou EPA.

Qu'est-ce que la protection étendue pour l'authentification et pourquoi est-ce important ?

La protection étendue pour l’authentification ajoute la liaison de canal à l’authentification NTLM en liant les jetons d’authentification à la session TLS entre le client et le serveur. Cette liaison rend les informations d’identification relayées inutilisables même si elles sont interceptées, car les jetons de liaison de canal ne correspondront pas lorsque l’attaquant tentera de les relayer vers d’autres serveurs. 

EPA empêche les attaques de relais NTLM visant AD CS, LDAP, Exchange Server et d’autres services d’authentification intégrés à Windows. Windows Server 2025 active EPA par défaut sur les services critiques.