# LDAP (Active Directory) Troubleshooting for WSM 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. ## Verify domain connectivity with nltest `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. ``` nltest /dsgetdc: nltest /sc_query: ``` 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.
## Verify domain connectivity with Test-Connection If multiple domain controllers exist, verifying connectivity to each ensures proper reachability and helps determine whether LDAP or LDAPS is being used. ``` Test-NetConnection -ComputerName -Port 389 # For LDAP Test-NetConnection -ComputerName -Port 636 # For LDAPS ``` 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. ## Install AD Management Tools 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: ``` Add-WindowsFeature RSAT-AD-Tools ``` For **Windows 10 or Windows 11**, the AD Tools installation commands differ slightly. Use the following PowerShell commands. List all the tools available: ``` Get-WindowsCapability -Name RSAT* -Online | Select-Object -Property Name, DisplayName, State ``` Install the AD Tools: ``` Add-WindowsCapability -Online -Name Rsat.ActiveDirectory.DS-LDS.Tools~~~~0.0.1.0 ``` Confirm that it is installed: ``` Get-WindowsCapability -Name RSAT* -Online | Select-Object -Property DisplayName, State ```
## **Validate LDAP Search and Authentication** 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: ``` Get-ADUser -Filter * -SearchBase "DC=yourdomain,DC=com" ``` 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. ``` Get-ADUser -Filter * -SearchBase "DC=yourdomain,DC=com" -Property DistinguishedName | Select-Object Name, DistinguishedName ``` ## **Check Service Account Permissions** 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: ``` Get-ADUser -Identity "WSMServiceAccount" -Properties * | Select-Object Name, Enabled, DistinguishedName ```
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. ## **Test Kerberos Authentication** **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: ``` klist ``` This will display the **Kerberos tickets** for the current session, confirming successful authentication. To clear and renew tickets, use: ``` klist purge ```
## **Verify LDAP integrity with ldp** **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: 1. Open **Run** (`Win + R`) and type `ldp.exe`. 2. Click **Connection > Connect** and enter the domain controller name or IP. 3. 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**. 1. Navigate to **Connection > Bind** and enter the **service account credentials**. 2. **Ensure that "Encrypt traffic after bind" is NOT checked**, as this can interfere with authentication if LDAPS is not configured. 3. 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: 1. **Go to** `Browse > Search`. 2. Click **Base DN** and enter the expected OU path (e.g., `OU=Users,DC=yourdomain,DC=com`). 3. Use a **filter query** such as: ``` (objectClass=user) ```
If the user is **not found** during the LDAP search, it may indicate one of the following issues: 1. **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: ``` dsquery user -name ``` 2. **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)**. 3. **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. 4. **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: ``` Get-Acl "AD:\OU=Users,DC=yourdomain,DC=com" ``` By addressing these potential issues, you can ensure successful LDAP searches and proper user discovery in WSM. 🚀