Lightweight Directory Access Protocol (LDAP)
Protocole et modèle de communication
- Informations sur le protocole
- Principaux Messages
- Séquençage pour une connexion classique / SSL
- Séquençage pour une connexion TLS
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 :
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.
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 :
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.