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 http://us1.samba.org/samba/devel/roadmap-4.0.html for more information on Samba 4.
Older versions of the Hannibal LDAP-server documentation can be found here
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, http://directory.fedora.redhat.com/wiki/Main_Page.
yum install centos-ds yum install openldap-clients
(see also the 389DS on debian-4.x howto)
Start the interactive creation of an instance with:
/usr/sbin/setup-ds-admin.pl
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 libtermcap.so.2 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/libncurses.so /usr/lib/libtermcap.so.2 ln -s /usr/sbin/apache2 /usr/sbin/httpd
Download a pre-build Fedora Directory Server rpm from the download page which is available at http://directory.fedora.redhat.com/wiki/Download. 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):
[General] FullMachineName= ldap1.intra.example.com SuiteSpotUserID= fds SuiteSpotGroup= fds ServerRoot= /opt/fedora-ds AdminDomain= intra.example.com ConfigDirectoryAdminID= admin ConfigDirectoryAdminPwd= hannibal ConfigDirectoryLdapURL= ldap://ldap1.intra.example.com:389/o=NetscapeRoot UserDirectoryAdminID= admin UserDirectoryAdminPwd= hannibal UserDirectoryLdapURL= ldap://ldap1.intra.example.com:389/dc=intra,dc=example,dc=com [slapd] 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 [admin] SysUser= root Port= 7777 ServerIpAddress= 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/mod_log_config.so
Now you can manually start the admin-server:
/opt/fedora-ds/start-admin
After this, netstat should show listeners at port 389 and 7777(admin).
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 #START="yes" # FDSNAME is the instance name of your fds instance FDSNAME="xenfds" # FDSDIR is the directory where fds is installed FDSDIR="/opt/fedora-ds" # SLAPDDIR is the directory where the ns-slapd stop/start scripts are located SLAPDDIR="${FDSDIR}/slapd-${FDSNAME}" # PIDFILE is the name of the PID file PIDFILE="${SLAPDDIR}/logs/pid"
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
You can run the necessary commands by hand or use the available all-in-one 'setupssl.sh' 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 http://directory.fedora.redhat.com/wiki/Howto:SSL
The 'setupssl.sh' script requires the ldap-utils to be installed.
apt-get install ldap-utils
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:
myhost=ldap.intra.example.com
Check that the host can resolve the service name (ldap.intra.example.com) to its service IP address (192.168.1.12).
Now run the script
chmod +x setupssl.sh ./setupssl.sh
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.
These extra masters or slaves use the CA of the first FDS. In other words, they use the same CA-root certificate.
#!/bin/sh MYHOST=xenfds01.intra.pref.nl NOISE=/opt/fedora-ds/alias/noise.txt PWDFILE=/opt/fedora-ds/alias/pwdfile.txt 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}
../shared/bin/pk12util -d . -o ldapserver2.p12 -k pwdfile.txt -P slapd-ldap1- -n Server-Cert2
../shared/bin/certutil -N -P slapd-ldap2- -d .
echo "Internal (Software) Token:abcdefg8" > slapd-ldap2-pin.txt
../shared/bin/certutil -A -d . -P slapd-ldap2- -n "CA certificate" -t "CT,," -a -i cacert.asc
../shared/bin/pk12util -i ldapserver2.p12 -P slapd-ldap2- -d . -n "Server-Cert2"
#!/bin/sh FDS=ldap2 CERTNAME=Server-Cert2 # 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, +rsa_des_sha,+rsa_fips_des_sha,+rsa_3des_sha,+rsa_fips_3des_sha,+fortezza, +fortezza_rc4_128_sha,+fortezza_null,+tls_rsa_export1024_with_rc4_56_sha, +tls_rsa_export1024_with_des_cbc_sha - 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 EOF
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.
If the IP-number of your directory-server is not resolvable, add an entry in /etc/hosts on your workstation:
192.168.1.12 ldap.intra.example.com ldap
This has to do with the default access-restrictions of the admin-server
As a non-root user start the console (have your X settings correct):
PATH=/opt/jre1.5.0_14/bin:$PATH export PATH cd /opt/fedora-ds ./startconsole -u admin -a http://ldap1.intra.example.com:7777 &
An X window pops up now, type in the admin password (ie. hannibal here).
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
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: http://www.redhat.com/docs/manuals/dir-server/ag/replicat.htm#pgfId-1027091
The Fedora wiki contains fine documentation on howto install a MMR-environment. See: http://directory.fedora.redhat.com/wiki/Howto:MultiMasterReplication
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:
#!/bin/sh 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 EOF
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 http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.0/html/Administration_Guide/Managing_Replication-Initializing_Consumers.html
Build one or more standalone servers. On all masters, make replication agreements to the slaves.
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.
#!/bin/sh # Full LDAP export to LDIF # # Olivier Brugman (Pref Sourcing) LDAPSEARCH=/usr/bin/ldapsearch FILEDATE=`date +%Y%m%d` TARGETDIR=/root/ldifs TARGETFILE=${TARGETDIR}/full_ldap2ldif-${FILEDATE} /usr/bin/test -d ${TARGETDIR} || mkdir -p ${TARGETDIR} ${LDAPSEARCH} -x \ -b dc=intra,dc=example,dc=com \ -h YOURLDAPHOST \ -D cn="Directory Manager" \ -w YOURPASSWORD \ -LLL \ '(objectclass=*)' > ${TARGETFILE}