Votre Mac envoie le mauvais compte Windows via RDP

Le tunnel se reconnecte, le Mac atteint de nouveau le réseau du bureau, et le Bureau à distance répond toujours par un échec d'ouverture de session. Cette erreur n'est pas celle du VPN. Le tunnel place le Mac sur un réseau approuvé ; un compte Windows se connecte à l'ordinateur distant, et l'entrée de connexion peut continuer d'envoyer un compte que vous avez cessé d'utiliser il y a des mois.

Passez l'entrée en revue avant de toucher au trousseau.

Le compte VPN et le compte Windows sont deux choses différentes

Une identité VPN authentifie l'appareil ou la personne auprès de la passerelle du tunnel. Elle ne dit rien du compte Windows que l'hôte distant acceptera et ne peut pas le remplacer. Quand le tunnel est sain et que le bureau refuse l'ouverture de session, le problème a déjà dépassé la couche réseau. Traitez les deux authentifications comme des événements distincts avec des journaux distincts. La passerelle peut afficher une session propre tandis que le journal de sécurité de Windows enregistre un échec d'ouverture de session pour une raison entièrement différente.

Supposons que l'administrateur vous ait dit d'utiliser EXAMPLE\alex et que l'entrée enregistrée sélectionne encore un alex nu. Ce sont des comptes différents. Le nom non qualifié est résolu par rapport aux comptes locaux de l'ordinateur distant, et sur une machine jointe à un domaine, il peut très bien ne pas se résoudre du tout vers l'identité du domaine.

Retirer le préfixe de domaine n'est donc pas une réparation générique. Cela change le compte demandé et peut produire un refus qui ressemble à un problème de mot de passe alors que le mot de passe n'a jamais été en cause.

Ouvrez l'entrée de connexion, pas tout le trousseau

Dans l'application Windows App actuelle pour macOS, trouvez le PC distant sous Appareils, ouvrez son action Modifier et regardez le compte associé à cette entrée précise. L'application expose des contrôles d'identifiants enregistrés qui vous permettent de choisir un autre compte enregistré ou d'en supprimer un obsolète. C'est l'endroit pris en charge pour corriger la sélection. Changez une propriété à la fois, afin de savoir quelle modification a réellement compté. Un changement d'identifiants et un changement de nom d'hôte effectués ensemble produisent un résultat que personne ne peut attribuer.

Ne commencez pas par supprimer chaque élément du trousseau dont le nom contient le nom du serveur. Les éléments du trousseau sont partagés entre applications, et une suppression large peut retirer un accès sans rapport sans rien changer côté Windows. Elle détruit aussi les preuves que vous voudriez si le vrai problème s'avère être le nom d'hôte, la route ou le service RDP.

Si un identifiant enregistré est utilisé par plusieurs PC distants, vérifiez ces dépendances avant de le supprimer. Modifier l'entrée d'un seul PC est réversible ; supprimer un identifiant partagé est un changement à plus large rayon d'action et à pire traçabilité.

Utilisez la forme de compte fournie par l'administrateur

Saisissez le compte exactement tel qu'il a été émis, dans la forme attendue par l'environnement : DOMAIN\user pour un domaine de style NetBIOS, ou le user principal name si c'est ce que le répertoire utilise. Enregistrez-le ensuite pour ce PC et faites une tentative de connexion délibérée.

Regardez quel compte l'invite d'ouverture de session affiche. Une invite qui contient déjà un autre nom signifie que la sélection enregistrée n'a pas été remplacée, et la tentative que vous venez de faire a de nouveau testé l'ancien identifiant.

Gardez le mot de passe hors des notes, des tickets et des captures d'écran. Notez plutôt le nom du compte et le code d'erreur exact, car le code distingue un mauvais identifiant d'un refus de stratégie, d'un mot de passe expiré ou d'une machine qui n'accepte pas du tout RDP.

Une connexion échouée avant l'ouverture de session est une autre panne

Si la visionneuse échoue avant l'apparition de toute ouverture de session Windows, les identifiants ne sont pas en cause. Vérifiez que le nom d'hôte se résout, que la route vers l'hôte existe via le tunnel et que le service RDP écoute. Une connexion TCP qui ne s'établit jamais n'atteint jamais la couche du compte.

À l'inverse, un refus explicite de compte n'est pas la preuve que le DNS est cassé ni qu'il faut assouplir la validation du certificat. Ces changements affaiblissent la connexion et laissent généralement le refus exactement là où il était.

Testez par les plus petits pas possibles : confirmez que le port est joignable, que l'invite d'ouverture de session apparaît, que le compte affiché est bien celui voulu, puis fournissez le mot de passe. Chaque étape a une défaillance distincte et une correction distincte.

Laissez la reconnexion automatique tranquille

La reconnexion automatique réutilise l'entrée existante, y compris son compte enregistré. C'est une commodité, pas une réparation d'identifiants : la désactiver ne corrige pas une mauvaise sélection et l'activer n'en crée pas. Si l'entrée contient maintenant le bon compte, la reconnexion l'utilisera.

Enregistrez l'entrée corrigée, connectez-vous une fois à la main et notez quel compte a fonctionné. Cette seule ligne fait passer le diagnostic de la personne suivante de cinq minutes au lieu d'un après-midi d'archéologie du trousseau.