====== Guide d'exploitation OpenLDAP ======
**Ce document est en cours d'écriture.**
Ce chapitre décrit les bases de l'exploitation OpenLDAP. Il se veut non-exhaustif. Des compétences annuaire supplémentaires sont exigées pour une utilisation poussée du logiciel.
La version d'OpenLDAP utilisée est la version 2.3.35. Le système d'exploitation hôte est compatible UNIX.
===== Information système =====
==== Où se trouvent les fichiers ====
De façon générale, OpenLDAP est installé dans /usr/local. Pour le reste du guide, la suite logicielle est disponible dans /usr/local/openldap-2.3.35.
# ls -l /usr/local/openldap-2.3.35
total 9
drwxr-xr-x 2 bin bin 512 Jul 25 09:41 bin
drwxr-xr-x 5 bin bin 512 Jul 25 09:41 etc
drwxr-xr-x 2 bin bin 512 Jul 25 09:41 include
drwxr-xr-x 2 bin bin 512 Jul 25 09:41 lib
drwxr-xr-x 3 bin bin 512 Jul 25 09:41 libexec
drwxr-xr-x 6 bin bin 512 Jul 25 09:41 man
drwxr-xr-x 2 bin bin 512 Jul 25 09:41 sbin
drwxr-xr-x 4 bin bin 512 Jul 25 09:41 src
drwxr-xr-x 4 bin bin 512 Jul 25 09:41 var
Le répertoire //etc// contient trois sous répertoires :
* Le répertoire de configuration nommé //openldap//, dans lequel se trouve le fichier de configuration du serveur : //slapd.conf// ;
* Le répertoire //init.d// qui contient un script de lancement du service OpenLDAP ;
* Le répertoire //default// contient un fichier de configuration du script précédent.
Le répertoire //bin// contient les outils utilisateur d'interrogation LDAP, les outils d'administration sont quant à eux dans le répertoire //sbin//. Les répertoires //include// et //lib// concernent les bibliothèques partagées. Les pages du manuel UNIX sont disponibles dans le répertoire //man//. Enfin, le répertoire //var// contient les données OpenLDAP.
==== Environnement ====
Il est fortement conseillé de fixer les chemins des bibliothèques systèmes, en rajoutant les chemins vers les nouveaux répertoires //lib//. Si ces chemins ne sont pas fixés, il est fort probable qu'OpenLDAP ne démarre pas.
Il n'est pas conseillé de fixer ces chemins via la variable d'environnement LD_LIBRARY_PATH sur des serveurs de production.
=== GNU/Linux ===
TODO : ldconfig
=== Solaris ===
Sur les systèmes Solaris, ceci se fait grâce à la commande **crle**, "l'équivalent" de la commande GNU **ldconfig**.
# rm /var/ld/ld.config
# crle -u
# crle -l /usr/local/BerkeleyDB.4.2/lib \
-l /usr/local/openldap-2.3.35/lib \
-l /usr/local/lib:/usr/lib
# crle
Configuration file [version 4]: /var/ld/ld.config
Default Library Path (ELF): /usr/local/BerkeleyDB.4.2/lib:/usr/local/openldap-2.3.35/lib:/usr/local/lib:/usr/lib
Trusted Directories (ELF): /usr/lib/secure (system default)
[...]
===== Arrêt et démarrage du service =====
==== Le service OpenLDAP est-il disponible ? ====
Le service OpenLDAP est régie par le binaire **slapd**. Il est possible de savoir si ce service est disponible de plusieurs manières. Mais la plus simple reste de regarder dans la liste des processus système :
$ ps -ef | grep slapd
bin 15759 1 0 16:34:13 ? 0:00 /usr/local/openldap-2.3.35/libexec/slapd -h ldap://*:389 \
ldaps://*:636 -f /usr/local/openldap-2.3.35/etc/openldap/slapd.conf
==== Script d'initialisation ====
Le script d'initialisation est fournit sur le site [[http://www.linagora.org|www.linagora.org]]. De façon générale, ce fichier est placé dans le répertoire ///usr/local/openldap-2.3.35/etc/init.d//. Le script se nomme //slapd//.
Ce script peut-être directement copié dans le répertoire ///etc/init.d//. Mais, par soucis de clarté, il est plutôt préférable de le linker symboliquement :
# ln -s /usr/local/openldap-2.3.35/etc/init.d/slapd /etc/init.d/slapd
$ ls -l /etc/init.d/slapd
lrwxrwxrwx 1 root other 43 Jul 25 10:09 /etc/init.d/slapd -> /usr/local/openldap-2.3.35/etc/init.d/slapd
Ce script utilise un fichier de configuration. Il est lui aussi disponible sur le site [[http://www.linagora.org|www.linagora.org]]. Ce fichier est placé dans le répertoire ///usr/local/openldap-2.3.35/etc/default//, et se nomme //slapd//. De la même façon, il est préférable de le linker symboliquement :
# ln -s /usr/local/openldap-2.3.35/etc/default/slapd /etc/default/slapd
$ ls -l /etc/default/slapd
lrwxrwxrwx 1 root other 44 Jul 25 10:09 /etc/default/slapd -> /usr/local/openldap-2.3.35/etc/default/slapd
Le fichier de configuration ///etc/default/slapd// est de la forme suivante :
# IP and port to listen
IP="*"
PORT="636"
# OpenLDAP directory and files
SLAPD_PATH="/usr/local/openldap-2.3.35"
DATA_PATH="auto"
SLAPD_PID_FILE="$SLAPD_PATH/var/slapd.pid"
SLAPD_CONF="$SLAPD_PATH/etc/openldap/slapd.conf"
SLAPD_SERVICES="ldap://$IP:389 ldaps://$IP:$PORT"
SLAPD_PARAMS=""
SLAPD_BIN="$SLAPD_PATH/libexec/slapd"
SLAPD_USER="bin"
SLAPD_GROUP="bin"
SLAPCAT_BIN="$SLAPD_PATH/sbin/slapcat"
SLAPINDEX_BIN="$SLAPD_PATH/sbin/slapindex"
SLAPTEST_BIN="$SLAPD_PATH/sbin/slaptest"
SLURPD_PID_FILE="$SLAPD_PATH/var/slurpd.pid"
SLURPD_PARAMS=""
SLURPD_BIN="$SLAPD_PATH/libexec/slurpd"
# BerkeleyDB directory and files
BDB_PATH="/usr/local/BerkeleyDB.4.2"
DB_ARCHIVE_BIN="$BDB_PATH/bin/db_archive"
DB_RECOVER_BIN="$BDB_PATH/bin/db_recover"
RECOVER_AT_STARTUP="0"
# Backup
BACKUP_AT_SHUTDOWN="0"
BACKUP_PATH="$SLAPD_PATH/var/save"
BACKUP_FILE="$BACKUP_PATH/data_`date +%Y%m%d%H%M%S`.ldif"
BACKUP_SUFFIX="`date +%Y%m%d%H%M%S`.ldif"
# Other
TIMEOUT="30" # Max time to stop process
FD_LIMIT="1024" # Max file descriptor
La majorité des directives de configuration sont compréhensibles, grâce à leurs noms explicites. Voici ce qu'il faut retenir pour celles dont le sens n'est pas évident :
* DATA_PATH contient normalement le chemin du répertoire de données d'OpenLDAP. Cependant, le script d'initialisation est capable de retrouver automatiquement ce chemin, c'est pourquoi il est préférable de fixer la valeur de cette directive à « auto » ;
* SLAPD_SERVICES contient les URIs auxquelles peut répondre OpenLDAP ;
* SLAPD_PARAMS contient des paramètres supplémentaires à passer au serveur OpenLDAP, à savoir ///usr/local/openldap-2.3.35/libexec/slapd//. Le script d'initialisation calcule lui-même ces paramètres, c'est pourquoi cette directive est vide ;
* SLAPD_USER et SLAPD_GROUP sont respectivement l'utilisateur et le groupe sous lesquels le service OpenLDAP va être exécuté. C'est une mesure de sécurité de moyen niveau désormais indispensable sur des serveurs en production ;
* Les directives SLURPD_PID_FILE, SLURPD_PARAMS et SLURPD_BIN sont obsolètes. Elles servent essentiellement pour les serveurs OpenLDAP qui supportent encore la réplication grâce au service slurpd ;
* RECOVER_AT_STARTUP peut prendre comme valeur 0 (inactive) ou 1 (active). Cette directive indique si une restauration des données de l'annuaire doit être effectuée à partir des dernières sauvegardes automatiques effectuées par le script d'initialisation, et ce avant le démarrage du service OpenLDAP. Il est conseillé d'activer cette option uniquement lorsque l'option BACKUP_AT_SHUTDOWN est elle-même aussi activée ;
* BACKUP_AT_SHUTDOWN peut prendre comme valeur 0 (inactive) ou 1 (active). Cette direction indique si une sauvegarde des données de l'annuaire doit être effectuée lors de l'arrêt du service.
==== Mode debug ====
Il est tout à fait possible de démarrer OpenLDAP en mode debug. Dans ce cas, le serveur n'est plus multi-threadé, et ne possède alors plus qu'une seule file d'exécution. De manière générale, le mode debug est associé à un niveau de journalisation du serveur (voir section //journalisation//).
Pour démarrer le serveur en mode debug 255 (niveau recommandé pour tracer les requêtes LDAP) :
# /usr/local/openldap-2.3.35/libexec/slapd -h "ldap:// ldaps://" -d 255
Une simple combinaison de touche « Ctrl + C » permet d'arrêter le serveur.
===== Tests de base =====
L'ensemble des tests présentés ici permettent de tester si le serveur OpenLDAP est opérationnel.
==== Configuration ====
Un outil permettant de vérifier la syntaxe du fichier de configuration est mis à disposition dans OpenLDAP. Le code de retour de l'outil est soit 0 (vrai), soit 1 (faux) :
# /usr/local/openldap-2.3.35/sbin/slaptest
WARNING: No dynamic config support for overlay unique.
config file testing succeeded
# echo $?
0
Si le fichier de configuration //slapd.conf// n'est pas correctement renseigné, une erreur survient et est affichée à l'écran. Par exemple, ici, le répertoire censé contenir les données n'existe pas :
# /usr/local/openldap-2.3.35/sbin/slaptest
WARNING: No dynamic config support for overlay unique.
bdb_db_open: Cannot access database directory /usr/local/Openldap-2.3.35/var/openldap-data (2)
backend_startup_one: bi_db_open failed! (-1)
slap_startup failed (test would succeed using the -u switch)
# echo $?
1
Par défaut, **slaptest** utilise le répertoire ///usr/local/openldap-2.3.35/etc/openldap// comme répertoire de configuration.
==== Connexion ====
Un test de connexion s'effectue généralement par le biais de la commande telnet :
# telnet ldap.example.com 389
Trying 192.168.0.1...
Connected to ldap.example.com (192.168.0.1).
Où ldap.example.com est le nom de machine du système hébergeant le serveur OpenLDAP.
==== Authentification ====
Afin de tester l'authentification sur l'annuaire LDAP, il est possible d'utiliser l'outil **ldapsearch** fournit avec la suite logicielle d'OpenLDAP (ou tout autre équivalent, compatible LDAP).
Le principe est de s'authentifier sur l'annuaire sous le compte d'un utilisateur intégré dans la branche « ou=People » du contexte de nommage de l'annuaire visé, en utilisant la commande ldapsearch. Pour cela, la commande reconnaît quatre options principales :
* L'option « -D » qui permet de spécifier le nom distinctif complet de l'utilisateur LDAP ;
* L'option « -W » qui permettra de renseigner le mot de passe par la suite (et non en ligne de commande) ;
* L'option « -x » qui active une authentification simple, sans passer par la couche SASL ;
* L'option « -b » qui permet de spécifier le nom distinctif de la base de recherche ;
Exemple du authentification échouée :
# ldapsearch -D cn=manager,dc=example,dc=com -W -x -b dc=example,dc=com
[...]
ldap_bind: Invalid credentials (49)
Tandis qu'une authentification réussie renvoi le résultat de la recherche.
Il est tout à fait possible d'initier une telle requête LDAP en sécurisant le flux réseau. Pour cela, la commande **ldapsearch** d'OpenLDAP reconnaît l'option « -Z », qui permet de demander le support TLS vers le serveur OpenLDAP. Si l'on double l'option (« -ZZ »), la requête échoue si le support TLS n'est pas disponible sur le serveur OpenLDAP.
Cependant, il faut que le client connaisse le certificat de l'autorité de certification ayant signée le certificat du serveur OpenLDAP. Ceci ce fait via la directive TLS_CACERT dans le fichier de configuration ///usr/local/openldap-2.3.35/etc/openldap/ldap.conf// :
TLS_CACERT = /usr/local/openldap-2.3.35/etc/openldap/ssl/server.crt
==== Recherche ====
Comme vu dans la section précédente, c'est la commande ldapsearch qui permet d'effectuer des recherches sur l'annuaire LDAP, régi par le serveur OpenLDAP.
Une requête de recherche renvoi toujours une réponse au format LDIF version 1.0 :
# ldapsearch -D cn=manager,dc=example,dc=com -W -x -b dc=example,dc=com
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# example.com
dn: dc=example,dc=com
objectClass: top
objectClass: dcObject
objectClass: organization
dc: example
o: example
description: Annuaire LDAP exemple
# People, example.com
dn: ou=People,dc=example,dc=com
objectClass: top
objectClass: organizationalUnit
ou: People
description: Utilisateurs
[...]
===== Manipulation =====
Avant d'aborder la manipulation de données LDAP, le chapitre précédent est pré-requis. Les options vu dans cette section ne seront pas reprises ici.
==== Recherche d'informations ====
La recherche d'information est effectuée grâce à la commande ldapsearch de la suite logicielle OpenLDAP. Tous les résultats de recherche sont retournés au format LDIF v1. Plusieurs options sont disponibles, en plus des options classiques déjà évoquées plus haut dans les pré-requis de ce chapitre.
Ces options sont essentiellement :
* L'option « -s » spécifie l'étendue de recherche : « base », « one » ou « sub » ;
* Le filtre de recherche LDAP ;
* La liste des attributs recherchés séparés par un espace.
Exemple de recherche :
$ ldapsearch -H ldap://ldap.example.com \
-D uid=test,ou=People,dc=example,dc=com -W -x -b dc=example,dc=com -s sub \
"(&(objectClass=inetOrgPerson)(uid=t*))" uid sn cn +
[...]
Deux caractères spéciaux sont autorisés dans la liste des attributs LDAP :
* Le caractère « * » qui permet de retourner l'ensemble des attributs normaux des entrées trouvées ;
* Le caractères « + » qui permet de retourner l'ensemble des attributs opérationnels des entrées trouvées.
==== Ajout d'informations ====
Avant tout, pour ajouter une entrée dans l'annuaire, il faut que l'utilisateur sous lequel on se loggue ait les droits appropriés (lecture/écriture) sur la base LDAP. Ici, il s'agira pour les exemples de l'utilisateur « cn=manager,dc=example,dc=com ».
L'ajout d'informations s'effectue par le biais de la commande **ldapadd**. Elle prend les mêmes paramètres que la commande **ldapsearch**, et notamment un fichier qui va contenir les données qu'il faut ajouter dans l'annuaire.
Il ne s'agit pas ici de décrire en détail l'écriture de fichier LDIF, ce n'est pas le sujet de ce document. Néanmoins, voici de courts exemples dont le scénario est le suivant :
* Ajouter un nouveau groupe ;
* Ajouter un nouvel utilisateur apparemment au groupe précédemment créé ;
=== Ajouter un nouveau groupe ===
TODO
=== Ajouter un nouvel utilisateur ===
TODO
==== Suppression d'informations ====
Avant tout, pour supprimer une entrée de l'annuaire, il faut que l'utilisateur sous lequel on se loggue ait les droits appropriés (lecture/écriture) sur la base LDAP. Ici, il s'agira pour les exemples de l'utilisateur « cn=manager,dc=example,dc=com ».
Ensuite, la suppression d'entrées LDAP s'effectue par le biais de la commande **ldapdelete**. Cette commande prend à peu de chose près les mêmes options que la commande **ldapsearch**, le dernier paramètre étant le DN qu'il faut supprimer :
$ ldapdelete -H ldap://ldap.example.com -D cn=manager,dc=example,dc=com -W \
-x uid=test,ou=People,dc=example,dc=com
[...]
==== Modification d'informations ====
Avant tout, pour modifier une entrée de l'annuaire, il faut que l'utilisateur sous lequel on se loggue ait les droits appropriés (lecture/écriture) sur l'entrée LDAP. Ici, il s'agira pour les exemples de l'utilisateur « cn=manager,dc=example,dc=com ».
La modification d'informations LDAP s'effectue grâce à la commande **ldapmodify**. Elle prend les mêmes paramètres que la commande **ldapadd**. D'ailleurs, la modification d'information peut s'effectue par le biais de la commande **ldapadd**.
TODO
===== Maintenance =====
Ce chapitre regroupe un condensé des commandes de maintenance du serveur OpenLDAP.
==== Sauvegarde simple ====
Le script d'initialisation permet d'effectuer des sauvegardes et des restaurations automatiques, respectivement au démarrage et à l'arrêt du service (via l'activation des options dans le fichier de configuration associé).
Exemple de sauvegarde :
# /etc/init.d/slapd backup
Attention : La commande de backup ci-dessous ne fonctionne que sous systèmes GNU/Linux, du à des problèmes de compatibilité entre commandes système. A la place, il est possible d'utiliser la sauvegarde manuelle qui effectue à peu de chose près l'opération identique, les vérifications en moins (étant laissé à la charge de l'utilisateur).
Le résultat de la sauvegarde de l'annuaire est alors disponible dans le répertoire de sauvegarde, comme défini dans le fichier de configuration du script d'initialisation, au format LDIF. Le mécanisme de sauvegarde du script d'initialisation utilise la commande OpenLDAP d'administration nommée **slapcat**. Cette commande est utilisable de préférence quand le serveur est hors service.
Il est bien entendu possible d'effectuer une sauvegarde manuelle :
# /usr/local/openldap-2.3.35/sbin/slapcat -l ldapdirectory.backup.ldif
Où l'option « -l » spécifie le fichier qui va recevoir la sauvegarde au format LDIF.
==== Récupérer une base LDAP endommagées ====
Une base LDAP est très fragile. Une telle base est généralement de type Berkeley DB. Il existe plusieurs solutions pour récupérer une base LDAP endommagée :
* Utiliser les outils livrés avec la suite logiciel Berkeley DB ;
* Utiliser les outils livrés avec la suite logiciel OpenLDAP.
Bien entendu, les deux solutions sont totalement différentes. La première tente de réparer brutement les fichiers de données, tandis que la seconde effectuera la restauration d'une sauvegarde précédemment effectuée. Il est recommandé d'effectuer la seconde solution, beaucoup plus fiable et pertinente, combinées avec quelques options qui seront explicitées plus loin.
=== Utilisation des outils Berkeley DB ===
Plusieurs outils viennent avec la suite logiciel Berkeley DB, dont les outils **db_archive** et **db_recover**.
== Archivage de la base LDAP ==
Comme pré-requis, il faut stopper le serveur LDAP. Ensuite, la première chose à faire est de forcer un « checkpoint » de la base. Cette manipulation permet d'indiquer au système de copier les données en mémoire vers les fichiers du disque.
# /usr/local/BerkeleyDB.4.2/bin/db_checkpoint -1 \
-h /usr/local/openldap-2.3.35/var/openldap-data/
Le répertoire ///usr/local/openldap-2.3.35/var/openldap-data// contient les fichiers de la base LDAP. Ensuite, il s'agit d'archiver la base LDAP, au sens Berkeley DB du terme :
# /usr/local/BerkeleyDB.4.2/bin/db_archive -s \
-h /usr/local/openldap-2.3.35/var/openldap-data/
Maintenant, il est possible de sauvegarder les fichiers de la base LDAP. Par exemple, dans le répertoire ///usr/local/openldap-2.3.35/var/backup// :
# mkdir /usr/local/openldap-2.3.35/var/backup-data
# cp -p /usr/local/openldap-2.3.35/var/openldap-data/*db.00* \
/usr/local/openldap-2.3.35/var/backup-data
# cp -p /usr/local/openldap-2.3.35/var/openldap-data/*.bdb \
/usr/local/openldap-2.3.35/var/backup-data
Les fichiers journaux doivent être archivés et copiés. Ils recensent toutes les transactions LDAP :
# mkdir /usr/local/openldap-2.3.35/var/backup-log
# /usr/local/BerkeleyDB.4.2/bin/db_archive -l \
-h /usr/local/openldap-2.3.35/var/openldap-data/
# cp -p /usr/local/openldap-2.3.35/var/openldap-data/log.0000000001 \
/usr/local/openldap-2.3.35/var/backup-log
== Restauration de la base à partir des archives ==
Pour restaurer les données de la base depuis une sauvegarde précédente, suivant la méthode décrite plus haut, il faut utiliser l'outil **db_recover**. Comme pré-requis, il faut veiller à ce que le serveur LDAP ne soit pas démarré (ici d'un crash par exemple).
Tout d'abord, il s'agit de restaurer les fichiers de données précédemment sauvés :
# cp -p /usr/local/openldap-2.3.35/var/backup-data/*db.00* \
/usr/local/openldap-2.3.35/var/openldap-data/
# cp -p /usr/local/openldap-2.3.35/var/backup-data/*.bdb \
/usr/local/openldap-2.3.35/var/openldap-data/
Il faut ensuite restaurer les fichiers journaux de transaction :
# cp -p /usr/local/openldap-2.3.35/var/openldap-log/log.0000000001 \
/usr/local/openldap-2.3.35/var/openldap-data
Pour le moment, les fichiers ont juste été replacés au bon endroits. Il faut maintenant les « formater » :
# /usr/local/BerkeleyDB.4.2/bin/db_recover -c \
-h /usr/local/openldap-2.3.35/var/openldap-data/
# chown bin:bin /usr/local/openldap-2.3.35/var/openldap-data/*
Où « bin » est à la fois l'utilisateur et le groupe sous lequel le serveur OpenLDAP démarre.
La base a normalement été reconstruite. Il suffit de démarrer le serveur LDAP pour s'en assurer.
=== Utilisation des outils OpenLDAP ===
Plusieurs outils viennent avec la suite logiciel OpenLDAP, dont les outils **slapcat** et **slapadd**.
== Archivage de la base LDAP ==
Comme pré-requis, il faut stopper le serveur LDAP. Ensuite, il suffit d'effectuer la commande suivante :
# /usr/local/openldap-2.3.35/sbin/slapcat \
-f /usr/local/openldap-2.3.35/etc/openldap/slapd.conf
-l /usr/local/openldap-2.3.35/var/backup.ldif
[...]
Cette commande extrait toutes les données LDAP au format LDIF, vers le fichier //backup.ldif//.
== Restauration de la base à partir des archives ==
Comme pré-requis, il faut stopper le serveur LDAP, et avoir une sauvegarde effectuée grâce à la commande **slapcat**. Ensuite, il est supposé que la base LDAP est détruite.
Par simplicité, il faut supprimer les fichiers, excepté le fichier critique DB_CONFIG :
# cd /usr/local/openldap-2.3.35/var/openldap-data
# mv DB_CONFIG ../
# rm -f *
# mv ../DB_CONFIG ./
Ensuite, il suffit d'effectuer la commande suivante :
# /usr/local/openldap-2.3.35/sbin/slapadd \
-f /usr/local/openldap-2.3.35/etc/openldap/slapd.conf \
-l /usr/local/openldap-2.3.35/var/backup.ldif
# chown bin:bin /usr/local/openldap-2.3.35/var/openldap-data/*
Où « bin » est à la fois l'utilisateur et le groupe sous lequel le serveur OpenLDAP démarre.
Le processus peut être long, car les fichiers de transaction sont aussi reconstruits. Il est possible d'outrepasser cette étape en spécifiant l'option supplémentaire « -q ». De plus, il est possible que quelque requête LDAP échoue. Dans ce cas précis, le comportement par défaut est de quitter le processus de restauration à la première erreur. Il est possible d'outrepasser cette étape en spécifiant l'option supplémentaire « -c ».
Exemple :
# /usr/local/openldap-2.3.35/sbin/slapadd \
-f /usr/local/openldap-2.3.35/etc/openldap/slapd.conf \
-l /usr/local/openldap-2.3.35/var/backup.ldif \
-c -q
# chown bin:bin /usr/local/openldap-2.3.35/var/openldap-data/*
==== Ré-indexation de la base LDAP ====
L'indexation permet à OpenLDAP d'optimiser les temps de recherches. En effet, OpenLDAP maintient un index en RAM, une sorte de table de hachage vers les données sur le disque. La ré-indexation permet essentiellement de reconstruire à neuf l'index en RAM, avec éventuellement de nouveaux critères d'indexation. Cette manipulation est justement nécessaire après une restauration de données sans journalisation (où l'option « -q » est passée dans la commande slapadd). Tout se base sur le fichier de configuration du serveur OpenLDAP, //slapd.conf//.
La commande ci-dessous permet de ré-indexer la base LDAP, alors que le serveur OpenLDAP est arrêté :
# /usr/local/openldap-2.3.35/sbin/slapindex \
-f /usr/local/openldap-2.3.35/etc/openldap/slapd.conf
# chown bin:bin /usr/local/openldap-2.3.35/var/openldap-data/*
Où « bin » est à la fois l'utilisateur et le groupe sous lequel le serveur OpenLDAP démarre.
==== Volumétrie des données ====
La volumétrie des données peut être estimée par la commande **db_stat** de la suite logiciel BerkeleyDB :
$ /usr/local/Berkeley/bin/db_stat \
-h /usr/local/openldap-2.3.35/var/openldap-data -m
320MB 2KB 912B Total cache size.
1 Number of caches.
320MB 8KB Pool individual cache size.
0 Requested pages mapped into the process' address space.
1381 Requested pages found in the cache (99%).
8 Requested pages not found in the cache.
0 Pages created in the cache.
8 Pages read into the cache.
0 Pages written from the cache to the backing file.
0 Clean pages forced from the cache.
0 Dirty pages forced from the cache.
0 Dirty pages written by trickle-sync thread.
8 Current total page count.
0 Current clean page count.
8 Current dirty page count.
32771 Number of hash buckets used for page location.
1397 Total number of times hash chains searched for a page.
1 The longest hash chain searched for a page.
1381 Total number of hash buckets examined for page location.
68651 The number of hash bucket locks granted without waiting.
0 The number of hash bucket locks granted after waiting.
0 The maximum number of times any hash bucket lock was waited for.
58 The number of region locks granted without waiting.
0 The number of region locks granted after waiting.
25 The number of page allocations.
0 The number of hash buckets examined during allocations
0 The max number of hash buckets examined for an allocation
0 The number of pages examined during allocations
0 The max number of pages examined for an allocation
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pool File: uid.bdb
4096 Page size.
0 Requested pages mapped into the process' address space.
118 Requested pages found in the cache (98%).
2 Requested pages not found in the cache.
0 Pages created in the cache.
2 Pages read into the cache.
0 Pages written from the cache to the backing file.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pool File: objectClass.bdb
4096 Page size.
0 Requested pages mapped into the process' address space.
643 Requested pages found in the cache (100%).
2 Requested pages not found in the cache.
0 Pages created in the cache.
2 Pages read into the cache.
0 Pages written from the cache to the backing file.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pool File: dn2id.bdb
4096 Page size.
0 Requested pages mapped into the process' address space.
436 Requested pages found in the cache (100%).
2 Requested pages not found in the cache.
0 Pages created in the cache.
2 Pages read into the cache.
0 Pages written from the cache to the backing file.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Pool File: id2entry.bdb
16384 Page size.
0 Requested pages mapped into the process' address space.
184 Requested pages found in the cache (99%).
2 Requested pages not found in the cache.
0 Pages created in the cache.
2 Pages read into the cache.
0 Pages written from the cache to the backing file.
Cette commande permet de constater qu'OpenLDAP utilise effectivement tout le cache alloué par la directive //set_cachesize// du fichier ///usr/localopenldap-2.3.35/var/openldap-data/DB_CONFIG//.
La commande **du** permet d'évaluer la taille du répertoire de données, en octets :
$ du -k /usr/local/openldap-2.3.35/var/openldap-data
3150 /usr/local/openldap-2.3.35/var/openldap-data
==== Vérifier la réplication des données ====
Il est possible de vérifier que la réplication s'effectue correctement, suivant l'intervalle de temps indiqué dans le fichier de configuration sur le serveur esclave.
Pour vérifier que les données sont bien à jour, il faut récupérer un attribut particulier sur le noeud du contexte de nommage de la base LDAP. Il s'agit de l'attribut contextCSN maintenu par OpenLDAP. Pour information, chaque entrée contient un attribut entryCSN indiquant l'état de changement de l'entrée. L'attribut contextCSN contient la valeur contenu dans l'attribut entryCSN qui correspond à l'entrée modifiée la plus récente.
Le but est donc de récupérer les « contextCSN » des deux annuaires (ldap1 et ldap2) puis de comparer les deux valeurs. Les commandes ci-dessous indiquent si les deux annuaires sont en phases ou non :
# ldapsearch -LLL -H ldap://ldap1 -x -b dc=example,dc=com \
-s base contextCSN > ldap1.csn
# ldapsearch -LLL -H ldap://ldap2 -x -b dc=example,dc=com \
-s base contextCSN > ldap2.csn
# diff ldap1.csn ldap2.csn
Si la commande **diff** renvoi quelque chose, alors les deux annuaires ne sont pas synchronisés.
==== Réinitialisation complète de la base LDAP du serveur esclave ====
Il est possible de réinitialiser à neuf la base LDAP sur serveur OpenLDAP esclave. Cette procédure requiert les conditions OBLIGATOIRES suivantes :
* Le serveur OpenLDAP maître est démarré ;
* La réplication entre le serveur maître et le serveur esclave fonctionne déjà.
Une fois ces conditions vérifiée, il suffit d'effectuer les commandes suivantes :
# /etc/init.d/slapd stop
# rm -f /usr/local/openldap-2.3.35/var/openldap-data/*.*
# rm -f /usr/local/openldap-2.3.35/var/openldap-data/alock
# /etc/init.d/slapd start
La réplication des données depuis le serveur maître peut prendre quelques minutes suivant l'importance de la base LDAP maître.
Cette procédure n'est pas applicable sur le serveur OpenLDAP maître.
===== Journalisation =====
==== Généralités ====
Le serveur OpenLDAP a la capacité de tracer l'ensemble des actions qu'il effectue, et d'envoyer ces traces vers un serveur de journalisation (syslog, syslog-ng, ksyslog, etc...). Cette fonctionnalité doit cependant être activée à la compilation des binaires OpenLDAP. Par défaut, celle-ci est activée si les bibliothèques de journalisation système sont trouvées.
Le mécanisme de journalisation OpenLDAP s'intègre à la journalisation système, par le biais du niveau Syslog //local4//. Un serveur compatible syslog est alors facilement configurable pour journaliser les activités d'OpenLDAP. Dans le fichier ///etc/syslog.conf// du service syslogd, il est possible de fixer la directive suivante :
local4.* -/var/log/slapd
Le niveau de verbosité est paramétrable par le biais du fichier de configuration du serveur OpenLDAP, //slapd.conf//. Ce niveau est en tout point similaire au niveau que l'on fixe lorsque l'on souhaite démarrer le serveur OpenLDAP en mode debug. Le tableau ci-dessous regroupe l'ensemble des niveaux possibles, sachant que l'on peut les additionner.
^ Niveau ^ Description ^
| -1 | Journalisation maximale |
| 0 | Pas de journalisation |
| 1 | Trace les appels de fonctions |
| 2 | Trace les paquets LDAP |
| 4 | Trace les actions |
| 8 | Trace les connexions |
| 16 | Affiche les paquets reçus et envoyés |
| 32 | Trace le parseur des filtres de recherche |
| 64 | Trace le parseur du fichier de configuration |
| 128 | Trace le module ACL |
| 265 | Statistiques sur les connexions, opérations, et résultats |
| 512 | Statistiques sur les entrées LDAP retournées |
| 1024 | Affiche les communications avec les backends de scripts (Shell, Perl) |
| 2048 | Trace le parseur d'entrées LDAP |
Ces niveaux peuvent être additionnées entre eux. Par exemple, le niveau 296 active les niveaux 256, 32 et 8. Ces niveaux sont des puissances de deux, les additions se font donc bit à bit, il n'y a pas de confusions.
Une valeur spéciale existe pour le champ //loglevel// du fichier slapd.conf: **none**. Ce niveau affiche seulement les messages à haute priorité, qui sont affichés quelque soit le niveau de log. Attention, //loglevel none// n'est pas équivalent à //loglevel 0// - ce dernier supprime toute sortie.
La directive de journalisation //loglevel// d'OpenLDAP doit être placée avant la déclaration des backends, dans le fichier //slapd.conf// du serveur OpenLDAP :
loglevel 256
==== Tracer les authentifications ====
Les logs d'OpenLDAP permettent de tracer les authentifications. Mais ils peuvent s'avérer beaucoup trop bavards. Ainsi, en pratique, ce genre d'opération s'effectue en mettant en oeuvres deux mécanismes :
* Fixer le niveau de traces dans le fichier //slapd.conf//, grâce à la directive //loglevel// ;
* Parser en temps réel ces logs pour tracer simplement les authentifications, grâce à un script.
Attention : cette procédure reste très coûteuse en terme de temps de traitement, de fiabilité et d'espace disque.
=== Fixer le niveau de traces ===
Le niveau de traces à fixer est le niveau 256. Il permet de tracer les requêtes d'authentification :
conn=1 fd=14 ACCEPT from IP=192.168.0.10:34700 (IP=0.0.0.0:389)
conn=1 op=0 BIND dn="uid=mtest,ou=people,dc=example,dc=com" method=128
conn=1 op=0 BIND dn="uid=mtest,ou=People,dc=example,dc=com" mech=SIMPLE ssf=0
conn=1 op=0 RESULT tag=97 err=0 text=
[...]
conn=1 op=2 UNBIND
conn=1 fd=14 closed
L'extrait ci-dessus est un exemple de connexion LDAP non sécurisée réussie. Cette opération est tracée par quatre lignes distinctes indiquant :
* Les adresses IP source et destination, respectivement le client à l'origine de l'authentification et le serveur qui doit recevoir la requête ;
* Le nom distinctif complet de l'entrée LDAP correspondant à l'utilisateur en cours d'authentification ;
* Le mécanisme utilisé pour l'authentification (simple, SASL, Kerberos, etc...) ;
* L'erreur renvoyée par le serveur : 0 indique que l'authentification a réussie, une valeur supérieur à 0 indique qu'une erreur est survenue lors de l'authentification.
L'extrait ci-dessous illustre une authentification qui a échouée :
conn=2 fd=14 ACCEPT from IP=192.168.0.10:34701 (IP=0.0.0.0:389)
conn=2 op=0 BIND dn="uid=mtest,ou=people,dc=example,dc=com" method=128
conn=2 op=0 RESULT tag=97 err=49 text=
conn=2 fd=14 closed (connection lost)
=== Parser le log LDAP en temps réel via syslog-ng ===
Syslog n'est pas capable d'associer une action à un événement de log. Mais le service Syslog-NG l'autorise, par l'appel de script si nécessaire. La configuration de Syslog-NG se trouve dans le fichier ///etc/syslog-ng.conf//, de façon générale. Pour le cas présent, il s'agit d'ajouter les lignes suivantes :
# Destination section
destination d_openldap {
program("/usr/local/openldap-2.3.35/utils/slapd-syslog-ng.sh \
> /var/log/slapd-auth");
};
# Log section
log {
source(local);
filter(f_local4);
destination(d_openldap);
};
Deux choses importantes à retenir :
* Le chemin vers le script qui va travailler le log doit être juste, et ne doit pas « crasher » à cause d'une éventuelle erreur de programmation ;
* Le répertoire contenant le fichier de destination doit exister.
Le mécanisme est simple. Syslog-NG, lors de son chargement, va charger en mémoire le script, qui doit lire indéfiniment sur son entrée standard les logs. Si le script « crashe » pour une quelconque raison, celui-ci ne sera pas relancé.
Le script slapd-syslog-ng.sh ressemble à ceci (non parfait :) :
#!/bin/sh
LOG_CMD="/usr/bin/logger -p local0.info"
current_time=""
previous_time=""
current_conn=-1
previous_conn=-1
while read LINE
do
user_authenticated="failed "
previous_conn="${current_conn}"
current_user=""
current_conn="`echo \"${LINE}\" \
| sed -e 's/.*\(conn=\([0-9][0-9]*\)\).*/\2/'`"
if [ "`echo \"${LINE}\" | grep 'IP='`" ]; then
current_ip="`echo \"${LINE}\" \
| sed -e 's/.*from IP=\([0-9][0-9\.]*\).*/\1/'`"
fi
if [ "`echo \"${LINE}\" | grep 'BIND' | grep 'dn='`" ]; then
current_user="`echo ${LINE} | sed -e 's/.*\(dn=\"\(.*\)\"\).*/\2/'`"
read LINE
if [ "`echo \"${LINE}\" | grep 'BIND' | grep 'mech='`" ]; then
user_authenticated="successed"
fi
fi
if [ "${current_conn}" = "${previous_conn}" ] && [ "${current_user}" ]; then
current_infos="`echo \"${LINE}\" \
| sed -e 's/<.*>//;s/\(.*\) conn=.*/\1/'`"
previous_time="${current_time}"
current_time="`echo \"${current_infos}\" | cut -d ' ' -f 1-3`"
if [ "${current_time}" != "${previous_time}" ] \
|| [ "${current_user}" != "${previous_user}" ]
then
${LOG_CMD} "${current_infos} authentication " \
"${user_authenticated} for ${current_user} " \
from ${current_ip}"
fi
previous_user="${current_user}"
fi
done
Il ne reste plus qu'à redémarrer le service syslog-ng :
# /etc/init.d/syslog-ng stop
# /etc/init.d/syslog-ng start