Réduire NTLM dans Active Directory : une feuille de route réaliste en six étapes
Microsoft a clairement indiqué sa volonté de faire reculer NTLM au profit de Kerberos, et le protocole est désormais considéré comme obsolète. Pourtant, dans la plupart des domaines, il reste utilisé chaque jour par des applications, des équipements et des scripts. Le supprimer brutalement serait risqué ; le réduire méthodiquement est à la portée de toute équipe.
Pourquoi NTLM pose problème
NTLM est un protocole de type défi-réponse qui n'authentifie pas le serveur et ne lie pas nativement l'authentification à la session qui la transporte. Il est donc vulnérable au relais : un attaquant qui provoque une authentification, par exemple via une coercition de type PetitPotam ou un empoisonnement LLMNR, peut la rejouer vers LDAP, SMB ou un service web d'AD CS. NTLMv1 et LM aggravent encore le risque, car leurs réponses se cassent très facilement.
Étape 1 : mesurer avant d'agir
Commencez par l'audit. Sur les contrôleurs de domaine, la stratégie « Sécurité réseau : Restreindre NTLM : Auditer l'authentification NTLM dans ce domaine » génère des événements dans le journal Microsoft-Windows-NTLM/Operational, notamment l'événement 8004, qui indique le compte, la machine source et le serveur cible. Sur les serveurs, l'audit du trafic NTLM entrant produit des événements similaires. L'événement 4624 précise aussi le package d'authentification et la version de NTLM utilisée. Prévoyez plusieurs semaines de collecte pour couvrir les traitements mensuels.
Étape 2 : éliminer NTLMv1 et LM
Configurez « Sécurité réseau : niveau d'authentification LAN Manager » sur « Envoyer uniquement les réponses NTLMv2. Refuser LM et NTLM » (niveau 5), après avoir identifié les rares clients qui utilisent encore NTLMv1 grâce à l'événement 4624. Microsoft a annoncé le retrait de NTLMv1 dans Windows 11 24H2 et Windows Server 2025 ; vérifiez le comportement exact sur vos versions.
Étape 3 : corriger les causes du repli sur NTLM
La plupart des usages NTLM ne sont pas voulus. Les causes courantes sont :
- l'accès à un serveur par adresse IP plutôt que par nom ;
- des SPN manquants ou dupliqués ;
- des applications qui imposent NTLM au lieu de Negotiate ;
- l'utilisation de comptes locaux ou de machines hors domaine ;
- des équipements tiers (NAS, copieurs, appliances) aux implémentations limitées.
Étape 4 : protéger contre le relais
En parallèle, réduisez l'impact du relais : signature SMB exigée, signature LDAP et liaison de canal sur les contrôleurs de domaine, protection étendue de l'authentification (EPA) sur les services web d'AD CS et IIS, désactivation de LLMNR et NBT-NS. Ces mesures rendent NTLM beaucoup moins exploitable, même avant sa réduction.
Étape 5 : restreindre progressivement
Les stratégies « Restreindre NTLM » permettent de refuser NTLM par serveur ou par domaine, avec une liste d'exceptions. Procédez par cercles : d'abord les comptes à privilèges (le groupe Protected Users interdit NTLM à ses membres), puis les serveurs sensibles, puis le reste du parc.
Ne jamais bloquer à l'aveugle. Chaque restriction doit être précédée d'une période d'audit sur le même périmètre. Une exception documentée et temporaire vaut mieux qu'un retour arrière en urgence.
Étape 6 : suivre et maintenir
Suivez le volume d'authentifications NTLM comme un indicateur, revoyez les exceptions régulièrement et intégrez l'exigence Kerberos dans les critères d'achat des nouvelles applications. Microsoft travaille sur des fonctionnalités destinées à couvrir les derniers cas d'usage de NTLM ; leur disponibilité dépendra des versions de Windows, restez donc prudent dans votre calendrier.
Ce qu'un audit vérifie
- le niveau d'authentification LAN Manager appliqué aux contrôleurs de domaine et aux membres ;
- l'activation de l'audit NTLM ;
- les mesures anti-relais : signature SMB et LDAP, liaison de canal, EPA ;
- l'utilisation du groupe Protected Users pour les comptes privilégiés.