Manually Testing LDAP Functionality to Active Directory with ldapsearch and ldp

If you’re at this page, you have most likely have a problem with secure ldap authentication. The following commands will assist you in troubleshooting exactly why your secure ldap lookups aren’t working. Setting up secure ldap is beyond the scope of this blog post, and this post assumes that you are querying Active Directory and that the following items have been checked and are in proper working order:

  • You have an SSL certificate installed into the correct store on your Active Directory Domain Controller. Depending on your application and Operating System version, you will either have your certificate installed in the local computer store, or within the ADDS Store. For more information, consult Google.
  • Your SSL certificate is marked for “Server Authentication” (OID 1.3.6.1.5.5.7.3.1)
  • Your SSL certificate chain is valid, including all intermediate certificates.
  • Your perimeter firewall is allowing secure ldap (636) traffic to your DC if you are querying from an external source
  • The Windows Firewall on your Active Directory Domain Controller is allowing 636 in the correct profile(s)
  • A basic understanding of distinguished names in Active Directory

Testing from CentOS 7

These steps should also work from a Macintosh – I tested ldapsearch on Yosemite 10.10.2 and it worked fine. YMMV.

Testing from CentOS 7 was quite straight forward. You are required to have the ldapsearch application installed. ldapsearch is part of openldaps-clients, and you can grab it and install it with the following:

yum install openldap-clients

After installing openldap-clients, ldapsearch becomes available, and you are able to test.

Here is an example of testing secure ldap. You obviously need to modify the values to your environment.

ldapsearch -H ldaps://yourdc.yourdomain.org  -x -D "CN=testuser,OU=YourOU,OU=YourOU,DC=domain,DC=com" -b "dc=domain,dc=com" -W -d 7
Example: ldapsearch -H ldaps://dc01.contoso.org -x -D “CN=JoeBob,OU=Managers,OU=AllUsers,DC=contoso,DC=org” -b “dc=contoso,dc=org” -W -d 7

The important thing to note here is the “-d 7” at the end of the command – this is debug level 7, and will provide you with very verbose output as to what the actual problem with your secure ldap lookup is. Consult your manpages for a lot more information about ldapsearch.

A Snippet of the Example Output from my CentOS 7 VM. For demonstration purposes, I purposely misconfigured this VM, removing the dc01_contoso.PEM certificate file from the /cacerts/ location so that it threw the following errors.

TLS: certdb config: configDir=’/etc/openldap/cacerts’ tokenDescription=’ldap(0)’ certPrefix=” keyPrefix=” flags=readOnly

TLS: cannot open certdb ‘/etc/openldap/cacerts’, error -8018:Unknown PKCS #11 error.

TLS: could not read certificate file /etc/openldap/cacerts/dc01_contoso.PEM – error -5950:File not found.

TLS: /etc/openldap/cacerts/dc01_contoso.PEM is not a valid CA certificate file – error -5950:File not found.

TLS: could not initialize moznss using security dir /etc/openldap/cacerts prefix  – error -8018.

TLS: could not perform TLS system initialization.

TLS: error: could not initialize moznss security context – error -5939:No more entries in the directory

TLS: can’t create ssl handle.

As you can see, debug level 7 gives you very verbose output, and will point you in the direction to fix your secure ldap issue(s). If secure ldap is working correctly, you should see a plethora of information as the TLS handshake occurs and as data is queried.

In a semi-related note: There are some rough edges and inconsistencies between various versions of OpenLDAP, as is typical with Open Source projects. For instance, the default values in my ldap.conf in /etc/openldap/ on the version of OpenLDAP that I had installed, pointed to /etc/openldap/cacerts. However, upon installing OpenLDAP, it made the /etc/openldap/certs folder, not cacerts — the difference is minor, but if you aren’t paying attention you will copy your CA cert into the directory thinking it should work, and it won’t, because default values and what is made by default on install is inconsistent.

Testing from Windows

Testing from Windows is also pretty straight forward. You can use the ldp utility for this. LDP is a Lightweight Directory Access Protocol (LDAP) client that allows users to perform operations (such as connect, bind, search, modify, add, delete) against any LDAP-compatible directory.

LDP is installed by default on Server 2008 and above. If you are on an older version of Windows, you can download LDP here: Windows XP Service Pack 2 Support Tools or here: Windows Server 2003 Service Pack 2 32-bit Support Tools

To test LDAP over SSL connections, do the following:

  • Run the LDP utility (typically, click Start > Run > LDP)
  • In the LDP menu, click Connection > Connect
  • Enter the directory server name/IP Address, the port (typically, 636 for secure LDAP), and check the SSL checkbox.

Connect-719601

  • If the connection is successful, you will see a list of output similar to this:

ldp-Output-768467
You can further test, by going to Connection > Bind then choosing Bind With Credentials and enter in valid AD credentials — if it works properly, you will see something similar to the following in the ldp screen:

-----------

53 = ldap_set_option(ld, LDAP_OPT_ENCRYPT, 1)

res = ldap_bind_s(ld, NULL, &NtAuthIdentity, NEGOTIATE (1158)); // v.3

{NtAuthIdentity: User='testUser'; Pwd=<unavailable>; domain = ''}

Authenticated as: 'CONTOSO\testUser'.

-----------

If your connection fails, browse through the output for any error messages. They should get you closer to resolving your issues, as the output will likely be more verbose than a simple failure error.

Testing via OpenSSL

openssl s_client -connect fqdn.to.your.ldap.host.here:636

 

But it still doesn’t work…

If you are configured correctly and things still don’t work, check your perimeter firewall again. Things like deep packet inspection, or a very granular firewall like a Palo Alto, will still block secure protocols and traffic from going over 636 even if you have it open, so be sure to check that secure protocols are allowed through deep packet inspection or whatever other perimeter checks that you have.

Hope this helps.

Leave a Comment

Your email address will not be published. Required fields are marked *