One of the security options that OpenLDAP offers is to not accept TLS connections below a certain grade. The OpenLDAP cn=config option is called ‘olcLocalSSF’. If you set it to 256 then any LDAP client will need to connect with a 256 bit ciphersuite or else the TLS connection will fail.
After an update of OpenLDAP to 2.4.40 on an up-to-date CentOS 6.5 box (which also had a recent OpenSSL update) the TLS connection between Postfix and OpenLDAP stopped working. The problem as reported by the client (a Postfix ldap lookup) was just:
dict_ldap_lookup: Search error 13: Confidentiality required
Not very helpful so after increasing the olcLogLevel in OpenLDAP to 256 the following started to show up in the log:
Aug 14 02:41:51 r83c24 slapd: conn=1123 fd=22 TLS established tls_ssf=128 ssf=128
Aug 14 02:41:51 r83c24 slapd: conn=1123 op=1 RESULT tag=97 err=13 text=stronger confidentiality required
Notice the “tls_ssf=128” and text “stronger confidentiality required”? It tells you that the client connects with a 128 bit ciphersuite which is clearly not enough as 256 bit is required. So the TLS connection fails.
The solution is to make the client use a 256 bit ciphersuite.
In ldap.conf or ldaprc add:
And if you use Postfix ldap_table lookups then add in your /etc/postfix/<ldap-table>.cf config file:
tls_cipher_suite = AES256
Recently the OpenLDAP project released version 2.4.34. It contains tons of bug fixes and improvements like the lightening fast LMDB backend (so you don’t need Oracle’s BerkeleyDB anymore).
One of the features of OpenLDAP is the Refint overlay: “The Referential Integrity overlay can be used with a backend database such as slapd-mdb(5) to maintain the cohesiveness of a schema which utilizes reference attributes”.
Basically it means that if you for example delete or rename a user and that user is referenced elsewhere, the Refint overlay makes sure that the reference is deleted or renamed too.
One thing to realize is that the Refint overlay only works on DNs. So you must use DNs as references or else it won’t work.
Apache Directory Studio is a very nice LDAP tool that works great with OpenLDAP. Unfortunately it lacks a critical feature: support for X.509 Client Certificate Authentication. There is a feature request from 2011 but it has not even been assigned yet.
Does this mean that you can not use Apache Directory Studio with a Directory server that enforces TLS/SSLv3 & Client Certificate Authentication? Nope but luckily there is a solution called socat.
With socat you can forward a local port via SSH to a socket on the remote server on which your LDAP server is listening. Make sure that you have a working SSH connection to your LDAP server using public key authentication and that your LDAP server is configured to (also) listen on a socket. You also need to install socat on both the client and on the LDAP server. A simple
yum install socat should do it.
The command to run as a regular user is:
socat "TCP-LISTEN:10389,bind=127.0.0.1,fork" EXEC:'ssh user@ldap-server socat STDIO UNIX-CONNECT\:/var/run/ldapi'
socat listens on TCP port 10389 on 127.0.0.1. When it receives a connection on TCP port 10389 on IP address 127.0.0.1 it sets up an SSH link to ‘ldap-server’ as ‘user’ using public key authentication and forwards the incoming connection on the client to the socket at /var/run/ldapi which is the socket location configured on your LDAP server.
To make sure that the socat relay is available when you use Apache Directory Studio you can create a simple script to start socat first and then start Apache Directory Studio:
socat "TCP-LISTEN:10389,bind=127.0.0.1,fork" EXEC:'ssh user@ldap-server socat STDIO UNIX-CONNECT\:/var/run/ldapi' &
pkill -9 socat
Don’t forget to change the ssh user & ldap-server and the location of the Apache Directory Studio binary.
Now you should be able to use Apache Directory Studio to access your LDAP server via a secure SSH link. As usual do take a few security precautions:
1) do *not* save the Bind password in Apache Directory Studio
2) only make socat listen on 127.0.0.1 so the link can not be accessed by other hosts on the network or even from the Internet
3) if you want to allow other hosts on the network to use the socat relay then make sure you also use the ‘range‘ option to limit access