Troubleshooting AD Connector
The following can help you troubleshoot some common issues you might encounter when creating or using your AD Connector.
Topics
Creation issues
The following are common creation issues for AD Connector
I receive an "AZ Constrained" error when I create a directory
Some AWS accounts created before 2012 might have access to Availability Zones in the US East (N. Virginia), US West (N. California), or Asia Pacific (Tokyo) Regions that do not support AWS Directory Service directories. If you receive an error such as this when creating a Active Directory, choose a subnet in a different Availability Zone and try to create the directory again.
I receive a "Connectivity issues detected" error when I try to create AD Connector
If you receive the "Connectivity issue detected" error when trying to create an AD Connector, the error could be due to port availability or AD Connector password complexity. You can test your AD Connector's connection to see whether the following ports are available:
-
53 (DNS)
-
88 (Kerberos)
-
389 (LDAP)
To test your connection, see Test your AD Connector. The connection test should be performed on the instance joined to both subnets that the AD Connector's IP addresses are associated to.
If the connection test is successful and the instance joins the domain, then check your AD Connector’s password. AD Connector must meet AWS password complexity requirements. For more information, see Service account in AD Connector prerequisites.
If your AD Connector does not meet these requirements, recreate your AD Connector with a password that complies with these requirements.
Connectivity issues
The following are common connectivity issues for AD Connector
I receive a "Connectivity issues detected" error when I try to connect to my on-premises directory
You receive an error message similar to the following when connecting to your on-premises directory:
Connectivity issues detected: LDAP unavailable (TCP port 389) for IP: <IP address>
Kerberos/authentication unavailable (TCP port 88) for IP: <IP address>
Please ensure that the listed ports are available and retry the operation.
AD Connector must be able to communicate with your on-premises domain controllers via TCP and UDP over the following ports. Verify that your security groups and on-premises firewalls allow TCP and UDP communication over these ports. For more information, see AD Connector prerequisites.
-
88 (Kerberos)
-
389 (LDAP)
You may need additional TCP/UDP ports depending on your needs. See the
following list for some of these ports. For more information about ports used by
Active Directory, see How to configure a firewall for Active Directory domains and trusts
-
135 (RPC Endpoint Mapper)
-
646 (LDAP SSL)
-
3268 (LDAP GC)
-
3269 (LDAP GC SSL)
I receive a "DNS unavailable" error when I try to connect to my on-premises directory
You receive an error message similar to the following when connecting to your on-premises directory:
DNS unavailable (TCP port 53) for IP: <DNS IP address>
AD Connector must be able to communicate with your on-premises DNS servers via TCP and UDP over port 53. Verify that your security groups and on-premises firewalls allow TCP and UDP communication over this port. For more information, see AD Connector prerequisites.
I receive an "SRV record" error when I try to connect to my on-premises directory
You receive an error message similar to one or more of the following when connecting to your on-premises directory:
SRV record for LDAP does not exist for IP: <DNS IP address>
SRV record for Kerberos does not exist for IP: <DNS IP address>
AD Connector needs to obtain the _ldap._tcp.
and
<DnsDomainName>
_kerberos._tcp.
SRV
records when connecting to your directory. You will get this error if the service
cannot obtain these records from the DNS servers that you specified when connecting
to your directory. For more information about these SRV records, see SRV record requirements.<DnsDomainName>
Authentication issues
Here are some common authentication issues with AD Connector:
I receive a '“Certificate Validation failed” error when I try to sign in to Amazon WorkSpaces with a smart card
You receive an error message similar to the following when you try to sign in to your WorkSpaces with a smart card:
ERROR: Certificate Validation failed. Please try again by restarting your browser or application and make sure you select the correct certificate.
The error occurs if the smart card’s certificate is not properly stored on the client that uses the certificates. For more information on AD Connector and smart card requirements, see Prerequisites.
Use the following procedures to troubleshoot the smart card’s ability to store certificates in the user’s certificate store:
-
On the device that is having trouble accessing the certificates, access the Microsoft Management Console (MMC).
Important
Before moving forward, create a copy of the smart card’s certificate.
-
Navigate to the certificate store in the MMC. Delete the user's smart card certificate from the certificate store. For more information about viewing the certificate store in the MMC, see How to: View certificates with the MMC snap-in
in Microsoft documentation. -
Remove the smart card.
-
Reinsert the smart card so it can repopulate the smart card certificate in the user’s certificate store.
Warning
If the smart card is not repopulating the certificate to the user store then it cannot be used for WorkSpaces smart card authentication.
The AD Connector's Service account should have the following:
-
my/spn
added to the Service Principle Name -
Delegated for LDAP service
After the certificate is repopulated on the smart card, the on-premise domain controller should be checked to determine
if they are blocked from User Principal Name (UPN) mapping for Subject Alternative Name. For more information about this
change, see
How to disable the Subject Alternative Name for UPN mapping
Use the following procedure to check your domain controller's registry key:
In the Registry Editor, navigate to the following hive key
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdc\UseSubjectAltName
Select UseSubjectAltName. Ensure the value is set to 0.
Note
If the registry key is set on the on-premise Domain Controllers then the AD Connector will not be able to locate the users in Active Directory and result in the above error message.
The Certificate Authority (CA) certificates should be uploaded to the AD Connector smart card certificate. The certificate should contain OCSP information. The following list additional requirements for the CA:
-
The certificate should be in the Trusted Root Authority of the Domain Controller, the Certificate Authority Server, and the WorkSpaces.
-
Offline and Root CA certificates will not contain the OSCP information. These certificates contain information about their revocation.
-
If you are using a third-party CA certificate for smart card authentication, then the CA and intermediate certificates need to be published to the Active Directory NTAuth store. They must be installed in the trusted root authority for all domain controllers, certificate authority servers, and WorkSpaces.
-
You can use the follow command to publish certificates to the Active Directory NTAuth store:
certutil -dspublish -f
Third_Party_CA.cer
NTAuthCA
-
For more information about publishing certificates to the NTAuth store, see Import the issuing CA certificate into the Enterprise NTAuth store in Access Amazon WorkSpaces with Common Access Cards Installation Guide.
You can check to see if the user certificate or CA chain certificates are verified by OCSP by following this procedure:
-
Export the smart card certificate to a location on the local machine like the C: drive.
-
Open a Command Line prompt and navigate to the location where the exported smart card certificate is stored.
-
Enter the following command:
certutil -URL
Certficate_name.cer
-
A pop-up window should appear following the command. Select the OCSP option on the right corner and select Retrieve. The status should return as verified.
For more information about the certutil command, see certutil
I receive an "Invalid Credentials" error when the service account used by AD Connector attempts to authenticate
This can occur if the hard drive on your domain controller runs out of space. Ensure that your domain controller's hard drives are not full.
I receive a “Unable to Authenticate” error when using AWS applications to search for users or groups
You may experience errors when searching for users while using AWS applications, such as WorkSpaces or Amazon QuickSight, even while the AD Connector status was active. Expired credentials can prevent AD Connector from completing queries on objects in your Active Directory. Update the password for the service account using the ordered steps provided in Seamless domain join for Amazon EC2 instances stopped working.
I receive an error about my directory credentials when I try to update the AD Connector service account
You receive an error message similar to one or more of the following when trying to update the AD Connector service account:
Message:An Error Has Occurred
Your directory needs a credential update. Please update the directory credentials.
An Error Has Occurred
Your directory needs a credential update. Please update the directory credentials
following Update your AD Connector Service Account Credentials
Message:
An Error Has Occurred
Your request has a problem. Please see the following details.
There was an error with the service account/password combination
There could be an issue with the time synchronization and Kerberos.
AD Connector sends Kerberos authentication requests to Active Directory. These requests
are time sensitive and if the requests are delayed, they will fail. To resolve
this issue, see Recommendation - Configure the Root PDC with an Authoritative Time Source
and Avoid Widespread Time Skew
Some of my users cannot authenticate with my directory
Your user accounts must have Kerberos preauthentication enabled. This is the
default setting for new user accounts, but it should not be modified. For more
information about this setting, go to Preauthentication
Maintenance issues
The following are common maintenance issues for AD Connector
-
My directory is stuck in the "Requested" state
-
Seamless domain join for Amazon EC2 instances stopped working
My directory is stuck in the "Requested" state
If you have a directory that has been in the "Requested" state for more than five
minutes, try deleting the directory and recreating it. If this problem persists,
contact AWS Support
Seamless domain join for Amazon EC2 instances stopped working
If seamless domain join for EC2 instances was working and then stopped while the AD Connector was active, the credentials for your AD Connector service account may have expired. Expired credentials can prevent AD Connector from creating computer objects in your Active Directory.
To resolve this issue, update the service account passwords in the following order so that the passwords match:
Update the password for the service account in your Active Directory.
-
Update the password for the service account in your AD Connector in AWS Directory Service. For more information, see Updating your AD Connector service account credentials in AWS Management Console.
Important
Updating the password only in AWS Directory Service does not push the password change to your existing on-premises Active Directory so it is important to do it in the order shown in the previous procedure.
I cannot delete my AD Connector
If your AD Connector switches to an inoperable state, you no longer have access to
your domain controllers. We block the deletion of an AD Connector when there are still
applications linked to it because one of those applications may still be using the
directory. For a list of applications you need to disable in order to delete your
AD Connector, see Deleting your AD Connector. If you still can’t delete your
AD Connector, you can request help through AWS Support