Liste de contrôle (checklist)
La liste de contrôle suivante peut aider à identifier un problème ou au moins obtenir une piste d’investigation.
1.	Utiliser l’outil slaptest pour vérifier les configurations avant de démarrer le service "slapd".	
[root@ldap01 cn=config]# slaptest -f slapd.1.conf  
 config file testing succeeded
Exemple d’un problème de configuration :
[root@ldap01 cn=config]# slaptest -f slapd.tmp 
59d777ce slapd.tmp: line 28: unknown directive <xxxxx> inside 
backend database definition. 
slaptest: bad configuration file! 
[root@ldap01 cn=config]#
Exemple en mode "debug" :
[root@ldap01 cn=config]# slaptest -f slapd.1.conf -d 256 
bdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52:  
(December  3, 2003) 
hdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52:  
(December  3, 2003) 
bdb_db_init: Initializing BDB database 
bdb_db_open: db_open(./db.1.a/id2entry.bdb) failed: No such file 
or directory (2) 
backend_startup: bi_db_open failed! (2) 
slap_startup failed (test would succeed using the -u switch)
2.	Si impossibilité de démarrer le service, alors utiliser directement le binaire de l’application en mode "debug".	
/usr/sbin/slapd -d1
Voici un exemple du résultat de cette commande :
# Output 
ldap_url_parse_ext(ldap://localhost/) 
ldap_init: trying /etc/openldap/ldap.conf 
ldap_init: using /etc/openldap/ldap.conf 
ldap_url_parse_ext(ldaps://ldap02.exemple.com:636) 
ldap_url_parse_ext(ldaps://ldap01.exemple.com:636) 
ldap_init: HOME env is /root 
ldap_init: trying /root/ldaprc 
ldap_init: trying /root/.ldaprc 
ldap_init: LDAPCONF env is NULL 
ldap_init: LDAPRC env is NULL 
598463a4 @(#) $OpenLDAP: slapd 2.4.39 (Jun 18 2014 05:19:18) $ 
   mockbuild@x86-028.build.eng.bos.redhat.com:/builddir/build/
BUILD/openldap-2.4.39/openldap-2.4.39/build-servers/servers/slapd 
ldap_pvt_gethostbyname_a: host=testrhel66.localdomain, r=11 
598463a4 daemon_init: listen on ldap:///
Il est également possible de déclencher le mode "debug" au démarrage en spécifiant le paramètre -d dans le fichier /etc/sysconfig/ldap.
3.	Vérifier que le processus "slapd" écoute sur le(s) port(s) spécifié(s) (389 et 636, par défaut) avec la commande :	
[root@ldap01 sbin]# netstat -atunp | grep -i slapd 
tcp     0    0 0.0.0.0:389     0.0.0.0:*     LISTEN      10515/slapd 
tcp     0    0 :::389          :::*          LISTEN      10515/slapd 
[root@ldap01 sbin]#
4.	Effectuer une simple commande telnet depuis un client LDAP afin de valider que la communication réseau est opérationnelle (routage et ouverture de ports sur les pare-feu). Ex. : telnet ldap01 389.	
5.	Ensuite, lancer une simple commande ldapsearch sur le port non sécurisé (si permis) afin de s’affranchir de l’établissement d’une connexion SSL et des problèmes de certificat.	
6.	Hormis les problèmes de mot de passe des utilisateurs de liaison, vérifier que ceux-ci ne sont pas bloqués par des ACL.	
7.	Puis tester avec une commande sécurisée (port 636). En cas d’échec, il faut s’assurer de l’état du certificat du serveur LDAP à l’aide des commandes openssl et également s’assurer que le client LDAP a bien le certificat de type rootca.	
8.	Augmenter le niveau de verbosité des logs du serveur LDAP.	
9.	Consulter le site www.openldap.org et… les moteurs de recherche.	
http://www.openldap.org/lists/#archives 
http://www.openldap.org/faq/