La connexion a fonctionné hier. Aujourd'hui, le Bureau à distance s'arrête avec une erreur d'authentification NTLM ou le message cousin concernant la correction Oracle du chiffrement CredSSP. Rien n'est cassé dans votre installation Windows - Microsoft abandonne délibérément NTLM et le correctif est une commande de paramètres, pas une réinstallation.
NTLM est l'ancien protocole d'authentification Windows de l'ère Windows NT. Il est faible contre les attaques de relais et de pass-the-hash, c'est pourquoi Microsoft a déprécié NTLM et le désactive par étapes. NTLMv1 est déjà supprimé de Windows 11 version 24H2 et de Windows Server 2025, et en janvier 2026, Microsoft a publié un plan en trois phases qui se termine par la désactivation par défaut du réseau NTLM dans une future version de Windows Server. Lorsque votre PC ou serveur essaie toujours d’utiliser NTLM et que l’autre côté ne l’accepte plus, vous obtenez exactement cette famille d’erreurs. Dans la vidéo ci-dessus, Anshu corrige la version Remote Desktop de cette erreur en une minute environ - voici l'ordre complet de correction, de la vérification la plus sûre au paramètre qu'il modifie à l'écran.
L'erreur exactement telle que les utilisateurs la voient dans la connexion Bureau à distance. Le libellé est un exemple de la véritable boîte de dialogue Windows.
Rien dans votre installation n'est corrompu. Un côté de la connexion propose toujours NTLM - ou une ancienne version de CredSSP - et l'autre côté a été mis à jour ou renforcé pour le refuser. Trois déclencheurs sont à l'origine de presque tous les cas :
Étant donné que la cause est une inadéquation de politique ou de protocole, la réinstallation de Windows ne change rien, sauf vous faire perdre votre journée : les mêmes politiques et les mêmes valeurs par défaut mises à jour reviennent directement.
BlockNtlmv1SSO d'Audit à Enforce, qui bloque l'authentification unique dérivée de NTLMv1 pour les connexions Wi-Fi, câblées 802.1X et VPN.Il s’agit du correctif authentique le plus rapide et il ne nécessite aucun paramètre. Kerberos, le remplacement moderne de NTLM, ne fonctionne que lorsque vous adressez une machine par son nom, car le ticket est émis pour ce nom.
Si le nom se connecte là où l'adresse IP a échoué, votre problème était depuis le début le repli NTLM - et il est déjà résolu de manière sécurisée.
mstscSERVER01 ou SERVER01.office.local – et non 192.168.1.50.La moitié CredSSP de cette famille d'erreurs est purement une incompatibilité au niveau du correctif : le côté corrigé refuse de communiquer avec le côté non corrigé pour protéger vos informations d'identification (ce comportement existe en raison de la vulnérabilité CredSSP CVE-2018-0886). Le correctif recommandé par Microsoft est simple et souvent ignoré :
Un nombre surprenant de ces erreurs disparaissent ici. Ne continuez que si les deux côtés sont entièrement mis à jour et que l’erreur persiste.
C'est la méthode qu'Anshu démontre à l'écran. Sur la machine que vous essayez d'atteindre, les paramètres distants sont resélectionnés afin que l'hôte accepte la connexion proprement :
Pourquoi ça marche : L'authentification au niveau du réseau (NLA) effectue la connexion avant l'ouverture de la session, à l'aide de CredSSP - c'est exactement là que le blocage NTLM frappe. La désactivation de NLA déplace la connexion vers l'écran de connexion Windows normal, afin que la connexion soit établie.
mstsc en utilisant le nom d'utilisateur et le mot de passe corrects.Dans les bureaux, le blocage provient généralement de la stratégie de groupe plutôt que de l'onglet Distant. La politique CredSSP se trouve à Computer Configuration - Administrative Templates - System - Credentials Delegation - Encryption Oracle Remediation. Ses trois niveaux sont également stockés sous la valeur de registre AllowEncryptionOracle sous HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters :
Appliquez la modification avec gpupdate /force et redémarrez. La bonne réponse à long terme est toujours : patchez la machine non corrigée, puis revenez au niveau 0 ou 1.
0 - Forcer la mise à jour des clients : l'état final sécurisé. Clients corrigés uniquement.1 - Atténué : un niveau intermédiaire raisonnable alors que certaines machines sont encore en cours de mise à jour.2 - Vulnérable : autorise l'ancien comportement. Utilisez-le uniquement comme pont court pour atteindre une machine non corrigée, puis supprimez-le.Si la machine cible elle-même rejette les connexions NTLM, examinez deux autres paramètres sous Computer Configuration - Windows Settings - Security Settings - Local Policies - Security Options :
Modifiez un paramètre à la fois et testez après chaque modification. Les modifications apportées aux fusils de chasse rendent le prochain problème impossible à retracer.
Le processus complet avec démonstration en direct - chaque paramètre affiché à l'écran, étape par étape.
Watch Full VideoParce qu'un côté de la connexion a essayé de s'authentifier auprès de NTLM et que l'autre côté ne l'accepte plus. Les déclencheurs habituels sont la connexion par adresse IP au lieu du nom de l'ordinateur, une machine cible renforcée par une stratégie ou une mise à jour récente, ou la suppression de NTLMv1 de Windows 11 24H2 et Windows Server 2025.
Non. Le blocage provient des paramètres par défaut et des politiques du protocole, et non de fichiers système endommagés. Une réinstallation restaure les mêmes valeurs par défaut mises à jour, donc l'erreur revient. Suivez plutôt l'ordre des correctifs : nom de l'ordinateur, mises à jour aux deux extrémités, utilisateurs de l'onglet Distant et NLA, puis politiques CredSSP et NTLM.
Il s'agit d'une solution de contournement temporaire légitime et c'est exactement ce qui fait revenir de nombreuses personnes, car l'échange NTLM bloqué se produit pendant la phase NLA. Mais NLA existe pour s'authentifier avant l'ouverture d'une session, donc le laisser désactivé expose en permanence l'écran de connexion au réseau. Réactivez-le une fois que la cause réelle est corrigée.