Quand Windows indique que la connexion a été refusée parce que le compte utilisateur n’est pas autorisé à ouvrir une session à distance, le mot de passe n’est pas en cause. Il a été accepté ; la session a été rejetée une étape plus tard, au moment de l’autorisation.
Deux vérifications déterminent ce résultat : le compte doit appartenir au groupe local Utilisateurs du Bureau à distance ou au groupe Administrateurs, et il doit figurer dans la stratégie Autoriser l’ouverture de session par Services Bureau à distance dans secpol.msc. Si l’une des deux conditions n’est pas remplie, vous obtenez cette erreur.
Un paramètre prime sur les deux précédents : Refuser l’ouverture de session par Services Bureau à distance. Si le compte, ou l’un des groupes auxquels il appartient, figure dans cette liste, il sera bloqué quoi qu’il en soit de la configuration par ailleurs.
Sur les machines jointes au domaine, il existe une quatrième couche. Une Stratégie de groupe appliquée au niveau du domaine ou de l’UO peut discrètement réinitialiser les paramètres locaux au prochain rafraîchissement, annulant une correction qui semblait effectuée quelques minutes plus tôt.
Commencez par vérifier l’appartenance aux groupes : c’est la cause la plus fréquente.
Procédure de correction rapide
Si vous souhaitez commencer immédiatement sans lire l’explication complète, suivez-les dans l’ordre et arrêtez-vous lorsque l’erreur disparaît.
-
Ajoutez le compte au groupe local Utilisateurs du Bureau à distance sur la machine cible.
-
Ouvrez secpol.msc et confirmez que le groupe du compte apparaît sous Autoriser l’ouverture d’une session par les Services Bureau à distance.
-
Au même endroit, vérifiez Refuser l’ouverture de session via les Services Bureau à distance et confirmez que le compte n’y figure pas.
-
Si la machine est membre d’un domaine, vérifiez le GPO du domaine dans la GPMC, et pas seulement la stratégie locale dans secpol.msc.
-
Supprimez les informations d’identification enregistrées obsolètes du Gestionnaire d’informations d’identification uniquement après avoir confirmé que les paramètres de stratégie ci-dessus sont corrects.
Ce que de vrais utilisateurs signalent à propos de cette erreur
La plainte la plus fréquente sur les forums : tout semble correct, et l’erreur persiste quand même. Un administrateur de domaine sur Microsoft Q&A a décrit un poste de travail Windows 11 qui refusait toutes les connexions RDP non administrateur malgré une appartenance au groupe correcte et un secpol.msc local apparemment propre. Le véritable blocage provenait d’une GPO au niveau du domaine qui remplaçait silencieusement les paramètres locaux. (Microsoft Q&A, septembre 2024)
Sur les VM Azure, un problème connexe apparaît sous forme de boucle : un compte est ajouté manuellement, les sessions fonctionnent, puis le compte disparaît après un redémarrage et l’erreur réapparaît. Une GPO Groupes restreints supprimant l’appartenance à chaque actualisation des stratégies en était la cause, et aucune correction via l’interface ne tient tant que la GPO elle-même n’est pas mise à jour. (Microsoft Tech Community, juin 2023)
Les informations d’identification enregistrées sont un déclencheur moins évident. Un pool RDS qui fonctionnait depuis des années s’est soudainement mis à rejeter tous les utilisateurs avec cette erreur. Les autorisations n’avaient pas changé. La suppression du mot de passe enregistré puis sa saisie manuelle a résolu le problème immédiatement, comme l’ont confirmé plusieurs utilisateurs dans le même fil. (Microsoft Q&A, octobre 2022)
Sur des VM Azure jointes au domaine, un administrateur gérant 1 000 utilisateurs a ajouté des comptes à la stratégie Autoriser l’ouverture de session via les Services Bureau à distance, a exécuté gpupdate /force, et a tout de même rencontré l’erreur. L’étape manquante était d’ajouter les utilisateurs au groupe local Utilisateurs du Bureau à distance sur la VM elle-même. Les deux vérifications sont nécessaires. (Microsoft Q&A, novembre 2022)
Dans les environnements gérés par Intune, lusrmgr.msc n’affiche pas le domaine Azure comme emplacement disponible, donc la correction classique par appartenance à un groupe ne s’applique pas. Une stratégie de configuration Intune réussie ne suffit pas à elle seule. Une stratégie distincte ciblant le droit Autoriser l’ouverture de session via les Services Bureau à distance est requise pour les appareils joints à Entra. (Microsoft Q&A, décembre 2024)
Comment corriger la connexion a été refusée car le compte d’utilisateur n’est pas autorisé à l’ouverture de session à distance
Solution 1 : Ajouter l'utilisateur au groupe Utilisateurs du Bureau à distance
L’absence d’appartenance à un groupe est la cause la plus fréquente de cette erreur sur les machines autonomes. Exécutez ces étapes sur le PC distant, et non sur la machine depuis laquelle vous vous connectez. Notez que lusrmgr.msc n’est pas disponible sur les éditions Windows Home, lesquelles ne peuvent d’ailleurs pas servir d’hôtes RDP.
-
Appuyez sur Win + R, tapez lusrmgr.msc, et appuyez sur Entrée.
-
Sélectionnez Groupes dans le volet de gauche, puis double-cliquez sur Utilisateurs du Bureau à distance.
-
Cliquez sur Ajouter.
-
Saisissez le nom d’utilisateur, cliquez sur Vérifier les noms pour confirmer qu’il est reconnu, puis cliquez sur OK.
-
Cliquez sur OK pour fermer la fenêtre des propriétés du groupe.
Pour une méthode plus rapide via Propriétés système : appuyez sur Win + R, tapez sysdm.cpl, sélectionnez l’onglet Utilisation à distance, cliquez sur Sélectionner des utilisateurs, et ajoutez-y le compte.
Depuis une invite PowerShell élevée sur l’ordinateur distant :
Add-LocalGroupMember -Group “Remote Desktop Users” -Member “username”
Remplacez username par le nom de compte réel. Aucun redémarrage n’est requis.
Solution 2: Vérifiez la stratégie Autoriser l'ouverture d'une session par les Services Bureau à distance
L’appartenance au groupe et la stratégie d’attribution des droits utilisateur sont vérifiées indépendamment. Les deux doivent être satisfaites, et corriger l’une sans l’autre laisse l’erreur en place. Exécutez ces étapes sur le PC distant.
-
Appuyez sur Win + R, tapez secpol.msc, puis appuyez sur Entrée.
-
Accédez à Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateur.
-
Double-cliquez sur Autoriser l’ouverture de session par les Services Bureau à distance.
-
Vérifiez que Utilisateurs du Bureau à distance et Administrateurs figurent tous deux dans la liste. Si l’un des deux manque, cliquez sur Ajouter un utilisateur ou un groupe, saisissez le nom du groupe, puis cliquez sur OK.
-
Cliquez sur OK, puis exécutez la commande suivante à partir d’une Invite de commandes élevée: gpupdate /force
Sur une machine jointe au domaine, une GPO de domaine en conflit peut remplacer ce paramètre dans les minutes qui suivent son enregistrement. Si le paramètre revient à son état précédent, passez à la Solution 4.
Correctif 3 : Vérifiez s'il existe une stratégie de refus qui prime sur le paramètre Autoriser
La stratégie Refuser l’ouverture de session par les Services Bureau à distance bloque l’accès, indépendamment de l’appartenance à un groupe ou de la stratégie Autoriser. Vérifiez cela même lorsque les paramètres Autoriser semblent complets.
-
Dans secpol.msc, accédez à Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateur.
-
Double-cliquez sur Refuser l’ouverture de session via les Services Bureau à distance.
-
Examinez la liste. Si le compte de connexion, ou l’un des groupes auxquels il appartient, y compris Invités ou Invités du domaine, apparaît ici, sélectionnez-le et cliquez sur Supprimer.
-
Cliquez sur OK, puis exécutez gpupdate /force.
Si le paramètre continue de revenir à son état précédent après l’avoir enregistré et exécuté gpupdate /force, une GPO de domaine contrôleSi le paramètre continue de revenir à son état précédent après l’avoir enregistré et exécuté gpupdate /force, une GPO de domaine contrôle au niveau du domaine. Gérez cette stratégie uniquement via la Stratégie de sécurité locale ou la Gestion des stratégies de groupe. Évitez de tenter de modifier directement dans le Registre les attributions de droits utilisateur, puisque les droits de connexion Autoriser et Refuser sont gérés par Windows en tant que constantes de privilèges nommées (SeRemoteInteractiveLogonRight et SeDenyRemoteInteractiveLogonRight), et non comme de simples valeurs du Registre. Pour l’audit, utilisez secpol.msc, gpresult ou secedit.
Solution 4: Accédez directement au GPO de domaine
Sur une machine jointe au domaine où les modifications locales sont constamment annulées, une GPO de domaine les écrase. Cette solution nécessite un accès à la Console de gestion des stratégies de groupe, généralement disponible sur un contrôleur de domaine ou une machine avec RSAT installé.
-
Ouvrez la GPMC via le Gestionnaire de serveur > Outils > Gestion de stratégie de groupe.
-
Développez le domaine, cliquez avec le bouton droit sur la GPO contrôlant la machine affectée, et sélectionnez Modifier.
-
Accédez à Configuration de l’ordinateur > Stratégies > Paramètres Windows > Paramètres de sécurité > Stratégies locales > Attribution des droits utilisateur.
-
Ouvrez Autoriser l’ouverture de session par les Services Bureau à distance et confirmez que Utilisateurs du Bureau à distance et Administrateurs sont tous deux répertoriés.
-
Ouvrez Refuser l’ouverture de session via les Services Bureau à distance et confirmez que le compte concerné et ses groupes ne sont pas répertoriés.
-
Enregistrez les modifications, puis exécutez la commande suivante sur la machine affectée : gpupdate /force
Si le GPO pertinent n’est pas immédiatement évident, exécutez ceci sur la machine concernée et ouvrez le fichier résultant afin d’identifier quelle stratégie contrôle l’Attribution des droits utilisateur:
gpresult /h gpreport.html
Solution 5 : Supprimer les informations d’identification enregistrées obsolètes dans le Gestionnaire d’informations d’identification
C’est une cause moins courante, mais qui mérite d’être vérifiée après avoir confirmé que l’appartenance aux groupes et les paramètres de stratégie sont corrects. Les identifiants RDP enregistrés peuvent devenir obsolètes après un changement de mot de passe, une migration de compte ou des modifications apportées à un pool RDS. Dans certains cas, cela entraîne des échecs de connexion qui ressemblent à des erreurs d’autorisation. La solution, documentée dans un fil de discussion Microsoft Q&A où un pool RDS avec des années d’identifiants enregistrés s’est soudainement mis à échouer pour tous les utilisateurs, a consisté à effacer l’entrée stockée et à ressaisir manuellement les identifiants.
-
Ouvrez le Panneau de configuration, allez dans Comptes d’utilisateurs, puis cliquez sur Gestionnaire d’informations d’identification.
-
Sélectionnez les informations d’identification Windows.
-
Recherchez des entrées commençant par TERMSRV/ suivies du nom de l’ordinateur ou de l’adresse IP du PC distant.
-
Développez chaque entrée pertinente et cliquez sur Supprimer.
-
Fermez le Gestionnaire d’identifiants et tentez à nouveau la connexion RDP, en saisissant les identifiants manuellement lorsque vous y êtes invité.
Solution 6: Utilisez HelpWire comme une alternative gratuite pendant que vous réparez RDP
Si une erreur d’autorisation bloque l’accès à une machine dont vous avez besoin immédiatement, HelpWire vous offre une connexion à distance fonctionnelle pendant que vous réglez la configuration des stratégies. Elle n’utilise pas le service Bureau à distance de Windows ni le port 3389, de sorte que les problèmes d’appartenance à des groupes et de droits des utilisateurs qui produisent l’erreur “compte utilisateur non autorisé” ne l’affectent pas.
HelpWire fonctionne sous Windows, macOS et Linux et est gratuit. La configuration prend quelques minutes : installez le client opérateur sur votre machine, installez l’agent HelpWire sur la machine distante, puis connectez-vous. Pour un accès non supervisé à une machine que vous administrez, l’agent peut être configuré pour s’exécuter en tant que service en arrière-plan sans qu’il soit nécessaire que quelqu’un côté distant accepte chaque connexion.
Foire aux questions
Les comptes d’administrateur appartiennent au groupe Administrateurs local, que Windows inclut toujours dans la stratégie Autoriser l’ouverture de session par Services Bureau à distance. Les comptes d’utilisateur standard ne sont pas ajoutés par défaut au groupe Utilisateurs du Bureau à distance ni à la stratégie Autoriser l’ouverture de session par Services Bureau à distance, ils se voient donc refuser l’accès tant que les deux ne sont pas explicitement configurés.
Oui. Les paramètres de GPO de domaine appliqués au niveau du domaine, du site ou de l’OU remplacent les paramètres locaux de secpol.msc à chaque actualisation de la Stratégie de groupe. Si une correction locale continue de revenir, une GPO conflictuelle est active. Utilisez GPMC pour traiter cela au niveau du domaine et exécutez gpresult /h gpreport.html sur la machine concernée afin d’identifier quelle stratégie contrôle l’Attribution des droits utilisateur.
Elle empêche tout compte qui y est répertorié, ou tout groupe contenant ce compte, de se connecter via RDP. La stratégie de refus a priorité à la fois sur le paramètre Autoriser l’ouverture de session via les Services Bureau à distance et sur l’appartenance au groupe Utilisateurs du Bureau à distance. Des comptes peuvent se retrouver par accident dans un groupe de refus, par exemple en appartenant au groupe Invités, que de nombreux environnements renforcés incluent par défaut dans la stratégie de refus.
“La connexion a été refusée car le compte utilisateur n’est pas autorisé à ouvrir une session à distance” signifie que la requête de session a atteint la machine cible et a été refusée au niveau de l’autorisation, généralement en raison d’une appartenance à un groupe manquante, d’une lacune dans la stratégie de droits utilisateur ou d’une stratégie de refus active. “Accès refusé” est plus général et peut aussi indiquer des restrictions liées à Credential Guard, des limitations d’accès au SAM, ou des problèmes généraux d’autorisations sans lien direct avec les droits de connexion à distance. La distinction est importante, car elles orientent vers des pistes de dépannage différentes.
