Comment puis-je résoudre les erreurs liées à une instance WorkSpace WorkSpaces Personal qui ne parvient pas à joindre un domaine Active Directory ?

Résolution

Remarque : Si vous utilisez une approbation de forêt, un message d'erreur s'affiche lorsque vous essayez de joindre un domaine alors que l'utilisateur et l’instance WorkSpace se trouvent dans des annuaires actifs différents. Il est recommandé d'utiliser l’approbation bidirectionnelle pour les instances WorkSpaces Amazon Linux, Ubuntu et Red Hat Enterprise Linux (RHEL). Les instances WorkSpaces Ubuntu et RHEL utilisent le démon SSSD (System Security Services Daemon) pour l'intégration Active Directory. Dans la mesure où SSSD ne prend pas en charge l’approbation de forêt, vous devez configurer une approbation externe à la place.

Vérifier la communication avec les contrôleurs de domaine

Assurez-vous que l’instance WorkSpace peut communiquer avec les contrôleurs de domaine Active Directory via n'importe quelle ressource de cloud privé virtuel (VPC). Ces ressources incluent des groupes de sécurité, des listes de contrôle d'accès au réseau (ACL réseau) et des tables de routage. Vérifiez également que l’instance WorkSpace peut communiquer avec vos contrôleurs de domaine sur les ports requis afin de communiquer avec les contrôleurs d'annuaire.

Les instances WorkSpaces utilisent l'interface réseau Elastic du VPC pour communiquer avec les contrôleurs de domaine sur les ports requis lorsqu'elles joignent un domaine puis se connectent.

Lorsque vous créez et enregistrez un répertoire auprès de WorkSpaces, le service d'annuaire crée le groupe de sécurité directoryID_controllers et WorkSpaces crée le groupe de sécurité directoryID_workspacesMembers. Si les règles de l'un de ces groupes de sécurité n'autorisent pas WorkSpaces à communiquer avec les contrôleurs de domaine, vous ne pouvez pas créer de nouvelle instance WorkSpace. Pour résoudre ce problème, assurez-vous que les groupes de sécurité disposent des règles par défaut. Pour AD Connector, le groupe de sécurité du répertoire autorise tout le trafic sortant par défaut. Pour plus d'informations sur les autres annuaires actifs, consultez la section Ce qui est créé avec votre AWS Directory Service pour Microsoft Active Directory.

Important : Assurez-vous que le groupe de sécurité directoryID_workspacesMembers n'a pas été modifié. Par défaut, le groupe de sécurité WorkSpaces autorise tout le trafic sortant.

Pour un Microsoft Active Directory autogéré, vérifiez que le pare-feu sur site ne bloque pas le trafic entre les sous-réseaux WorkSpaces et les contrôleurs de domaine sur les ports requis.

Vérifiez que les ports requis sont ouverts dans une instance Windows WorkSpace

Procédez comme suit :

1. Lancez une instance Amazon Elastic Compute Cloud (Amazon EC2) dans chaque sous-réseau WorkSpaces et attachez le groupe de sécurité directoryID_workspacesMembers.
2. Utilisez RDP pour vous connecter à l'instance.
3. Pour désactiver le pare-feu du système d'exploitation et définir le DNS statique, exécutez la commande PowerShell suivante :

   Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False
   Set-DnsClientServerAddress -InterfaceIndex ((Get-NetAdapter).ifIndex) -ServerAddresses ("DNS Server IP 1","DNS Server IP 2")

   Remarque : Remplacez Adresse IP 1 du serveur DNS et Adresse IP 2 du serveur DNS par les adresses IP de votre serveur DNS.
4. Utilisez l'outil PortQry pour tester la connectivité au contrôleur de domaine. Pour plus d'informations, consultez la page Spécifier un ou plusieurs ports cibles sur le site Web de Microsoft. Pour télécharger l'outil PortQry, consultez la page PortQry Command Line Port Scanner version 2.0 sur le site Web de Microsoft. Pour tester la connectivité aux ports, exécutez la commande suivante pour chaque adresse IP de serveur DNS et de contrôleur de domaine :

   portqry -n DNS Server IP address -p both -e 53
   portqry -n Domain-FQDN-Domain-Controller-IP-address -p both -e 88
   portqry -n Domain-FQDN-Domain-Controller-IP-address -p both -e 389
   portqry -n Domain-FQDN-Domain-Controller-IP-address -p both -e 445
   portqry -n Domain-FQDN-Domain-Controller-IP-address -p both -e 636
   portqry -n Domain-FQDN-Domain-Controller-IP-address -p udp -e 123,137,138
   portqry -n Domain-FQDN-Domain-Controller-IP-address -p tcp -e 135,139

   Remarque : Remplacez Adresse IP du serveur DNS par l’adresse IP de votre serveur DNS et Domain-FQDN-Domain-Controller-IP-address par votre nom de domaine complet (FQDN) ou l'adresse IP de votre contrôleur de domaine.
5. Corrigez les erreurs dès que vous les trouvez. Une fois tous les tests de port réussis, joignez manuellement l'instance au domaine.
   Remarque : Vous pouvez suivre les étapes pour joindre l'instance d’un AWS Managed Microsoft AD ou d’un Active Directory autogéré.

Vérifiez que les ports requis sont ouverts dans une instance WorkSpace Amazon Linux 2, Ubuntu ou RHEL

Procédez comme suit :

1. Sous le système d'exploitation Linux que vous avez utilisé pour lancer l’instance WorkSpace, lancez une instance EC2 dans chaque sous-réseau WorkSpaces et attachez le groupe de sécurité directoryID_workspacesMembers.
2. Utilisez SSH pour vous connecter à l'instance.
3. Pour tester la connectivité de port entre les sous-réseaux WorkSpaces et le contrôleur de domaine, exécutez les commandes suivantes :

   nc -z -v -w 15 domain controller ip 53
   nc -z -v -u -w 15 domain controller ip 53
   nc -z -v -w 15 domain controller ip 88
   nc -z -v -u -w 15 domain controller ip 88
   nc -z -v -u -w 15 domain controller ip 135
   nc -z -v -w 15 domain controller ip 389
   nc -z -v -u -w 15 domain controller ip 389
   nc -z -v -w 15 domain controller ip 636
   nc -z -v -u -w 15 domain controller ip 636
   nc -z -v -w 15 domain controller ip 3268
   nc -z -v -w 15 domain controller ip 3269

   apt-get install -y adcli
   adcli info -S Domain FQDN
   adcli info -S domain controller ip

   Remarque : Remplacez adresse IP du contrôleur de domaine par l'adresse IP du contrôleur de domaine et nom de domaine complet par le nom de domaine complet.
4. Corrigez les erreurs dès que vous les trouvez. Une fois tous les tests de port réussis, joignez manuellement l'instance au domaine.

Pour plus d'informations sur vos indicateurs de commande netcat, utilisez les résumés des indicateurs de commande suivants :

• nc -z recherche les ports ouverts sur un hôte distant mais n'établit pas de connexion complète.
  Remarque : Utilisez nc -4 pour vous connecter à des adresses IPv4 uniquement.
• nc -v fournit une sortie détaillée
• nc -u utilise UDP plutôt que TCP.
  Remarque : Utilisez nc -t pour afficher toutes les connexions TCP.
• nc -w spécifie un délai d'expiration pour la connexion qui ne peut pas être établie.

(Connecteur AD uniquement) Vérifiez les autorisations du compte AWS du service

Pour joindre une instance WorkSpace à un domaine, vous devez configurer des informations d'identification de domaine avec des autorisations déléguées. Si votre organisation utilise AD Connector, il est recommandé d'utiliser un compte de service pour communiquer avec votre Active Directory. Pour vérifier la configuration de votre connecteur AD, procédez comme suit :

1. Vérifiez que le compte de service est activé dans Active Directory.
2. Vérifiez que le mot de passe du compte de service n'est pas expiré.
3. Vérifiez que les autorisations déléguées pour le compte de service dans l'unité d’organisation (UO) WorkSpaces sont exactes.
4. Vérifiez que le nom de l'unité d'organisation dans le répertoire WorkSpaces est exact.

Par défaut, un utilisateur authentifié peut joindre jusqu'à 10 ordinateurs au domaine. Si vous dépassez ce quota, vous rencontrez des problèmes lorsque vous essayez de joindre un domaine. Pour plus d'informations sur la modification du quota, consultez la page Limite par défaut du nombre de postes de travail qu'un utilisateur peut joindre au domaine sur le site Web de Microsoft.

Informations connexes

Les instances Linux ne peuvent pas joindre un domaine ni s'authentifier