Configuration du serveur OpenLDAP
Le démon ou processus serveur d’OpenLDAP se nomme "slapd" et utilise depuis la version d’OpenLDAP v2.3, non plus un fichier "plat" contenant ses informations de configuration, mais un mécanisme de configuration d’exécution dynamique chargée dans un DIT dédié (cn=config) et stocké sur le système sous forme de fichier LDIF dans le répertoire suivant : /etc/openldap/slapd.d.
Ce mécanisme de configuration se nomme "OLC" pour "On-Line Configuration".
Ainsi, la modification de la configuration doit se faire directement dans l’annuaire à l’aide de commandes LDAP (ex. : ldapmodify, ldapadd...) ou bien par l’intermédiaire d’un navigateur LDAP. Mais il ne faut surtout pas, et en aucun cas, modifier les fichiers de configuration LDIF avec un éditeur de texte de type "vi", car ceux-ci pourraient y inclure des caractères non tolérés pouvant ainsi corrompre la configuration du serveur LDAP.
De plus, cette innovation permet au démon "slapd" d’intégrer à "chaud" les modifications apportées à sa configuration sans redémarrage de l’annuaire comme cela était le cas dans les versions précédentes avec le fichier /etc/openldap/slapd.conf.
En effet, dans l’ancienne version, lors de l’ajout par exemple d’un schéma, il fallait donc modifier le "slapd.conf" pour y ajouter la référence à celui-ci, ajouter son fichier LDIF dans le répertoire de configuration et puis redémarrer le service. Dans de très gros environnements, ce processus pouvait prendre énormément de temps et donc impacter la production. Mais désormais avec OLC l’ajout de ce schéma se fait en ligne de commande avec prise en compte immédiate.
La configuration via le fichier "slapd.conf" est toujours supportée, mais dépréciée, et disparaîtra très certainement dans les futures versions.
Cependant, lors de l’installation initiale d’un serveur OpenLDAP, il est (très) utile de se servir de ce fichier de configuration comme fichier de configuration initial pour ensuite le convertir au nouveau format. Cette opération sera détaillée plus loin dans ce chapitre à la section Configuration initiale par le fichier "slapd.conf".
La section suivante présente l’organisation des fichiers de configuration dans l’annuaire OpenLDAP.
1. Organisation des fichiers de configuration
Ainsi, la configuration de l’annuaire LDAP se trouve dans un DIT spécial (cn=config) contenant entre autres un schéma spécifique définissant toutes les classes d’objets et attributs nécessaires à la configuration et au paramétrage d’un serveur OpenLDAP. Un exemple d’arborescence de configuration est illustré par la figure 4-2.
¬
Figure 4-2 : Arborescence de configuration du "cn=config"
Certaines des entrées répertoriées ci-dessus ont un index numérique "{X}" dans leur nom. Il est utilisé seulement pour distinguer les différentes entrées de type olcDatabase et cn=module{x}. Dans la plupart des cas, l’indice ne doit pas être fourni  ; il sera généré automatiquement en fonction de l’ordre dans lequel les entrées sont créées.
Par ailleurs, il est possible de voir sa structure physique à l’aide d’un navigateur LDAP (figure 4-4) ou sur le système lui-même par la commande tree (figure 4-3).
# 
[root@ldap01 yum.repos.d]# tree /etc/openldap/slapd.d 
/etc/openldap/slapd.d 
├── cn=config 
│   ├── cn=schema 
│   │   ├── cn={0}corba.ldif 
│   │   ├── cn={10}ppolicy.ldif 
│   │   ├── cn={11}collective.ldif 
│   │   ├── cn={1}core.ldif 
│   │   ├── cn={2}cosine.ldif 
│   │   ├── cn={3}duaconf.ldif 
│   │   ├── cn={4}dyngroup.ldif 
│   │   ├── cn={5}inetorgperson.ldif 
│   │   ├── cn={6}java.ldif 
│   │   ├── cn={7}misc.ldif 
│   │   ├── cn={8}nis.ldif 
│   │   └── cn={9}openldap.ldif 
│   ├── cn=schema.ldif 
│   ├── olcDatabase={0}config.ldif 
│   ├── olcDatabase={-1}frontend.ldif 
│   ├── olcDatabase={1}monitor.ldif 
│   └── olcDatabase={2}bdb.ldif 
└── cn=config.ldif 
2 directories, 18 files 
[root@ldap01 yum.repos.d]#
Figure 4-3 : Arborescence du dossier "/etc/openldap/slapd.d"
¬
Figure 4-4 : Arborescence "/etc/openldap/slapd.d"
2. Présentation des entrées de configuration
Cette section présente brièvement le contenu de chacune des sous-entrées de l’entrée "cn=config".
¬
a. "dn: cn=config"
L’entrée "cn=config" est ainsi la racine ou le suffixe du DIT de configuration (OLC).
Celle-ci contient donc à sa base des informations de configuration globale du serveur OpenLDAP comme par exemple des paramètres systèmes (thread, pid, chemin de fichiers, etc.) ou bien des paramètres concernant les connexions à l’annuaire.
dn: cn=config 
objectClass: olcGlobal 
cn: config 
olcAllows: bind_v2 
olcArgsFile: /var/run/openldap/slapd.args 
olcAttributeOptions: lang- 
olcAuthzPolicy: none 
olcConcurrency: 0 
olcConfigDir: /etc/openldap/slapd.d/ 
olcConfigFile: slapd.conf 
olcConnMaxPending: 100 
olcConnMaxPendingAuth: 1000 
olcGentleHUP: FALSE 
olcIdleTimeout: 0 
olcIndexIntLen: 4 
olcIndexSubstrAnyLen: 4 
olcIndexSubstrAnyStep: 2 
olcIndexSubstrIfMaxLen: 4 
olcIndexSubstrIfMinLen: 2 
olcListenerThreads: 1 
olcLocalSSF: 71 
olcLogLevel: 0 
olcPidFile: /var/run/openldap/slapd.pid 
olcReadOnly: FALSE 
olcReverseLookup: FALSE 
olcSaslSecProps: noplain,noanonymous 
olcServerID: 1 
olcSockbufMaxIncoming: 262143 
olcSockbufMaxIncomingAuth: 16777215 
olcThreads: 16 
olcTLSCACertificateFile: /etc/openldap/certs/DigiCertCA.crt 
olcTLSCertificateFile: /etc/openldap/certs/star_exemple_com.crt 
olcTLSCertificateKeyFile: /etc/openldap/certs/star_exemple_com.key 
olcTLSProtocolMin: 3.1 
olcTLSVerifyClient: never 
olcToolThreads: 1 
olcWriteTimeout: 0
Figure 4-6 : Contenu de l’entrée "dn: cn=config"
Ainsi, on peut observer dans la figure 4-6 tout un tas d’attributs concernant le nom et le chemin des fichiers de configuration, les processus au travers des paramètres "threads/listeners" et des connexions (olcConnMMaxPending, olcIdleTimeout, etc.). C’est également ici que l’on paramétrera les certificats pour établir une connexion SSL (LDAPS) via les attributs : olcTLSCACertificateFile, olcTLSCertificateFile, olcTLSCertificateKeyFile, olcTLSProtocolMin et olcTLSVerifyClient.
olcLogLevel est aussi un autre paramètre intéressant, car il permet de contrôler le niveau de verbosité des logs LDAP.
b. "dn: cn=module, cn=config"
C’est à cet endroit que seront ajoutées des fonctionnalités telles que la réplication, la supervision des connexions, l’application de règles de mot de passe, etc.
Le chapitre Ajout de fonctionnalités appelées "overlay" sera d’ailleurs consacré à la présentation et à la configuration de ces fonctionnalités.
¬
Figure 4-7 : Contenu de l’entrée "dn: cn=module, cn=config"
Dans l’exemple de la figure 4-7, il apparaît que trois modules sont chargés sur le serveur OpenLDAP par la directive olcModuleLoad :
	•	olcModuleLoad: {0}syncprov.la : pour la réplication.
	•	olcModuleLoad: {1}ppolicy.la : pour l’application d’une politique de mots de passe.
	•	olcModuleLoad: {2}back_monitor.la : pour la supervision.
c. "dn: cn=schema, cn=config"
Cette partie sera dédiée aux schémas chargés dans l’annuaire LDAP.
¬
Figure 4-8 : Contenu de l’entrée "dn: cn=schema,cn=config"
En d’autres termes, la nature des entrées qui seront ajoutées dans l’annuaire doit être définie à cet emplacement. C’est-à-dire que toutes les classes d’objets et tous les attributs utilisés pour définir chacune des entrées de l’annuaire sont référencés à cet endroit à l’aide des directives olcAttributeTypes et olcObjectClasses. 
d. "dn: olcBackend=<type>, cn=config"
Cette entrée est optionnelle et peut être créée pour chaque type de backend (voir tableau de la figure 4-9). Il définira alors des paramètres globaux qui seront appliqués ou non aux entrées olcDatabase utilisant ce type. En effet, si de mêmes paramètres sont définis au niveau des entrées olcDatabase, alors ils seront prioritaires.
Une présentation des backend sera réalisée dans ce chapitre à la section Les backend dynamiques.
Types	Description	
bdb	Berkeley DB transactional backend	
config	Slapd configuration backend	
dnssrv	DNS SRV backend	
hdb	Hierarchical variant of bdb backend	
ldap	Lightweight Directory Access Protocol (Proxy) backend	
ldif	Lightweight Data Interchange Format backend	
meta	Meta Directory backend	
monitor	Monitor backend	
passwd	Provides read-only access to passwd(5)	
perl	Perl Programmable backend	
shell	Shell (extern program) backend	
sql	SQL Programmable backend	
Figure 4-9 : Les différents types de backend
e. "dn: Database={x}<type>, cn=config"
Cette entrée définit la base de données (DIT) qui sera créée en vue de l’exploitation de l’annuaire par des utilisateurs. Il peut y en avoir plusieurs du même type, dans ce cas, les entrées se distingueront par leur index. À l’installation d’OpenLDAP, deux bases de données par défaut seront générées automatiquement :
	•	olcDatabase={-1}frontend
	•	olcDatabase={0}config
Le "frontend" est une base de données spéciale utilisée pour contenir des paramètres applicables à toutes les autres bases de données. Elles ne sont pas prioritaires si des options similaires sont appliquées au niveau des entrées de base de données elles-mêmes. L’entrée "cn=config" contient les paramètres de configuration de la base de données de configuration.
3. Présentation des backend disponibles
Dans le cas de la dernière distribution d’OpenLDAP, un choix s’offre parmi une dizaine de backend différents qui sont présents sous forme de modules (autrement dit sous forme de bibliothèques logicielles) qu’il est possible d’activer de manière dynamique.
Il est possible de classer ces backend en trois catégories :
	•	Ceux qui stockent les données localement sur le serveur LDAP de manière structurée, organisée, sécurisée et de type transactionnel... ou bien sans structure dans un fichier dit "plat".
	•	Ceux qui envoient les données à d’autres "backend" que l’on appelle dans ce cas des "proxy backend" et agissent donc comme des passerelles. Ces backend distants peuvent être d’autres serveurs LDAP ou bien tout autre type de SGBD gérant les requêtes SQL.
	•	Et ceux qui contiennent des données non persistantes telles que des informations sur la configuration actuelle du serveur OpenLDAP, des statistiques comme par exemple le nombre de clients LDAP actuellement connectés avec leurs adresses IP et tout un tas d’autres informations pouvant être exploitées par l’administrateur du serveur LDAP. Les données de ces backend sont stockées en mémoire et sont donc volatiles. Dès l’arrêt du service, elles seront effacées.
a. Les backend locaux
Ce sont ceux qui stockent les données localement sur le serveur LDAP. Par exemple, dans l’application OpenLDAP, ils peuvent être activés dynamiquement depuis la configuration du serveur, car ils sont chargés sous forme de bibliothèque logicielle au démarrage du démon LDAP (slapd).
Voici une liste des backend les plus utilisés :
	•	back-bdb : premier backend de type transactionnel utilisé et recommandé par OpenLDAP. Il est basé sur la Berkeley DB.
	•	back-hdb : basé sur back-bdb et offre une meilleure utilisation de l’indexation et de la mise en cache. Il offre également une structure hiérarchique et la possibilité de renommer les arborescences.
	•	back-mdb : c’est le backend recommandé actuellement par OpenLDAP qui utilise les librairies "OpenLDAP Lightning Memory-Mapped Database (LMDB)". Il utilise également l’indexation, mais pas de mise en cache, et ne nécessite aucun paramétrage particulier pour une utilisation maximale des fonctions de recherche dans la base de données.
	•	back-ldif : il enregistre les données en syntaxe LDIF dans des fichiers LDIF.
b. Les proxy backend
	•	back-ldap : transmet les données vers d’autres serveurs LDAP sous forme de requêtes LDAP.
	•	back-passwd : utilise les données sous forme de fichier "/etc/passwd". Utilisé pour le test seulement.
	•	back-relay : transfère les informations vers d’autres backend LDAP.
	•	back-sql : envoie les données dans un SGBD sous forme de requête SQL.
c. Les backend dynamiques
	•	back-config : utilisé par la configuration dynamique (OLC).
	•	back-monitor : utilisé par l’overlay "monitor" qui n’est autre qu’une fonctionnalité à ajouter à l’annuaire permettant de collecter des données liées à l’activité de celui-ci de manière dynamique.
4. Configuration initiale par le fichier "slapd.conf"
Bien que depuis la version OpenLDAP 2.4, la configuration On-line (OLC) est disponible, il paraît plus simple d’utiliser l’ancien fichier de paramétrage "/etc/openldap/slapd.conf" lors de la configuration initiale de l’annuaire. Puis, une fois celui-ci finalisé, nous le convertirons dans son nouveau format en tant que fichiers LDIF hiérarchisés sous le répertoire : "/etc/openldap/slapd.d" configurant ainsi la branche "cn=config".
¬
Attention : ne pas chercher le fichier "/etc/openldap/slapd.conf", car celui-ci n’existe plus... en revanche, son format est toujours supporté par le daemon "slapd" et peut d’ailleurs toujours être configuré pour son utilisation.
a. Création du fichier "/etc/openldap/slapd.conf"
Voici un exemple de fichier "slapd.conf" :
# Partie (1) configuration générale 
include     /etc/openldap/schema/core.schema 
include     /etc/openldap/schema/cosine.schema 
include     /etc/openldap/schema/inetorgperson.schema 
include     /etc/openldap/schema/nis.schema 
include     /etc/openldap/schema/ppolicy.schema 
allow bind_v2 
pidfile     /var/run/openldap/slapd.pid 
argsfile    /var/run/openldap/slapd.args 
modulepath  /usr/lib64/openldap 
moduleload  syncprov.la 
loglevel sync 
 
database        config 
rootpw  {SSHA}ffSRljtzczPh7aMqwEn8zG3FQ2tdNfde 
# Partie (2) configuration ’Base de donnée’ 
database    bdb 
suffix      "dc=exemple,dc=com" 
rootdn      "cn=root,dc=exemple,dc=com" 
rootpw      {SSHA}ffSRljtzczPh7aMqwEn8zG3FQ2tdNfde 
directory   /var/lib/ldap 
index objectClass                       eq,pres 
index ou,cn,mail,surname,givenname      eq,pres,sub 
index uidNumber,gidNumber,loginShell    eq,pres 
index uid,memberUid                     eq,pres,sub 
index nisMapName,nisMapEntry            eq,pres,sub 
index entryCSN              eq 
index entryUUID             eq 

# Partie (3) configuration de la réplication 
serverID 1 
syncrepl         rid=001 
                 provider=ldap://ldap02:389 
                 bindmethod=simple 
                 binddn="cn=root,dc=exemple,dc=com" 
                 credentials=secret 
                 searchbase="dc=exemple,dc=com" 
                 attrs=",+" 
                 schemachecking=off 
                 type=refreshAndPersist 
                 retry="1 +" 
 
overlay syncprov 
syncprov-checkpoint 100 10 
syncprov-sessionlog 100 
 
mirrormode TRUE
Ainsi, la première partie du fichier de configuration (1) contiendra des informations de configuration générale telles que les schémas à utiliser, la définition des chemins des fichiers de fonctionnement du serveur OpenLDAP (pid, binaires, librairies, etc.) et également les modules à charger. Il ne faut donc pas modifier ces valeurs. En revanche, il faudra ajouter la ligne suivante : "moduleload syncprov.la" afin d’activer la fonction de réplication du provider (cf. chapitre La réplication). C’est également dans cette partie qu’il faudra ajouter le mot de passe du compte ’cn=config’ permettant d’accèder au DIT de configuration ’cn=config’.
Puis, il faudra configurer la partie (2) concernant le stockage des données en précisant le type de moteur de stockage (ici bdb), le suffixe, le super-utilisateur et son mot de passe (rootdn/rootpw) et les index à utiliser pour optimiser la recherche des informations.
¬
Afin de rendre illisibles les mots de passe des utilisateurs de liaison administrateur nommés ’rootdn’ pour les différents DIT de l’annuaire depuis les fichiers de configuration ou depuis un navigateur LDAP, il est fortement conseillé d’utiliser la commande ’slappasswd’ fournie dans le package ’openldap server".
¬
Si l’annuaire fait partie d’une infrastructure répliquée, alors il est conseillé afin d’obtenir de meilleures performances d’ajouter les index "entryCSN" et "entryUUID".
Concernant la configuration de la réplication (3), le mécanisme de réplication par le démon "slurpd" n’étant plus utilisé depuis la version OpenLDAP v2.4 au profit d’un module (dit overlay) nommé : syncprov, il faudra donc ne pas oublier de le charger avec l’ajout de la ligne : "moduleload syncprov.la" (vu dans la première partie (1) du fichier de configuration).
Ensuite, comme il s’agit d’une réplication "Peer To Peer", il faudra ajouter le paramètre serverID afin de différencier les serveurs impliqués dans la réplication, et paramétrer la fonction consumer au travers de la configuration du syncrepl. Il faudra alors essentiellement renseigner les informations de connexions au "Peer" distant puis activer et configurer la partie provider (syncprov).
Et enfin, ajouter le paramètre mirrormode TRUE.
Pour réaliser la configuration de l’autre serveur LDAP partenaire, il faudra prendre exactement la même configuration en changeant seulement les paramètres suivants :
serverID 2 
syncrepl rid=002 
               provider=ldap://ldap01:389
¬
Garder les mêmes identifiants (utilisateur et mot de passe) afin de faciliter l’installation initiale puis la gestion des serveurs LDAP. Cependant, cela pourra très bien être changé par la suite si nécessaire.
¬
Dans le cadre de la configuration initiale, le protocole "SSL/TLS" n’a pas été ajouté afin de simplifier notre recherche de panne en cas de problème de fonctionnement au démarrage du serveur LDAP. Il sera donc ajouté par la suite.
b. Conversion de l’ancien (slapd.conf) au nouveau format de configuration (olc, cn=config)
Voici les étapes à suivre afin de convertir le fichier "slapd.conf" précédemment obtenu dans son nouveau format (OLC). Pendant cette opération, le service "slapd" doit être bien entendu stoppé.
Afin de ne rencontrer aucun problème lors de cette étape, il est tout d’abord conseillé de supprimer, puis de recréer le répertoire de configuration du serveur OpenLDAP :
rm -rvf /etc/openldap/slapd.d/ 
mkdir /etc/openldap/slapd.d/
Ensuite, il faudra passer la commande slaptest fournie par "OpenLDAP" pour convertir le fichier "slapd.conf" :
[root@ldap01]# slaptest -f slapd.conf -F /etc/openldap/slapd.d/ 
57567d77 bdb_db_open: warning - no DB_CONFIG file found in  
directory /var/lib/ldap: (2). 
Expect poor performance for suffix "dc=exemple,dc=com". 
57567d77 bdb_monitor_db_open: monitoring disabled; configure  
monitor database to enable config file testing succeeded
Puis, il faut appliquer les bonnes permissions d’accès sur le répertoire de configuration ’/etc/openldap/slapd.d/’, penser à renommer le fichier de configuration ’/etc/openldap/slapd.conf’ pour qu’il ne puisse pas être utilisé en cas de redémarrage du serveur LDAP et éviter ainsi toute sorte de conflits de source de configuration.
mv /etc/openldap/slapd.conf slapd.conf.bkp 
chown -R ldap:ldap /etc/openldap/slapd.d/
Il est désormais possible de démarrer le service serveur LDAP :
service slapd start
Ensuite, créer l’entrée racine de notre DIT :
[root@ldap01]# ldapadd -h localhost -D  
"cn=root,dc=exemple,dc=com" -W 
Enter LDAP Password:  
dn: dc=exemple,dc=com 
dc:  exemple 
objectClass: top 
objectClass: domain 
 
adding new entry "dc=exemple,dc=com"
Et enfin, tester l’annuaire LDAP en consultant l’entrée du suffixe (soit en ligne de commande avec la requête ldapsearch ou bien à l’aide d’un navigateur LDAP) :
[root@ldap01]# ldapsearch -h localhost -D 
"cn=root,dc=exemple,dc=com" -W -b "dc=exemple,dc=com" -s base -LLL 
Enter LDAP Password:  
dn: dc=exemple,dc=com 
dc: exemple 
objectClass: top 
objectClass: domain 
 
[root@ldap01]#
Même si le test précédent est suffisant pour s’assurer du bon fonctionnement de la configuration, il est également possible de visualiser l’état du processus LDAP et de ses connexions réseau :
[root@ldap01 ~]# ps -aef | grep -i slapd 
root      3503  3472  0 10:33 pts/0    00:00:00 grep -i slapd 
ldap     23801     1  0 Apr03 ?        00:45:10 /usr/sbin/slapd 
-h  ldap:/// ldapi:/// -u ldap 
 
[root@ldap01 ~]# netstat -atunp | grep slapd 
tcp        0      0 0.0.0.0:389                 0.0.0.0:*   
                LISTEN      23801/slapd
Ainsi, les commandes précédentes montrent que le processus (slapd) est bien démarré, et écoute sur le port standard LDAP non sécurisé (389/TCP) au travers de toutes les interfaces définies sur le système (0.0.0.0).