Qu'est-ce que LDAP ?

LDAP en bref#

LDAP (Lightweight Directory Access Protocol) est le protocole qui permet à une application d’interroger et de modifier un annuaire : une base qui décrit les personnes, les groupes, les applications et les équipements d’une organisation.

Quand un salarié ouvre sa session Windows, qu’une application métier affiche l’organigramme ou qu’un serveur vérifie un mot de passe, la question part très souvent vers un annuaire, en LDAP. Active Directory, OpenLDAP, 389 Directory Server ou TosDJ, l’annuaire fourni avec TOSIAM, parlent tous ce protocole.

La version actuelle, LDAPv3, date de 1997. Elle a été entièrement révisée en 2006 dans une série de RFC, de la RFC 4510 à la RFC 4519 ; la RFC 4511 décrit le protocole lui-même.

Pourquoi LDAP existe#

En 1988, l’organisme de normalisation des télécommunications (le CCITT, devenu l’UIT-T) a publié la norme d’annuaire X.500, avec son protocole d’accès, DAP. Puissant mais lourd, DAP reposait sur toute la pile réseau OSI. LDAP est né comme une version légère (lightweight) de ce protocole, fonctionnant directement sur TCP/IP, tout en gardant le modèle de données de X.500.

Un annuaire n’est pas une base de données relationnelle comme les autres. Il est optimisé pour un usage précis :

beaucoup de lectures et peu d’écritures : on vérifie un mot de passe bien plus souvent qu’on ne le change ;
des données organisées en arbre, comme une organisation ;
un schéma standard, pour que des applications de fournisseurs différents lisent les mêmes attributs ;
la réplication entre serveurs, pour que l’annuaire reste disponible partout.

Le modèle de données#

Un annuaire LDAP range ses données dans un arbre, le DIT (Directory Information Tree). Chaque nœud de l’arbre est une entrée, identifiée par un nom unique, son DN (Distinguished Name). Le DN se lit de la feuille vers la racine :

texte· Un DN et ses composants

uid=claire.martin,ou=people,dc=example,dc=fr
└───────┬───────┘ └───┬───┘ └──────┬───────┘
       RDN        conteneur     suffixe

La première partie, le RDN (Relative Distinguished Name), distingue l’entrée parmi ses voisines. Le reste désigne son parent, jusqu’au suffixe, la racine de l’annuaire, souvent dérivé du nom de domaine.

Chaque entrée est un ensemble d’attributs, qui peuvent avoir plusieurs valeurs. Ses classes d’objets (objectClass) déterminent, selon le schéma, les attributs obligatoires et autorisés. On échange des entrées au format texte LDIF :

ldif· claire.martin.ldif

dn: uid=claire.martin,ou=people,dc=example,dc=fr
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
uid: claire.martin
cn: Claire Martin
givenName: Claire
sn: Martin
mail: claire.martin@example.fr
userPassword: {SSHA512}…

Faites défiler le tableau

Attribut	Signification
`uid`	L’identifiant de connexion.
`cn`	Le nom complet (common name).
`sn`, `givenName`	Le nom de famille et le prénom.
`mail`	L’adresse e-mail.
`userPassword`	Le mot de passe, stocké sous forme d’empreinte salée par un serveur bien configuré.
`member`	Dans une entrée de groupe (`groupOfNames`), le DN de chaque membre.

La classe inetOrgPerson, définie par la RFC 2798, est la plus utilisée pour décrire une personne.

Les opérations#

Le protocole définit un petit nombre d’opérations, échangées sur une connexion TCP qui reste ouverte :

Faites défiler le tableau

Opération	Rôle
Bind	S’authentifier sur la connexion.
Search	Rechercher des entrées et lire leurs attributs.
Compare	Tester si une entrée possède une valeur d’attribut donnée.
Add, Delete	Créer ou supprimer une entrée.
Modify	Ajouter, remplacer ou retirer des valeurs d’attributs.
Modify DN	Renommer ou déplacer une entrée.
Unbind	Fermer la connexion.
Extended	Opération étendue, comme StartTLS ou le changement de mot de passe.

Chaque réponse porte un code de résultat : 0 (success), 32 (noSuchObject), 49 (invalidCredentials), etc.

Rechercher dans l’annuaire#

Une recherche se définit par quatre paramètres principaux :

la base, le DN à partir duquel chercher ;
la portée (scope) : l’entrée de base seule (base), ses enfants directs (one) ou tout le sous-arbre (sub) ;
le filtre, qui sélectionne les entrées, dans la syntaxe de la RFC 4515 ;
la liste des attributs à renvoyer.

bash

ldapsearch -H ldaps://annuaire.example.fr:636 \
  -D "cn=tosiam-svc,ou=services,dc=example,dc=fr" -W \
  -b "ou=people,dc=example,dc=fr" -s sub \
  "(&(objectClass=inetOrgPerson)(uid=claire.martin))" cn mail

Les filtres s’écrivent en notation préfixée, entre parenthèses :

Faites défiler le tableau

Filtre	Sélectionne
`(uid=claire.martin)`	Les entrées dont l’`uid` vaut exactement `claire.martin`.
`(mail=*@example.fr)`	Les entrées dont l’adresse se termine par `@example.fr`.
`(&(objectClass=inetOrgPerson)(sn=Martin))`	Les personnes dont le nom est Martin (ET logique).
`(\|(uid=claire.martin)(mail=claire.martin@example.fr))`	L’une ou l’autre condition (OU logique).
`(!(employeeType=stagiaire))`	Les entrées qui ne sont pas des stagiaires (négation).

S’authentifier : le bind#

L’opération Bind associe une identité à la connexion. La norme en prévoit trois formes :

le bind anonyme, sans identité, que la plupart des annuaires limitent à très peu de données ;
le bind simple, avec un DN et un mot de passe ;
le bind SASL, qui délègue l’authentification à un mécanisme : EXTERNAL (certificat client TLS), GSSAPI (Kerberos), SCRAM…

Une application qui veut vérifier le mot de passe d’un utilisateur applique en général le schéma rechercher puis lier (search then bind). L’utilisateur saisit un identifiant, pas un DN : l’application doit d’abord retrouver son entrée.

Utilisateur vers TOSIAM Saisit son identifiant et son mot de passe
TOSIAM vers Annuaire Bind avec le compte de service
Annuaire vers TOSIAM success
TOSIAM vers Annuaire Search (&(uid=claire.martin)(objectClass=inetOrgPerson))
Annuaire vers TOSIAM Renvoie le DN uid=claire.martin,ou=people,…
TOSIAM vers Annuaire Bind avec ce DN et le mot de passe saisi
Annuaire Compare le mot de passe à l’empreinte stockée
Annuaire vers TOSIAM success ou invalidCredentials (49)
TOSIAM vers Utilisateur Poursuit la connexion ou la refuse

Vérification d’un mot de passe par recherche puis bind. Le mot de passe n’est jamais lu dans l’annuaire : c’est l’annuaire qui le compare à l’empreinte stockée.

Chiffrer les échanges#

LDAP transmet ses messages en clair : un bind simple sur une connexion non chiffrée expose le mot de passe à quiconque écoute le réseau. Deux façons de protéger la connexion coexistent :

Faites défiler le tableau

Méthode	Fonctionnement	Port habituel
StartTLS	La connexion démarre en clair, puis le client demande par une opération étendue de passer en TLS avant tout échange sensible. C’est la méthode décrite par la norme.	389
LDAPS	La connexion est chiffrée en TLS dès son ouverture, comme HTTPS. Non normalisée, mais très répandue.	636

Bonnes pratiques#

Chiffrez toutes les connexions par StartTLS ou LDAPS, et vérifiez le certificat du serveur. N’activez jamais une option « faire confiance à tous les certificats » en production.
Refusez les mots de passe vides avant d’appeler l’annuaire. Un bind simple avec un DN et un mot de passe vide est un bind « non authentifié » (RFC 4513) : certains serveurs répondent success, et une application naïve croit alors l’utilisateur authentifié.
Protégez-vous de l’injection LDAP : échappez les caractères spéciaux (*, (, ), \ et le caractère nul) des valeurs saisies avant de les placer dans un filtre, ou construisez les filtres avec l’API de votre bibliothèque.
Donnez au compte de service le minimum de droits : lire les entrées utiles, rien de plus s’il n’a pas à écrire.
Stockez les mots de passe sous forme d’empreintes salées et lentes à calculer, jamais en clair ni avec un simple hachage.
Fixez des limites de taille et de durée aux recherches, et indexez les attributs utilisés dans les filtres.
N’exposez pas l’annuaire sur Internet : seuls les serveurs applicatifs doivent pouvoir le joindre.

LDAP dans TOSIAM#

LDAP est au cœur du fonctionnement de TOSIAM : c’est à la fois le protocole de ses propres bases et celui qu’il utilise pour lire les identités.

TosDJ, l’annuaire fourni. TOSIAM est livré avec TosDJ, un serveur d’annuaire conforme à LDAPv3, issu d’OpenDJ. TosDJ porte les trois bases décrites dans Composants et couches : le Config Store, qui contient la configuration de TOSIAM ; le Core Token Store (CTS), où chaque session et chaque jeton stocké devient une entrée LDAP, sous ou=famrecords,ou=openam-session,ou=tokens du suffixe ; et, si vous le souhaitez, le User Store. À l’installation, un profil (config, cts ou user) choisit le schéma et les données chargés : voir Installer TosDJ.

Les magasins d’identités. Chaque royaume déclare un ou plusieurs magasins d’identités. TOSIAM en propose pour TosDJ, pour un annuaire LDAPv3 générique, pour Active Directory et AD LDS (ADAM), pour Tivoli Directory Server et pour Sun Directory Server. Un magasin précise :

le ou les serveurs, et le mode de connexion : LDAP, LDAPS ou StartTLS (la valeur par défaut, LDAP, est à remplacer par l’un des deux autres dès que l’annuaire n’est pas sur la même machine) ;
le compte de service et le DN de base ;
l’attribut de recherche des utilisateurs, uid par défaut, et le filtre de leur classe d’objets, (objectclass=inetorgperson) par défaut.

TOSIAM peut aussi s’abonner aux changements de l’annuaire par une recherche persistante, une extension répandue mais non normalisée, pour être prévenu des modifications faites directement dans l’annuaire.

L’authentification. Dans un graphe d’authentification, le nœud DataStoreNode vérifie l’identifiant et le mot de passe collectés par les nœuds précédents auprès du magasin d’identités du royaume. Avec un magasin LDAP, TOSIAM applique exactement le schéma « rechercher puis lier » : il cherche le DN de l’utilisateur avec son compte de service, puis effectue un bind simple avec ce DN et le mot de passe sur une connexion séparée. Le filtre est construit par la bibliothèque LDAP, et non par concaténation de chaînes, et le nœud refuse un mot de passe vide avant même de contacter l’annuaire. Un résultat invalidCredentials mène à la sortie false du nœud.

Pour les déploiements qui utilisent encore les chaînes d’authentification, le module LDAP hérité d’OpenAM se connecte directement à un annuaire, avec son propre compte de service, son filtre de recherche, son mode de connexion et la prise en charge des politiques de mots de passe de l’annuaire.

Qu'est-ce que LDAP ?

LDAP en bref#

Pourquoi LDAP existe#

Le modèle de données#

Les opérations#

Rechercher dans l’annuaire#

S’authentifier : le bind#

Chiffrer les échanges#

Bonnes pratiques#

LDAP dans TOSIAM#

Pour aller plus loin#

Voir aussi