Active Directory is necessary for Amazon WorkSpaces to manage user authentication, apply security policies, and enable seamless access to corporate resources within a centralized directory.
Last updated
If you're experiencing issues with LDAP (Active Directory) integration in WorkSpaces Manager (WSM), this troubleshooting guide will help you diagnose and resolve common authentication, connectivity, and configuration errors. Follow the steps below to ensure seamless directory synchronization and user access.
nltest is a command-line tool used to diagnose domain trust relationships, domain controller discovery, and network logon issues in Active Directory. We will verify the domain trust and connection from our WorkSpaces Manager appliance.
Running the first command retrieves key information about the Active Directory domain by querying a Domain Controller.
The second command verifies the authentication service status.
If multiple domain controllers exist, verifying connectivity to each ensures proper reachability and helps determine whether LDAP or LDAPS is being used.
This command will indicate whether the connection was successful or not.
Keep in mind that one of the LDAP protocols may not be enabled, so an error in one does not necessarily indicate a connectivity issue.
In our example, both LDAP and LDAPS are enabled.
Active Directory (AD) Management Tools, such as RSAT-AD-Tools, provide administrators with the necessary utilities to manage users, groups, and domain services. These tools include Active Directory Users and Computers (ADUC), ldp.exe, and PowerShell cmdlets for AD administration.
We need to install the AD Tools on Windows Server using PowerShell with the following command:
For Windows 10 or Windows 11, the AD Tools installation commands differ slightly. Use the following PowerShell commands.
List all the tools available:
Install the AD Tools:
Confirm that it is installed:
Validating LDAP search and authentication helps ensure that users are located in the correct Organizational Unit (OU) within Active Directory. By running LDAP queries, administrators can identify the default OU where users are stored.
To query LDAP objects using PowerShell, we can use the command:
This command will list users along with their DistinguishedName, which reveals their exact path in Active Directory:
To make a list easier to handle, we can add the following to the previous command. The DistinguishedName (DN) indicates the full LDAP path of each user, helping administrators confirm their correct placement within the directory structure.
To ensure WorkSpaces Manager (WSM) functions correctly, the service account used for LDAP authentication must have the necessary permissions in Active Directory. Verify that the account has read and bind permissions to query user objects and organizational units (OUs). You can check this using Active Directory Users and Computers (ADUC) or PowerShell:
Here are some additional checks to ensure WorkSpaces Manager (WSM) Service Account can successfully connect to Active Directory (AD):
Ensure the WSM service account has read and bind permissions to query users and OUs in Active Directory.
Verify delegation settings to allow LDAP queries.
Check that the service account is enabled, not locked out, and has the correct group memberships.
Ensure password policies and expiration settings do not interfere with authentication.
Ensure the correct LDAP URL, credentials, and search base are set in WSM.
Check AWS Directory Service logs, Active Directory logs or Windows Event Viewer (Security & Directory Services logs) for failed authentication attempts.
Kerberos is a secure authentication protocol that uses ticket-based authentication to verify user identities within Active Directory. To test authentication, use the following klist command on PowerShell:
This will display the Kerberos tickets for the current session, confirming successful authentication. To clear and renew tickets, use:
LDP.exe is a graphical LDAP client tool provided by Microsoft that allows administrators to connect to, browse, and query Active Directory (AD) and other LDAP directories. It is commonly used to verify LDAP connectivity, test authentication, and troubleshoot directory issues. Key Features of LDP.exe:
Connects to an LDAP server (Domain Controller) over LDAP (port 389) or LDAPS (port 636).
Allows binding to AD using different authentication methods.
Enables browsing and querying Active Directory objects and attributes.
Assists in troubleshooting LDAP authentication and configuration issues.
Open ldp.exe to test LDAP binding and browsing:
Open Run (Win + R) and type ldp.exe.
Click Connection > Connect and enter the domain controller name or IP.
Use the port to connect, like LDAP 389. Click OK
It will show if we have successfully connected or not:
Once a connection is established, the next step is to bind to LDAP using the WSM service account.
Navigate to Connection > Bind and enter the service account credentials.
Ensure that "Encrypt traffic after bind" is NOT checked, as this can interfere with authentication if LDAPS is not configured.
Click OK and verify that the bind is successful without errors.
This confirms that the service account has the correct permissions and can authenticate against LDAP.
Once authenticated in LDP.exe, you can test the Default OU by following these steps:
Go to Browse > Search.
Click Base DN and enter the expected OU path (e.g., OU=Users,DC=yourdomain,DC=com).
Use a filter query such as:
If the user is not found during the LDAP search, it may indicate one of the following issues:
Invalid Default OU (Base DN)
The specified Base DN may be incorrect or misspelled.
Verify the correct DN by checking with Active Directory Users and Computers (ADUC) or running:
Default OU (Base DN) Set at the Wrong Level
The Base DN might be too high or too restrictive, preventing the search from reaching the intended objects.
Ensure that the Base DN includes the correct organizational unit (OU).
Search Timeout
If the directory contains many objects, the query might exceed the time limit.
Increase the timeout settings or refine the search filter to return fewer results.
Insufficient Permissions on Sub-Trees
The service account may lack read permissions on all objects or sub-OUs under the Default OU.
Verify that the account has read and bind permissions at the appropriate level.
Use PowerShell to check permissions:
By addressing these potential issues, you can ensure successful LDAP searches and proper user discovery in WSM. 🚀
