Using Browsers with OpenLDAP cn=config Tree

The new OpenLDAP configuration is an LDAP tree like any other, and can be browsed as such. Using a graphical browser like Apache Directory Studio can simplify configuration (somewhat).

When setting up a new LDAP connection, specify the user as the admin user for the configuration tree – like so:


Also specify the tree root as:


With the appropriate settings, you should then get a list of the configuration tree, where you can view and edit entries. It would behoove you to be very careful about changing things in this tree: if you change the wrong thing, your LDAP server could stop functioning properly.

OpenLDAP with SSL in Ubuntu Lucid Lynx

In researching configuration tasks for OpenLDAP, I found this article about using sudo with OpenLDAP. As I am going to implement SSL with OpenLDAP, problems with sudo and SSL could be fatal, so I decided to investigate further.

It turns out that the problem is embedded in GnuTLS, a GPL-licensed OpenSSL replacement. GnuTLS was used by Debian because of a licensing conflict between OpenSSL and OpenLDAP. A backend library used by GnuTLS (libgcrypt11) causes problems based on the way it is initialized and the way it handles the dropping of privilege (that is, it gets rid of its “root” access). This shows up as suid applications failing when run against LDAP users; Ubuntu bugs 926350 (GnuTLS) and 423252 (sudo) are this exact problem.

GnuTLS is replacing libgcrypt11 with the nettle backend as of 2.11.x, but Ubuntu Lucid Lynx continues to use GnuTLS with the original (flawed) backend. The “fix” espoused by some is to use nscd – but this is acknowledged to be a workaround.

There is a GnuTLS version compiled not against libgcrypt11 but libnettle which should the problem. I did not test this PPA; if you wish to stick with OpenLDAP and GnuTLS this might be the way to go.

However, there is also a version of OpenLDAP compiled against OpenSSL. Add the PPA to your APT configuration and then perform a system update (apt-get update && apt-get upgrade). This will upgrade your OpenLDAP and cause it to stop at least temporarily; thus, make sure you allow for some server downtime.

This version of OpenLDAP works except for a few initial problems that must be overcome. When you first install, it may refuse to run.

First, it seems to add an openldap user and group – and while this is good, it does not completely change appropriate files to give access to the openldap user. There are two locations that need to be fixed:

  • /var/lib/ldap (the location of the LDAP data store)
  • /etc/ssl (the location of the SSL certificates)

Fixing the first is simple:

chown -R openldap:openldap /var/lib/ldap

The second is not as straight-forward; in my case, I added the user openldap to the group ssl-cert which has access into the /etc/ssl directory and subdirectories. Use the vigr command to make this happen: add openldap to the end of the ssl-cert group line (your group id might be different):


Note that if the SSL certificates aren’t set up right, then running the new OpenLDAP will not work – even if LDAPS is not enabled at startup. (There is a fantastic message showing how to make sure your certificates match from You also need to make sure that the certificates are not expired; it is reported that OpenLDAP will also fail to start with expired certificates.

As the final step, change the /etc/default/slapd file to start LDAPS:

SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

Eventually, the best thing to do is to remove LDAP support entirely (and use LDAPS completely):

SLAPD_SERVICES="ldapi:/// ldaps:///"

Tips and Tidbits About LDAP

Setting up and understanding LDAP is not easy. In my opinion, nothing is obfuscated more and unnecessarily so than LDAP. There are a number of tips that can help you to understand LDAP.

LDAP is not authentication. This was the number one problem I had when I started (a while back). The first time user might search for documents on setting up LDAP when in fact they are looking for documents on how to set up UNIX and Linux authentication using LDAP. An LDAP server at its most basic doesn’t understand UNIX uids, doesn’t understand GECOS fields, doesn’t understand UNIX gids, and doesn’t understand Linux shadow files. Support for all of this must be added.

Support for UNIX authentication must be added. You would think that the most common usage for LDAP would come bundled and ready to go with the server; however, often this is not the case. Even if it is the case, you may find that for certain capabilities you are expected to add new LDIF files to support the fields in LDAP.

LDAP is not just another database server. Virtually everything in LDAP has a different name; it is unlike anything you’ve done before. Take heart: X.500 (where LDAP comes from) was worse. You’ll have to slog through a pile of new terms, but after a while it will become easier to understand.

OpenLDAP is not synonymous with LDAP. There are other servers out there. OpenLDAP does come with virtually every Linux platform; there are however, many others – many of which may be easier to use. There is the 389 Directory Server from Red Hat, the ApacheDS (part of the Apache Directory Project) from Apache, and OpenDJ from ForgeRock. OpenDJ itself is a spin-off from OpenDS, originally from Sun.

OpenLDAP is known for making non-backwards-compatible changes. The most recent example is the complete replacement of the configuration system.

OpenLDAP no longer uses slapd.conf. This will cause you no end of problems: there are a lot of people trying to explain how to set up OpenLDAP, and with a single strike (as of version 2.3) OpenLDAP made all of that documentation obsolete and useless. This is incomprehensible, but it is a fact.

Using and administering LDAP requires command line expertise. This is basically true, but like many things, it is not the complete truth. There are many programs designed to make it easy to browse LDAP stores, along with editing capabilities. Some of the more interesting products include Jxplorer, Luma, and the Apache Directory Studio. Of these, the Apache Directory Studio is the most capable, robust, and actively developed – and by far the largest.

Some LDAP entries can be present more than once or have more than one value. If you are comparing LDAP to a database, then this will come as a surprise. One valuable example is UNIX groups: the original UNIX systems only had one group per user; later, secondary groups were added – thus presenting a single user with multiple groups. This is handled in LDAP in a variety of ways, but they all amount to having multiple entries with different values.

Limiting user logins by host is not available in LDAP. This capability is most likely to be done by using the client host. There are a number of ways to do it, but all require LDAP client configuration, and all are limited in their application. Without client configuration, all LDAP users will have authenticated access to the host.

Be prepared to do a lot of web searches for documentation and solutions. The best places to go for searches are: Google (of course) and Ubuntu Documentation.

There are also very good articles and documents on using LDAP for authentication. There is an article about OpenLDAP authentication on FreeBSD (FreeBSD articles tend to be very well-written). Similarly, Ubuntu documentation is well-written as well; each of the Ubuntu versions has a section in the documentation on using and configuring OpenLDAP for authentication. Ubuntu 11.04 documentation has a good article on OpenLDAP for example.

Ubuntu documentation also includes a lot of well-written (and current) articles. For example, there are articles on OpenLDAP Server (a general article), LDAP Client Authentication, Samba and LDAP (from the 10.04 Server documentation), and Securing OpenLDAP Conenctions. If you plan to use 389 Server instead, there are even a couple of articles on using it with Ubuntu: Fedora Directory Server (the original name of 389 Server) and Fedora Directory Server Client Howto.

A nice overview of LDAP comes from Brian Jones at O’Reilly: specifically, his 2006 articles on Demystifying LDAP and Demystifying LDAP Data. Linux Journal also has myriad different articles on LDAP (not to mention an OpenLDAP theme for the December 2002 issue). Linux Journal also has an article from 2007 on Fedora Directory Server (now 389 Server).

Lastly, an excellent resource is the “book” LDAP for Rocket Scientists from You simply must go and read portions of this book. One very apt quote from the introduction to the book which sums up the state of LDAP documentation generally:

The bad news is that [in our humble opinion] never has so much been written so incomprehensibly about a single topic with the possible exceptions of BIND and … and …

(It should be noted that the other book at Zytrax is about DNS. Is it any surprise?)


Yet another trick to LDAP:

The cn= attribute is not solely a leaf attribute. This can be seen in OpenLDAP’s cn=config tree with OpenLDAP configuration. For example, a typical admin user can be designated like so:


However, when you use OpenLDAP’s configuration, the designation for the admin user is this:


When you look into the configuration tree, there are more cn= entries – like this:


Converting LDAP-UX to use SSL (HP-UX)

The utility used to create and manipulate the keys is certutil, found as /opt/ldapux/contrib/bin/certutil. The certutil utiltiy is actually a tool created by the Mozilla project, and it has a detailed explaination available. HP only supports the use of Netscape Directory Server or Microsoft Windows Active Directory. Mainly, this means that the docs are there and that they will help you if need be; it doesn’t mean it doesn’t work. The relevant documentation (at least for my versions of HP-UX 11i) is:

It appears, however, that there is a more recent version of LDAP-UX:

A good description of the schema LDAP-UX wants was given by Simon Elder in this message. There is a copy of the HP LDAP-UX Schema available; it appears to be some sort of standard POSIX schema.

Here, we assume that LDAP-UX is already configured using non-SSL connections, that the /etc/pam.conf has been configured, and that the name service switch file /etc/nsswitch.conf has been configured.

The best time to set up SSL and TLS is before you run LDAP; however, it is possible to do it afterwards. First, you need the certificate authority (CA) certificate from the server (just one). Make sure your certificate database is cleared first:

rm -f /etc/opt/ldapux/key3.db
rm -f /etc/opt/ldapux/cert[78].db

Make sure that you are deleting the right files. Once these are deleted, change directories to /opt/ldapux and run this command against your server’s key ( in this example) in order to properly populate the database:

/opt/ldapux/contrib/bin/certutil -N -d /etc/opt/ldapux
/opt/ldapux/contrib/bin/certutil -A -n my-ca-cert -t "C,," -d /etc/opt/ldapux -a -i

This will populate the database that the LDAP-UX client uses. Then run the set up to reconfigure:

cd /opt/ldapux/config

When the setup program asks if you want to re-enter the data (server, etc.) answer Yes. The program will then fully configure the client to use SSL, and will restart the client when necessary.


HP introduced LDAP support for password authentication in OpenVMS 8.3, which is fantastic. However, when looking for documentation about how it is configured and implemented, one comes up short – there is a dearth of information to be found.

Thanks to Hoffman Labs, this is no longer the case: their article on LDAP exposes the configuration details of ACME LDAP on OpenVMS quite nicely. They have the technical details as well as the README from the ACME LDAP add-on posted there; I’ll try to summarize installation and configuration concisely here.

ACME is the Authentication and Credential Management Extensions, which appear to be an architecture for creating plugins for authentication and so forth, like PAM (the Pluggable Authentication Modules) for UNIX. ACME appears to have been introduced in OpenVMS 8.3.

ACME LDAP is perhaps the most visible of the first of these extensions. This, perhaps, explains its dearth of publically accessible documentation. Currently, ACME LDAP has these features:

  • Support for TLS/SSL
  • Support for StartTLS
  • Support for Active Directory
  • Support for Netscape “expired password” mechanisms

ACME LDAP also has these restrictions:

  • Still requires local username; password only is checked against LDAP
  • Characters in usernames and passwords are restricted to ISO 8859-1 eight bit characters; UTF-8 support not present.
  • Characters in passwords used in Active Directory are restricted to ISO 8859-1 7-bit ASCII characters.

Each user account to be authenticated with LDAP must exist on the system (in the SYSUAF file) and must have the EXTAUTH flag set.

To use ACME LDAP, you must configure the SYS$STARTUP:LDAPACME$CONFIG-STD.INI file. The file can be started by copying the LDAPACME$CONFIG-STD.INI_TEMPLATE file:


An example LDAPACME$CONFIG-STD.INI may look like this:

server =
port = 636
port_security = ssl
bind_dn = uid=acme-admin,ou=people,dc=acme,dc=mycompany,dc=com
bind_password = swordfish
base_dn = ou=people,dc=acme,dc=mycompany,dc=com
login_attribute = uid
scope = sub
ca_file = sys$manager:acme_ca.crt

This example is suitable for the Red Hat Directory Server (also known as the Fedora Directory Server).

The LDAP Persona extension must also be loaded using the MCR utility:

SYSMAN> exit


Following the load of the LDAP Persona extension, the system must be rebooted:


If there are no errors during startup, then the LDAP Persona extension was loaded correctly.

Change the SYS$MANAGER:ACME$START.COM file to contain a pointer to the initialization file and to start the LDAP extension automatically.

Add the following definition line to ACME$START.COM:


To start the server at ACME load time, add this line:


Finally, configure the system to start the ACME subsystem by adding this line to SYS$MANAGER:SYSTART_VMS.COM:


The description from Hoffman Labs is a perfect example of how community support works!

Update: A nice description (from the VMS Help subsystem) of the ACME server can be found here; it describes SET SERVER ACME_SERVER.