LDAP - ldapsearch and SSL - what fun

Having set up a new Microsoft Active Directory 2012 domain controller, I was testing the LDAP connectivity using the ldapsearch command before adding WebSphere Application Server (WAS) into the mix.

I ran this command: -

ldapsearch -h windows2012.uk.ibm.com -p 636 -b dc=uk,dc=ibm,dc=com -D cn=wasbind,dc=uk,dc=ibm,dc=com -w Ch1mn3y5! cn=wasbind

which resulted in this helpful response: -

ldap_result: Can't contact LDAP server (-1)

In order to double-check the connectivity, I ran a few basic tests: -

telnet windows2012.uk.ibm.com 636

Trying 192.168.153.130...
Connected to windows2012.uk.ibm.com.
Escape character is '^]'.

openssl s_client -connect windows2012.uk.ibm.com:636 </dev/null

...
Protocol  : TLSv1.2
Cipher    : ECDHE-RSA-AES256-SHA384
...

Given that I'm using SSL/TLS, I tested ldapsearch using a non-SSL connection just to check ….

ldapsearch -h windows2012.uk.ibm.com -p 389 -b dc=uk,dc=ibm,dc=com -D CN=wasbind,CN=Users,DC=uk,DC=ibm,DC=com -w Ch1mn3y5! cn=wasbind

…

# wasbind, Users, uk.ibm.com
dn: CN=wasbind,CN=Users,DC=uk,DC=ibm,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: wasbind
givenName: wasbind
…

so the problem is SSL/TLS ….

I'd also noted that I was using the old syntax for ldapsearch in the way that I was specifying the hostname and port.

Both the -h and -p switches have been deprecated in favour of the -H switch: -

man ldapsearch

…

       -H ldapuri
              Specify URI(s) referring to the ldap server(s); a list of URI, separated by whitespace or commas is expected; only the protocol/host/port fields are allowed.  As an  exception,
              if  no  host/port  is  specified, but a DN is, the DN is used to look up the corresponding host(s) using the DNS SRV records, according to RFC 2782.  The DN must be a non-empty
              sequence of AVAs whose attribute type is "dc" (domain component), and must be escaped according to RFC 2396.

       -h ldaphost
              Specify an alternate host on which the ldap server is running.  Deprecated in favor of -H.

       -p ldapport
              Specify an alternate TCP port where the ldap server is listening.  Deprecated in favor of -H.
...

So I tried the new syntax: -

ldapsearch -H ldaps://windows2012.uk.ibm.com:636 -b dc=uk,dc=ibm,dc=com -D cn=wasbind,cn=users,dc=uk,dc=ibm,dc=com -w Ch1mn3y5! cn=wasbind

which returned the same thing: -

…

ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
…

so I added a bit of the old debug: -

ldapsearch -Z -H ldaps://windows2012.uk.ibm.com:636 -b dc=uk,dc=ibm,dc=com -D cn=wasbind,cn=users,dc=uk,dc=ibm,dc=com -w Ch1mn3y5! cn=wasbind

which was more insightful: -

…

ldap_start_tls: Can't contact LDAP server (-1)
additional info: SSLHandshake() failed: misc. bad certificate (-9825)
ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
…

This led me here: -

How to make ldapsearch working on SLES over tls using certificate?

I tried this: -

export LDAPTLS_REQCERT=never

and then: -

ldapsearch -Z -H ldaps://windows2012.uk.ibm.com:636 -b dc=uk,dc=ibm,dc=com -D cn=wasbind,cn=users,dc=uk,dc=ibm,dc=com -w Ch1mn3y5! cn=wasbind

…

# wasbind, Users, uk.ibm.com
dn: CN=wasbind,CN=Users,DC=uk,DC=ibm,DC=com
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user
cn: wasbind
givenName: wasbind
distinguishedName: CN=wasbind,CN=Users,DC=uk,DC=ibm,DC=com
…

Hurrah!