User Tools

Site Tools


LDAP, the Lightweight Directory Access Protocol is used as the foundation for our single (source of) sign on solution. It allows us to create a centralized database to store data for a corporate directory. The protocol supports replication for redundancy and high-availability. Secure connections via SSL/TLS are also supported.

In the future we expect to add Kerberos to the solution. Kerberos is a Ticket Granting system that supports building a single sign on solution. Even more interesting features are expected from the upcoming release of Samba 4. We'll definitely keep an eye on this piece of software. See for more information on Samba 4.

Older versions of the Hannibal LDAP-server documentation can be found here

RHDS (389DS)

The RHDS/389DS former Fedora Directory Server, former Iplanet- and Sun Directory Server, former Netscape Suitespot LDAP-server, generously made open source by RedHat, is chosen as the preferred LDAP-server for our solution at this moment.

You'll find lots of information on the Fedora Directory Server at the project's wiki,



yum install centos-ds
yum install openldap-clients

Instance and LDAP-database creation

(see also the 389DS on debian-4.x howto)

Start the interactive creation of an instance with:


Copy schema additions (61samba-schema-FDS.ldif 62postfix.ldif 70zarafa-389ds.ldif) in:

/etc/dirsrv/slapd-<servername>/schema/ ...



At this time there is no apt-repository for the Fedora Directory Server software. Fortunately the rpms from the Fedora community site are perfectly usable. For Debian-4.0 (Etch) use version fedora-ds-1.0.4-1.FC5.i386.opt.rpm or fedora-ds-1.0.4-1.FC5.amd64.opt.rpm, the Sun Java 1.5.x JRE or JDK, and install the package libncurses5-dev in order to obtain the shared object file If you create the .deb file using alien on a different system than the one you're installing on right now, you might also need librpm4.

Install a Java-Runtime-Environment on the system. The jre-1_5_0_14-linux-amd64.bin package from Sun-microsystems is known to work.

cd /opt
sh ./jre-1_5_0_14-linux-amd64.bin
ln -s /opt/jre1.5.0_14/bin/java /usr/local/bin/java
groupadd fds
useradd -d /opt/fedora-ds -s /bin/false -g fds fds
apt-get install libncurses5-dev librpm4 apache2-mpm-worker
ln -s /usr/lib/ /usr/lib/
ln -s /usr/sbin/apache2 /usr/sbin/httpd

Download a pre-build Fedora Directory Server rpm from the download page which is available at First you have to convert the rpm to a .deb package by applying the alien conversion software to it (preferably on a separate development server or virtual server).

apt-get install alien  
alien -d --scripts fedora-ds_1.0.4-2_amd64.deb


When you have your .deb do:

dpkg -i fedora-ds_1.0.4-2_amd64.deb

Create a resource-file (/opt/install.inf):

SuiteSpotUserID=   fds
SuiteSpotGroup=   fds
ServerRoot=   /opt/fedora-ds
ConfigDirectoryAdminID=   admin
ConfigDirectoryAdminPwd=   hannibal
ConfigDirectoryLdapURL=   ldap://
UserDirectoryAdminID=   admin
UserDirectoryAdminPwd=   hannibal
UserDirectoryLdapURL=   ldap://,dc=example,dc=com

SlapdConfigForMC=   Yes
SecurityOn=   No
UseExistingMC=   No
UseExistingUG=   No
ServerPort=   389
ServerIdentifier=   ldap1
Suffix=   dc=intra, dc=example, dc=com
RootDN=   cn=Directory Manager
AddSampleEntries=   No
InstallLdifFile=   suggest
AddOrgEntries=   Yes
DisableSchemaChecking=   No
RootDNPwd=   hannibal
SysUser=   root
Port=   7777
ServerAdminID=   admin
ServerAdminPwd=   hannibal
ApacheDir=   /usr/sbin
ApacheRoot=   /usr/lib/apache2 

Run the setup-script to perform a silent installation:

/opt/fedora-ds/setup/setup -s -f /opt/install.inf

The installation-script will successfully start the ns-slapd server and throw out some warnings that the admin-server can't be started. We'll solve that now. Make one change to the /opt/fedora-ds/admin-serv/config/httpd.conf file. Hash out the line (normally line 131):

#LoadModule log_config_module /usr/lib/apache2/modules/

Now you can manually start the admin-server:


After this, netstat should show listeners at port 389 and 7777(admin).

Post installation

If you want start/stop scripts to automagically stop/start the directory server first create a file /etc/default/fds with this content.

# The line that follows this comment needs to be uncommented in order for fds to run automagically

# FDSNAME is the instance name of your fds instance

# FDSDIR is the directory where fds is installed

# SLAPDDIR is the directory where the ns-slapd stop/start scripts are located

# PIDFILE is the name of the PID file

Put the init-script itself, which is available for download here, in /etc/init.d

Grant the proper permissions and create symbolic links for the required runlevels.

chmod 755 /etc/init.d/fds
update-rc.d fds defaults

SSL/TLS configuration

You can run the necessary commands by hand or use the available all-in-one '' script. For ease of configuration the latter option has been chosen. Get the script at the Fedora Directory Server Wiki, which is a very fine source for information on the SSL/TLS configuration details, see

The '' script requires the ldap-utils to be installed.

apt-get install ldap-utils

A standalone FDS server

As the script runs 'hostname –fqdn' in order to obtain the FQDN, and we want to use the service name (which is 'ldap') rather than the FQDN hostname, we'll change that entry in the script. Change line number 111 to become:

Check that the host can resolve the service name ( to its service IP address (

Now run the script

chmod +x

Finally restart the Directory Server as well as the Admin-server in order to activate the SSL/TLS. After restarting the Directory Server, netstat should also show a new listener at port 636 (by default) for LDAPS.

Additional FDS servers

These extra masters or slaves use the CA of the first FDS. In other words, they use the same CA-root certificate.

  • only use the CA on the first FDS system (and use the unix-user fds). Use /opt/fedora-ds/alias as working directory.
  • create a server-cert2 (on the CA; ie. the first system). When asked for a password, use for example the string abcdefg8
cd /opt/fedora-ds/alias
../shared/bin/certutil -S -n "Server-Cert2" -s "cn=${MYHOST},ou=Fedora Directory Server" -c "CA certificate" \
                       -t "u,u,u" -m 1003 -v 120 -P slapd-ldap2- -d . -z ${NOISE} -f ${PWDFILE}
  • export server-cert2 from the database to a PKCS12 file:
../shared/bin/pk12util -d . -o ldapserver2.p12 -k pwdfile.txt -P slapd-ldap1- -n Server-Cert2
  • copy the ldapserver2.p12 file and the root-CA cert cacert.asc to the second FDS.
  • create an empty database on the second FDS:
../shared/bin/certutil -N -P slapd-ldap2- -d .
  • create a pin-file (for auto-startup) with the password wich has been set upon the ldapserver2.p12 cert.
echo "Internal (Software) Token:abcdefg8" > slapd-ldap2-pin.txt
  • import cacert.asc in the empty database on FDS2:
../shared/bin/certutil -A -d . -P slapd-ldap2- -n "CA certificate" -t "CT,," -a -i cacert.asc
  • import server-cert2.p12 in the database on FDS2
../shared/bin/pk12util -i ldapserver2.p12 -P slapd-ldap2- -d . -n "Server-Cert2"
  • Enable SSL on the second server with the script below (in case the SSL was already enabled, the file /opt/fedora-ds/slapd-ldap2/config/dse.ldif has to be adapted):
ldapmodify -x -h localhost -p 389 -D "cn=directory manager" -W <<EOF
dn: cn=encryption,cn=config
changetype: modify
replace: nsSSL3
nsSSL3: on
replace: nsSSLClientAuth
nsSSLClientAuth: allowed
add: nsSSL3Ciphers
nsSSL3Ciphers: -rsa_null_md5,+rsa_rc4_128_md5,+rsa_rc4_40_md5,+rsa_rc2_40_md5,
add: nsKeyfile
nsKeyfile: alias/slapd-${FDS}-key3.db
add: nsCertfile
nsCertfile: alias/slapd-${FDS}-cert8.db

dn: cn=config
changetype: modify
add: nsslapd-security
nsslapd-security: on
replace: nsslapd-ssl-check-hostname
nsslapd-ssl-check-hostname: off

dn: cn=RSA,cn=encryption,cn=config
changetype: add
objectclass: top
objectclass: nsEncryptionModule
cn: RSA
nsSSLPersonalitySSL: ${CERTNAME}
nsSSLToken: internal (software)
nsSSLActivation: on

  • restart ldap-server2

DS management console

The directory/admin-server can be managed with a client-server GUI application. This is an X-window-system application, so your workstation might be a good place to install and run this on. Mention that it is possible to run the admin-console from the directory-server itself when you install the X11 libraries on it. If you prefer to run the admin-console using X11forwarding over ssh, you'll want to install the package 'xbase-clients' on the server. Check that your ssh client configuration (by default /etc/ssh/ssh_config) allows for X11forwarding.


We assume Ubuntu as the preferred desktop. A Microsoft Windows desktop console-client will be available from FDS version 1.1.

Install the software

  • Install the SUN JRE/JDK 1.5
  • Install the FDS software from tar, rpm or .deb (as root) in /opt/fedora-ds

If the IP-number of your directory-server is not resolvable, add an entry in /etc/hosts on your workstation: ldap

This has to do with the default access-restrictions of the admin-server

Start the console

As a non-root user start the console (have your X settings correct):

export PATH
cd /opt/fedora-ds
./startconsole -u admin -a &

An X window pops up now, type in the admin password (ie. hannibal here).

LDAP schema additions

Now we have this:

We created four custom LDAP-schemes for our project (additional to the posix schema). They are required for running the other software modules. The LDAP-schemes are available for download below. The target directory for Fedora Directory Server LDAP-schemes is /opt/fedora-ds/slapd-ldap/config/schema

The directory server will activate the new schemes after a restart.

It doesn't harm to check the slapd errorlog after this :-)

cat /opt/fedora-ds/slapd-ldap/logs/errors

Directory-Server replication

The Fedora Directory server supports Multi-Master and Master-Slave replication. The Hannibal community team suggests to deploy a multi-master configuration with several slaves. In our example we set up two masters and two slaves.

The documentation on setting up a replication LDAP-server is available at:

The Fedora wiki contains fine documentation on howto install a MMR-environment. See:


First build two standalone servers. One of them may be empty. They need to have identical ldap-schema's and SSL enabled.

Create a replication user:

ldapmodify -x -h localhost -p 389 -D "cn=directory manager" -W <<EOF
dn: cn=repman,cn=config
changetype: add
objectclass: top
objectclass: person
cn: repman
sn: repman
userPassword: rephan
passwordExpirationTime: 20380119031407Z

Enable the changelog on both the suplier and the consumer servers.

Enable replication on both the suplier and the consumer servers.

Make replication agreements in both directions:

The advice is not to use the init-consumer option from this wizzard:

The warning can be ignored.

If you want to propagate data from a non-empty LDAP-server to an empty LDAP-server. Do an init-consumer (on the supplier server; i.e. the the LDAP-server with the data) by right-click the user-root label. When finished, both LDAP-servers contain all data, and replication is active :-) See also


Build one or more standalone servers. On all masters, make replication agreements to the slaves.

LDAP Export/Backup

Create a full export of your directory to LDIF on a regular base. You wouldn't want to loose your precious data, would you? This is an example to do so.


# Full LDAP export to LDIF
# Olivier Brugman (Pref Sourcing)

FILEDATE=`date +%Y%m%d`

/usr/bin/test -d ${TARGETDIR} || mkdir -p ${TARGETDIR}

               -b dc=intra,dc=example,dc=com \
               -h YOURLDAPHOST \
               -D cn="Directory Manager" \
               -w YOURPASSWORD \
               -LLL \
               '(objectclass=*)' > ${TARGETFILE}
hannibal/fds.txt · Last modified: 2011/06/14 09:34 by Luc Nieland