Amazon FSx File Gateway n'est plus disponible pour les nouveaux clients. Les clients existants de FSx File Gateway peuvent continuer à utiliser le service normalement. Pour des fonctionnalités similaires à celles de FSx File Gateway, consultez ce billet de blog
Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Résolution des problèmes : problèmes de connexion de la passerelle à Active Directory
Utilisez les informations de dépannage suivantes pour déterminer ce qu'il convient de faire si vous recevez des messages d'erreur tels que « NETWORK_ERRORTIMEOUT, » ou ACCESS_DENIED lorsque vous essayez de joindre votre passerelle de fichiers à un domaine Microsoft Active Directory.
Pour résoudre ces erreurs, effectuez les vérifications et les configurations suivantes.
Vérifiez que la passerelle peut atteindre le contrôleur de domaine en exécutant un test nping
Pour exécuter un test nping :
-
Connectez-vous à la console locale de la passerelle à l'aide de votre logiciel de gestion d'hyperviseur (VMware ou KVM) pour les passerelles sur site Hyper-V, ou à l'aide de SSH pour les passerelles Amazon EC2.
-
Entrez le chiffre correspondant pour sélectionner Gateway Console, puis entrez
hpour répertorier toutes les commandes disponibles. Pour tester la connectivité entre la machine virtuelle Storage Gateway et le domaine, exécutez la commande suivante :nping -dcorp.domain.com-p389-c 1 -t tcpNote
Remplacez-le
corp.domain.compar le nom DNS de votre domaine Active Directory et remplacez-le389par le port LDAP correspondant à votre environnement.Vérifiez que vous avez ouvert les ports requis dans votre pare-feu.
Voici un exemple de test nping réussi où la passerelle a pu atteindre le contrôleur de domaine :
nping -d corp.domain.com -p 389 -c 1 -t tcp Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:24 UTC SENT (0.0553s) TCP 10.10.10.21:9783 > 10.10.10.10:389 S ttl=64 id=730 iplen=40 seq=2597195024 win=1480 RCVD (0.0556s) TCP 10.10.10.10:389 > 10.10.10.21:9783 SA ttl=128 id=22332 iplen=44 seq=4170716243 win=8192 <mss 8961> Max rtt: 0.310ms | Min rtt: 0.310ms | Avg rtt: 0.310ms Raw packets sent: 1 (40B) |Rcvd: 1 (44B)| Lost: 0 (0.00%) Nping done: 1 IP address pinged in 1.09 seconds<br>
Voici un exemple de test nping où il n'y a aucune connectivité ou réponse de la part de la corp.domain.com destination :
nping -d corp.domain.com -p 389 -c 1 -t tcp Starting Nping 0.6.40 ( http://nmap.org/nping ) at 2022-06-30 16:26 UTC SENT (0.0421s) TCP 10.10.10.21:47196 > 10.10.10.10:389 S ttl=64 id=30318 iplen=40 seq=1762671338 win=1480 Max rtt: N/A | Min rtt: N/A | Avg rtt: N/A Raw packets sent: 1 (40B) | Rcvd: 0 (0B) |Lost: 1 (100.00%)Nping done: 1 IP address pinged in 1.07 seconds
Vérifiez les options DHCP définies pour le VPC de votre instance de passerelle Amazon EC2
Si File Gateway s'exécute sur une instance Amazon EC2, vous devez vous assurer qu'un ensemble d'options DHCP est correctement configuré et connecté à l'Amazon Virtual Private Cloud (VPC) qui contient l'instance de passerelle. Pour plus d'informations, consultez la section Ensembles d'options DHCP dans Amazon VPC.
Vérifiez que la passerelle peut résoudre le domaine en exécutant une requête dig
Si le domaine ne peut pas être résolu par la passerelle, celle-ci ne peut pas rejoindre le domaine.
Pour exécuter une requête Dig, procédez comme suit :
-
Connectez-vous à la console locale de la passerelle à l'aide de votre logiciel de gestion d'hyperviseur (VMware ou KVM) pour les passerelles sur site Hyper-V, ou à l'aide de SSH pour les passerelles Amazon EC2.
-
Entrez le chiffre correspondant pour sélectionner Gateway Console, puis entrez
hpour répertorier toutes les commandes disponibles. Pour vérifier si la passerelle peut résoudre le domaine, exécutez la commande suivante :dig -dcorp.domain.comNote
corp.domain.comRemplacez-le par le nom DNS de votre domaine Active Directory.
Voici un exemple de réponse réussie :
; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> corp.domain.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24817 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;corp.domain.com. IN A ;; ANSWER SECTION:corp.domain.com. 600 IN A 10.10.10.10 corp.domain.com. 600 IN A 10.10.20.10;; Query time: 0 msec ;; SERVER: 10.10.20.228#53(10.10.20.228) ;; WHEN: Thu Jun 30 16:36:32 UTC 2022 ;; MSG SIZE rcvd: 78
Vérifiez les paramètres et les rôles des contrôleurs de domaine
Vérifiez que le contrôleur de domaine n'est pas configuré en lecture seule et qu'il possède suffisamment de rôles pour que les ordinateurs puissent y accéder. Pour tester cela, essayez de rejoindre d'autres serveurs à partir du même sous-réseau VPC que la machine virtuelle de passerelle vers le domaine.
Vérifiez que la passerelle est connectée au contrôleur de domaine le plus proche
Il est recommandé de connecter votre passerelle à un contrôleur de domaine géographiquement proche de l'appliance de passerelle. Si l'appliance de passerelle ne parvient pas à communiquer avec le contrôleur de domaine dans les 20 secondes en raison de la latence du réseau, le processus de jonction de domaine peut expirer. Par exemple, le processus peut expirer si l'appliance de passerelle se trouve dans l'est des États-Unis (Virginie du Nord) Région AWS et si le contrôleur de domaine se trouve dans la région Asie-Pacifique (Singapour) Région AWS.
Note
Pour augmenter la valeur du délai d'attente par défaut de 20 secondes, vous pouvez exécuter la commande join-domain dans le AWS Command Line Interface (AWS CLI) et inclure l'--timeout-in-secondsoption permettant d'augmenter le délai. Vous pouvez également utiliser l'appel JoinDomain d'API et inclure le TimeoutInSeconds paramètre pour augmenter le temps. La valeur maximale du délai d'attente est de 3 600 secondes.
Si vous recevez des erreurs lors de l'exécution de AWS CLI commandes, assurez-vous que vous utilisez la AWS CLI version la plus récente.
Vérifiez qu'Active Directory crée de nouveaux objets informatiques dans l'unité d'organisation (OU) par défaut
Assurez-vous que Microsoft Active Directory ne possède aucun objet de stratégie de groupe qui crée de nouveaux objets informatiques dans un emplacement autre que l'unité d'organisation par défaut. Avant de pouvoir joindre votre passerelle au domaine Active Directory, un nouvel objet informatique doit exister dans l'unité d'organisation par défaut. Certains environnements Active Directory sont personnalisés pour avoir des unités d'organisation différentes pour les objets nouvellement créés. Pour garantir l'existence d'un nouvel objet informatique pour la machine virtuelle de passerelle dans l'unité d'organisation par défaut, essayez de créer l'objet ordinateur manuellement sur votre contrôleur de domaine avant de joindre la passerelle au domaine. Vous pouvez également exécuter la commande join-domain à l'aide du. AWS CLI Spécifiez ensuite l'option pour--organizational-unit.
Note
Le processus de création de l'objet informatique s'appelle le pré-staging.
Vérifiez les journaux d'événements de votre contrôleur de domaine
Si vous ne parvenez pas à joindre la passerelle au domaine après avoir essayé toutes les autres vérifications et configurations décrites dans les sections précédentes, nous vous recommandons d'examiner les journaux d'événements de votre contrôleur de domaine. Vérifiez s'il y a des erreurs dans l'observateur d'événements du contrôleur de domaine. Vérifiez que les requêtes de passerelle ont atteint le contrôleur de domaine.