Comment résoudre les erreurs d'authentification lorsque j'utilise RDP pour me connecter à une instance Windows EC2 ?

Date de la dernière mise à jour : 29/06/2021

Je ne parviens pas à me connecter à mon instance Amazon Elastic Compute Cloud (Amazon EC2) avec le protocole RDP (Remote Desktop Protocol). Je reçois l'un des messages d'erreur d'authentification suivants :

  • « 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 la NLA en utilisant les options de l'onglet Remote (Distant) de la boîte de dialogue System Properties (Propriétés système). »

Brève description

Les erreurs précédentes peuvent se produire dans les deux scénarios suivants :

  • L'authentification au niveau du réseau (NLA) est activée sur le serveur.
  • La relation d'approbation entre votre domaine et l'instance EC2 jointe à ce domaine échoue lors de la connexion RDP.

Solution

NLA est activée sur le serveur

Des erreurs NLA se produisent souvent lorsque l'instance a perdu la connectivité à un contrôleur de domaine, car les autorisations du domaine ne sont pas authentifiées. Pour résoudre ce problème, vous pouvez utiliser le document d'automatisation AWS Systems Manager AWSSupport-TroubleshootRDP. Vous pouvez également désactiver NLA sur l'instance.

Document d'automatisation AWSSupport-TroubleshootRDP

Le document d'automatisation AWSSupport-TroubleshootRDP vous permet de modifier des paramètres courants (comme le port RDP, l'authentification au niveau du réseau (NLS) et les profils de pare-feu Windows) sur une instance Windows Amazon EC2 qui peut avoir un impact sur les connexions RDP. Pour obtenir des instructions de dépannage à l'aide du document AWSSupport-TroubleshootRDP, consultez AWSSupport-TroubleshootRDP.

Désactiver NLA sur l'instance

Vous pouvez désactiver NLA sur l'instance inaccessible à l'aide de l'une des méthodes suivantes :

  • Désactivez NLA à l'aide du document Systems Manager AWS-RunPowerShellScript.
  • Effectuez manuellement les modifications du registre hors connexion.

Remarque : la désactivation de NLA nécessite des modifications de registre. Avant de commencer, créez une Amazon Machine Image (AMI) à partir de votre instance. Cela crée une sauvegarde avant d'apporter des modifications au registre.

Désactiver NLA à l'aide du document Systems Manager AWS-RunPowerShellScript

Suivez les étapes ci-dessous pour utiliser la fonctionnalité AWS Systems Manager AWS-RunPowerShellScript Run Command pour ajouter des clés de registre.

Important : l'agent SSM AWS Systems Manager doit être installé sur l'instance. L'instance doit également posséder un rôle AWS Identity and Access Management (IAM) (AmazonEC2RoleForSSM) avec des autorisations sur Systems Manager, et doit présenter des rapports « en ligne » sur le tableau de bord de Systems Manager. Pour plus d'informations, consultez la section Prérequis de Systems Manager.

1.    Ouvrez la console AWS Systems Manager.

2.    Dans la section Instances & Nodes (Instances et nœuds) du volet de navigation, choisissez Run Command.

3.    Pour Command document (Document de commande), sélectionnez AWS-RunPowerShellScript.

4.    Pour Command parameters (Paramètres de commande), entrez 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

5.    Pour Targets (Cibles), sélectionnez Choose instances manually (Choisir manuellement les instances).

6.    Sélectionnez votre instance.

7.    Sélectionnez Exécuter.

8.    Patientez jusqu'à ce que Overall status (Statut global) passe à Success (Réussi). Actualisez la page au bout de 2 minutes.

9.    Redémarrez l'instance.

10.    Connectez-vous à l'instance à l'aide de RDP.

Effectuez manuellement les modifications du registre

  1. Arrêtez l'instance inaccessible et détachez le volume racine.
  2. Lancez une nouvelle instance dans la même zone de disponibilité que l'instance d'origine que vous venez d'arrêter. Cela devient votre instance de secours. Il est recommandé de lancer une version Windows différente de l'instance inaccessible. Cela permet d'éviter les problèmes de signature de disque.
  3. Attachez le volume détaché à l'instance de secours en tant que /dev/xvdf.
  4. Connectez-vous à l'instance de secours à l'aide de RDP, puis mettez en ligne le volume que vous venez d'attacher en ligne dans Disk Manager.
  5. Exécutez regedit.exe pour ouvrir l'éditeur du Registre.
  6. Sélectionnez HKEY_LOCAL_MACHINE, puis Fichier, Load Hive.
  7. Accédez au dossier Windows sur le volume attaché, puis sélectionnez le fichier SYSTEM. Le chemin par défaut est D:\Windows\System32\config.
  8. Nommez le fichier SYSTEM. Par exemple badsys.
  9. badsys apparaît désormais sous HKEY_LOCAL_MACHINE. Sous badsys, accédez à ControlSet001, Control, Terminal Server, WinStations, RDP-Tcp.
  10. Double-cliquez sur SecurityLayer et définissez ses données de valeur sur 0. Sélectionnez ensuite UserAuthentication et définissez ses données de valeur sur 0.
  11. Faites défiler vers le haut et sélectionnez badsys, File, Unload Hive.
  12. Après le déchargement de Hive, ouvrez Disk Manager et déconnectez le disque.
  13. Détachez le volume de l'instance de secours et attachez-le à l'instance inaccessible en tant que volume racine (/dev/sda1).
  14. Démarrez l'instance et testez RDP.

La relation d'approbation entre votre domaine et l'instance EC2 jointe à ce domaine échoue lors de la connexion RDP

Vous pouvez essayer de vous connecter à l'instance inaccessible à l'aide des autorisations de l'utilisateur mises en cache.

Conditions préalables

  • Un compte local qui peut s'authentifier auprès de l'instance EC2.
  • (Options) Au moins un compte de domaine doit être connecté lorsque l'instance a réussi à communiquer avec le contrôleur de domaine. Pour que le compte de domaine fonctionne, les autorisations du compte de domaine doivent être mises en cache sur le serveur. Par conséquent, il est toujours recommandé d'utiliser un compte local.
  • Pour utiliser la connexion interactive, assurez-vous que la politique définissant le nombre d'identifiants précédents à mettre en cache (si le contrôleur de domaine n'est pas disponible) est défini sur au moins 1. Vous pouvez également définir la politique sur la valeur par défaut de 10. Par défaut, cette politique n'est pas définie dans le GPO et la politique locale du serveur est utilisée.

Pour vous connecter à l'aide des autorisations de l'utilisateur mises en cache, procédez comme suit :

  1. Ouvrez la console Amazon EC2, puis sélectionnez Groupes de sécurité.
  2. Sélectionnez Créer un groupe de sécurité, puis ajoutez un nom et une description.
  3. Sous Règles de groupe de sécurité, sélectionnez Entrante – Ajouter une règle.
  4. Entrez RDP.
  5. Dans le champ Source, entrez l'adresse IP à partir de laquelle vous souhaitez exécuter RDP.
  6. Pour la Règle sortante, supprimez tous les accès sortants, puis sélectionnez Créer.
  7. Choisissez l'instance inaccessible, puis sélectionnez Actions, Réseaux, Modifier les groupes de sécurité. Supprimez tous les groupes de sécurité existants et attribuez uniquement le groupe de sécurité que vous venez de créer.
  8. RDP vers l'instance EC2 en utilisant le compte de domaine normal. Étant donné que tous les accès sortants sont supprimés d'EC2, RDP utilise les autorisations mises en cache stockées dans le serveur.

Remarque : Au départ, l'authentification est tentée par rapport au contrôleur de domaine. Toutefois, étant donné qu'il n'y a pas d'accès sortant depuis EC2, l'authentification finit par vérifier les autorisations mises en cache dans le serveur. En utilisant les autorisations mises en cache, l'authentification est retentée et la connexion aboutit. Une fois connecté, vous pouvez rétablir l'état d'origine des paramètres du groupe de sécurité et continuer à résoudre les problèmes liés à votre domaine.

Résolution de problèmes supplémentaires

Si vous ne parvenez toujours pas à vous connecter, consultez la section Comment résoudre les problèmes de connexion Bureau à distance à mon instance Windows Amazon EC2 ?


Cet article vous a-t-il été utile ?


Besoin d'aide pour une question technique ou de facturation ?