Apache Directory Studio and Client Certificate Authentication

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:

Explanation:
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:

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

Fixes for the OpenLDAP example config and deployment tips

If you want to setup an LDAP server with OpenLDAP and are new to LDAP then you may have gone through the Admin Guide and bumped into some mysterious errors trying to setup the example configs. Here are some notes how to make this configuration work followed by some tips at the end about deploying an OpenLDAP based directory.

The example config in the Admin Guide is located in chapter 5.3 when viewing the guide as a single HTML file on the OpenLDAP website (link above) or in the PDF version of the Admin Guide.

The relevant part of the example config in chapter 5.3 in the Admin Guide (page 38 in the PDF version) is:

When trying to add this config to your OpenLDAP server with slapadd then you will see the following errors:

5117a0af str2entry: invalid value for attributeType olcSuffix #0 (syntax
1.3.6.1.4.1.1466.115.121.1.12)

5117a1ea str2entry: invalid value for attributeType olcRootDN #0 (syntax
1.3.6.1.4.1.1466.115.121.1.12)

/etc/openldap34/slapd.d: line 1: duplicate index definition for attr “uid”

The solution:
1) remove the quotes from olcSuffix (line 34)

should become

2) remove the quotes from olcRootDN (line 36)

should become

3) remove the double uid entry

should be removed in it’s entirety so remove that line

Working example configuration

Note 1: this example config follows the files and paths on RHEL 6.3 or CentOS 6.3. If you use another distribution then you will need to figure out what those files and paths are for your distro.

Note 2: the section # BDB definition for example.com in the Admin Guide also has the problems as described above. The solution is exactly the same: remove the quotes from olcSuffix and olcRootDN and remove the olcDbIndex: uid pres,eq line.

Note 3: in the example config below the lines starting with “by…” are preceded by two (2) spaces! If you do not use 2 spaces then the config file is invalid and you will get errors. To illustrate, each dot is a space:

Extended example configuration

Here is an extended version of the example config above with the loading of modules and monitoring added.

Note 1: this extended configuration example assumes that your OpenLDAP server has been custom built with dynamic modules. So this configuration does not apply to the default openldap-servers-2.4.23 RPM that comes with RHEL6/CentOS6.

Some tips when deploying an OpenLDAP based directory

1) use the latest OpenLDAP release

The OpenLDAP 2.4.23 release that comes with RHEL6/CentOS6 is ancient and has bugs. It also has several patches which introduce GnuTLS support. From reading the various discussions about those patches the OpenLDAP developers do not seem to look favourably upon those patches. Currently it does not seem very likely that those GnuTLS patches will be applied upstream by the OpenLDAP developers. So Red Hat is on it’s own when it comes to those patches. It is recommended to use at least the latest stable release, currently 2.4.33.

2) use the MDB database

It’s faster than the BDB or HDB database (2 to 2.5x with olcDbEnvFlags: writemap and olcDbEnvFlags: nometasync) and does not have the problems which BDB and HDB suffer from. More information about MDB can be found at the OpenLDAP MDB site. The paper and LinuxCon slides are an interesting read.

If you want to use the MDB database then you will probably want to use the OpenLDAP RE24 branch from git upstream. AFAIK there is no readily available RPM but you can use either the Fedora 18/19 OpenLDAP SRPM, strip it and adjust it to build the RE24 branch or get the 2.4.33 EL6 SRPMs from the LDAP ToolBox project and adjust it to build the RE24 branch. <sales pitch>If you need a consultant to create those RPMs for RHEL/CentOS, I can help</salespitch>

3) consider delta-syncrepl

If you need replication then (if possible) consider delta-syncrepl for the simple reason that it has been recommended on the OpenLDAP mailinglist by core members over and over again. More information about delta-syncrepl can be found here in the Admin Guide.

Update 1 on March 24, 2013 – per Howard Chu’s comment the Extended Example Configuration has been corrected by putting the Module config before the Schema config. Thanks Howard!

Update 2 on March 24, 2013 – please read Howard Chu’s comment on tip #1 ‘use the latest OpenLDAP release. Howard is the lead developer of the OpenLDAP project so his view on GnuTLS/MozNSS is both relevant as well as leading.