Comment résoudre les erreurs d'authentification lorsque j'utilise le protocole RDP pour me connecter à une instance Windows EC2 ?
Je reçois des erreurs d'authentification lorsque j'utilise le protocole RDP (Remote Desktop Protocol) pour essayer de me connecter à mon instance Windows Amazon Elastic Compute Cloud (Amazon EC2).
Résolution
Les erreurs d'authentification suivantes peuvent s'afficher lorsque vous utilisez le protocole RDP pour vous connecter à une instance Windows Amazon EC2 :
- « Une erreur d’authentification s’est produite. L’autorité de sécurité locale ne peut pas être contactée. »
- « L’ordinateur distant auquel vous essayez de vous connecter nécessite une authentification au niveau du réseau (NLA), mais votre contrôleur de domaine Windows ne peut pas être contacté pour effectuer la NLA. Si vous êtes administrateur sur l’ordinateur distant, vous pouvez désactiver NLA à l’aide des options de l’onglet Distant de la boîte de dialogue Propriétés système. »
Cette erreur peut se produire dans les scénarios suivants :
- L'authentification au niveau du réseau (NLA) est activée pour le serveur.
- La relation de confiance entre votre domaine et l'instance EC2 jointe à ce domaine échoue lorsque RDP se connecte.
L’authentification NLA est activée pour le serveur
Des erreurs NLA se produisent lorsqu'une instance perd sa connectivité à un contrôleur de domaine parce que les informations d'identification du domaine ne sont pas authentifiées. Pour résoudre ce problème, utilisez le document d'automatisation AWS Systems Manager AWSSupport-TroubleshootRDP pour modifier les paramètres de l'instance ou désactiver l’authentification NLA sur l'instance.
Le document d'automatisation AWSSupport-TroubleshootRDP vous permet de modifier les paramètres courants d'une instance qui peuvent avoir un impact sur les connexions RDP.
Utilisez l'une des méthodes suivantes pour désactiver la NLA sur une instance inaccessible :
- Utilisez le Gestionnaire de session d'AWS Systems Manager.
- Exécutez le document de commande AWS-RunPowerShellScript.
- Modifiez manuellement le registre hors ligne.
**Remarque :**Vous devez modifier le registre lorsque vous modifiez la NLA. Avant de commencer, créez une Amazon Machine Image (AMI) à partir de votre instance. Cela crée une sauvegarde avant de modifier le registre.
Désactiver l’authentification NLA avec le gestionnaire de session de Systems Manager
Pour désactiver la NLA avec le gestionnaire de session, ajoutez des clés de registre en procédant comme suit :
Important : L'agent Systems Manager (agent SSM) doit être installé sur l'instance et celle-ci doit être en ligne. L'instance doit également disposer d'un rôle AWS Identity and Access Management (IAM) qui accorde des autorisations au gestionnaire de session. Pour plus d'informations, consultez la section Prérequis pour Session Manager.
- Ouvrez la console Systems Manager.
- Dans le volet de navigation, sélectionnez Fleet Manager.
- Choisissez l'instance gérée à laquelle vous souhaitez vous connecter.
- Dans le menu Actions du nœud, choisissez Démarrer la session du terminal, puis Connecter. Vous êtes connecté à l'instance à l'aide du gestionnaire de sessions.
- Exécutez les commandes suivantes dans la session du terminal :
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
Désactivez la NLA avec le document de commande AWS-RunPowerShellScript
Pour désactiver la NLA avec le document de commande AWS:RunPowerShellScript, ajoutez des clés de registre en procédant comme suit :
**Important :**L'agent SSM doit être installé sur l'instance et elle doit être en ligne. L'instance doit également avoir un rôle IAM qui accorde des autorisations pour le gestionnaire de sessions. Pour plus d'informations, consultez la section Prérequis pour Session Manager.
-
Ouvrez la console Systems Manager.
-
Dans le volet de navigation, choisissez Exécuter des commandes, puis sélectionnez Exécuter une commande.
-
Pour le Document de commande, choisissez AWS-RunPowerShellScript.
-
Pour les Paramètres de commande, saisissez ce qui suit :
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
-
Pour Sélection de la cible, choisissez Choisir les instances manuellement, puis sélectionnez votre instance.
-
Choisissez Exécuter.
-
Attendez que le Statut général passe à Succès. Rafraîchissez la page au bout de deux minutes.
-
Redémarrez l'instance.
-
Utilisez le protocole RDP pour vous connecter à l'instance.
Modifiez manuellement le registre hors ligne
-
Arrêtez l'instance inaccessible et détachez le volume racine.
-
Lancez une nouvelle instance dans la même zone de disponibilité que l'instance inaccessible que vous avez arrêtée. La nouvelle instance devient votre instance de secours.
**Important :**Il est recommandé de lancer une instance Windows différente de l'instance inaccessible afin d'éviter les problèmes de signature de disque.
-
Attachez le volume détaché à l'instance de secours en tant que /dev/xvdf.
-
Utilisez le protocole RDP pour vous connecter à l'instance de secours, puis mettez en ligne le volume que vous venez de connecter dans le Gestionnaire de disques.
-
Dans une invite de commande, tapez regedit.exe, puis appuyez sur Entrée pour ouvrir l'éditeur du registre.
-
Sélectionnez HKEY_LOCAL_MACHINE puis sélectionnez Fichier, Charger la ruche.
-
Accédez au dossier Windows sur le volume joint, puis sélectionnez le fichier SYSTEM. Le chemin par défaut est D:\Windows\System32\config.
-
Nommez le fichier SYSTEM. Par exemple, badsys.
-
Le fichier système badsys apparaît désormais sous HKEY_LOCAL_MACHINE. Sous badsys, accédez à ControlSet001, Contrôle, Serveur de Terminal, WinStations, RDP-TCP.
-
Double-cliquez sur SecurityLayer et définissez les données de valeur sur **0.**Sélectionnez UserAuthentication et définissez les données de valeur sur 0. Sélectionnez ensuite AllowSecProtocolNegotiation et définissez les données de valeur sur 0.
-
Faites défiler l'écran vers le haut et sélectionnez badsys, Fichier, Décharger la ruche.
-
Une fois le déchargement de la ruche terminé, ouvrez le Gestionnaire de disques et déconnectez le disque.
-
Détachez le volume de l'instance de secours et attachez-le à l'instance inaccessible en tant que volume racine (/dev/sda1).
-
Démarrez l'instance et testez le protocole RDP.
La relation de confiance entre votre domaine et l'instance EC2 jointe à ce domaine échoue lors de la connexion RDP
Utilisez les informations d'identification utilisateur mises en cache pour essayer de vous connecter à l'instance inaccessible.
Prérequis
-
Un compte local capable de s'authentifier avec succès auprès de l'instance EC2.
-
(Facultatif) Au moins un compte de domaine qui était connecté lorsque l'instance communiquait avec le contrôleur de domaine. Pour que le compte de domaine fonctionne, les informations d'identification du compte de domaine doivent être mises en cache sur le serveur.
**Remarque :**Il est recommandé d'utiliser un compte local.
-
Lorsque le contrôleur de domaine n'est pas disponible, assurez-vous que le paramètre du nombre de connexions précédentes à mettre en cache est défini sur au moins 1. Cela doit être fait pour utiliser des connexions interactives. La politique peut être définie sur la valeur par défaut de 10. Par défaut, la politique n'est pas définie et vous pouvez utiliser la politique locale du serveur.
Pour vous connecter à l'aide des informations d'identification utilisateur mises en cache, procédez comme suit :
- Ouvrez la console EC2, puis sélectionnez Groupes de sécurité.
- Dans le volet de navigation, choisissez Groupes de sécurité.
- Choisissez Créer un groupe de sécurité.
- Ajoutez un nom et une description du groupe de sécurité.
- Pour les Règles entrantes, choisissez Ajouter une règle.
- Pour le Type, choisissez RDP. Fournissez ensuite des informations sur la source à partir de laquelle vous souhaitez utiliser le protocole RDP pour vous connecter.
- Sous Règles sortantes, supprimez tous les accès sortants.
- Choisissez Créer un groupe de sécurité.
- Dans le volet de navigation, choisissez Instances, puis sélectionnez l'instance inaccessible.
- Choisissez Actions, Sécurité, Modifier les groupes de sécurité. Supprimez tous les groupes de sécurité existants, puis attribuez le groupe de sécurité que vous venez de créer.
- Utilisez le compte de domaine normal pour utiliser le protocole RDP afin de vous connecter à l'instance EC2. Comme tous les accès sortants sont supprimés d'Amazon EC2, RDP utilise les informations d'identification mises en cache stockées sur le serveur.
**Remarque :**L'authentification est initialement tentée auprès du contrôleur de domaine. Mais comme il n'y a aucun accès sortant depuis Amazon EC2, l'authentification finit par vérifier les informations d'identification mises en cache stockées sur le serveur. L'authentification est à nouveau tentée avec les informations d'identification mises en cache et la connexion réussit. Une fois connecté, vous pouvez rétablir les paramètres du groupe de sécurité à leur état d'origine, puis continuer à résoudre les éventuels problèmes liés à votre domaine.
Résolution des problèmes supplémentaires
Si vous ne parvenez toujours pas à vous connecter à l'instance, consultez Comment résoudre les problèmes de connexion au bureau à distance à mon instance Windows Amazon EC2 ?
Informations connexes
Vidéos associées
Contenus pertinents
- demandé il y a 5 moislg...
- demandé il y a 2 anslg...
- demandé il y a 3 moislg...
- demandé il y a 10 jourslg...
- demandé il y a 9 moislg...
- AWS OFFICIELA mis à jour il y a 2 ans
- AWS OFFICIELA mis à jour il y a un an
- AWS OFFICIELA mis à jour il y a un an