Connexion VPN refusée : vérifiez la build avant le registre
Une valeur absente du registre peut imposer sa propre valeur par défaut après une mise à jour. Lisez d’abord le niveau de build, la stratégie effective et un événement concordant.
La connexion est refusée sur une machine où personne n’a modifié le registre, et la réponse du forum dit d’ajouter une valeur qui n’y est pas. L’absence n’est pas la constatation. Windows applique des valeurs par défaut, une valeur par défaut peut changer avec une mise à jour installée, et la stratégie effective sur l’appareil peut donc être plus stricte que ce que le registre laisse entendre.
Partez de l’erreur que le client a réellement affichée
Lisez le message, pas le résumé qui vous est parvenu de seconde main. Une invite qui revient immédiatement, un délai d’expiration après la formation du tunnel et une défaillance qui n’apparaît que lorsque la connexion tente de réutiliser le compte ouvert sont trois situations différentes. Seule la troisième concerne l’authentification unique, et les deux premières ne seront pas corrigées par quoi que ce soit dans cet article.
La couche qui a pris la décision détermine quel journal y répond. Ces quatre observations renvoient à quatre responsables différents :
| What you observe | Where the decision was made | Who owns the fix |
|---|---|---|
| The prompt returns before the tunnel forms | Local credential handling on the client | Device policy or the installed build |
| Authentication succeeds, no internal site loads | Routing or access control after login | The gateway or network owner |
| Fails only when the logged-on account is reused | SSO credential generation | The policy boundary this page covers |
| Every user on one build fails | Update level or vendor regression | Patch management |
Inscrivez le texte exact, la minute et le contexte du compte dans le ticket. Le caractère interactif ou automatique de la tentative détermine quel composant Windows a fait l’appel, et un rapport disant que le VPN est cassé décrit souvent un site interne manquant plutôt que des identifiants refusés.
Lisez la stratégie effective, pas la valeur absente
Établissez d’abord le niveau de build et de mise à jour, car la valeur par défaut de la génération d’identifiants dérivés de NTLMv1 a changé dans les versions citées de Windows 11 et Windows Server 2025. Avec Credential Guard désactivé et BlockNtlmv1SSO non défini, une mise à jour publiée le 13 octobre 2026 ou après fait passer le comportement d’Audit à Enforce sans jamais créer cette valeur. Rien n’apparaît dans le registre, et l’appareil devient plus strict que ne l’avait voulu le dernier administrateur. C’est toute la raison pour laquelle une recherche dans le registre prouve ici si peu.
Gardez les frontières séparées pendant la lecture de la sortie. LmCompatibilityLevel est le niveau de réponse de l’authentification réseau, qui décide quel défi et quelle réponse la machine enverra à un serveur ; ce n’est pas le contrôle qui régit la génération des identifiants d’authentification unique, donc l’abaisser ne rétablit pas la connexion. Le fait que l’appareil parle encore ou non NTLMv1 comme protocole réseau est une troisième frontière, et les versions actuelles de Windows 11 et de Server 2025 l’ont déjà abandonné. Credential Guard, la quatrième, protège les secrets de l’appareil.
Corrélez une tentative avec un événement
Reproduisez la défaillance une fois, notez la minute, puis réunissez les preuves locales en une seule séance. Trois commandes couvrent la build, la valeur effective et le journal opérationnel NTLM où est consignée une génération d’identifiants d’authentification unique bloquée :
Get-ComputerInfo | Select-Object WindowsProductName, OsBuildNumber, OsVersion
reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v LmCompatibilityLevel
Get-WinEvent -LogName "Microsoft-Windows-NTLM/Operational" -MaxEvents 30 | Select-Object TimeCreated, Id, MessageUn événement au même moment que la défaillance est une preuve. Un événement d’hier, d’un autre compte ou un journal sans aucune entrée n’en est pas une, et le cas vide mérite d’être consigné comme vide plutôt que comme preuve absente. Le guide Microsoft sur les changements NTLMv1 nomme l’identifiant d’événement de la génération bloquée d’identifiants d’authentification unique, alors comparez l’Id à celui-ci au lieu de deviner d’après le texte du message.
Gardez ensemble le message du client et la vision de la passerelle de la même tentative. Un blocage local de génération d’identifiants, un rejet de compte distant et une route privée absente après une connexion réussie ont trois responsables différents, et seul le premier est une question de stratégie Windows. Assainissez l’événement avant qu’il ne quitte l’équipe : un horodatage et un Id d’événement répondent généralement à la question sans les détails du compte.
Passez à une méthode de connexion prise en charge
Si la stratégie effective est le blocage, la réponse est un chemin d’authentification pris en charge et non un retour silencieux à la valeur par défaut. L’authentification par certificat est la destination habituelle là où le déploiement la prend en charge, et elle exige une inscription, une distribution de confiance et une passerelle qui accepte les certificats. Le guide Microsoft sur les prochains changements NTLMv1 est le document à citer lors de l’examen du cas.
Désactiver Credential Guard à titre d’expérience supprime la protection sans fournir de connexion de remplacement, et les restrictions documentées sur les identifiants réutilisables expliquent pourquoi il s’agit d’une décision de conception et non d’une étape de diagnostic. Si une exception temporaire est autorisée, donnez-lui un périmètre, un responsable et une date de retrait, et conservez un chemin d’administration indépendant vers la machine au cas où le changement vous priverait de la connexion dont vous avez besoin. Le test d’acceptation est l’authentification prévue plus la ressource derrière elle, et non la disparition d’un code d’erreur local.