Alors que je rédigeais un article de blog sur NTLMv1 et Windows Server 2025, je me suis souvenu d'un problème ancien, bien connu, mais souvent mal compris : les niveaux d'authentification LAN Manager mal configurés. Ce paramètre d'authentification spécifie le protocole d'échange de défis et de réponses utilisé pour les connexions réseau lorsque Kerberos n'est pas négocié.
Pourquoi il n'est pas recommandé d'utiliser le niveau d'authentification 2 (ou un niveau inférieur)
L'une des erreurs de configuration les plus courantes que je rencontre dans les environnements Active Directory est un niveau d'authentification LAN Manager défini sur 2 ou moins sur les contrôleurs de domaine (DC). Ce niveau d'authentification peut être défini de deux manières :
- Via la stratégie de groupe :
Network security: LAN Manager authentication level - Directement via la clé de registre :
HKLM\System\CurrentControlSet\Control\Lsa\LmCompatibilityLevel
La raison pour laquelle l'authentification est réglée sur 2 est presque toujours la même : « Nous avons des applications héritées qui s'authentifient à l'aide de NTLMv1, et nous ne pouvons pas prendre le risque de les endommager. »
Cette logique est compréhensible. Mais elle conduit à une erreur subtile et critique.
Quelle est la différence entre les niveaux d'authentification 2 et 3 de LAN Manager ?
Le paramètre de niveau d'authentification LAN Manager contrôle à la fois le comportement d'authentification entrant et sortant, qui ne sont pas identiques.
Régler le niveau sur 2 signifie que :
- Le DC accepte l'authentification NTLMv1 entrante.
- Le DC utilise également NTLMv1 pour initier les connexions sortantes.
Ce deuxième point crée une vulnérabilité.
En revanche, régler le niveau sur 3 signifie que :
- Le DC accepte toujours les requêtes entrantes NTLMv1 (afin que les clients hérités continuent de fonctionner).
- Le DC est empêché d'envoyer des connexions sortantes NTLMv1.
En d'autres termes, l'utilisation du niveau 3 préserve la compatibilité tout en éliminant une surface d'attaque importante.
Pourquoi l'envoi de NTLMv1 depuis un contrôleur de domaine est dangereux
Les contrôleurs de domaine sont des cibles de grande valeur. Si un pirate parvient à contraindre un contrôleur de domaine à effectuer une tentative d'authentification sortante (à l'aide de techniques telles que PrinterBug, DFSCoerce, PetitPotam ou d'autres méthodes de coercition similaires) et si cette authentification utilise NTLMv1, la réponse capturée est nettement plus faible que celle qui utilise NTLMv2.
Les réponses NTLMv1 peuvent souvent être piratées rapidement à l'aide de matériel moderne ou de tables précalculées. Un pirate peut ainsi obtenir le hachage NT du mot de passe du compte informatique.
Mais cela ne s'arrête pas là...et c'est là que la différence devient vraiment cruciale.
Les pirates n'ont même pas besoin du hachage NT.
Au lieu de cela, ils peuvent relayer l'authentification NTLMv1 forcée directement vers un autre contrôleur de domaine sur lequel la liaison du canal LDAPS n'est pas imposée (une autre erreur de configuration alarmant courante). En relayant l'authentification du compte machine du contrôleur de domaine via LDAP, l'attaquant
peut mener l'une des deux attaques dévastatrices suivantes :
Les deux voies mènent au même résultat : le contrôle total du DC. De la coercition initiale à la compromission complète du domaine, cela peut prendre moins d'une minute.
Aucun craquage de hachage nécessaire. Aucun privilège élevé requis pour démarrer. Il suffit d'un contrôleur de domaine compatible NTLMv1 et d'une absence d'application de liaison de canal LDAP.
Ce qu'il faut retenir dans la pratique
Si vous restez au niveau d'authentification 2 (ou inférieur) de LAN Manager pour des raisons de compatibilité avec des applications héritées, vous pouvez passer au niveau 3 dès aujourd'hui sans que cela n'affecte le fonctionnement de ces applications.
Vous pouvez réserver les niveaux 4 et 5 pour le moment où vous serez prêt à abandonner complètement LM et NTLMv1 dans votre environnement, car ces niveaux commencent à refuser l'authentification NTLMv1 entrante. (Remarque : dans Windows Server 2025, les connexions sortantes utilisant LM et NTLMv1 ne sont plus autorisées.)
Gardez cette progression à l'esprit :
- Niveau 2 : le contrôleur de domaine accepte les authentifications LM et NTLMv1 entrantes et envoie des authentifications NTLMv1 sortantes. Les applications héritées fonctionnent, mais les contrôleurs de domaine sont exposés.
- Niveau 3 : le contrôleur de domaine accepte les authentifications LM et NTLMv1 entrantes, mais n'envoie pas de NTLMv1 sortantes. Les applications héritées continuent de fonctionner et vos contrôleurs de domaine sont protégés.
- Niveau 4 : le contrôleur de domaine envoie des requêtes NTLMv2 sortantes, refuse les requêtes LM entrantes, mais accepte toujours les requêtes NTLMv1 entrantes. Il est compatible avec la plupart des applications et protège vos contrôleurs de domaine.
- Niveau 5 : Le contrôleur de domaine refuse complètement toutes les authentifications LM et NTLMv1 entrantes et sortantes. Ce niveau offre une sécurisation totale, mais les applications héritées ne fonctionnent plus.
Si vous gérez des contrôleurs de domaine (DC) dans un environnement soumis à des exigences d'authentification héritées, le niveau 3 doit constituer votre seuil minimal. Régler le niveau d'authentification de LAN Manager sur le niveau 3 est une modification à faible risque et à fort bénéfice qui est souvent négligée en raison d'idées reçues profondément ancrées concernant la compatibilité.
