In this article we cover how to troubleshoot bind issues when connecting to Active Directory using LDAPS. Typically when a LDAPS connection fails, very little information is provided on the reason for the failure. We will look at using NetTools to help troubleshoot the bind process and identify the reason for the LDAPS bind failure.
There are a few troubleshooting options available, including bypassing the standard certificate revocation process, display the certificate chain with the details of the revocation process and finally displaying the certificate that is installed on the servers used for the connection.
We will use the LDAP Search option in NetTools to test the LDAPS connection. For details on the SSL option see here.
Check a Certificate is Installed
First, we want to confirm that there is a certificate installed on the domain controller and its being used for the LDAPS. These tests can be performed remotely or on the domain controller being tested.
In the server field enter the FQDN of the domain controller, and then select the SSL Bind option, port 636 will be appended to the end of the server name, you will then need to uncheck the Verify Certs and click Go.
If the connection works and there are no bind errors are returned, then a certificate is installed on the domain controller and Active Directory is using it for LDAPS.
If you do receive a connection failure error:
Here are a few checks to determine why the connection failed, or the certificate is not being used.
-
-
- Check name resolution, and the FQDN can be resolved; see DsGetDCName
- Use the DC Resolution Port Scan option to confirm the port is not blocked
- On the domain controller, check the Directory Services event log for event id 1220, Source: ActiveDirectory_DomainService, which means that AD was unable to find a suitable certificate to use
- To confirm that a certificate is available, open MMC on the domain controller, add the Certificates snap-in, select Service Account, and select Active Directory Domain Services. Check under the NTDS\Personal, Certificates and confirm that a certificate is listed
- If the certificate exists:
-
-
- Check the certificate has the private key
- Confirm that the Enhanced Key Usage includes Server Authentication (1.3.6.1.5.5.7.3.1)
- Open the certificate and confirm on the Certification Path tab that the certificate is trusted
-
-
- If no certificate is listed, check your certificate delivery mechanism or manually install a suitable certificate
- Try disabling the local firewall in case it's blocking the LDAPS connection on port 636
- Check for Event ID 36874, source schannel on server, "An SSL connection request was received from a remote client application, but none of the cipher suites supported by the client are supported by the server. The SSL connection request has failed." Check that matching ciphers are available - https://learn.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings?tabs=diffie-hellman
-
Verify the Certificate
If the first test worked, then we now repeat the test but with the Verify Certs option selected; this time, the standard Windows certificate revocation process will check the certificate; if this fails, then the connection will also fail. Select Verify Certs and click Go.
If you receive the following error, Error: ldap_sslinit failed with error: Error: (0x51) Cannot contact the LDAP server, then the Windows revocation process has identified an issue with the certificate and this has caused the connection to fail.
Common Certificate Issues
To help identify what has caused the issue with the certificate, if we select the select the Display Results option, which will display the results of certificate revocation process.
Here are a couple of common examples of the errors that can occur. In these examples the test domain controller has a self-signed certificate and means only one certificate is shown in the certificate chain in the examples. If your domain controller has a certificate that has been issued by a root CA or an intermediate CA, your certificate chain will have multiple certificates, in this case each of these would be display and tested. At the end of the certificate chain output if an issue has been found, an ERR: message will be displayed.
FQDN of the server doesn’t match the certificate
In this example the server name that has been entered does not match the subject or SAN, in the output the subject and SAN are displayed and an ERR message is returned stating that Certificate name does not match the host name
Multiple Certificate Errors
In this example the certificate chain has three errors: 1- the certificate has expired, 2 – the certificate is not trusted, 3 – the entered server name does not match the subject or SAN in the certificate
This is output for a certificate that has passed the certificate revocation process
Display the Certificate
We also have the option to display the certificate in the normal Certificate dialog, by selecting the Display Cert option, the certificate will be displayed, and we can look at the additional properties of the certificate. NetTools will pause until the certificate dialog is closed.
In the dialog you can also confirm that the certificate is trusted by the local machine by viewing the Certification Path tab.