Erreur d'authentification RDP (Remote Desktop Protocol) sous Windows : causes et solutions

Si vous utilisez quotidiennement le Bureau à distance, vous rencontrerez tôt ou tard un message d'authentification vous bloquant l'accès. Les échecs RDP sous Windows sont généralement dus à l'authentification au niveau du réseau (NLA), à CredSSP, aux stratégies de sécurité, au réseau ou aux certificats . Bien que frustrants, ces problèmes peuvent être résolus facilement. Consultez les exigences de sécurité et de configuration.

Ce guide pratique rassemble en un seul document toutes les causes et solutions validées par les principaux fournisseurs et la documentation officielle. Vous y apprendrez tout, de la gestion des canaux Active Directory sécurisés au protocole TLS, FIPS, aux ports et aux certificats , avec des instructions pour les machines jointes à un domaine et les machines autonomes, locales ou dans le cloud, ainsi que l'utilisation de l' Observateur d'événements pour diagnostiquer les erreurs.

Symptômes courants lors de la connexion via RDP

• Erreur d'authentificationLes autorités de sécurité locales sont injoignables.
• L'ordinateur distant requiert une authentification au niveau du réseau (NLA), mais il est impossible de contacter le contrôleur de domaine pour l'effectuer.
• Cet ordinateur ne peut pas se connecter à l'ordinateur distant. Veuillez réessayer ou contacter l'administrateur..
• Une erreur interne s'est produite. La connexion se coupe sans autre explication..
• Une erreur d'authentification s'est produite. La fonction demandée n'est pas prise en charge. Cela peut être dû à CredSSP..

Pourquoi cela se produit : causes courantes

• La communication avec le contrôleur de domaine (DC) est interrompue.: canal sécurisé AD endommagé, mot de passe de compte d'équipe non synchronisé ou contrôleur de domaine défaillant.
• Incompatibilités de chiffrementLe serveur requiert un niveau de chiffrement supérieur à celui du client, ou la politique FIPS n'est activée que pour le protocole RDP.
• Protocoles TLS du serveur désactivés (1.0, 1.1 ou 1.2) et échec de la négociation.
• NLA bloque la connexion soit parce que le contrôleur de domaine est inaccessible, soit à cause d'une configuration qui interdit les informations d'identification du domaine.
• Certificats problématiques: certificat racine expiré, non fiable ou absent sur le client.
• Réseau et pare-feu: règles manquantes, DNS obsolète, port 3389 occupé, NAT ou VPN interférant.
• Services RDS Écouteur RDP-Tcp arrêté ou défectueux.
• Les mises à jour Windows modifient les stratégies ou la compatibilitéaffectant CredSSP ou NLA.

Solution rapide : désactiver temporairement NLA

Si vous devez vous connecter immédiatement pour corriger le problème à la source, vous pouvez désactiver temporairement NLA sur le serveur. Il s'agit d'une solution temporaire pour résoudre le problème sous-jacent.

Redémarrez votre ordinateur et testez la connexion. Une fois le problème résolu, réactivez l'authentification au niveau du réseau (NLA) avec ces paramètres et redémarrez à nouveau :

REG add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v disabledomaincreds /t REG_DWORD /d 0 /f
REG add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 1 /f

REM Desactiva Network Level Authentication
REG add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f

Machines jointes au domaine : canal sécurisé, contrôleur de domaine et informations d’identification

Ouvrez une console ou une session PowerShell avec privilèges élevés sur le serveur concerné. Commencez par identifier le contrôleur de domaine auprès duquel il tente de s'authentifier :

set | find /i "LOGONSERVER"

Vérifiez le canal sécurisé entre votre ordinateur et le contrôleur de domaine. S'il est rompu, réparez-le à l'aide de PowerShell.

Test-ComputerSecureChannel -Verbose
Test-ComputerSecureChannel -Repair

Si vous pensez que le mot de passe de votre compte d'équipe n'est plus synchronisé, réinitialisez-le. Utilisez des identifiants disposant des privilèges d'administrateur de domaine.

Reset-ComputerMachinePassword -Server <NOMBRE_DC> -Credential <CUENTA_ADMIN_DOMINIO>

Si le contrôleur de domaine est instable, envisagez de le redémarrer ou d'accéder à un autre contrôleur de domaine fonctionnel. En dernier recours, quitter le domaine puis le rejoindre permet généralement de résoudre les problèmes d'état corrompu.

cmd /c "netdom remove <Equipo> /domain:<Dominio> /userD:<AdminDominio> /passwordD:<Password> /reboot:10 /Force"

cmd /c "netdom join <Equipo> /domain:<Dominio> /userD:<AdminDominio> /passwordD:<Password> /reboot:10"

Vérifiez que l'utilisation d'identifiants de domaine sur la machine n'est pas interdite. Si disabledomaincreds est égal à 1, remplacez-le par 0.

REG query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa" /v disabledomaincreds

Dans les environnements Amazon EC2, vous pouvez imposer l'utilisation des informations d'identification mises en cache en limitant les déconnexions temporaires du groupe de sécurité. Le contrôleur de domaine étant inaccessible, le processus de connexion utilise le cache local , ce qui vous permet de vous connecter et de réparer le domaine.

Machines autonomes : chiffrement minimal, TLS et FIPS

Vérifiez le niveau de chiffrement minimal du serveur RDP. Une valeur trop élevée bloquera les clients.

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MinEncryptionLevel

• 4 FIPS : nécessite des algorithmes FIPS. Utilisez-le uniquement si la politique l'exige..
• 3 128 bits : si cela pose problème, passez à 2.
• 2 Maximum possible selon le client : si cela échoue, essayez 1 à titre de test.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v MinEncryptionLevel /t REG_DWORD /d 2 /f

Vérifiez que les protocoles TLS du serveur sont activés. RDP dépend de SCHANNEL.

reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled
reg query "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled

reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server" /v Enabled /t REG_DWORD /d 1 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server" /v Enabled /t REG_DWORD /d 1 /f

Si la norme FIPS est activée, vérifiez qu'elle n'impose pas un scénario inacceptable. Désactivez FIPS si elle n'est pas requise dans votre environnement.

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy" /v Enabled
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Lsa\FIPSAlgorithmPolicy" /v Enabled /t REG_DWORD /d 0 /f

Réseau, pare-feu, DNS et ports

Activez les règles de Bureau à distance dans le Pare-feu Windows Defender. Autorisez le protocole RDP sur les réseaux privés et, le cas échéant, sur les réseaux publics également.

Vérifiez que le port 3389 est libre et à l'écoute. Un conflit avec un autre service peut entraîner des erreurs inhabituelles.

netstat -ano | find "3389"
Tasklist /svc | find <PID_en_escucha>

Si un autre service utilise le port 3389, modifiez son port ou, en dernier recours, ajustez le port RDP et n'oubliez pas de vous connecter au format IP:port. Redémarrez ensuite les services Bureau à distance.

Pour exclure la présence de blocs intermédiaires, testez la connectivité avec psping depuis un autre appareil. Une perte de 100 % indique que le trafic n'atteint pas l'appareil.

Sur les réseaux d'entreprise, vérifiez la configuration NAT et la redirection de ports si vous accédez au réseau depuis Internet. Envisagez d'utiliser un VPN ( consultez le guide d'erreurs VPN ) ou une passerelle RDP plutôt que d'exposer le port 3389. Si votre profil réseau est public, passez-le en mode privé lorsque cela est nécessaire afin d'activer la découverte et les règles de confiance.

Certificats SSL et TLS et erreurs

Si le serveur exige des connexions sécurisées, vérifiez le certificat dans Ordinateur local > Services Bureau à distance > Certificats. Renouvelez-le s'il a expiré et assurez-vous que le client fait confiance à l' autorité de certification racine.

Si le certificat d'écoute est corrompu, supprimez le certificat auto-signé RDP et redémarrez le service pour le régénérer. S'il n'est pas créé, vérifiez les autorisations MachineKeys.

Carpeta: C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys
Builtin\Administrators: Control total
Everyone: lectura, escritura

Évitez de désactiver les validations de sécurité, sauf temporairement à des fins de diagnostic. Un renforcement adéquat du protocole TLS et une gestion appropriée des certificats permettront d'éviter les avertissements répétés.

Lorsque la fonction demandée apparaît, elle n'est pas compatible avec CredSSP.

Cette erreur indique généralement une incompatibilité de correctifs entre le client et le serveur CredSSP. La solution recommandée consiste à mettre à jour les deux éléments pour garantir leur compatibilité.

À titre de solution temporaire, vous pouvez désactiver l'authentification au niveau du réseau (NLA) ou modifier la stratégie de l'oracle de chiffrement. Dans la stratégie de groupe, définissez le niveau de protection sur « Vulnérable » pour la connexion uniquement, avec une correction ultérieure.

Editor de directivas de grupo
Configuración del equipo > Plantillas administrativas > Sistema > Delegación de credenciales
Corrección del oráculo de cifrado: Habilitado, Nivel de protección: Vulnerable

Dans le Registre, définissez AllowEncryptionOracle sur 2. N'oubliez pas que 0 force la mise à jour des clients et 1 est atténué.

HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\CredSSP\Parameters
AllowEncryptionOracle = 2

Si le problème est apparu après une mise à jour spécifique, envisagez de désinstaller temporairement le correctif en cause (par exemple, KB4103727 ou KB4103718). Appliquez le correctif approprié dès que possible.

Si vous voyez RDP, une erreur interne s'est produite.

Ce message générique masque souvent une erreur de configuration. Vérifiez les paramètres RDC, d'authentification et de ressources partagées, qui peuvent être incorrects.

Permet la mise en cache persistante des images bitmap et la reconnexion automatique côté client. Améliore la résilience sur les liaisons instables.

Les problèmes de domaine peuvent également en être la cause. Quitter le domaine puis le rejoindre après un redémarrage permet de corriger les erreurs d'application des stratégies.

Ajuster la MTU de l'interface permet de résoudre les problèmes de fragmentation des tunnels et des VPN. Des valeurs comme 1458 constituent généralement un bon point de départ.

netsh interface ipv4 show subinterfaces
netsh interface ipv4 set subinterface 'Ethernet' mtu=1458 store=persistent

Dans RDS Security, vous pouvez forcer l'utilisation du protocole RDP via une stratégie de groupe. Cela s'avère utile en cas d'incompatibilité TLS ou NLA.

Configuración del equipo > Plantillas administrativas > Componentes de Windows > Servicios de Escritorio remoto > Host de sesión > Seguridad
Requerir uso de una capa de seguridad específica: Habilitado, RDP

Services RDP, écouteur et réparation du registre

Assurez-vous que les services TermService et UmRdpService sont démarrés à la fois sur le client et le serveur. Sans eux, il n'y aura ni session ni redirection.

Vérifiez l'état du protocole rdp-tcp avec qwinsta. Il devrait afficher « Écoute ».

qwinsta

Si le serveur d'écoute est corrompu, exportez la clé RDP-Tcp depuis un serveur sain, sauvegardez-la et remplacez-la sur le serveur affecté ; puis redémarrez TermService. C'est une solution de dernier recours.

reg export "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp" C:\Rdp-tcp-backup.reg
Remove-Item -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp' -Recurse -Force
regedit /s C:\<archivo_sano>.reg
Restart-Service TermService -Force

Cloud : spécificités d’Azure et d’AWS

Dans Azure, utilisez la console série, l'invite de commandes à distance ou PowerShell à distance. Ces outils sont essentiels pour accéder au registre et aux services en cas d'échec du protocole RDP.

Dans AWS, le document d'automatisation AWSSupport-TroubleshootRDP et Session Manager vous permettent de modifier le registre pour désactiver NLA. Vous avez besoin de l'agent SSM et du rôle IAM appropriés.

reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v SecurityLayer /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v UserAuthentication /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp" /v fAllowSecProtocolNegotiation /t REG_DWORD /d 0 /f

Si l'instance est inaccessible, vous pouvez modifier le Registre hors ligne : démontez le volume système, montez-le sur une instance de secours, chargez la ruche SYSTEM, modifiez les valeurs, puis remontez-la. Procédez toujours avec une AMI de sauvegarde.

Questions rapides et cas typiques

• Peut-on utiliser le protocole RDP sans Internet ? Si les deux ordinateurs sont sur le même réseau local, oui. Il vous suffit de leur adresse IP locale et d'autoriser le port 3389 dans le pare-feu.
• Est-il sûr de se connecter sans VPN ? Ce n'est pas idéal. Ouvrir le port 3389 vous rend vulnérable aux attaques par force brute et aux exploits ; utilisez un VPN ou une passerelle.
• La connexion est lente.Ajustez les paramètres vidéo, désactivez les arrière-plans et les animations, fermez les applications gourmandes en bande passante et vérifiez votre VPN. Disposer de ressources CPU et RAM disponibles sur le serveur est essentiel.

Solutions alternatives en cas de résistance du protocole RDP

Si votre environnement ou vos politiques rendent l'utilisation du protocole RDP complexe, il existe des solutions d'accès à distance plus simples à déployer. Des outils comme RealVNC Connect, AnyViewer ou TeamViewer facilitent un accès sécurisé sans exposer de ports ni gérer le DNS ; vous pouvez également utiliser Chrome Remote Desktop.

Pour la publication d'applications et les scénarios de sécurité renforcée, des plateformes comme TSplus proposent une passerelle, un renforcement de la sécurité et un contrôle centralisé. Leur objectif est d'améliorer la sécurité, les performances et l'expérience utilisateur tout en simplifiant les opérations.

Grâce à ces informations, vous devriez pouvoir résoudre l'erreur d'authentification RDP sous tous ses aspects : domaine et NLA, chiffrement et TLS, certificats, réseau, pare-feu et services système. Commencez par identifier le symptôme, vérifiez les dépendances essentielles et appliquez les modifications minimales réversibles . Si vous avez besoin d'un accès immédiat, désactivez temporairement le NLA et, une fois connecté, corrigez la cause première en réactivant les protections pour sécuriser l'environnement.