HannibalWiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.


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 [[hannibal:ldap_directory_oldversions|here]]



======RHDS/389DS=======
The RHDS/389DS former Fedora Directory Server, former Netscape Suitespot, former Iplanet- and Sun Directory 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.




=====CentOS-5.x=====

====Preparation====

  yum install centos-ds
  yum install opeldap-clients


====Instance and LDAP-database creation====
See The debian-4.x 


Exceptions: the schema additions wil go in:

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




=====Debian-4.0=====

====Pre-installation====

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 [[hannibal:devserver|separate development server]] or virtual server).
  apt-get install alien  
  alien -d --scripts fedora-ds_1.0.4-2_amd64.deb



====Installation====
When you have your .deb do:
  dpkg -i fedora-ds_1.0.4-2_amd64.deb


Create a resource-file (/opt/install.inf):
<code>
[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 
</code>




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).




====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.
<code>
# 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"
</code>



Put the init-script itself, which is available for [[fds-init-script|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 '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

===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:
  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.


===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
<code>
#!/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}
</code>

  * 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):

<code>
#!/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
</code>

  * 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.



====Ubuntu-7.10====
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:
  192.168.1.12  ldap.intra.example.com 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):
  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).








=====LDAP schema additions=====
Now we have this:

{{hannibal:fds-out-of-the-box-ldap-schema.png|}}


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
  * [[61samba.ldif]]
  * [[62postfix.ldif]]
  * [[63ldapdns.ldif]]
  * [[64ldapdhcp.ldif]]

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

{{hannibal:ldap-ds-infra.png|}}

====Master-Master====
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:
<code>
#!/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
</code>

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

{{hannibal:ldap-replication.01.enable-changelog.png|}}


Enable replication on both the suplier and the consumer servers.

{{hannibal:ldap-replication.02.enable-replica.png|}}

Make replication agreements in both directions:

{{hannibal:ldap-replication.03.replic-agreement-m1tom2.png|}}

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

{{hannibal:ldap-replication.05.do-not-init-consumer.png|}}

The warning can be ignored.

Now do an init-consumer by right-click the user-root label. When finished, the replication is active :-)


====Master-Slave====
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.

<code>
#!/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}
</code>
HannibalWiki

User Tools

Site Tools

Page Tools
