Authentification (ou ouverture de session LDAP)
Comme pour toute application, afin de pouvoir l’utiliser, il faut d’abord s’y connecter.
Ainsi, un client LDAP souhaitant parcourir les données contenues dans l’annuaire devra ouvrir une session sécurisée sur celui-ci. Cette opération de connexion à l’annuaire est nommée Bind (du verbe "lier" en français) et est apparue avec le protocole LDAPv3 qui impose à un client LDAP de s’authentifier auprès de l’annuaire ciblé afin d’accéder aux données de celui-ci. Cette étape est critique, car les données échangées ne doivent en aucun cas être interceptées pour ainsi être utilisées à des fins frauduleuses. L’annuaire OpenLDAP intègre donc ses propres mécanismes d’authentification et en propose d’autres bien plus sécurisés.
1. L’authentification de base ou simple
L’authentification de base (ou simple), comme son nom l’indique, est celle utilisée par le protocole LDAPv3 et offre tel quel, bien peu de sécurité, car l’opération d’authentification (l’échange de l’utilisateur et du mot de passe) s’effectue "en clair" sur le réseau... et ceci n’est donc évidemment plus recommandé. Cependant, il sera expliqué plus loin dans ce chapitre, qu’il est possible de faire appel à un protocole de couche inférieure (SSL/TLS) qui permet de réaliser le cryptage de l’opération d’authentification et même de l’échange des données.
Ce mode d’authentification offre la possibilité de se connecter à l’annuaire par trois méthodes :
	•	Avec une combinaison "utilisateur/mot de passe" connue de l’annuaire (user/password authenticated) .
	•	Avec seulement le nom de l’utilisateur, mais sans le mot de passe (unauthenticated) .
	•	Et enfin, de manière anonyme (anonymous).
L’authentification classique dite "authentifiée" par transmission d’un identifiant utilisateur et d’un mot de passe permet donc de s’assurer de l’identité des personnes qui accèdent à l’annuaire et de parcourir les informations de celui-ci en fonction des droits accordés à l’utilisateur par le mécanisme d’ACL (si supporté par le serveur LDAP).
Voici un exemple de syntaxe au travers d’une recherche LDAP :
ldapsearch -D cn=root -w root -b <basedn> -s <scope> <filter>
L’authentification dite "anonyme" ne demande aucun compte utilisateur ni évidemment de mot de passe. Ce type d’authentification est utile pour donner accès à des données dites "publiques" telles que des informations concernant des adresses de courrier électronique ou bien des numéros de bureau (ex. un who’s who d’entreprise) et qui seront consultable par quiconque... un peu à la manière d’un site web. Cela se traduit donc au niveau d’une requête LDAP par l’absence des informations concernant l’utilisateur et son mot de passe.
Voici un exemple de syntaxe au travers d’une recherche LDAP :
ldapsearch -b <basedn> -s <scope> <filter>
¬
Noter l’absence des paramètres -D (bind DN) et -w (mot de passe).
L’authentification dite "non authentifiée" est une liaison à l’annuaire avec un identifiant utilisateur connu de l’annuaire, qui ne nécessite aucun de mot de passe pour valider la connexion. Ce mode est (était) utilisé à des fins de traçabilité des connexions à l’annuaire, cependant le problème est qu’il peut être sujet à des attaques de type "Déni de service".
2. L’authentification SASL
L’annuaire OpenLDAP offre également la possibilité d’utiliser les mécanismes d’authentification SASL au travers du protocole LDAPv3 afin de permettre de surmonter les lacunes d’authentification du protocole LDAPv2.
Le Simple Authentication and Security Layer ou SASL est en fait le nom d’une standardisation Internet sous la référence RFC4422 qui rassemble de nombreux mécanismes d’authentification et agit concrètement comme une couche d’abstraction entre des mécanismes d’authentification offrant confidentialité et intégrité des données, et des protocoles de connexion comme illustré par la figure 10-1 ci-après.
¬
Figure 10-1 : L’authentification SASL
Ainsi, les protocoles de connexion, tels que SMTP et LDAP, intègrent dans leurs dernières versions des librairies de fonctions qui permettent de communiquer avec celles de SASL. Dans le cas du protocole LDAP, c’est à partir de sa version 3 que la fonction ldap_sasl_bind() est apparue.
Voici un exemple quelque peu caricatural qui illustre la manière dont une communication s’initie entre un client et un serveur :
1.	Le client se connecte au serveur et dit : « Je supporte SASL  ! Comment puis-je m’authentifier  ? »	
2.	Le serveur reçoit la connexion et répond : « Je supporte également SASL, et je peux utiliser ces mécanismes par ordre décroissant : GSSAPI, CRAM-MD5, PLAIN ».	
3.	Le client répond : « Parmi les choix, j’aimerais utiliser GSSAPI ».	
4.	Le serveur répond « GSSAPI ? Je supporte Kerberos et NTLM ».	
5.	Le client répond : « Utilisons Kerberos. Voici mon ticket chiffré... »	
Voici les mécanismes d’authentification les plus couramment utilisés :
	•	PLAIN : ce mécanisme communique le mot de passe en clair sur le réseau et n’offre donc pas plus de garanties que l’authentification basique du protocole LDAP. Il est donc inutile et à proscrire.
	•	LOGIN : version améliorée du PLAIN, mais toujours avec la transmission du mot de passe en clair sur le réseau... à proscrire également.
	•	DIGEST-MD5 : c’est le mécanisme d’authentification préféré pour implémenter LDAPv3. Bien qu’il ne soit pas un mécanisme d’authentification fort par rapport aux systèmes d’authentification appelés "tiers de confiance" tels que des infrastructures Kerberos ou des structures à clés publiques, il offre cependant assez de garanties contre un certain nombre d’attaques. Il permet de ne pas envoyer le mot de passe en clair sur le réseau, car seule son empreinte MD5 (appelé CHALLENGE) sera transmise. Ainsi, l’accès sera accordé si et seulement si les deux empreintes correspondent. Cette méthode, bien que sécurisée par l’utilisation du protocole MD5, possède deux inconvénients :
	▪	Il faut communiquer le mot de passe initial auparavant au client et au serveur.
	▪	Le mot de passe stocké sur le serveur LDAP ne pourra pas être condensé et devra donc être en clair. Attention donc à bien sécuriser l’annuaire par le biais des ACL.
	•	GSSAPI : ce mécanisme permet de déléguer la phase d’authentification à un annuaire LDAP auprès d’une infrastructure de type Kerberos offrant ainsi un échange ultra-sécurisé et limité dans le temps à l’aide de tickets horodatés.
	•	EXTERNAL : permet de déléguer l’authentification à un protocole de niveau inférieur tel que TLS ou IPsec par le biais donc de certificats (TLS) ou d’une clé secrète (PSK).
	•	OTP : permet d’utiliser un système générant des mots de passe à usage unique (un serveur OTP) qui va ensuite le transmettre directement au serveur OpenLDAP et également au client par l’envoi d’un SMS. Il existe aussi des solutions embarquées dans des clés à affichage numérique (appelé jeton d’authentification) lesquelles intègrent un algorithme mathématique qui permet d’être en permanence synchronisé avec le serveur OTP par des calculs basés sur les anciens mots de passe ou par l’envoi d’un défi.
3. Consulter les mécanismes SASL disponibles sur OpenLDAP
Pour trouver les mécanismes SASL apportés par les paquetages cyrus-sasl, il faut tout d’abord identifier celui apportant les librairies à l’aide d’une commande :
[root@ldap01 sasl2]# rpm -qa | grep -i cyrus 
cyrus-sasl-lib-2.1.23-15.el6.x86_64 
cyrus-sasl-md5-2.1.23-15.el6.x86_64 
cyrus-sasl-plain-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 
...
Et ensuite, voir les fichiers déposés par ce paquetage :
[root@ldap01 sasl2]# rpm -ql cyrus-sasl-lib-2.1.23-15.el6.x86_64 
/etc/sasl2 
/usr/lib64/libsasl2.so.2 
/usr/lib64/libsasl2.so.2.0.23 
/usr/lib64/sasl2 
...
Puis, il faudra se positionner dans le répertoire /usr/lib64/sasl2 pour y lister le contenu :
[root@ldap01 sasl2]# ls -lrt 
total 192 
-rwxr-xr-x. 1 root root 22784 Jun 23  2014 libsasldb.so.2.0.23 
-rwxr-xr-x. 1 root root 18808 Jun 23  2014 libplain.so.2.0.23 
-rwxr-xr-x. 1 root root 18808 Jun 23  2014 liblogin.so.2.0.23 
-rwxr-xr-x. 1 root root 31256 Jun 23  2014 libgssapiv2.so.2.0.23 
-rwxr-xr-x. 1 root root 52088 Jun 23  2014 libdigestmd5.so.2.0.23 
-rwxr-xr-x. 1 root root 22936 Jun 23  2014 libcrammd5.so.2.0.23 
-rwxr-xr-x. 1 root root 18776 Jun 23  2014 libanonymous.so.2.0.23 
...
Il y apparaîtra alors les librairies des méthodes d’authentification SASL.
La commande ci-dessous permettra d’obtenir la liste des mécanismes SASL proposés par le serveur OpenLDAP :
ldapsearch  -h localhost -p 636 -D ”cn=admin” -W -s base -b ”” ’+’ 
... 
supportedLDAPVersion: 3 
supportedSASLMechanisms: DIGEST-MD5 
supportedSASLMechanisms: EXTERNAL 
...
Ou bien par l’intermédiaire d’un navigateur LDAP (par exemple Apache Directory Studio) en se positionnant au niveau de l’entrée "RootDSE".
¬
Figure 10-2 : Les mécanismes SASL proposés
Puis la déclaration des mécanismes SASL utilisables par le serveur OpenLDAP se fera directement dans la branche cn=config par l’intermédiaire de l’attribut : olcSaslSecProps: <valeur> (figure 10-3).
¬
Figure 10-3 : Configuration des mécanismes SASL
¬
Dans l’exemple ci-dessus, les valeurs noplain, noanonymous écartent les mécanismes SASL de type PLAIN, LOGIN et ANONYMOUS.