Performing ldapsearch over TLS/SSL against Active Directory

Hello everyody.

I recently configured a Windows Server 2003 R2 with Active Directory, installed the Certificate service and create both a local root CA and a certificate for the server itself.

After exporting the root CA certificate, on OpenSuSE 11 the following command seems to work fine (just to test the TLS/SSL connection is fine):

openssl s_client -connect ip_server:636 -CAfile adroot.cer

This command completes with the following:

New, TLSv1/SSLv3, Cipher is RC4-MD5
Server public key is 1024 bit
Compression: NONE
Expansion: NONE
Protocol : TLSv1
Cipher : RC4-MD5
Session-ID: D80D000023E7107F29616FECFF4B5350B859D93D24F6D426BF201E618AEBCBDF
Master-Key: 19A14767C533E5730CAE5A37D461AF140EF279F4167C708D3CE57F6F8118D966928CA3442EBC09EC36F87DE336B563A9
Key-Arg : None
Start Time: 1229003030
Timeout : 300 (sec)
Verify return code: 0 (ok)

Now I’d like to perform ldapsearch over the TLS/SSL connection but I can’t figure out the syntax to use.

A simple query (-x) does work:

ldapsearch -x -D “cn=Administrator,cn=Users,dc=zen,dc=strhold,dc=it”
-w password -h <host> -b “cn=Users,dc=zen,dc=strhold,dc=it”

How can I enable a ldapsearch over TLS/SSL?

I tried by configuring /etc/openssl/ldap.conf as follows:

URI ldaps://
BASE "cn=Users,dc=zen,dc=strhold,dc=it
TLS_CACERT /tmp/adir/adroot_b64.cer

Also, I modified the ldapsearch to read:

ldapsearch -d 1 -H ldaps://<host>
-D “cn=Administrator,cn=Users,dc=zen,dc=strhold,dc=it”
-b “cn=Users,dc=zen,dc=strhold,dc=it”
-Z ‘sAMAccountName=myname’

but I got (last lines):

ldap_sasl_interactive_bind_s: server supports: GSSAPI GSS-SPNEGO EXTERNAL DIGEST-MD5
SASL/EXTERNAL authentication started
ldap_sasl_interactive_bind_s: Unknown authentication method (-6)

Again, I added the “-Y DIGEST-MD5”, got prompted for a password and got:

ldap_sasl_interactive_bind_s: Invalid credentials (49)

OK, TLS/SSL is not my cup of tea but I’d like to know if there’s a method I can query AD over LDAP+TLS/SSL with.


Well, after much searching and testing (and LEARNING) I was able to accomplish that task.

At the benefit of future posters/seekers, here’s what I found:

  1. make ABSOLUTELY sure the DNS you’re using is able to perform a direct and reverse lookup of the hosts involved in the scenario

  2. you can perform LDAP queries over the SSL channel by connecting to the AD server at port 636; first, grab (export in Base64) the AD Root certificate and store it on the Linux box (eg, under /tmp/adir/adroot_b64.cer).

Then, configure the /etc/openldap/ldap.conf file as follows:

PORT 636
TLS_CACERT /tmp/adir/adroot_b64.cer

Last, issue the query:

ldapsearch -x -D “”
-b “cn=Users,dc=my,dc=domain,dc=it”
-H ldaps://
-W sAMAccountName=myuser

Please notice that:

. binding is still required (-D and -W)
. -H ldaps://… (connects to port 636)

  1. another method is to connect to port 389 and issue the Start_TLS command; in fact AD is able to use the same “unencrypted” port (389) to start a TLS tunnel and thus encrypt the pieces of info being exchanged.

The ldap.conf file does not change but the ldapsearch syntax does:

ldapsearch -x -D “”
-b “cn=Users,dc=my,dc=domain,dc=it”
-H ldap://
-Z -W sAMAccountName=myuser

Please notice the use of the “-Z” flag and the connection to ldap:// (port 389)

  1. You can finally use the external SASL authentication which relies (among other things) over a kerberos configuration; thus making, once you get a valid ticked from the KDC, you’re not required to authenticate to the AD server over the command line.

Make sure clocks on both servers are in synch using NTP or whatever you have.

Make sure you have the following packages installed:


Also, check for the following ones:


Create the /etc/krb5.conf file as follows ( is the IP of the AD server):

default_realm = MY.DOMAIN.IT
clockskew = 300

kdc =
default_domain =
admin_server =

kdc = FILE:/var/log/krb5/krb5kdc.log
admin_server = FILE:/var/log/krb5/kadmind.log

pam = {
ticket_lifetime = 1d
renew_lifetime = 1d
forwardable = true
proxiable = false
retain_after_close = false
minimum_uid = 1
try_first_pass = true

Get you kerberos ticket using the

kinit Administrator


kinit <valid_ad_user>

Type your password and verify your ticket using “klist”:

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@MY.DOMAIN.IT

Valid starting Expires Service principal
12/15/08 16:00:12 12/16/08 02:00:14 krbtgt/MY.DOMAIN.IT@MY.DOMAIN.IT
renew until 12/16/08 16:00:12

Kerberos 4 ticket cache: /tmp/tkt0
klist: You have no tickets cached

Last, perform your LDAP search using this syntax:

ldapsearch -Hldap:// -b “” -s base -Omaxssf=0

As you can see, we’re still connecting to LDAP (389); the flag “-Omaxssf=0” disables the SASL security layers (and it seems it’s required when you perform LDAP queries against AD).

If you want to have BOTH SASL + TLS authentication:

ldapsearch -Hldap:// -b “” -s base -Omaxssf=0 -ZZ

Please notice the use of “-ZZ”.

Well, hope this helps!



thanks for posting that!