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.
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 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.
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.
TODO : ldconfig
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) [...]
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
Le script d'initialisation est fournit sur le site 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 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 :
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.
L'ensemble des tests présentés ici permettent de tester si le serveur OpenLDAP est opérationnel.
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.
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.
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 :
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
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 <dc=example,dc=com> 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 [...]
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.
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 :
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 :
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 :
TODO
TODO
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 [...]
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
Ce chapitre regroupe un condensé des commandes de maintenance du serveur OpenLDAP.
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.
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 :
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.
Plusieurs outils viennent avec la suite logiciel Berkeley DB, dont les outils db_archive et db_recover.
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
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.
Plusieurs outils viennent avec la suite logiciel OpenLDAP, dont les outils slapcat et slapadd.
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.
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/*
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.
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
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.
Il est possible de réinitialiser à neuf la base LDAP sur serveur OpenLDAP esclave. Cette procédure requiert les conditions OBLIGATOIRES suivantes :
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.
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
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 :
Attention : cette procédure reste très coûteuse en terme de temps de traitement, de fiabilité et d'espace disque.
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 :
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)
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 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