LmCompatibilityLevel est une stratégie Windows, pas un correctif VPN

Quelqu'un n'atteint pas un partage de fichiers par le VPN, lit que baisser LmCompatibilityLevel règle les problèmes NTLM et le modifie sur un serveur partagé. Le lendemain matin, d'autres applications échouent, et le problème d'origine est toujours là. Ce paramètre n'a jamais été un commutateur par tunnel ; c'est une déclaration à l'échelle de la machine sur les réponses d'authentification que ce système enverra et acceptera. Le changer pour réparer une seule ouverture de session réécrit les règles de chaque ouverture de session effectuée par la machine.

Lire les niveaux documentés est le moyen le plus rapide de cesser de traiter une valeur de stratégie comme un nombre magique.

Trois niveaux, trois promesses différentes

Le niveau 1 fait envoyer au client des réponses LM et NTLM, en utilisant la sécurité de session NTLMv2 lorsque la négociation le permet. Le niveau 3 fait envoyer au client uniquement des réponses NTLMv2, ce qui n'est pas la même chose que refuser toutes les réponses anciennes côté destinataire. Le niveau 5 maintient le client sur NTLMv2 et ajoute le refus documenté de LM et NTLMv1 par le contrôleur de domaine. Trois nombres, et l'écart entre eux est une décision de stratégie et non une préférence.

Ces différences expliquent pourquoi copier une valeur depuis un cas qui fonctionne n'est pas fiable. Déplacer un client mal configuré du niveau 1 vers la base de référence approuvée peut être correct. Déplacer un déploiement durci du niveau 5 vers le niveau 3 parce qu'un fil de forum a mentionné 3 relâche une frontière que quelqu'un a choisie délibérément, et cela pour chaque service avec lequel la machine dialogue.

Lisez la stratégie effective, pas une valeur de registre

Un examen en lecture seule de la valeur locale est un point de départ raisonnable : Get-ItemProperty -LiteralPath 'HKLM:\System\CurrentControlSet\Control\Lsa' -Name LmCompatibilityLevel. Une valeur absente ne signifie pas que la stratégie effective est nulle, car une stratégie de domaine ou une stratégie de sécurité locale peut la définir ailleurs, et le rôle de la machine change ce qu'elle fait de ce nombre.

Vérifiez la stratégie gérée, le rôle du système et la version réelle avant de conclure quoi que ce soit. Un poste de travail et un contrôleur de domaine avec la même valeur se comportent différemment en haut de l'échelle, et c'est ce que les gens oublient lorsqu'ils comparent deux machines.

Identifiez quelle authentification a réellement échoué

Les problèmes de tickets Kerberos, les refus NTLM et les échecs d'admission VPN nécessitent des preuves différentes. Gardez le service cible, le compte et l'erreur exacte ensemble dans une seule note, puis regardez ce que le service a demandé plutôt que ce que le client préfère. Cette note unique évite le faux pas le plus courant : modifier une valeur côté client pour répondre à un refus côté serveur.

Abaisser une stratégie à répétition jusqu'à ce qu'une erreur d'ouverture de session générique disparaisse n'est pas un diagnostic ; c'est un changement qui cache la preuve. Si l'application utilise Kerberos, le niveau de compatibilité NTLM n'est même pas le contrôle pertinent, et vous avez relâché une frontière pour rien.

Certaines prises en charge de protocole ne peuvent pas être restaurées

Windows 11 24H2 et Windows Server 2025 n'incluent plus du tout l'authentification réseau NTLMv1. Aucun numéro de compatibilité ne ramène un protocole que la version n'implémente plus, si bien qu'une rétrogradation qui a aidé sur une version plus ancienne échouera simplement sur une plus récente. Microsoft documente cette suppression séparément du paramètre de stratégie, et confondre les deux produit des conseils qui ne peuvent pas fonctionner.

Une restriction apparentée mais distincte s'applique aux informations d'identification dérivées de NTLMv1 utilisées par l'authentification unique basée sur MSCHAPv2. C'est une question d'informations d'identification dérivées, pas du protocole réseau lui-même, et pas de cette valeur de registre. Traiter les trois comme un seul sujet est la façon dont les organisations finissent par affaiblir un contrôle en essayant d'en réparer un autre.

Modifiez-la par le propriétaire, puis testez les deux sens

Si une correction est vraiment nécessaire, faites-la passer par le propriétaire de la stratégie afin que la base de référence reste cohérente, et consignez pourquoi. Testez ensuite une application autorisée sous le nouveau paramètre et un cas d'authentification volontairement interdit, car un changement qui répare un partage et autorise silencieusement des réponses anciennes ailleurs n'est pas une réussite. Une connexion VPN qui fonctionne prouve que l'admission a réussi. Elle ne valide pas la stratégie d'authentification de la machine, et ne montre certainement pas que chaque service derrière elle se comporte encore comme prévu.

Si le service défaillant repose sur Kerberos, cessez complètement de regarder ce paramètre. S'il s'agit d'un appareil ancien qui ne peut vraiment pas faire mieux, documentez cette exception et délimitez-la, car l'alternative est une base de référence silencieusement affaiblie que personne ne se souvient avoir approuvée.