Connexion Remote Desktop Windows : résoudre l’échec d’authentification sur un réseau local

Connexion refusée ? Avant de réinstaller Windows, vérifiez méthodiquement les comptes, les droits et le pare‑feu : dans 90 % des cas, une simple incohérence d’identifiants ou de groupes est la cause d’un échec d’authentification RDP.

Sommaire

Contexte et enjeux

Remote Desktop Protocol (RDP) est la solution native de Microsoft pour prendre la main à distance sur un poste Windows. Sur un réseau local, la latence est quasi nulle ; l’expérience utilisateur se rapproche donc d’une session physique. Pourtant, dès que la boîte de dialogue RDP refuse les identifiants — « Votre nom d’utilisateur ou votre mot de passe est incorrect » — la productivité s’effondre. Le problème est amplifié par l’arrivée des comptes Microsoft, de Windows Hello et d’Azure Active Directory : un administrateur pressé peut facilement tenter la mauvaise combinaison nom + domaine, bloquant ainsi son accès.

Prérequis techniques

  • Édition Windows prise en charge : l’ordinateur cible doit être Windows Pro, Entreprise ou Éducation (10 ou 11). Windows Home ne possède que le client RDP, pas le service hôte.
  • Version RDP : de préférence 10.0 ou supérieure pour bénéficier de la couche de sécurité NLA (Network Level Authentication).
  • Port 3389/TCP ouvert dans le pare‑feu Windows (profil privé ou domaine) ou tout autre solution de sécurité interposée.
  • Comptes disposant du droit « Autoriser l’ouverture de session via Services Bureau à distance », normalement attribué automatiquement au groupe Remote Desktop Users.
  • Adresse IP fixe ou réservation DHCP pour éviter qu’un bail changeant rende le nom NetBIOS obsolète sur le réseau.

Diagnostic rapide en trois commandes

  1. whoami : retourne l’identité exacte du compte connecté. Exemple : desktop‑pc\julie (compte local) ou microsoftaccount\julie@example.com (compte Microsoft).
  2. hostname : affiche le nom NetBIOS de la machine, utile si l’on n’utilise pas l’adresse IP.
  3. quser : liste les sessions RDP actives et non actives ; permet de savoir si une limite de session est atteinte.

Méthode détaillée pour rétablir la connexion

ÉtapeActionPourquoi c’est utile
1Identifier exactement le compte utilisé sur le PC cible
– Ouvrir un Invite de commandes puis exécuter whoami pour obtenir le nom de session réel.
– Lancer netplwiz pour lister la totalité des comptes locaux et Microsoft.
Évite de deviner le nom d’utilisateur et révèle si le compte est local ou Microsoft.
2Tenir compte du type de compte
Compte local : saisir le nom précis affiché par whoami.
Compte Microsoft : utiliser l’adresse e‑mail complète (ex. : nom@outlook.com).
RDP refuse les alias abrégés des comptes Microsoft.
3Vérifier l’appartenance au groupe “Remote Desktop Users”
– Ouvrir Gestion de l’ordinateur ▶ Utilisateurs et groupes locaux ▶ Groupes, ajouter le compte s’il n’y figure pas.
Sans ce droit explicite, l’authentification échoue même avec le bon mot de passe.
4Utiliser le mot de passe du compte, pas le code PIN Windows HelloRDP ne gère pas Windows Hello ; seule une authentification par mot de passe fonctionne.
5Contrôler les paramètres système et réseau
Paramètres ▶ Bureau à distance : activer « Autoriser les connexions ».
– Pare‑feu Windows : profil privé ▶ Règle « Remote Desktop (TCP-In) » activée.
Garantit que le service RDP et son port restent accessibles.

Comprendre la cohabitation comptes locaux, Microsoft et Azure AD

Depuis Windows 8, un utilisateur peut associer son profil à un compte Microsoft. Le service RDP n’interprète pas l’alias court proposé sur l’écran de connexion (Julie L.) ; il exige soit le nom principal UPN (julie@example.com), soit le format microsoftaccount\julie@example.com. Pour un poste joint à Azure AD, le préfixe devient AzureAD\. Exemple complet : AzureAD\julie@entreprise.fr.

Configurer correctement les droits et politiques de sécurité

  • Remote Desktop Users : ajoute automatiquement la permission « Se connecter via Services Bureau à distance ». 
  • Politiques locales : dans secpol.msc ▶ Stratégies locales ▶ Attribution des droits utilisateur, vérifier que Refuser l’ouverture de session via Services Bureau à distance est vide.
  • Stratégie NLA : si l’infrastructure de domaine utilise un niveau fonctionnel ancien, désactiver temporairement NLA pour tester, mais la réactiver ensuite pour ne pas exposer la machine à la brute‑force.

Sécurité et bonnes pratiques

Bien que l’article traite d’un réseau local, la surface d’attaque RDP reste élevée :

  • Mettez à jour le client et le service RDP afin de bénéficier du chiffrement CredSSP corrigé (CVE‑2018‑0886) et du correctif « BlueKeep » (CVE‑2019‑0708).
  • Activez le chiffrement TLS 1.2 et désactivez RC4/3DES via les paramètres du registre SChannel.
  • Verrouillez le port 3389 aux seuls segments VLAN qui en ont besoin. Même sur un LAN, un invité en Wi‑Fi peut être un risque.
  • Activez l’audit des échecs de connexion : événement 4625 avec le sous‑type 0x0 = nom d’utilisateur ou mot de passe invalide.

Cas particuliers à connaître

Windows 11 Home

Pour transformer un PC Home en hôte RDP, deux options légales s’offrent à vous : Windows 11 Pro Upgrade sur le Microsoft Store ou un In‑Place Upgrade vers Windows 11 Pro via un média volume. Les fichiers système « termsrv.dll » modifiés circulant sur Internet violent le CLUF et introduisent souvent des malware.

PC joint à Azure AD ou hybride

Sur un poste Azure AD, l’utilisateur doit disposer du rôle Azure AD Joined Device Local Administrator ou être ajouté au groupe Administrateurs locaux. Le premier logon RDP nécessite le format AzureAD\UPN. Si « Single Sign‑On » est souhaité, installez Azure AD Kerberos Trust ou configurez un connecteur Cloud Kerberos.

Connexion via VPN site‑à‑site

Lorsque les deux PC sont sur des sous‑réseaux différents reliés par VPN, le chemin mtu peut tronquer les paquets TLS, générant l’erreur 0x4 : « La connexion a été perdue car le serveur ne peut pas prendre en charge le canal graphique requis ». Testez alors un MTU de 1300 avec ping -f -l 1300 adresse_ip.

Dépannage avancé

# Script PowerShell : Tester l’écoute du port RDP
$target = "PC‑RDP"
Test-NetConnection -ComputerName $target -Port 3389 | Select-Object -Property ComputerName,RemotePort,TcpTestSucceeded

Interprétation : si TcpTestSucceeded est False, le pare‑feu ou un filtre réseau bloque le port. Si True mais la session échoue, se tourner vers l’audit de sécurité.

Décoder l’événement 4625

Code du statutSignificationPiste de résolution
0xC0000064Nom d’utilisateur inexistantRevérifier whoami sur le PC cible
0xC000006AMot de passe erronéVérifier la disposition du clavier ou une touche ⇩ Verre Num
0xC000006DÉchec général d’authentificationCompte non autorisé dans Remote Desktop Users
0xC0000193Compte expiréRéinitialiser la date d’expiration dans lusrmgr.msc

Scripts d’automatisation utiles

# Ajouter un utilisateur local au groupe RDP
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "Julien"

# Activer le service RDP et ouvrir le port

Set-ItemProperty -Path "HKLM:\System\CurrentControlSet\Control\Terminal Server" -Name fDenyTSConnections -Value 0
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

FAQ

Q : Puis‑je réutiliser mon code PIN Windows Hello une fois la première connexion RDP réussie ?
R : Oui, mais uniquement pour les connexions interactives locales. Le client RDP continuera d’exiger le mot de passe classique.

Q : Pourquoi RDP me demande‑t‑il deux fois les identifiants ?
R : Le mode NLA effectue une authentification préalable côté client ; si les informations d’identification cachées dans le Gestionnaire d’informations d’identification Windows sont obsolètes, il réinvite l’utilisateur.

Q : La licence RDS est‑elle nécessaire sur un LAN ?
R : Pas pour une connexion administrateur unique. Au‑delà de deux sessions simultanées par serveur, une infrastructure RDS et des CAL Utilisateur/Appareil deviennent obligatoires.

Checklist finale avant validation

  • Le service Services Bureau à distance est démarré (services.msc).
  • Le compte figure dans Remote Desktop Users et n’est bloqué par aucune stratégie de restriction.
  • Le test Test‑NetConnection confirme la disponibilité du port 3389.
  • Le format d’utilisateur correspond au résultat whoami ou AzureAD\UPN.
  • Le mot de passe est validé localement (connexion console OK).
  • Les journaux Windows affichent 4624 Logon Success et plus de 4625 après correction.
  • L’édition Windows de l’hôte est Pro ou supérieure.

Conclusion

Une authentification RDP rejetée masque rarement une panne matérielle ; dans l’immense majorité des cas, l’erreur provient soit d’un identifiant inexact, soit d’un droit d’accès manquant. En appliquant la démarche pas‑à‑pas détaillée ci‑dessus — identification du compte exact, ajout au groupe « Remote Desktop Users », validation du mot de passe et test réseau — vous rétablirez la connexion sans réinstallation ni interventions lourdes. Vous profiterez alors pleinement des performances offertes par RDP sur un réseau local, tout en respectant les meilleures pratiques de sécurité.

Sommaire