Le stockage des mots de passe
Les mots de passe des utilisateurs stockés dans l’annuaire LDAP sont généralement contenus dans l’attribut userPassword.
Cet attribut peut exister localement dans l’annuaire LDAP où se trouve l’utilisateur, ou bien faire référence à un attribut userPassword distant situé sur un autre annuaire LDAP grâce au mécanisme PTA.
De plus, cet attribut étant bien entendu très sensible en termes de sécurité, car confidentiel et propre à chaque utilisateur, il devient donc important de le chiffrer afin de le cacher aux yeux de toutes personnes y compris du "Super LDAP administrateur".
En effet, il n’est pas obligatoire, mais fortement conseillé de choisir de le chiffrer par un algorithme de type "empreinte cryptographique" qui est indéchiffrable, car irréversible : aucune clé n’existe pour le déchiffrer.
Ainsi, l’annuaire LDAP ne conservera que l’empreinte du mot de passe appelé "hash", "hashing" ou bien "condensé" du mot de passe.
L’annuaire OpenLDAP permet dans son schéma de contenir des condensés de type SHA, MD5 et d’autres. Il utilise par défaut SSHA qui est jusqu’à présent le plus robuste.
¬
Attention : OpenLDAP, par défaut, ne condense pas les mots de passe qui lui sont transmis en clair. En effet, il accepte les condensés transmis par les clients LDAP, mais lui n’en générera pas. À moins de le forcer au travers d’une politique de mot de passe via l’attribut olcPPolicyHashCleartext = TRUE (cf. chapitre traitant des overlays).
¬
Même en étant connecté en "Super LDAP administrateur" souvent nommé cn=root, il est impossible d’avoir accès à la valeur de l’attribut userPassword, car l’annuaire ne stocke que l’empreinte des mots de passe.
1. Rappel sur les algorithmes de cryptage de type condensé
Il existe deux types d’algorithmes de cryptage : ceux dont le message initial est brouillé, mais peut être ensuite décrypté, et ceux dont le brouillage est à sens unique et donc non réversible. Ces derniers sont généralement nommés "empreinte, condensé ou hash(ing)".
Celui utilisé pour stocker les mots de passe dans les annuaires OpenLDAP est de type "empreinte", et est donc impossible à déchiffrer puisqu’aucune clé de déchiffrement n’existe. Ainsi, dans le cadre de l’authentification d’un utilisateur par un mot de passe, il serait inutile de déchiffrer le mot de passe reçu pour ensuite le comparer avec celui contenu dans l’annuaire... car la seule comparaison de leurs empreintes suffit.
Cependant, des types d’attaques ont tout de même été élaborés pour "casser" ces algorithmes de cryptage. Ainsi, l’attaque de pré-image consiste par exemple à trouver une méthode d’inversion de l’algorithme. L’attaque dite de "collision" consiste à trouver une faille en montrant que deux fichiers sources différents produisent la même empreinte... Cette attaque sert donc uniquement à discréditer l’algorithme, pas à trouver la chaîne de caractères ou le fichier source.
Il existe cependant une autre méthode pour tenter de cracker une empreinte de mot de passe consistant à comparer les empreintes "volées" avec des empreintes connues.
En effet, ce type d’algorithme étant disponible publiquement, il convient donc une fois l’empreinte du mot de passe récupérée et l’algorithme de cryptage identifié, d’utiliser "l’attaque par dictionnaire" ou "l’attaque par force brute" qui consiste à utiliser des mots du dictionnaire ou composés aléatoirement et de les condenser par l’algorithme de cryptage identifié pour ensuite, les comparer avec l’empreinte du mot de passe recherché... Si l’empreinte est la même, alors le mot de passe est trouvé !
Autant dire que cette technique peut prendre extrêmement de temps... mais cela peut évidemment être réduit en fonction de la capacité de traitement de l’infrastructure informatique utilisée pour cette tâche.
Une autre technique consiste à utiliser les rainbow tables ou autrement dit les "tables arc-en-ciel" qui contiennent un référencement d’empreintes de mot de passe triés par algorithme d’empreinte. Et ainsi, il "suffit" d’entrer la chaîne de caractères condensée et de voir si le mot de passe y est référencé.
Afin de contrer ce type d’attaques, de nouveaux algorithmes de condensé ont été développés avec la technique de "salage" qui consiste à associer une chaîne de caractères (appelé "grain de sel") au mot de passe d’origine avant de le passer dans l’algorithme de hachage, cela donnera donc une empreinte qui sera différente pour un même mot de passe.
¬
Ce "salage" n’est pas identifiable à partir de l’empreinte et doit donc être géré par l’application stockant les empreintes.
2. Revue des fonctions de hachage supportées par OpenLDAP
Voici dans cette section, une présentation des algorithmes d’empreinte supportés par OpenLDAP. Il y aura donc les algorithmes utilisés pour condenser les mots de passe des utilisateurs et stocker cette valeur dans l’attribut userPassword de l’utilisateur, et une présentation/configuration du mécanisme PTA qui renseigne dans ce même attribut une référence à un autre annuaire LDAP en lieu et place de l’empreinte du mot de passe. C’est ce dernier qui effectuera donc l’authentification de l’utilisateur LDAP.
a. CRYPT
C’est la méthode de hachage standard utilisée par les systèmes UNIX/LINUX pour stocker les mots de passe dans le fichier "/etc/passwd".
Ce n’est donc pas le plus fiable, mieux vaut éviter de l’employer… cependant il présente le réel avantage d’être utilisé en cas de transfert de mots de passe de comptes utilisateurs UNIX/Linux depuis ou vers notre annuaire sans connaître les mots de passe en clair.
b. MD5
Cet algorithme code sous une forme en base64 sur 128 bits ou 32 caractères.
echo -n secret | md5sum 
5ebe2294ecd0e0f08eab7690d2a6ee69
Bien que plus sûr que le stockage en clair et très rapide, l’algorithme MD5 n’est plus fiable depuis qu’une faille de collision a été découverte par des cryptanalystes chinois. Ainsi, son utilité réside dans la génération d’empreintes de fichiers permettant de vérifier l’intégrité et la non altération de données téléchargées.
De plus, étant donné qu’il n’y a pas de sel, cette fonction est vulnérable à une attaque par dictionnaire ou par les tables arc-en-ciel.
c. SMD5
Même fonction que le MD5, mais avec l’ajout d’une chaîne de caractères dit technique du "grain de sel", qui permet de contrer les attaques par dictionnaire.
L’empreinte précédente de "secret" en MD5 devient donc en SMD5 :
f3363e0485343b8e5dada99fe4027b9 
Avec comme ’grain de sel’ : fd4ecc5fc5b08bc8
Résultat : plus efficace que le MD5 classique, mais possédant la même faille que celui-ci, il est aussi à éviter dans le cadre de création d’empreintes de mots de passe.
d. SHA "Secure Hash Algorithm"
C’est une fonction d’empreinte plus récente que MD5, inspiré de celui-ci et plus fiable. Il en existe plusieurs versions : SHA-0, SHA-1, SHA-2 et dernièrement SHA-3.
La dernière version d’OpenLDAP supporte les deux algorithmes de hachage : SHA-1 et SHA-2.
SHA-2 comprend quatre types de hash : SHA-224, SHA-256, SHA-384 et SHA-512.
La différence entre ces versions est bien entendu une sécurité plus importante due à la taille de l’empreinte obtenue. Ainsi, le SHA-256 générera par exemple une empreinte de 256 bits (soit 64 caractères hexadécimaux) alors que le SHA-512 générera une empreinte de 512 bits (soit 128 caractères hexadécimaux).
Bien qu’aucune attaque de type collision ou pré-image n’a été découverte depuis la version SHA-1, il présente la faiblesse d’être vulnérable aux attaques par dictionnaire ou par les Rainbow table.
[root@ldap01 bin]# ls -lrt | grep -i sha 
-rwxr-xr-x. 1 root root      41568 Jan 24  2014 sha512sum 
-rwxr-xr-x. 1 root root      41568 Jan 24  2014 sha384sum 
-rwxr-xr-x. 1 root root      41576 Jan 24  2014 sha256sum 
-rwxr-xr-x. 1 root root      41576 Jan 24  2014 sha224sum 
-rwxr-xr-x. 1 root root      37408 Jan 24  2014 sha1sum 
Voici l’empreinte du mot "secret" en SHA-1 :
echo -n "secret" | sha1sum 
e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4
e. SSHA
Cet algorithme est la version "grain de sel" de SHA. Ainsi, il permet de contrer les attaques par dictionnaire ou par les Rainbow tables. En effet, cet algorithme ajoute une chaîne de caractères aléatoire à la suite de la chaîne de caractères que l’on veut condenser et l’on obtient donc une empreinte différente pour la même chaîne de caractères source.
Toujours avec le mot "secret", l’algorithme SSHA donne l’empreinte suivante :
7788198cd81770d648a0285d83f021d564f66c3f 
Avec comme ’grain de sel’ : b217e0972922cdf4
¬
SSHA est ainsi considéré comme le plus sûr moyen de condenser un mot de passe et est donc utilisé dans la plupart des annuaires LDAP (dont OpenLDAP) comme algorithme d’empreinte de mot de passe par défaut.
f. PTA
L’authentification par délégation (Pass-Through Authentication) n’est donc pas une fonction d’empreinte, mais un mécanisme utilisé par certains répertoires LDAP pour déléguer les opérations d’authentification des utilisateurs à d’autres annuaires, et plus particulièrement aux serveurs Active Directory.
Ce mécanisme existe depuis la version OpenLDAP 2.0 et permet aux utilisateurs d’une organisation de ne posséder qu’une seule et unique accréditation de type "utilisateur/mot de passe" (même si d’un point de vue technique, cela n’est pas vrai).
Ainsi cette configuration devient très pratique dans la réalité, car elle permet d’interconnecter un serveur d’annuaire OpenLDAP à un annuaire Windows Active Directory, et de conserver si besoin des mots de passe utilisateurs similaires.
Ce type d’authentification est donc purement transparent pour les clients LDAP qui n’ont aucune connaissance de ces annuaires intermédiaires ou complémentaires, contrairement aux mécanismes de référents où le client LDAP reçoit, de la part de l’annuaire contacté, les "coordonnées" de l’annuaire à joindre.
Même si ce mécanisme s’appuie sur les librairies SASL, il doit être distingué des méthodes d’authentification externes, qui sont, elles, gérées par le client LDAP pour s’authentifier sur une source fiable pour ensuite se connecter à l’annuaire.
¬
Figure 10-4 : Présentation du service PTA
3. Configuration du service PTA
Cette section va permettre de présenter la configuration du service PTA sur un serveur OpenLDAP. Pour cela, l’architecture LDAP de démonstration située dans le Datacenter devra permettre aux administrateurs d’utiliser les mêmes mots de passe que ceux utilisés pour se connecter à leurs applications habituelles. Ainsi, ils auront l’impression d’utiliser un seul et même compte de connexion.
Afin de pouvoir utiliser les mots de passe de l’Active Directory situé en dehors du Datacenter, OpenLDAP offre la possibilité d’utiliser le mécanisme d’authentification PTA qui permet de déléguer l’authentification des mots de passe à un autre serveur LDAP.
Pour ce faire, il faut tout d’abord s’assurer que la version du serveur OpenLDAP installé a bien été compilée avec l’option suivante :
./configure --enable-spasswd
Si l’installation a été réalisée à partir de packages issus d’une distribution (ex. : openldap-servers-2.4.39-8.el6.x86_64 pour un Red Hat version 6 en 64 bits) alors il est possible de s’assurer de la capacité du serveur OpenLDAP à gérer le mécanisme PTA en listant les bibliothèques partagées qu’utilise le binaire "slapd".
[root@ldap01 etc]# ldd /usr/sbin/slapd 
linux-vdso.so.1 =>  (0x00007fffc553a000) 
libldap_r-2.4.so.2 => /lib64/libldap_r-2.4.so.2 (0x00007f6ca1ea7000) 
liblber-2.4.so.2 => /lib64/liblber-2.4.so.2 (0x00007f6ca1c98000) 
libltdl.so.7 => /usr/lib64/libltdl.so.7 (0x00007f6ca1a8e000) 
libdb-4.7.so => /lib64/libdb-4.7.so (0x00007f6ca171a000) 
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x00007f6ca1500000) 
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f6ca12c8000) 
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007f6ca10ae000) 
libssl3.so => /usr/lib64/libssl3.so (0x00007f6ca0e6f000) 
libsmime3.so => /usr/lib64/libsmime3.so (0x00007f6ca0c42000) 
libnss3.so => /usr/lib64/libnss3.so (0x00007f6ca0903000) 
libnssutil3.so => /usr/lib64/libnssutil3.so (0x00007f6ca06d7000) 
libplds4.so => /lib64/libplds4.so (0x00007f6ca04d2000) 
libplc4.so => /lib64/libplc4.so (0x00007f6ca02cd000) 
libnspr4.so => /lib64/libnspr4.so (0x00007f6ca008f000) 
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f6c9fe71000) 
libwrap.so.0 => /lib64/libwrap.so.0 (0x00007f6c9fc66000) 
libc.so.6 => /lib64/libc.so.6 (0x00007f6c9f8d2000) 
libdl.so.2 => /lib64/libdl.so.2 (0x00007f6c9f6cd000) 
libfreebl3.so => /lib64/libfreebl3.so (0x00007f6c9f454000) 
libz.so.1 => /lib64/libz.so.1 (0x00007f6c9f23e000) 
librt.so.1 => /lib64/librt.so.1 (0x00007f6c9f035000) 
/lib64/ld-linux-x86-64.so.2 (0x00007f6ca25bc000) 
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f6c9ee1c000)
Dans l’exemple ci-dessus, le démon "slapd" est lié à la bibliothèque partagée libsasl2.so.2.
En cherchant le package qui a installé cette bibliothèque, nous découvrirons qu’il s’agit du  package "cyrus-sasl" qui installe également le service "saslauthd" utilisé pour l’authentification via des mécanismes SASL, dont le PTA.
[root@ldap01~]# find / -name libsasl2.so.2 
/usr/lib64/libsasl2.so.2 
 
[root@ldap01~]# rpm -qf /usr/lib64/libsasl2.so.2 
cyrus-sasl-lib-2.1.23-15.el6.x86_64 
 
[root@ldap01~]# rpm -qa | grep -i cyrus 
cyrus-sasl-lib-2.1.23-15.el6.x86_64 
cyrus-sasl-gssapi-2.1.23-15.el6.x86_64 
cyrus-sasl-2.1.23-15.el6.x86_64 
 
[root@ldap01~]# rpm -ql cyrus-sasl-2.1.23-15.el6.x86_64 
/etc/rc.d/init.d/saslauthd 
/etc/sysconfig/saslauthd 
/usr/lib64/sasl2 
/usr/sbin/pluginviewer 
/usr/sbin/saslauthd 
/usr/sbin/testsaslauthd
a. Configuration du service saslauthd
¬
Figure 10-5 : Interaction entre les services saslauthd et slapd
La figure 10-5 montre que le serveur OpenLDAP s’appuie sur le service "saslauthd" afin de contacter le serveur Active Directory.
Il convient donc désormais de configurer le service "saslauthd" et pour ce faire, il existe deux fichiers à configurer :
	•	Le fichier /etc/sysconfig/saslauthd qui permet de configurer les informations de base du service "saslauthd" telles que les fichiers pid ou socket du processus, le mécanisme SASL à utiliser pour joindre l’annuaire, et des options tel que l’activation du "caching" ou bien du mode "debug".
	•	Et le fichier /etc/saslauthd.conf qui contiendra les informations de connexion afin d’accéder à l’annuaire.
Voici ci-dessous un exemple de fichier de configuration du service "saslauthd" qui désignera le mécanisme "ldap" comme mécanisme "sasl" à utiliser pour joindre les serveurs Active Directory, configuré en mode "caching" avec une expiration du mot de passe de 604 800 secondes correspondant à 7 jours.
[root@ldap01~]# cat /etc/sysconfig/saslauthd 
# Directory in which to place saslauthd’s listening socket,  
pid file, and so on.  This directory must already exist. 
 
SOCKETDIR=/var/run/saslauthd 
 
# Mechanism to use when checking passwords.  Run "saslauthd -v" 
to get a list 
# of which mechanism your installation was compiled with 
the ablity to use. 
#MECH=pam 
MECH=ldap 
 
# Options sent to the saslauthd. If the MECH is other than "pam" 
uncomment the next line. 
# DAEMONOPTS=--user saslauth 
 
# Additional flags to pass to saslauthd on the command line.  
See saslauthd(8) 
# for the list of accepted flags. 
FLAGS="-c -t 604800 -O /etc/saslauthd.conf"
Maintenant, il faut configurer le fichier /etc/saslauthd.conf afin de renseigner les informations nécessaires à la connexion aux serveurs LDAP distants : à savoir les adresses IP ou les alias à joindre avec le suffixe à utiliser, et le "rootDN" avec son mot de passe en clair. Ce qui au passage n’est pas très "securisé" et il faudra donc penser à n’autoriser la lecture de ce fichier qu’au compte root à l’aide de la commande chmod 600. À noter également que le paramètre ldap_filter configuré fait appel aux entrées définies dans un annuaire Active Directory (AD).
Exemple
[root@ldap01~]#cat saslauthd.conf 
ldap_servers: ldaps://AD_01 ldaps://AD_02 
ldap_search_base: dc=exemple,dc=com 
ldap_timeout: 10 
ldap_filter: sAMAccountName=%U 
ldap_bind_dn:CN=rootDN,OU=Service  
Accounts,OU=Paris,DC=exemple,DC=com 
ldap_password: G&m@lt0MCt2!
¬
Toujours s’assurer avant de finaliser la configuration du service "saslauthd" que la communication vers les serveurs AD fonctionne correctement depuis les serveurs LDAP. La simple exécution d’une commande ldapsearch permettra de le confirmer :
ldapsearch -x -H ldaps://AD_01 -D " CN=rootDN,OU=Service  
Accounts,OU=Paris,DC=exemple,DC=com " -w G\&m@lt0MCt2! -b  
"DC=exemple,DC=com" -s base objectclass=*
Si aucun résultat n’est retourné alors il faudra corriger le problème avant de continuer la configuration du service "saslauthd" en s’assurant par exemple que la liaison réseau fonctionne correctement ou bien de la validité du compte de liaison aux annuaires AD.
Il se pourrait aussi, dans le cas de l’utilisation du protocole sécurisé LDAPS, que les certificats des serveurs LDAP ne soient pas correctement renseignés. Dans ce cas, il faut s’en assurer en contrôlant dans le fichier /etc/openldap/ldap.conf que le fichier ou le répertoire désignant les certificats des autorités de certification dit "RootCA" a bien été mis à jour avec ceux des serveurs AD à contacter (paramètre TLS_CACERTDIR).
Sinon, il est possible de s’en affranchir grâce à la valeur :
TLS_REQCERT never.
Exemple
[root@ldap01~]# cat /etc/openldap/ldap.conf 
# 
# LDAP Defaults 
# 
 
# See ldap.conf(5) for details 
# This file should be world readable but not world writable. 
 
#BASE   dc=example,dc=com 
#URI    ldap://ldap.example.com ldap://ldap-master.example.com:666 
 
#SIZELIMIT      12 
#TIMELIMIT      15 
#DEREF          never 
 
TLS_REQCERT never 
TLS_CACERTDIR /etc/openldap/cacerts 
URI ldaps://ldap01.exemple.com:636 ldaps://ldap02. exemple.com:636 
BASE dc=exemple,dc=com
En revanche, si le test est concluant, il faudra s’assurer que les deux services "slapd" et "saslauthd" peuvent parfaitement communiquer entre eux au travers d’un fichier "mutex".
Il faudra donc configurer le fichier (confusément) appelé slapd.conf dans le répertoire des bibliothèques partagées du package "Cyrus SASL" à savoir, le répertoire : /usr/lib/sasl2/ ou /usr/lib64/sasl2.
Si le fichier slapd.conf n’existe pas, il faudra alors le créer et le rendre accessible en lecture pour tout le monde ou au moins pour le groupe de l’utilisateur qui a démarré le démon "slapd".
Exemple
[root@ldap01~]# rpm -qf /usr/lib64/sasl2 
cyrus-sasl-lib-2.1.23-15.el6.x86_64 
cyrus-sasl-2.1.23-15.el6.x86_64 
 
[root@ldap01~]# ls -lrt | grep slapd 
-rw-r--r--  1 root root    82 Feb 20 14:51 slapd.conf 
 
[root@ldap01~]# cat slapd.conf 
mech_list: plain 
pwcheck_method: saslauthd 
saslauthd_path: /var/run/saslauthd/mux
Redémarrer les deux services et les ajouter à la liste des services à redémarrer automatiquement :
service saslauthd restart 
service slapd restart 
 
chkconfig --levels 345 saslauthd on 
chkconfig --levels 345 slapd on
Il est possible maintenant de tester le service "saslauthd" grâce à la commande testsaslauthd :
[root@ldap01~]# testsaslauthd ? 
testsaslauthd: usage: testsaslauthd -u username -p password 
              [-r realm] [-s servicename] 
              [-f socket path] [-R repeatnum] 
 
[root@ldap01~]# testsaslauthd -u testuser1@exemple.com -p 
bon_mot_de_passe 
0: OK "Success." 
[root@ldap01~]# testsaslauthd -u testuser1@exemple.com -p  
mauvais_mot_de_passe 
0: NO "authentication failed"
Ce test valide donc le bon fonctionnement du service "saslauthd" qui va bien contrôler le mot de passe sur l’AD.
¬
Pour réaliser ce test il a fallu utiliser l’identifiant de l’utilisateur suivi du nom de domaine Active Directory (ex. testuser1@gemalto.com)
Maintenant, il suffira, au niveau de l’annuaire OpenLDAP, de renseigner le champ de l’attribut userpassword des comptes utilisateurs voulant utiliser cette fonction par la valeur suivante : {SASL}username@realm.
Cette opération peut être réalisée avec un navigateur LDAP en spécifiant par exemple la valeur "testuser1@exemple.com" en clair (plaintext) ou bien à l’aide de la commande LDAP ldapmodify comme dans l’exemple ci-dessous :
[root@ldap01 ldif]# cat passwd.ldif 
dn: uid=testuser1,ou=users,dc=exemple,dc=com 
changetype: modify 
replace: userPassword 
userPassword: {SASL}testuser1@exemple.com 
[root@ldap01 ldif]# 
 
[root@ldap01 ldif]# ldapmodify -h localhost -D 
cn=root,dc=exemple,dc=com -w secret  -f passwd.ldif 
modifying entry " uid=testuser1,ou=users,dc=exemple,dc=com " 
[root@ldap01 ldif]#
¬
En ligne de commande, par l’intermédiaire des commandes LDAP, il n’est pas nécessaire de spécifier le mode "plaintext", même si une politique de mot de passe exige une empreinte des mots de passe.
Il est maintenant possible de vérifier l’entrée dans l’annuaire par la commande LDAP suivante :
[root@ldap01~]# ldapsearch -h localhost -D  
cn=root,dc=exemple,dc=com -w secret -b "dc=exemple,dc=com" -s 
sub uid= testuser1 | more  
 
dn: uid=testuser1,ou=users,dc=exemple,dc=com 
objectClass: shadowAccount 
objectClass: posixAccount 
objectClass: top 
objectClass: account 
cn: testuser1 
gidNumber: 60001 
homeDirectory: /home/testuser1 
uid: testuser1 
uidNumber: 60012 
gecos: TEST.USER1/GGS_IT 
loginShell: /bin/bash 
userPassword:: e1NBU0x9dGVzdHVzZXIxQGV4ZW1wbGUuY29t
Il apparaît ici que le mot de passe ne s’affiche pas en clair. Cela vient du fait qu’OpenLDAP applique systématiquement un cryptage en base64 sur l’attribut userPassword... et même si celui-ci est une empreinte.
Ainsi, il suffit de taper la commande suivante pour afficher la valeur :
[root@ldap01 ldif]# echo e1NBU0x9dGVzdHVzZXIxQGV4ZW1wbGUuY29t | 
base64 -d 
{SASL}testuser1@exemple.com[root@ldap01 ldif]# ˆC 
[root@ldap01 ldif]#
Il est maintenant possible de tester si l’annuaire OpenLDAP consulte effectivement les annuaires AD lorsqu’il doit authentifier un compte contenant la balise {SASL}. Pour ce faire, il faudra utiliser la commande ldapwhoami auprès de l’annuaire OpenLDAP avec un compte dont le mot de passe se trouve sur les annuaires Active Directory.
Exemple
[root@ldap01]# ldapwhoami -h localhost -D "uid=testuser1,
ou=users,dc=exemple,dc=com" -W (bon_mot_de_passe_sur_l’AD) 
dn:uid=testuser1,ou=users,dc=exemple,dc=com 
 
[root@ldap01]# ldapwhoami -x -D "uid=testuser1,
ou=users,dc=exemple,dc=com" -W (mauvais_mot_de_passe_sur_l’AD) 
ldap_bind: Invalid credentials (49)
Ainsi, si le mot de passe n’est pas le bon, une notification « plutôt » claire sera envoyée : invalid credentials.
L’ultime validation à effectuer désormais est de s’authentifier auprès d’un client LDAP final tel qu’un serveur Linux ou une application et de s’assurer que l’authentification fonctionne bien.
En cas de problème, le service "saslauthd" envoie ses évènements au service "rsyslogd" dans le fichier par défaut : /var/log/messages.
Ainsi, pour plus de clarté, et en cas d’activation du mode "debug", il est préférable de configurer le service "rsyslogd" afin qu’il envoie les évènements spécifiques au service "saslauthd" dans un fichier dédié tel que : /var/log/saslauthd.log
Pour ce faire, il faut donc créer le fichier sasauthd.conf dans l’arborescence /etc/rsyslog.d et ajouter les lignes suivantes :
### Log les évènements du service ’saslauthd’ dans  
/var/log/saslauthd.log et nulle part d’autres 
if $programname == ’saslauthd’ then /var/log/saslauthd.log 
& stop
Redémarrer ensuite le service "rsyslogd" pour la prise en compte de ce nouveau fichier (/var/log/saslauthd.log) :
service rsyslogd restart
Des évènements devraient ainsi apparaître dans ce fichier :
May  9 12:41:53 ldap01 saslauthd[6943]: ldap_simple_bind() failed  
-1 (Can’t contact LDAP server). 
May  9 12:41:53 ldap01 saslauthd[6943]: Retrying authentication 
May 10 08:22:39 ldap01 saslauthd[6946]: ldap_simple_bind() failed  
-1 (Can’t contact LDAP server). 
May 10 08:22:39 ldap01 saslauthd[6946]: Retrying authentication 
May 10 08:22:39 ldap01 saslauthd[6946]: Authentication failed for 
testuser1/exemple.com: Bind to ldap server failed (invalid 
user/password or insufficient access) (-7) 
May 10 08:22:39 ldap01 saslauthd[6946]: do_auth         : auth  
failure: [user=testuser1] [service=ldap] [realm=exemple.com] 
[mech=ldap] [reason=Unknown] 
May 10 08:26:21 ldap01 saslauthd[6947]: ldap_simple_bind() failed  
-1 (Can’t contact LDAP server). 
May 10 08:26:21 ldap01 saslauthd[6947]: Retrying authentication 
May 10 08:48:23 ldap01 saslauthd[6945]: ldap_simple_bind() failed  
-1 (Can’t contact LDAP server). 
May 10 08:48:23 ldap01 saslauthd[6945]: Retrying authentication
En cas de problème avec le mécanisme d’authentification PTA, il est possible d’activer le mode de débogage du service "saslauthd" et les évènements seront ainsi transmis dans le fichier : /var/log/saslauthd.log.
Afin d’activer le mode "debug", il faudra :
# Arrêter le service ’saslauthd’ 
service saslauthd stop 
 
# Modifier le fichier ’/etc/sysconfig/saslauthd’ et ajouter (-d) 
au paramètre FLAGS 
FLAGS="-c -t 604800 -O /etc/saslauthd.conf -d" 
 
# Redémarrer le service ’saslauthd’ 
service saslauthd start