Résoudre le problème des informations d’identification du Bureau à distance qui ne fonctionnent pas

L’erreur Your credentials did not work dans Bureau à distance ne signifie pas que votre mot de passe est erroné. Dans de nombreux cas, l’ordinateur qui se connecte envoie des identifiants mis en cache périmés qui ont subsisté après un changement de mot de passe. Dans certaines configurations, la machine cible se trouve dans un état de connexion basé sur un code PIN Windows Hello qui peut bloquer la connexion RDP avec un compte Microsoft. Ce sont les déclencheurs les plus courants, mais les échecs d’authentification ont plus d’une douzaine de causes sous-jacentes distinctes sur les deux machines.

Ce guide couvre les correctifs les plus fiables signalés dans la documentation et les Questions & Réponses de Microsoft, ainsi que dans les fils de dépannage récurrents de la communauté.

Table des matières

Trouvez la cause la plus probable dans le tableau ci-dessous et allez directement à ce correctif au lieu de tester toutes les options.

Cause	Côté	Section des correctifs
Informations d’identification mises en cache ou obsolètes	Client	Correctif 1
Problème de connexion au compte Microsoft lié au code PIN Windows Hello	Machine cible	Correctif 2
Format de nom d’utilisateur incorrect	Client	Correctif 3
Utilisateur non présent dans le groupe Utilisateurs du Bureau à distance	Machine cible	Correctif 4
Délégation des informations d’identification bloquée par une GPO	Client	Correctif 5
Incompatibilité de la couche de sécurité RDP	Machine cible	Correctif 6
`Always prompt for password` est activé	Machine cible	Correctif 7
Profil réseau défini sur `Public`	Machine cible	Correctif 8
Incompatibilité du niveau d’authentification LAN Manager	Machine cible	Correctif 9
`fDenyTSConnections` défini sur `1`	Machine cible	Correctif 10
Restriction des mots de passe vides	Machine cible	Correctif 11
Écouteur RDP inactif	Machine cible	Correctif 12
Certificat RDP expiré	Machine cible	Cas particuliers
Port RDP non par défaut	Machine cible	Cas particuliers

C’est le correctif le plus fréquemment confirmé lorsque les informations d’identification du Bureau à distance ne fonctionnaient pas sur des machines utilisant des comptes Microsoft avec le code PIN Windows Hello activé. Selon des rapports d’utilisateurs, se connecter localement avec le mot de passe du compte a rétabli l’accès RDP après une utilisation exclusivement par code PIN sur l’appareil cible.

REMARQUE : Windows Hello Entreprise est une fonctionnalité d’entreprise distincte qui prend en charge l’ouverture de session RDP au moyen d’un déploiement basé sur des certificats, via Microsoft Intune ou les Services de certificats Active Directory. Cela nécessite une infrastructure PKI, le déploiement de certificats et des certificats de contrôleur de domaine. Elle n’est pas disponible dans les configurations standard grand public ou PME et n’a aucun lien avec le scénario de code PIN grand public décrit ici.

Sur la machine cible, déconnectez-vous de la session en cours.
À l’écran de connexion, cliquez sur Options de connexion.
Sélectionnez l’option de mot de passe (l’icône en forme de clé).
Connectez-vous avec le mot de passe complet de votre compte Microsoft.
Réessayez la connexion RDP depuis la machine qui initie la connexion.

À l’écran de connexion, cliquez sur Options de connexion, puis cliquez sur J'ai oublié mon code PIN.
Authentifiez-vous avec vos identifiants de compte Microsoft, y compris toute vérification en deux étapes.
Lorsque vous êtes invité à réinitialiser votre code PIN, confirmez la réinitialisation. Vous pouvez ressaisir le même code PIN.
Réessayez la connexion RDP après la fin de la procédure de connexion par mot de passe.

Plusieurs utilisateurs ont confirmé que la désactivation de cette seule option a résolu le problème sans qu’il soit nécessaire de se déconnecter puis de se reconnecter.

Sur la machine cible, allez dans Paramètres > Comptes > Options de connexion.
Recherchez Pour renforcer la sécurité, autorisez uniquement la connexion à l’aide de Windows Hello pour les comptes Microsoft sur cet appareil.
Éteignez-le.
Déconnectez-vous, puis reconnectez-vous à l’aide du mot de passe de votre compte Microsoft.

Le Gestionnaire d’informations d’identification Windows sur la machine qui se connecte met en cache les entrées TERMSRV/. Après une modification du mot de passe, il envoie silencieusement l’ancien mot de passe à chaque tentative de connexion sans afficher d’invite.

Sur l’ordinateur qui se connecte, ouvrez le Gestionnaire d’informations d’identification. Recherchez-le dans Démarrer, ou exécutez control /name Microsoft.CredentialManager.
Cliquez sur Informations d’identification Windows.
Trouvez toutes les entrées commençant par TERMSRV/ suivies du nom ou de l’adresse IP de la machine distante.
Cliquez sur chaque entrée, puis cliquez sur Supprimer.
Reconnectez-vous. Windows vous demandera de nouveaux identifiants.

Ouvrez la Connexion Bureau à distance (mstsc.exe).
Entrez le nom de la machine distante ou l’adresse IP.
Cliquez sur Afficher les options.
Dans Paramètres de connexion, cliquez sur le lien edit à côté du nom d’utilisateur enregistré.
Saisissez le mot de passe actuel et enregistrez.

Certaines configurations ne conservent pas les informations d’identification RDP d’une session à l’autre. L’ajout d’une entrée d’informations d’identification générique directement dans le Gestionnaire d’identification oblige Windows à les utiliser.

Ouvrez le Gestionnaire d’identification > Informations d’identification Windows.
Cliquez sur Ajouter une information d’identification générique.
Dans le champ Adresse Internet ou réseau, saisissez TERMSRV/ suivi du nom d’hôte ou de l’adresse IP de la machine distante. Par exemple : TERMSRV/103.27.76.117 ou TERMSRV/COMPUTERNAME.
Saisissez le nom d’utilisateur et le mot de passe.
Cliquez sur OK, fermez le Gestionnaire d’informations d’identification et reconnectez-vous.

Le format du nom d’utilisateur que vous saisissez détermine le fournisseur d’authentification ciblé par Windows. Utiliser un format incorrect oriente la requête vers la mauvaise source d’identité et échoue même avec un mot de passe correct.

Microsoft précise que, pour un appareil distant joint à Microsoft Entra, vous pouvez vous connecter soit avec user@domain.com soit avec AzureAD\user@domain.com, selon le chemin de connexion utilisé. Si un format échoue, essayez l’autre.

Type de compte	Format correct	Remarques
Compte local	`COMPUTERNAME\username</code`	Exemple : `DESKTOP-AB12\john`
Compte de domaine (NetBIOS)	`DOMAIN\username`	Exemple : `CORP\johndoe`
Compte de domaine (UPN)	`username@domain.com`	Exemple : `johndoe@corp.local`
Compte Microsoft	Adresse e-mail complète	Exemple : `john@outlook.com`
Joint à Microsoft Entra	`AzureAD\user@domain.com` ou `user@domain.com`	Microsoft documente les deux formats pour différents parcours de connexion. Essayez l'alternative si le premier échoue.

Un compte doit appartenir soit au groupe Utilisateurs du Bureau à distance, soit au groupe Administrateurs sur l’ordinateur cible. Event ID 4625 avec le sous-état 0xC000015B confirme que l’utilisateur ne s’est pas vu accorder le type d’ouverture de session requis. La seule appartenance à un groupe peut néanmoins être bloquée par un Refuser explicite dans Attribution des droits utilisateur.

Sur la machine cible, exécutez cette commande en tant qu’Administrateur :
net localgroup "Remote Desktop Users" /add "DOMAIN\username" ou dans PowerShell :
Add-LocalGroupMember -Group "Remote Desktop Users" -Member "DOMAIN\username"
Ouvrez Exécuter et tapez secpol.msc.
Accédez à Stratégies locales > Attribution des droits utilisateur.
Double-cliquez sur Autoriser l’ouverture de session par les Services Bureau à distance.
Cliquez sur Ajouter un utilisateur ou un groupe.
Saisissez le nom du compte, puis cliquez sur OK.
Vérifiez dans la même liste toute entrée Refuser l’ouverture de session par les Services Bureau à distance contenant l’utilisateur ou son groupe. Supprimez toutes les entrées de refus explicites.

Lorsque les stratégies de délégation des informations d’identification sur l’ordinateur qui se connecte restreignent la manière dont ces informations sont transmises, le client RDP ne parvient pas à s’authentifier même avec un mot de passe correct. Cela s’applique à tous les types de comptes et constitue l’une des causes les plus souvent négligées des informations d’identification qui ne fonctionnent pas avec le Bureau à distance. La correction s’effectue sur l’ordinateur client, pas sur l’ordinateur distant.

Sur l’ordinateur qui se connecte, ouvrez Exécuter et tapez gpedit.msc.
Accédez à Configuration de l’ordinateur > Modèles d’administration > Système > Délégation des informations d’identification.
Définissez Refuser la délégation des informations d’identification enregistrées sur Non configuré.
Définissez Refuser la délégation d’informations d’identification récentes sur Non configuré.
Ouvrez Autoriser la délégation des informations d’identification enregistrées avec l’authentification de serveur NTLM uniquement. Définissez-le sur Enabled.
Cliquez sur Afficher à côté de Ajouter des serveurs à la liste et entrez TERMSRV/*. Cliquez sur OK.
Répétez l’étape 5 pour : Autoriser la délégation des informations d’identification enregistrées, Autoriser la délégation des nouvelles informations d’identification avec authentification du serveur NTLM uniquement et Autoriser la délégation des nouvelles informations d’identification.
Accédez à Configuration ordinateur > Modèles d’administration > Composants Windows > Services Bureau à distance > Client de Connexion Bureau à distance.
Définissez Ne pas autoriser l’enregistrement des mots de passe sur Non configuré.
Définissez Demander des informations d’identification sur l’ordinateur client sur Non configuré.
Fermez l’Éditeur de stratégie de groupe et exécutez gpupdate /force dans une invite de commandes avec privilèges élevés.

Plusieurs utilisateurs ont confirmé ce correctif après l’échec de toutes les autres solutions. Lorsque la couche de sécurité négociée entre le client et la cible ne parvient pas à s’accorder, l’authentification est refusée avant que les identifiants ne soient entièrement vérifiés.

Sur la machine cible, ouvrez Exécuter et tapez gpedit.msc.
Accédez à Configuration ordinateur > Modèles d’administration > Composants Windows > Services Bureau à distance > Hôte de session Bureau à distance > Sécurité.
Ouvrez Exiger l’utilisation d’une couche de sécurité spécifique pour les connexions à distance (RDP).
Définissez-le sur Activé. Dans la liste déroulante, sélectionnez RDP comme couche de sécurité.
Cliquez sur OK, puis exécutez gpupdate /force dans une invite de commandes en tant qu’administrateur.

Lorsque cette stratégie est activée sur la machine distante, elle prend le pas sur les informations d’identification enregistrées sur le client et force une invite de réauthentification. Cette invite échoue silencieusement, produisant une erreur d’informations d’identification plutôt qu’une boîte de dialogue de mot de passe visible.

Sur la machine cible, ouvrez Exécuter et tapez gpedit.msc.
Accédez à Configuration ordinateur > Modèles d’administration > Composants Windows > Services Bureau à distance > Hôte de session Bureau à distance > Sécurité.
Ouvrez Toujours demander le mot de passe lors de la connexion.
Définissez-le sur Désactivé ou Non configuré.
Déconnectez-vous puis reconnectez-vous, ou exécutez gpupdate /force.

Lorsque le profil réseau de la machine cible est défini sur Public, Windows bloque les connexions RDP entrantes. Les conseils de dépannage RDP de Microsoft considèrent le profil réseau et la configuration du pare-feu comme des causes valides d’échec de connexion. C’est une constatation fréquente lorsque tout le reste de la configuration semble correct.

Sur la machine cible, ouvrez Paramètres > Réseau et Internet > État.
Cliquez sur Modifier les propriétés de connexion.
Définissez le profil réseau sur Privé.

Une incompatibilité de niveau d’authentification entre la machine qui se connecte et la machine distante provoque le rejet des informations d’identification au niveau de la négociation NTLM, que le mot de passe soit correct ou non.

Sur la machine cible, ouvrez Exécuter et tapez gpedit.msc.
Accédez à Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité.
Ouvrez Sécurité réseau : niveau d’authentification LAN Manager.
Définissez-le sur l’une de ces trois valeurs confirmées comme fonctionnelles : Send NTLMv2 response only, Send NTLMv2 response only. Refuse LM ou Send NTLMv2 response only. Refuse LM and NTLM. Chacune des trois résout l’incompatibilité. L’option la plus permissive à essayer en premier est Send NTLMv2 response only.
Cliquez sur OK.

Lorsque RDP apparaît comme activé dans Paramètres, mais que les connexions échouent toujours, deux valeurs du Registre peuvent remplacer le paramètre de l’interface utilisateur. Microsoft indique que fDenyTSConnections est le paramètre qui contrôle si les utilisateurs peuvent se connecter à distance à l’aide des Services Bureau à distance.

Ouvrez l’Éditeur du Registre en tant qu’administrateur (regedit.exe).
Accédez à : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server
Confirmez que fDenyTSConnections est défini sur 0.
Vérifiez également :
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services. Si fDenyTSConnections apparaît ici définie sur 1, une Stratégie de groupe impose le blocage. La modification de la valeur locale ne persistera pas. Le GPO doit être corrigé à la source.
Pour vérifier que le port RDP n’a pas été modifié par rapport à sa valeur par défaut, accédez à : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-tcp
Trouvez PortNumber. Passez la base d’affichage à Decimal.
La valeur doit être 3389. Si ce n’est pas le cas, votre client RDP doit se connecter à ce port personnalisé à la place, en utilisant le format hostname:PORT.

Après toute modification du Registre, redémarrez les Services Bureau à distance : ouvrez services.msc, trouvez Services Bureau à distance, cliquez avec le bouton droit et sélectionnez Redémarrer.

Windows bloque RDP par défaut pour les comptes sans mot de passe défini. Il s’agit d’une restriction de la stratégie de sécurité locale, et non d’un paramètre RDP.

Ouvrez Exécuter et tapez gpedit.msc.
Accédez à Configuration ordinateur > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Options de sécurité.
Ouvrez Comptes: Limiter l’utilisation des mots de passe vides pour les comptes locaux à l’ouverture de session sur la console uniquement.
Définissez-le sur Désactivé.

Avant de supposer que le problème est lié aux informations d’identification, confirmez que le protocole RDP est effectivement à l’écoute des connexions sur la machine cible. Si l’écouteur RDP n’est pas actif, le serveur rejette les connexions au niveau du protocole avant que les informations d’identification du Bureau à distance ne soient évaluées. Cela produit des erreurs qui ressemblent à des échecs d’authentification.

Exécutez cette commande avec des privilèges administratifs sur la machine cible, via PowerShell Remoting ou un accès physique à la console :

qwinsta

Recherchez une entrée nommée rdp-tcp avec STATE défini sur Listen. Si elle est absente ou indique un autre état, le service RDP présente une défaillance du protocole. Vérifiez les clés du Registre dans le Correctif 10 ci-dessus et le certificat RDP dans la section des cas particuliers ci-dessous, puis redémarrez les Services Bureau à distance.

ASTUCE DE PRO: Sur chaque machine que vous gérez à distance, maintenez un compte administrateur local dédié qui n’utilise pas de connexion via un Compte Microsoft. Lorsque des problèmes liés à MSA, au PIN ou aux certificats bloquent RDP, un compte local contourne entièrement le processus d’authentification MSA et vous offre une voie d’accès fonctionnelle.

Pour les équipes de support informatique qui travaillent à distance sur plusieurs machines, HelpWire mérite d’être conservé en complément de RDP. Les sessions démarrent avec un lien plutôt que d’exiger que l’utilisateur distant modifie des paramètres système. Cela signifie que les échecs d’authentification RDP sur la machine distante n’empêchent pas le démarrage d’une session d’assistance. Conservez les identifiants d’administrateur local dans un gestionnaire de mots de passe, et non mis en cache dans le Gestionnaire d’identifiants sur votre propre machine.

Ouvrez l’Observateur d’événements sur la machine cible et vérifiez Journaux Windows > Système pour l’ID d’événement 1057 ou 1058 provenant de Microsoft-Windows-TerminalServices-RemoteConnectionManager. Ces événements indiquent que le certificat auto-signé n’a pas pu être renouvelé.

Ouvrez mmc.exe > Fichier > Ajouter/Supprimer un composant logiciel enfichable > Certificats > Compte d’ordinateur.
Accédez à Certificats > Bureau à distance.
Supprimez le certificat autosigné expiré.
Redémarrez Services Bureau à distance dans services.msc. Windows régénère automatiquement le certificat.

Accédez à C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys.
Prenez possession du fichier de clé associé à RDP.
Supprimez le fichier.
Redémarrez les Services Bureau à distance.

Lors de la connexion par nom d’hôte, vérifiez que la résolution DNS pointe vers la bonne machine, en particulier après une réinstallation de la machine ou un changement d’adresse IP.

Sur la machine cible, exécutez IPCONFIG /All dans une invite de commandes avec privilèges élevés et notez l’adresse IP réelle.
Sur la machine qui se connecte, exécutez nslookup MACHINENAME et confirmez que l’adresse IP renvoyée correspond.
Exécutez également Test-NetConnection -ComputerName SERVER-IP -Port 3389 dans PowerShell. Si TcpTestSucceeded renvoie False, le problème est lié au réseau ou au pare-feu, et non aux identifiants.
Si le DNS est obsolète, connectez-vous directement via l’adresse IP ou mettez à jour l’enregistrement DNS.

Des tentatives RDP répétées et infructueuses déclenchent la stratégie de verrouillage de compte sur les machines jointes au domaine. Vérifiez Observateur d’événements sur le contrôleur de domaine pour ID d’événement 4625 avec Sous-état 0xC0000234. Pour un compte local sur la machine cible, exécutez:

net user USERNAME

Recherchez Account active: No dans la sortie. Pour le réactiver:

net user USERNAME /active:yes

Microsoft indique que, pour un appareil distant joint à Microsoft Entra, vous pouvez vous connecter avec user@domain.com ou AzureAD\user@domain.com, selon la méthode de connexion. Si un format échoue, essayez l’autre. Dans tous les cas, vérifiez que l’utilisateur est ajouté au groupe Remote Desktop Users sur la machine cible. De plus, vérifiez l’appareil dans le centre d’administration Entra sous Devices > the specific device > Local administrators.

ID d’événement 4625 dans les journaux de sécurité Windows enregistre chaque échec d’ouverture de session. Le champ Sous-état identifie la raison précise de l’échec d’authentification, ce qui élimine toute part de conjecture dans le diagnostic.

Sous-code d’état	Raison de l’échec	Correctif à appliquer
`0xC000006A`	Nom d’utilisateur correct, mot de passe erroné	Effacer le Gestionnaire des informations d’identification, vérifier le mot de passe actuel
`0xC0000234`	Compte verrouillé	Déverrouiller via un compte administrateur ou attendre la durée définie par la stratégie de verrouillage
`0xC0000072`	Compte désactivé	Activer le compte dans Gestion de l’ordinateur
`0xC0000071`	Mot de passe expiré	Modifier le mot de passe du compte cible
`0xC000015B`	L’utilisateur ne dispose pas du droit d’ouverture de session RDP	Ajouter au groupe Utilisateurs du Bureau à distance et vérifier l’Attribution des droits utilisateur

Pour accéder à ces journaux : ouvrez Observateur d’événements > Journaux Windows > Sécurité > filtrez par ID d’événement 4625. Dans les détails de l’événement, développez Informations sur l’échec et lisez la valeur hexadécimale de Sous-état.

La première chose que la plupart des gens font lorsque les informations d’identification du Bureau à distance Windows ne fonctionnent pas est de réinitialiser le mot de passe de leur compte Microsoft. Cela n’aide pas pour les scénarios de code PIN et d’informations d’identification mises en cache décrits ci-dessus. Le problème ne vient souvent pas du mot de passe du compte lui-même, mais des informations d’identification mises en cache ou d’un état d’authentification non concordant entre appareils. La réinitialisation du mot de passe ne résout pas le problème, car le client continue d’envoyer l’ancienne information d’identification mise en cache jusqu’à ce que l’entrée enregistrée TERMSRV/ soit effacée ou remplacée.

La deuxième tentative courante consiste à activer et désactiver NLA. Pour le problème de code PIN Windows Hello et les informations d’identification mises en cache obsolètes, l’état de NLA n’est pas la variable. Le problème de PIN se produit parce que l’authentification standard par code PIN Windows Hello est liée à l’appareil et n’est pas transmise via les flux d’authentification RDP standard. La désactivation de NLA affaiblit également la sécurité de la connexion sans traiter la cause sous-jacente.

Une troisième approche qui circule dans certains fils de discussion consiste à supprimer la clé de registre WinStations. Cependant, cela peut rendre la machine inutilisable et nécessiter une réinstallation complète du système d’exploitation.

Lorsque la configuration RDP est elle-même le problème, plutôt qu’un problème de formatage des informations d’identification, il vaut la peine de conserver dans la boîte à outils un outil conçu pour l’assistance. Par exemple, HelpWire lance les sessions en envoyant un lien à l’utilisateur distant, qui exécute un client léger. Vous vous connectez ensuite sans avoir besoin de vous authentifier du tout par rapport aux comptes locaux de la machine distante. Lorsque vous devez accéder à une machine dont la pile d’informations d’identification RDP est défaillante, cela supprime la dépendance à une configuration RDP correcte.

Lorsque vous constatez que les informations d’identification du Bureau à distance ne fonctionnent pas, la raison la plus courante est la présence, sur la machine qui se connecte, d’un mot de passe obsolète mis en cache dans le Gestionnaire d’informations d’identification Windows, envoyé automatiquement après un changement de mot de passe sans demander d’intervention de l’utilisateur. Une autre raison fréquente est que la machine cible s’est authentifiée localement pour la dernière fois avec un code PIN Windows Hello, ce qui peut bloquer la connexion RDP avec un compte Microsoft dans certaines configurations.

Un code PIN Windows Hello standard est lié à l’appareil et n’est pas transmis via les flux d’authentification RDP standard. RDP requiert des informations d’identification basées sur un mot de passe dans les configurations grand public et SMB.

Windows Hello for Business est une fonctionnalité d’entreprise distincte qui prend en charge RDP via une authentification basée sur des certificats, mais elle nécessite une infrastructure PKI, le déploiement de certificats via Intune ou AD CS, ainsi que des certificats de contrôleur de domaine. Elle n’est pas disponible dans les configurations grand public ou SMB.

Ouvrez le Gestionnaire d’informations d’identification depuis le menu Démarrer, cliquez sur Informations d’identification Windows, et supprimez toute entrée commençant par TERMSRV/ qui correspond à la machine distante. Si les informations d’identification ne sont pas conservées d’une session à l’autre, utilisez Ajouter des informations d’identification génériques dans le Gestionnaire d’informations d’identification et saisissez manuellement TERMSRV/[hostname] address ainsi que le nom d’utilisateur et le mot de passe.

Oui. Les paramètres de Délégation des informations d’identification sous Configuration ordinateur > Modèles d’administration > Système dans la Stratégie de groupe sur la machine qui se connecte déterminent si les informations d’identification sont transmises. Refuser la délégation des informations d’identification enregistrées ou Refuser la délégation des nouvelles informations d’identification réglé sur Activé bloque l’authentification sans avertissement. Définir les deux sur Non configuré et activer TERMSRV/* sous Autoriser la délégation des informations d’identification enregistrées avec l’authentification serveur NTLM uniquement résout ce problème.

Supprimez les entrées du Gestionnaire d’identifiants sur la machine qui se connecte et réessayez. Si la connexion échoue encore, exécutez Test-NetConnection -ComputerName SERVER-IP -Port 3389 dans PowerShell. Si TcpTestSucceeded renvoie True mais que les informations d’identification échouent toujours, le problème se situe sur la machine cible. S’il renvoie False, le problème vient du réseau ou du pare-feu. Une fois sur la machine cible, consultez l’ID d’événement 4625 dans le Journal de sécurité pour identifier la raison exacte de l’échec.

Comment résoudre le problème des identifiants du Bureau à distance qui ne fonctionnent pas

12 solutions pour résoudre le problème des identifiants du Bureau à distance qui ne fonctionnent pas

Solution 1: Connectez-vous une fois avec votre mot de passe sur l'ordinateur cible (problème lié au code PIN Windows Hello)

Méthode A: Déconnectez-vous et reconnectez-vous avec un mot de passe

Méthode B : Si l'option de mot de passe est absente ou grisée

Méthode C: Désactiver l'option de connexion uniquement via Windows Hello (correctif autonome)

Correctif 2 : Effacer les informations d’identification obsolètes du Gestionnaire d’informations d’identification sur l’ordinateur qui se connecte

Méthode A : Supprimer des entrées via le Gestionnaire des informations d’identification

Méthode B : Mettez à jour le mot de passe directement dans le client RDP

Méthode C : Ajouter manuellement des informations d’identification génériques lorsque les informations d’identification enregistrées ne sont pas conservées

Solution 3 : Utilisez le format de nom d'utilisateur correct

Solution 4 : Ajouter l'utilisateur au groupe Utilisateurs du Bureau à distance et vérifier les droits d'ouverture de session

Solution 5: Corriger la stratégie de groupe Délégation d’informations d’identification sur la machine cliente

Solution 6 : Modifier la couche de sécurité RDP via la Stratégie de groupe sur la machine cible

Correctif 7 : Désactiver « Toujours demander le mot de passe » sur la machine cible

Solution 8: Modifier le profil réseau de Public à Privé sur la machine cible

Correctif 9 : Définir le niveau d'authentification LAN Manager sur l'ordinateur cible

Solution 10 : Vérifiez la clé de Registre fDenyTSConnections et le port RDP

Solution 11: Corriger un mot de passe vide sur le compte cible

Correctif 12 : Vérifiez l'état de l'écouteur RDP

Correctifs pour des cas particuliers où les identifiants ne fonctionnent pas avec le Bureau à distance

Échec du certificat RDP auto-signé (ID d'événement 1057 ou 1058)

Vérifier le DNS et le ciblage des machines

Verrouillage du compte

Machines jointes à Azure AD / Entra ID

Comment lire l’Observateur d’événements pour identifier les échecs d’ouverture de session RDP

Erreurs courantes commises lorsque les informations d'identification du Bureau à distance Windows n'ont pas fonctionné

Foire aux questions