Lightweight Directory Access Protocol (LDAP)

Protocole et modèle de communication

Informations sur le protocole

Le protocole LDAP est un protocole de la couche Application (7) du modèle OSI. Il est conçu pour fonctionner au dessus de TCP, qui fonctionne au dessus d'IP. Par conséquent, les communications avec un annuaire LDAP sont en mode connecté, et les paquets échangés ont une garantie d'intégrité.

L'IANA a assigné les ports TCP 389 et 636 respectivement à LDAP et LDAP over TLS/SSL. Cependant, de nouvelles spécifications ont été publiées depuis cette assignation, pour également permettre l'établissement d'une session sécurisée en TLS au niveau du protocole. Dans ce cas, on parle de LDAP TLS ou de StartTLS, et les connexions se font alors comme lors d'une communication classique, sur le port 389.

Cette page décrit les principaux messages du protocole, et la façon dont ils sont agencés lors d'une communication en texte clair/en SSL, et lors d'une communication sécurisée en TLS.

Principaux Messages

Le protocole LDAP fonctionne sur un modèle Requête-Réponse(s) : tant qu'un client ne sollicite pas le serveur, il ne lui transmet pas de réponse. En revanche, depuis l'ajout de l'extension IntermediateResponse à LDAP, une requête peut correspondre à plusieurs réponses.

En revanche, il existe dans LDAP des évènements asynchrones, appelés "alertes". Une alerte est souvent attachée à un évènement, par exemple la fin du support de TLS lors d'une session protégée par StartTLS. Ces alertes peuvent émaner du client comme du serveur, indifféremment.

Ainsi, voici la description des principaux messages de requête et de réponses utilisés dans le protocole LDAP :

Message Signification
bindRequest Demande la connexion (authentifiée ou anonyme) à un annuaire
bindResponse Réponse à la demande d'authentification
unbindRequest Demande de déconnexion/fin de session
searchRequest Demande à effectuer une recherche en fonction d'un filtre donné
searchResEntry Réponse à une recherche, contenant une entrée LDAP
searchResDone Dernier message indiquant la fin des réponses à une recherche
StartTLS Request Demande de création d'une connexion chiffrée par une couche TLS émanant du client.
StartTLS Response Réponse de la demande de création d'une connexion par couche TLS, continue par un handshake
TLS closure alert Message envoyé pour demander/acquitter la fin d'une session protégée par une couche TLS
addRequest Demande d'ajout d'une entrée dans l'annuaire
modifyRequest Demande de modification d'une entrée de l'annuaire
modifyDNRequest Demande la modification d'un Distinguished Name de l'annuaire (cf. section modèles de données)

Remarque : Les noms des messages indiqués sont ceux précisés dans le document de référence du protocole LDAP. En réalité, ces messages sont codifiés par des valeurs binaires lors de leur envoi, réduisant ainsi la consommation de bande passante.

Séquençage pour une connexion classique / SSL

Pour une connexion classique (non chiffrée) ou chiffrée par l'utilisation d'une couche SSL/TLS, les communications se font sur le modèle suivant :

LDAP Protocol Communication Standard/SSL

Les phases 1 et 2 représentent la connexion, avec ou sans authentification de l'utilisateur, au service d'annuaire. Une fois la connexion établie, la session est conservée jusqu'à la rupture de la connexion, ou jusqu'à ce qu'un message unbindRequest le demande explicitement. L'authentification se fait, dans LDAPv3, en utilisant SASL, ce qui permet de supporter de nombreux mécanismes d'authentification (Plaintext, NTLM, Anonymous, Digest-MD5...).

Pendant la durée d'une session, tous les messages sont pris en compte en fonction des autorisations d'accès accordées à l'utilisateur authentifié ou à la connexion anonyme.

Remarque : la connexion SSL est implicite, et le handshake a lieu avant l'échange de paquets au format LDAP.
C'est pourquoi ces informations ne sont pas représentées sur la figure ci-dessus.

Ceci ne change en aucune façon le séquençage des messages LDAP.

Séquençage pour une connexion TLS

Dans ce modèle, la connexion chiffrée en TLS est explicite, et la demande de sécurisation peut se faire à [presque] tout moment. De même, il est possible de retourner en mode non chiffré à presque tout moment à l'aide de l'alerte TLS closure alert.

Cependant, pour des raisons de sécurité, il est fortement conseillé d'envoyer le message StartTLS avant l'opération bindRequest. Autrement, les informations liées au processus d'authentification seront envoyées en clair, ce qui exposerait ces informations à des attaques de type wiretapping (écoute du réseau).

Le modèle recommandé d'utilisation de StartTLS est donc le suivant :

LDAP Protocol Communication Standard/TLS

L'opération StartTLS peut avoir lieue à n'importe quel moment excepté :
  • Si TLS est déjà utilisé sur la session,
  • Si une négociation SASL à étapes multiples est en cours,
  • Et si des réponses sont en cours d'envoi au client, suite à une requête de sa part.

Suite [Modèles de données] >>>