How do I troubleshoot a WorkSpaces Personal WorkSpace that fails to join an Active Directory domain?

Resolution

Note: If you use forest trust, then you receive an error when you try to join a domain and the user and the WorkSpace are in different Active Directories. It's a best practice to use two-way trust for Amazon Linux, Ubuntu, and Red Hat Enterprise Linux (RHEL) WorkSpaces. Ubuntu and RHEL WorkSpaces use System Security Services Daemon (SSSD) for Active Directory integration. Because SSSD doesn't support forest trust, you must configure external trust instead.

Check the communication with the domain controllers

Make sure that the WorkSpace can communicate with the Active Directory domain controllers through any virtual private cloud (VPC) resource. These resources include security groups, network access control lists (network ACLs), and route tables. Also, verify that the WorkSpace can communicate with your domain controllers on the required ports to communicate with directory controllers.

WorkSpaces use the elastic network interface in the VPC to communicate with domain controllers on the required ports when it joins a domain and then logs in.

When you create and register a directory with WorkSpaces, the directory service creates the directoryID_controllers security group and WorkSpaces creates the directoryID_workspacesMembers security group. If the rules in either of these security group don't allow WorkSpaces to communicate with the domain controllers, then you can't create a new WorkSpace. To resolve this issue, make sure that the security groups have the default rules. For AD Connector, the directory security group allows all outbound traffic by default. For information about other Active Directories, see What gets created with your AWS Directory Service for Microsoft Active Directory.

Important: Make sure that the directoryID_workspacesMembers security group hasn't been modified. By default, the WorkSpaces security group allows all outbound traffic.

For a self-managed Microsoft Active Directory, verify that the on-premises firewall doesn't block traffic from WorkSpaces subnets to the domain controllers on the required ports.

Verify that the required ports are open in a Windows WorkSpace

Complete the following steps:

1. Launch an Amazon Elastic Compute Cloud (Amazon EC2) instance in each WorkSpaces subnet and attach the directoryID_workspacesMembers security group.
2. Use RDP to connect to the instance.
3. To turn off the operating system (OS) firewall and set the static DNS, run the following PowerShell command:

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

   Note: Replace DNS Server IP 1 and DNS Server IP 2 with your DNS server IP addresses.
4. Use the PortQry tool to test the connectivity to the domain controller. For more information, see Specify one or more target ports on the Microsoft website. To download the PortQry tool, see PortQry Command Line Port Scanner version 2.0 on the Microsoft website. To test connectivity to the ports, run the following command for each DNS server and domain controller IP address:

   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

   Note: Replace DNS Server IP address with your DNS server IP address and Domain-FQDN-Domain-Controller-IP-address with your fully qualified domain name (FQDN) or your domain controller IP address.
5. Fix errors as you find them. After all the port tests succeed, manually join the instance to the domain.
   Note: You can use the steps to join the instance for an AWS Managed Microsoft AD or for a self-managed Active Directory.

Verify that the required ports are open in an Amazon Linux 2, Ubuntu, or RHEL WorkSpace

Complete the following steps:

1. Use the Linux OS that you used to launch the WorkSpace to launch an EC2 instance in each WorkSpaces subnet and attach the directoryID_workspacesMembers security group.
2. Use SSH to connect to the instance.
3. To test port connectivity from the WorkSpaces subnets to the domain controller, run the following commands:

   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 

   Note: Replace domain controller ip with the domain controller IP address and Domain FQDN with the FQDN.
4. Fix errors as you find them. After all the port tests succeed, manually join the instance to domain.

For more information about your netcat command flags, use the following command flag summaries:

• nc -z scans for open ports on a remote host but doesn't establish a full connection.
  Note: Use nc -4 to connect to IPv4 addresses only.
• nc -v provides verbose output
• nc -u uses UDP instead of TCP.
  Note: Use nc -t to show all TCP connections.
• nc -w specifies a timeout for connection that can't be established.

(AD Connector only) Check the service AWS account permissions

To join a WorkSpace to a domain, you must set up domain credentials with delegated permissions. If your organization uses AD Connector, then it's a best practice to use a service account to communicate with your Active Directory. To verify your AD Connector configuration, complete the following steps:

1. Verify that the service account is activated in the Active Directory.
2. Verify that the service account password isn't expired.
3. Verify the delegated permissions for the service account in the WorkSpaces organizational unit (OU) are accurate.
4. Verify that the OU name in the WorkSpaces directory is accurate.

By default, an authenticated user can join up to 10 computers to the domain. If you exceed this quota, then you experience issues when you try to join a domain. For information about how to change the quota, see Default limit to number of workstations a user can join to the domain on the Microsoft website.

Related information

Linux instances unable to join domain or authenticate