A commenter asked how to enable secure LDAP with this configuration, so what follows is a quick and dirty guide which explains how I got this working using SSL on my setup. This is only intended for testing purposes.
A couple of changes should be noted however: First, I am now using OpenDJ 2.4.2 (as opposed to 2.4.1), and second I am running OpenDJ on Ubuntu 10.04 x86 as well in this example (i.e. same OS for server and client).
1) Export the OpenDJ server certificate in PEM encoded file format
During setup of our test OpenDJ server, we elected to generate a self-signed certificate for secure LDAP connectivity. We need to export this certificate in a format that ultimately will be installed in our Ubuntu client, such that it can trust the OpenDJ server for secure authentication.
We use the Java keytool utility to do this. More on keytool may be found here: http://download.oracle.com/javase/6/docs/technotes/tools/solaris/keytool.html
In the case of my sample OpenDJ server, the OpenDJ Java keystore file (which contains the certificate) is found at /opt/OpenDJ/config/keystore
We can then use the keytool command to export the self-signed certificate in the keystore as a PEM encoded certificate file. In my example there is no password for the keystore, so when promtped one can just press Enter without providing a password. The alias refers to the particular certificate as referenced in the keystore file, which for a self-signed certificate in a default OpenDJ installation is named server-cert. Finally we are exporting the certificate to the Desktop as opendjserver.pem:
$ keytool -keystore /opt/OpenDJ/config/keystore -export -alias server-cert -rfc -file ~/Desktop/opendjserver.pem Enter keystore password: ***************** WARNING WARNING WARNING ***************** * The integrity of the information stored in your keystore * * has NOT been verified! In order to verify its integrity, * * you must provide your keystore password. * ***************** WARNING WARNING WARNING ***************** Certificate stored in file </home/dave/Desktop/opendjserver.pem>
If you like, you can view the contents of a certificate by also using the keytool command. To view the certificate generated in the above step for example:
$ keytool -printcert -v -file opendjserver.pem Owner: CN=opendjserver, O=OpenDS Self-Signed Certificate Issuer: CN=opendjserver, O=OpenDS Self-Signed Certificate Serial number: Valid from: Sat Sep 10 00:34:27 NZST 2011 until: Mon Sep 09 00:34:27 NZST 2013 Certificate fingerprints: MD5: SHA1: Signature algorithm name: SHA1withRSA Version: 3
2) Copy the certificate to the Ubuntu client
We simply copy this certificate to the test Ubuntu VM and place it at /usr/share/ca-certificates
We also want to make the certificate owned by root and world readable:
$ ls -al opendjserver.pem -rw-r--r-- 1 root root 731 2011-09-15 17:03 opendjserver.pem
3) Modify the client LDAP configuration file
We now make some modifications to /etc/ldap.conf. There are many options which can be set or uncommented, however, I have found that only the below two modifications need to be made to an otherwise unmodified file in its default state. This is especially noteworthy considering that entries such as “#ssl on” apparently do not need to be uncommented.
First, specify a secure LDAP URI. In our example, OpenDJ running on the server named opendjserver is being accessed securely over port 1636:
# Another way to specify your LDAP server is to provide an uri ldaps://opendjserver:1636
(Note that if you are using a server host name instead of an IP address, and you are not running DNS, you will need to modify /etc/hosts so that the server hostname is pointing to the server IP address.)
Next, point to the server certificate. Create the following entry:
3) Test connectivity
From the command line on the client we can see if we can retrieve account information for LDAP users:
$ id dave uid=1001(dave) gid=119(admin) groups=119(admin) $ $ getent passwd dave dave:*:1001:119:Dave Koelmeyer:/home/dave:
(Note that if testing in this way it may be useful to uninstall nscd if it has been installed beforehand – as it may have cached successful lookups leading to potentially misleading results if something isn’t working as it should.)
That should be it, and you should now have a basic setup that securely authenticates host logins to the system.