Cette installation a été réalisée une Red Hat Entreprise 9.0.
Il est conseillé d’utiliser la dernière version de la BerkeleyDB afin d’éliminer les risques d’incompatibilité.
1 - Installation de la BerkeleyDB
Nous avons utilisé la version 4.2.52.
Il suffit de télécharger le fichier en tar.gz et d’entrer les commandes suivantes :
Tar xvzf (afin de décompresser l’archive dans le répertoire)
Cd db-4.2.52
Cd build_unix
./configure -> prépare les fichiers nécessaires à la compilation
make -> compile les fichiers du programme
make install -> exécute les instructions nécessaires à l’installation du programme
2 - Installation d’OpenSSL
Il suffit aussi de télécharger la dernière version d’OpenSSL et de décompresser le fichier .tgz.
L’installation se déroule de la manière suivante :
Tar xvzf openssl-0.9.9d.tar.gz
Cd openssl-0.9.9d.tar.gz
./configure
make
make test -> teste le logiciel avant l’installation
make install
3 - Installation d’OpenLDAP
Il faut télécharger la dernière version d’OpenLDAP sur www.openldap.org (dans notre cas la version 2.18) et la décompresser pour procéder à l’installation.
Tar xvzf openldap.2.18
Cd openldap.2.18
env CPPFLAGS="-I/usr/local/BerkeleyDB.4.2/include/ -I/usr/local/ssl/include/ -I\
/usr/local/include/" LDFLAGS="-L/usr/local/ssl/openssl/ -L/usr/local/BerkeleyDB\
.4.2/lib/ -L/usr/local/lib -L/usr/local/lib/sasl2" LIBS="-lssl -lcrypt -lsasl2"\
./configure --enable-debug --with-tls --without-cyrus-sasl --enable-bdb
make depend -> prépare les dépendances à la compilation
make
make test
make install
Une modification s’impose dans le fichier lapd.so.conf
Il faut ajouter la ligne :
/usr/local/db-4.2.52/build_unix/*.libs -> chemin d’accès de la libraire de la base de données
OpenLDAP est désormais installé…il serait judicieux d’observer avec attention le lancement du démon slapd afin de pouvoir diagnostiquer les problèmes éventuels.
Nous allons donc paramétrer syslogd afin d’obtenir un fichier de log à chaque démarrage/arrêt du démon.
4 - Paramétrage de syslogd
Le fichier de configuration a pour chemin d’accès :
/etc/syslog.conf
Il suffit de rajouter ces deux lignes à la fin du fichier
#Log pour LDAP
local4.* /var/log/ldap.log
Il faut ensuite arrêter le démon syslogd et le relancer…ainsi qu’à chaque modification du fichier de configuration bien sûr.
Pour relancer ce dernier il faut exécuter la commande :
syslogd –h
Syslogd est désormais paramétrer et il ne nous reste plus qu’à modifier le fichier de configuration d’OpenLDAP.
5 - Configuration d’OpenLDAP
Le fichier de configuration d’OpenLDAP est slapd.conf.
Dans notre cas, il se trouve dans /usr/local/etc/openldap/.
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/internet2.schema
include /usr/local/etc/openldap/schema/supann.schema
include /usr/local/etc/openldap/schema/nis.schema
Dans le cadre du projet de déploiement de Supann, nous avons intégrer les schémas internet2 et Supann à l’annuaire.
loglevel -1
Cette annotation permet de logger tous les événements survenus (aussi bien les interrogations de la base que son démarrage).
Il faut renseigner le fichier pour le suffixe de l’arborescence et le responsable de la base de données (dans notre cas, c’est Manager).
password-hash {MD5}
rootpw {MD5}
Afin de sécuriser le mot de passe du responsable de l’annuaire, nous avons crypté ce dernier en MD5.
Afin de crypter celui-ci, il suffit d’exécuter les commandes suivantes afin d’obtenir un prompt qui cryptera le mot de passe que vous taperez :
Slappasswd –c –v –h {MD5}
Afin de renforcer la sécurité de l’annuaire, nous avons utilisé différents certificats de sécurité :
Le premier certificat (ac-serveur.crt) est un certificat de sécurité délivré par le CRU (faisant ici office d’autorité de certification).
Il faut ensuite rédiger un fichier de structure et l’ajouter à l’annuaire.
Le fichier, creation_ldap.ldif est le suivant :
dn: dc=exemple,dc=fr
objectclass: dcObject
objectclass: organization
o: exemple
dc: exemple
description: Notre exemple
dn: ou=Group,dc=exemple,dc=fr
ou: Group
objectclass: top
objectclass: organizationalUnit
description: Groupes des utilisateurs identifies par ldap
dn: ou=People,dc=exemple,dc=fr
ou: People
objectclass: top
objectclass: organizationalUnit
description: Utilisateurs identifies par ldap
Il faut ensuite exécuter la commande suivante afin de l’entrer dans l’annuaire :
On peut désormais utiliser un browser LDAP pour avoir un affichage de la structure de l’annuaire et des entrées de celui-ci.
Nous utiliserons JXplorer.
7 - Jxplorer
Pour commencer, il nous faut indiquer à notre browser LDAP que nous referons au CRU afin de savoir si le serveur LDAP auquel nous nous connectons est valide.
Pour cela, nous devons installons le certificat ac-serveur du CRU dans les « Serveurs Trusted et CAs ».
Il faut ensuite renseigner les champs hôte, port, le protocole utilisé, le nom de l’annuaire (base DN) et bien entendu les informations de sécurité (niveau de sécurité, login et password).
Le port 636 est utilisé pour interroger le serveur d’annuaire via une connexion SSL.
8 - Réplication des données
Afin de préparer une architecture de haute disponibilité pour notre service d’annuaire, nous devons déjà assurer la réplication des données selon un modèle maître/esclave.
Pour cela, il faut créer un compte de réplication sur les deux serveurs et lui allouer des droits en écriture sur l’annuaire.
Il nous faut pour cela éditer les fichiers de configuration des serveurs de la manière suivante :
Sur le serveur maître :
access to *
…
by dn="cn=replica,dc=exemple,dc=fr" write
…
#replication vers le serveur esclave
replogfile /var/lib/ldap/replica/replication.log
replica host=:389
binddn="cn=replica,dc=exemple,dc=fr"
bindmethod=simple credentials=
Sur le serveur esclave :
access to *
…
by dn="cn=replica,dc=exemple,dc=fr" write
…
#replication depuis le serveur maitre
updatedn "cn=replica,dc=exemple,dc=fr"
updateref "ldap://:389"
Pour vérifier le bon déroulement de la réplication, il est conseillé de lancer slapd sur le serveur maître puis sur le serveur esclave. On peut lancer slurpd sur le serveur maître, dans une session ssh de la manière suivante :
/usr/local/libexec/slurpd –d 65635
Ce niveau de debugging nous permet d’observer tous les événements survenu lors de la réplication (ouverture de socket, écriture,…).
Dans notre cas la réplication s’effectue en clair, le mot de passe est diffusée sur le réseau alors il faut mieux la crypter.
9 - Restauration de la base de données
Il se peut que la base de données soit endommagée après un certain nombre de manipulations, le service slapd ne se lance alors plus.
Pour remédier à cela, il convient d’assurer une sauvegarde de cette dernière.
Il faut ensuite exporter la base de données sauvegardée et exécuter un db_recover afin de la restaurer correctement.
10 - Mise en place de scripts pour le lancement automatique des démons
Afin de relancer les démons slapd et slurpd en cas de redémarrage des serveurs, il est nécessaire d’écrire quelques scripts qui nous simplifieront la vie.
Sur le serveur maître, il faut placer les scripts slapd et slurpd dans /etc/init.d mais aussi les rendre exécutable grâce à la commande chmod +x slapd.
Votre script est désormais exécutable et il ne reste plus qu’à l’ajouter à la base des services gérée par chkconfig. Pour cela, il faut faire la commande suivante :
chkconfig –add slapd
Vous n’avez plus qu’à faire de même pour le script slapd sur le serveur esclave.
Vous trouverez les deux scripts en annexe.
Annexe
Fichier de configuration slapd.conf
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
include /usr/local/etc/openldap/schema/internet2.schema
include /usr/local/etc/openldap/schema/supann.schema
include /usr/local/etc/openldap/schema/nis.schema
# Define global ACLs to disable default read access.
# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral ldap://root.openldap.org
pidfile /usr/local/var/run/slapd.pid
argsfile /usr/local/var/run/slapd.args
loglevel -1
# Load dynamic backend modules:
# modulepath /usr/local/libexec/openldap
# moduleload back_bdb.la
# moduleload back_ldap.la
# moduleload back_ldbm.la
# moduleload back_passwd.la
# moduleload back_shell.la
# Sample security restrictions
# Require integrity protection (prevent hijacking)
# Require 112-bit (3DES or better) encryption for updates
# Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64
# Sample access control policy:
# Root DSE: allow anyone to read it
# Subschema (sub)entry DSE: allow anyone to read it
# Other DSEs:
# Allow self write access
# Allow authenticated users read access
# Allow anonymous users to authenticate
# Directives needed to implement policy:
# access to dn.base="" by * read
# access to dn.base="cn=Subschema" by * read
access to dn.base= by * read
access to * by * read
# access to *
# by self write
# by users read
# by anonymous auth
access to attr=userPassword
by self write
by anonymous auth
#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn. (e.g., "access to * by * read")
#
# rootdn can always read and write EVERYTHING!
#######################################################################
# BDB database definitions
#######################################################################
database bdb
suffix "dc=exemple,dc=fr"
rootdn "cn=Manager,dc=exemple,dc=fr"
# Cleartext passwords, especially for the rootdn, should
# be avoid. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
password-hash {MD5}
rootpw {MD5}
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd and slap tools.
# Mode 700 recommended.
directory /usr/local/var/openldap-data
# Indices to maintain
index objectClass eq
TLSCACertificate /usr/local/var/openldap-data/ac-serveur.crt
TLSCertificateFile /usr/local/var/openldap-data/ldap.exemple.fr.crt
TLSCertificateKeyFile /usr/local/var/openldap-data/ldap.exemple.fr.key
#TLSCipherSuite HIGH:MEDIUM:+SSLv2
#TLSVerifyClient never
