How do I troubleshoot issues when I join my Storage Gateway file gateway to a domain for Microsoft Active Directory authentication?

6 minute read
0

I created a file gateway on AWS Storage Gateway and I want to use Microsoft Active Directory (Microsoft AD) for authentication. However, when I try to join my file gateway with the Microsoft AD domain, I get a "NETWORK_ERROR TIMEOUT ACCESS_DENIED" error.

Short description

To troubleshoot "NETWORK_ERROR TIMEOUT ACCESS_DENIED" errors, complete the following tasks:

  1. Confirm that the gateway can reach the domain controller.
  2. Review the domain controller roles.
  3. Check the domain controller location.
  4. Check the Microsoft AD organizational unit (OU).
  5. Review your domain controller servers.
  6. Review the storage gateway NTP.
  7. Review your event logs.

Resolution

Note: If you receive errors when you run AWS Command Line Interface (AWS CLI) commands, then see Troubleshoot AWS CLI errors. Also, make sure that you're using the most recent AWS CLI version.

Confirm that the gateway can reach the domain controller

Run an Nping test to confirm that the gateway can reach the domain controller. Use ssh for Amazon Elastic Compute Cloud (Amazon EC2) to connect to the AWS Storage Gateway console and the console for VMware, Hyper-V, or KVM. Choose the option Command Prompt, and then type h to list the available commands from the console. To test the connectivity between the Storage Gateway virtual machine and the domain, run the following command:

Note: Replace corp.example.com with the domain DNS name and 389 with the LDAP port used. Also, verify that you opened the required ports within your firewall.

nping -d <corp.example.com> -p <389> -c 1 -t tcp

The following is an example of a successful nping test where the gateway reached the domain controller:

nping -d corp.example.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

If there's no connectivity, then the response of the nping command looks similar to the following output. The command doesn't have a response for the corp.example.com destination:

nping -d <corp.example.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

Create a DHCP options set

If the file gateway runs on an Amazon EC2 instance, you must first create a DHCP options set. Then, attach the set (if it's not already set) to the Amazon Virtual Private Cloud (VPC) that the instance is in.

Confirm that the file gateway can resolve the domain

Confirm that the file gateway can resolve the domain. If the domain isn't resolvable by the gateway appliance, then you can't join the domain. To confirm that the gateway resolves the DNS of the domain, run the following command:

Note: Replace corp.example.com with the domain DNS name.

dig -d <corp.example.com>

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-26.P2.amzn2.5.2 <<>> corp.example.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.example.com.        IN    A

;; ANSWER SECTION:
corp.example.com.    600    IN    A    10.10.10.10
corp.example.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

Review the domain controller roles

Verify that the domain controller isn't set to read-only, and that the domain controller has enough roles for more computers to join. To check this, try to join other servers in the same VPC subnet as the gateway VM to the domain.

Check the domain controller location

It's a best practice to join the file gateway to a domain controller that's geographically closer to the gateway. If the gateway appliance can't reach or query the domain controller within 20 seconds, then the process might time out. For example, if the gateway appliance is in the US East (N. Virginia) Region and the domain controller is in the Asia Pacific (Singapore) Region, then the domain-join process might time out.

To increase the default timeout value of 20 seconds, run the join-domain command on the AWS CLI. When you use this command, include the --timeout-in-seconds option to increase the time. You can also use the JoinDomain API call and include the TimeoutInSeconds parameter to increase the time. The maximum timeout value is 3,600 seconds.

Check the Microsoft AD OU

Check whether the Microsoft AD OU has any Group Policy Objects that create a new computer object outside of the default OU location. Before you join the domain to the file gateway, there must be a new computer object in the OU. Some environments are customized to have different OUs for newly created objects. Make sure that a computer object for the gateway VM under a certain OU joins the domain. Before you join the file gateway to the domain, create the computer object on your domain controller. Or, use the AWS CLI to run the join-domain command. Then, specify the option for --organizational-unit.

Note: The process of creating the computer object is called pre-staging.

Review your domain controller servers

Stale SRV records for the domain controller servers in DNS can cause Microsoft AD domain join failure. Before you join the storage gateway to the Microsoft AD domain, run the -d <domain> command and make sure that all domain controller servers are available. If any of the servers aren't in the network or don't resolve to their DNS name, then the Microsoft AD domain administrator must correct it. For more information, see Active Directory domain join troubleshooting guidance on the Microsoft website.

Review the storage gateway NTP

Verify that the storage gateway NTP is set correctly and that the time is fully in sync. High time skew can lead to Microsoft AD domain join failure. For more information, see Synchronize VM time with Hyper-V or Linux KVM host time.

Review your event logs

If you still can't join the gateway to the domain after you complete the preceding tasks, then check whether there are any related event logs. Check for any errors in the event viewer of the domain controller. Verify that the gateway query reached the domain controller.

AWS OFFICIAL
AWS OFFICIALUpdated 8 months ago
2 Comments
  1. Having stale SRV records for Domain Controller serves in DNS also can lead to AD domain join failure. Hence, before joining the storage gateway into AD domain, please make sure to run the command "dig -d <domain>" and then make sure all Domain Controller servers are available in network. If any one of those are not in network or not resolving to their DNS name then AD domain administrator should correct.
  2. Verify that the storage gateway NTP is set correctly and the time is in fully sync. Having high time skew can lead to AD domain join failure
AWS
replied 2 years ago

Thank you for your comment. We'll review and update the Knowledge Center article as needed.

profile pictureAWS
EXPERT
replied 2 years ago