LES ANNUAIRES LDAP

Salim Benayoune
 Plan

 Introduction : Les annuaires et leurs applications

 Le protocole LDAP

 Les modèles de LDAP

 Le modèle d’information

 Le modèle de nommage

 Le modèle de services

 Le modèle de sécurité

 Le modèle de duplication

Salim Benayoune 2
 INTRODUCTION

Salim Benayoune 3
 Concepts : qu’est-ce qu’un annuaire ?

 Petit Robert :
 « Recueil publié annuellement et qui contient des renseignements variables d'une
année à l'autre »
 Un conteneur d’informations organisées
 «une base de données optimisée pour les opérations de lecture, et supportant des
opérations de recherche et de navigation avancées»
 Exemples d’annuaires courants
 annuaire téléphonique, carnet d’adresses, catalogue de vente, guides télé

 Un service d'annuaire électronique, c'est en plus...

 un protocole qui permet l'accès au contenu
 une syntaxe qui permet d’interroger la base
 un modèle de duplication
 un modèle de distribution des données
Salim Benayoune 4
 Concepts : qu’est-ce qu’un annuaire ?

 Spécificités des annuaires électroniques :

 Gestion dynamique de l'annuaire
 Mise à jour en temps réel
 Coûts de mise à jour
 Flexibilité :
 Il est possible d'ajouter des nouveaux champs
 changement aisé type et organisation des données
 La recherche
 Plusieurs types de recherches
 Gestion de la sécurité
 La diffusion de l'information contenue dans un annuaire est facilement contrôlable
 peuvent être personnalisés (façon de présenter les données, action sur ses propres
données,...)

Salim Benayoune 5
 Comparaison avec d'autres systèmes

 Les caractéristiques propres d'un annuaire électronique :

 l'information y est stockée de manière structurée et hiérarchisée
 On trouve dans cette modélisation beaucoup des concepts de la programmation
orientée objet, comme des notions de classes, d'objets, d'attributs, et d'héritage.

 Les annuaires électroniques sont aussi prévus pour être distribués et répliqués à
grande échelle

 L'autre caractéristique des annuaires électroniques est l'existence d'un protocole

de communication réseau

 la spécification d'une manière de stockage n'intervient pas dans la définition d'un

annuaire

Salim Benayoune 6
 Comparaison avec d'autres systèmes

 Caractéristiques comparées des annuaires et base de données :

 rapport lecture/écriture (beaucoup) plus élevé pour les annuaires

 annuaires plus facilement extensibles (types de données)
 diffusion à beaucoup plus large échelle
 distribution des données entre serveurs plus facile avec les annuaires
 plus grande duplication des informations des annuaires (+ fiable, +performant, +
proche des clients)
 performances globales des annuaires plus élevées (en lecture)

Salim Benayoune 7
 Comparaison avec d'autres systèmes

 Caractéristiques comparées des annuaires et base de données :

 Conséquences :
 La contrepartie de l’extensibilité des annuaires est l'absence de transactions et de
procédures stockées
 Il faudra donc faire attention lors de l'exécution d'opérations complexes, et gérer du
côté applicatif les erreurs
 il n'existe pas dans les annuaires de notions de cohérence, ainsi la notion de clé
étrangères n'existe pas
 Si les annuaires permettent dans un certain sens d'effectuer des recherches assez
évoluées (recherches approximatives ou phonétiques), ils ne possèdent pas
l'équivalent de l'instruction SQL joint pour fusionner des informations de plusieurs
sources.

Salim Benayoune 8
 Comparaison avec d'autres systèmes

 Caractéristiques comparées avec le système de fichiers :

 Un système de fichiers est aussi un système d'informations hiérarchisées, les
répertoires formant une hiérarchie, espace de nommage homogène.
 Néanmoins les systèmes de fichiers ne permettent pas une gestion fine des
droits.
 les systèmes de fichiers peuvent contenir des informations très volumineuses
 Cette information n’est pas assez structurée
 Caractéristiques comparées avec les serveurs web:
 Les serveurs web sont optimisés eux aussi pour un rapport lecture sur écriture
élevé
 L’information présentée n’est pas assez structurée
 Caractéristiques comparées avec les serveurs DNS:
 Les serveurs DNS sont très similaires aux annuaires électroniques : hiérarchisés et
répliquées, possédant des fonctionnalités de recherche avancée.
 l'information qui y stockée est très figée, puisque normalisée dans des RFCs.
Salim Benayoune 9
 LDAP
Lightweight Directory Access Protocol

Salim Benayoune 10
 Introduction

The technical specification detailing version 3 of the Lightweight

Directory Access Protocol (LDAP), an Internet Protocol, consists of this
document and the following documents:

LDAP : Technical Specification Road Map [RFC4510]

LDAP: The Protocol [RFC4511]
LDAP: Directory Information Models [RFC4512]
LDAP: Authentication Methods and Security Mechanisms [RFC4513]
LDAP: String Representation of Distinguished Names [RFC4514]
LDAP: String Representation of Search Filters [RFC4515]
LDAP: Uniform Resource Locator [RFC4516]
LDAP: Syntaxes and Matching Rules [RFC4517]
LDAP: Internationalized String Preparation [RFC4518]
LDAP: Schema for User Applications [RFC4519]

Dix RFC principales, et encore plus de RFC complémentaires ? Si vous aviez traduit le
Lightweight de LDAP par "simple", la lecture de ces RFC risque de vous décevoir...

Salim Benayoune 11
 Introduction

 En 1993 Lightweight Directory Access Protocol (LDAP) est né de l’adaptation

et du dégraissage de X.500 DAP au protocole TCP/IP.

 LDAP garde beaucoup d’aspects de X.500 dans les grandes lignes, mais va
dans le sens de la simplification et de la performance

 LDAP est initialement un frontal d’accès à des bases d’annuaires X.500

(translateur LDAP/DAP).
 Début 1995, 99% des serveurs X500 sont accédés par LDAP. Mais les
implémentations des serveurs continuent à être complexes.

 Devient un annuaire natif (standalone LDAP) utilisant sa propre base de

données, sous l’impulsion d’une équipe de l’Université du Michigan
 Début 1996 Netscape prend la tête d'une coalition pour promouvoir l'usage de
LDAP.
Salim Benayoune 12
 Introduction

 LDAP normalise l’interface d’accès à des annuaires

 Cette normalisation concerne aussi bien le contenu que le contenant.
 Elle décrit d’une part le protocole d’échange d’informations entre un client et un
serveur d’annuaire,
 et d’autre part la nature des données échangées.

Salim Benayoune 13
 Le protocole

Le protocole définit :
 Comment s’établit la communication client-serveur :
 commandes pour se connecter ou se déconnecter, pour rechercher, comparer,
créer, modifier ou effacer des entrées.
 Comment s’établit la communication serveur-serveur :
 échanger leur contenu et le synchroniser (replication service)
 créer des liens permettant de relier des annuaires les uns aux autres (referral
service).
 Le format de transport de données :
 pas l’ASCII (comme pour http, smtp...) mais le Basic Encoding Rules (BER), sous
une forme allégée (appelée LBER : Lightweight BER)
 Les mécanismes de sécurité
 Méthodes de chiffrement et d’authentification
 Mécanismes d’accès aux données
 Les opérations de base : search, add, delete, etc.
Salim Benayoune 14
 Le protocole – le modèle client-serveur

 Un des objectifs de LDAP est de réduire la complexité des clients afin de

faciliter le déploiement
 Dialogue synchrone ou asynchrone

 Un client peut émettre plusieurs requêtes vers un serveur, et il n’y a pas

d’ordre imposé quant au renvoi des réponses par ce dernier.
Salim Benayoune 15
 Le protocole : Le format de transport de données

 Les éléments de protocole LDAP sont codés à l’aide d’une version simplifiée
de la syntaxe BER (Basic Encoding Rules), sous-ensemble de ASN 1 (Abstract
Syntax Notation 1)

 BER permet de rendre ce codage indépendant de tout système

d’exploitation et de tout type de machine.
 il gère l’ordre des octets dans un entier d’une façon qui lui est propre

Salim Benayoune 16
 Le protocole : les opérations

 Le protocole LDAP comprend neuf opérations élémentaires, regroupées en

trois catégories :
 Les opérations d’interrogation : elles comprennent deux fonctions, l’une permet
la recherche et l’autre la comparaison.

 Les opérations de mise à jour : elles regroupent quatre fonctions qui sont l’ajout,
la suppression, la modification et le changement de nom.

 Les opérations d’identification et de contrôle de la session : elles comprennent

trois fonctions qui sont l’ouverture de la session et l’identification, la fermeture
de la session, et l’abandon d’une requête en cours.

Salim Benayoune 17
 Le protocole : LDAPv3

 LDAPv3 est conçu pour être extensible sans avoir à modifier la norme grâce
à 3 concepts :

 LDAP extented operations : rajouter une opération, en plus des neuf opérations
de base.
 LDAP controls : paramètres supplémentaires associés à une opération qui en
modifient le comportement.
 Simple Authentification and Security Layer (SASL): couche supplémentaire
permettant à LDAP d’utiliser des méthodes d’authentification externes (Comme
Kerberos).

Salim Benayoune 18
 Le protocole : les opérations
LDAPMessage ::= SEQUENCE {
messageID MessageID,
protocolOp CHOICE {
bindRequest BindRequest,
bindResponse BindResponse,
unbindRequest UnbindRequest,
searchRequest SearchRequest,
searchResEntry SearchResultEntry,
searchResDone SearchResultDone,
searchResRef SearchResultReference,
modifyRequest ModifyRequest,
modifyResponse ModifyResponse,
addRequest AddRequest,
addResponse AddResponse,
delRequest DelRequest,
delResponse DelResponse,
modDNRequest ModifyDNRequest,
modDNResponse ModifyDNResponse,
compareRequest CompareRequest,
compareResponse CompareResponse,
abandonRequest AbandonRequest,
extendedReq ExtendedRequest,
extendedResp ExtendedResponse },
controls [0] Controls OPTIONAL }

MessageID ::= INTEGER (0 .. maxInt)

maxInt INTEGER ::= 2147483647 -- (2^^31 - 1) --

Salim Benayoune 19
 Le protocole : Opération d'association

BindRequest ::= [APPLICATION 0] SEQUENCE {

version INTEGER (1 .. 127),
name LDAPDN,
authentication AuthenticationChoice }

AuthenticationChoice ::= CHOICE {

simple [0] OCTET STRING,
-- 1 and 2 reserved
sasl [3] SaslCredentials }

SaslCredentials ::= SEQUENCE {

mechanism LDAPString,
credentials OCTET STRING OPTIONAL }

 version : Un numéro de version indiquant la version du protocole à

utiliser
 il n'y a aucune négociation de version
 nom : Le nom de l'objet de l'annuaire que le client souhaite voir associé.
 peut prendre une valeur nulle pour les associations anonymes ou quand
l'authentification a été exécutée à une couche inférieure par exemple.
 authentication : information utilisée pour authentifier le nom
Salim Benayoune 20
 Les modèles de LDAP

 Le modèle d’information

 Le modèle de nommage

 Le modèle des services

 Le modèle de sécurité

 Et aussi le modèle de duplication

Salim Benayoune 21
 Le modèle d’information

 Le modèle d’information définit le type des données pouvant être

stockées dans l’annuaire
 L’entrée :
 Élément de base de l’annuaire
 Contient les informations sur un objet de l’annuaire
 Un objet est un ensemble indissociable de valeurs
 À chaque valeur est associé un type d’attribut qui en décrit la syntaxe.
 Ces informations sont représentées sous forme d’un ensemble de paires
(attribut, valeur)
 Chaque entrée doit appartenir à une classe particulière
 Une classe peut dériver d’une autre (héritage)
 A chaque attribut est associé un type et une ou plusieurs valeurs
 Les attributs d’une entrée peuvent être obligatoires ou optionnels

Salim Benayoune 22
 Le modèle d’information

 Schéma de l’annuaire :
 définit pour le serveur l’ensemble des définitions relatives aux objets qu’il sait
gérer
 décrit les classes d’objets, leurs types d’attributs et leur syntaxe
 Vérification de schéma :
 A chaque création d’entrée, le serveur vérifie si elle est conforme à sa (ses)
classe(s) d’appartenance
 Flexibilité du schéma
 attributs optionnels
 attributs multi-valués

Avec LDAPv3, obligation pour un serveur de publier son schéma via LDAP en le
stockant dans l’entrée subschema

Salim Benayoune 23
 Le modèle d’information

 Qu’est-ce qu’un OID ou Object Identifier ?

 C’est un identifiant unique associé à chaque classe d’objet et à chaque type
d’attribut (il concerne uniquement les types de données et non leurs valeurs).
 Un OID est composé de plusieurs numéros séparés par un point.
 Chaque numéro représente une branche dans un arbre hiérarchique.

[Link]
Salim Benayoune 24
 Le modèle d’information

 Chaque attribut dans LDAP est caractérisé par un ensemble d’informations,

décrites dans le RFC4512.
 Un type d’attribut (ou attribut) est caractérisé par :
 Un nom, qui l’identifie
 Un Object Identifier (OID), qui l’identifie également
 Une description
 S’il est mono ou multi-valué
 Un attribut peut avoir une ou plusieurs occurrences
 Une syntaxe
 indique quel type d'information l'attribut peut contenir.(numéro, chaîne de
caractères, etc.)
 Des règles de comparaison (Matching Rules)
 Ex : la recherche ne doit pas différencier les majuscules et les minuscules.
 Une limite de taille de valeur qui lui est associée
 Un indicateur d'usage : Indique la nature de l’attribut (utilisateurs, opérationnels)
Salim Benayoune 25
 Le modèle d’information

 Indicateur d'usage (USAGE) : Il existe donc essentiellement deux types d’attributs :

 Les attributs utilisateurs : ce sont des attributs qui peuvent être modifiés par les
utilisateurs de l’annuaire (ou les applications), en fonction des permissions
attribuées par l’administrateur.
 Par exemple, les attributs mail et cn sont des attributs utilisateurs.

 Les attributs opérationnels : ce sont des attributs spéciaux qui affectent le

comportement d’un annuaire ou donnent des informations sur son statut.
 En général, ils ne sont pas accessibles aux utilisateurs, sauf si ceux-ci le demandent
explicitement.
 Par exemple, l’attribut modifytimestamp est un attribut opérationnel, mis à
jour automatiquement par le serveur d’annuaire et qui donne la date de la dernière
mise à jour d’un objet.

Salim Benayoune 26
 Le modèle d’information

 Exemple de syntaxes :

OID Nom Description

[Link].4.1.1466.[Link] boolean Booléen

[Link].4.1.1466.[Link] dn Un DN

Une chaîne de caractères,

[Link].4.1.1466.[Link] Directory String
encodée en UTF-8
Une chaîne de caractères
[Link].4.1.1466.[Link] IA5String
ASCII

[Link].4.1.1466.[Link] integer Un entier

Une suite quelconque

[Link].4.1.1466.[Link] binary
d’octets

[Link].4.1.1466.[Link] telephoneNumber Un numéro de téléphone

Salim Benayoune 27
 Le modèle d’information
 Exemple de Règles de comparaison :
OID Nom Description Syntaxe
Comparaison d'égalité entre deux
[Link] objectIdentifierMatch [Link].4.1.1466.[Link]
OIDs.
[Link] distinguishedNameMatch Comparaison d'égalité entre deux DN. [Link].4.1.1466.[Link]
Retourne vrai si les chaînes ont la
[Link] caseIgnoreMatch même taille et sont identiques, à la [Link].4.1.1466.[Link]
case près.
Règle d'inégalité, retourne vrai si la
valeur de l'attribut comparé apparaît
[Link] caseIgnoreOrderingMatch avant la valeur passé en paramètre, [Link].4.1.1466.[Link]
une fois les deux chaînes convertis en
majuscules.
Règle d'inclusion, insensible à la case,
[Link] caseIgnoreSubstringsMatch [Link].4.1.1466.[Link]
comme les deux règles précédentes.
Règle identique à la règle
[Link] numericStringMatch caseIgnoreMatch sauf que les espaces [Link].4.1.1466.[Link]
sont ignorés pendant la comparaison.
Règle identique à la règle
caseIgnoreSubstringsMatch sauf que
[Link] numericStringSubstringsMatch [Link].4.1.1466.[Link]
les espaces sont ignorés pendant la
comparaison.
Salim Benayoune 28
 Le modèle d’information

 Exemple d’attributs

OID Nom Description

[Link] createTimestamp Cet attribut contient la date de création d’un objet.
Code pays sur deux lettres. Ce code doit respecter
[Link] c
le standard ISO 3166,
[Link] cn Nom de l’objet (common name)
0.9.2342.19200300.100.1.25 dc Spécifie un composant d’un nom de domaine
[Link] dn (distinguishedName
[Link] o Nom de l’organisation
[Link] ou Nom de l’unité organisationnelle
[Link] sn Nom de famille d’une personne
[Link] telephoneNumber Numéro de téléphone
[Link] caCertificate. Certificat de l’autorité de certification
[Link].113730.3.1.1 carLicence Numéro d’immatriculation d’un véhicule.
0.9.2342.19200300.100.1.3 mail Adresse de messagerie.

Salim Benayoune 29
 Le modèle d’information

 createTimestamp

( [Link] NAME 'createTimestamp' EQUALITY generalizedTimeMatch

ORDERING generalizedTimeOrderingMatch
SYNTAX [Link].4.1.1466.[Link]
SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation )

 telephoneNumber

attributetype ( [Link] NAME 'telephoneNumber'

EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringsMatch
SYNTAX [Link].4.1.1466.[Link]{32} )

Salim Benayoune 30
 Le modèle d’information

 Les classes d’objets

 Les classes modélisent les objets réels ou abstraits décrits dans un annuaire
 Chaque entrée de l'annuaire appartient à une ou plusieurs classes
 Une entrée dans un annuaire peut être constituée d’un ou de plusieurs objets

 Exemple de classes :
 une organisation (o),
 ses départements (ou),
 son personnel (organizationalPerson),
 ses imprimantes (device),
 ses groupes de travail (groupofnames).

Salim Benayoune 31
 Le modèle d’information

 Les différents types de classe décrits dans le standard LDAP sont les
suivants:
 Abstrait : les classes de ce type ne peuvent pas avoir d’instance. Seules les classes
qui en dérivent peuvent en avoir.
 Exemple: top, dont dérivent toutes les autres classes.

 Structurel : les classes de ce type peuvent avoir des instances dans l’annuaire.
 Exemple : la classe person.

 Auxiliaire : les classes de ce type sont utilisées pour compléter les classes de type
structurel. Une entrée dans l’annuaire peut ainsi être complétée par un ensemble
d’attributs à l’aide d’une instance d’une classe auxiliaire.
 Généralement, tous les attributs d’une classe auxiliaire sont facultatifs et la classe
auxiliaire dérive directement de la classe top.

Salim Benayoune 32
 Le modèle d’information

 Caractéristiques d’une classe :

Caractéristique Description
OID Identifiant de la classe
NAME Nom de la classe
DESC Description de la classe
SUP OID de la classe dont celle-ci
dérive
TYPE Type de classe
MUST Liste des OID des attributs
obligatoires
MAY Liste des OID des attributs
facultatifs

Salim Benayoune 33
 Le modèle d’information

 L’héritage entre classes :

 Pas d’héritage multiple.

 Une classe dérivée d’une autre ne peut donc pas redéfinir un attribut de la classe
mère pour en modifier les caractéristiques

Salim Benayoune 34
 Le modèle d’information

 L’héritage entre classes :

 On précise la classe d’objet d’une entrée à l’aide de l’attribut objectClass.
 Il faut obligatoirement indiquer la parenté de la classe d’objet en partant de
l’objet top et en passant par chaque ancêtre de l’objet.
 Par exemple, l’objet inetOrgPerson a la filiation suivante :
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
 L’objet person a comme attributs : commonName, surname, description,
seeAlso, telephoneNumber,userPassword
 L’objet organizationalPerson ajoute des attributs comme :
organizationUnitName, title, postalAddress...
 L’objet inetOrgPerson lui rajoute des attributs comme : mail, labeledURI,
uid, photo...

Salim Benayoune 35
 Le modèle d’information

 L’agrégation d’objets :
 Une entrée dans l’annuaire peut être constituée de plusieurs objets
 chaque objet étant rattaché à une seule classe
 La seule condition est que seule une des classes utilisées soit de type structurel

 Exemple :
 Il n’est pas envisageable de créer un objet de type person et
organizationalUnit (ce qui d’ailleurs n’a pas de sens en soi).

 Mais, il est possible de créer un objet de type organizationalPerson et

strongAuthenticationUser qui est de type auxiliaire.

 L’objet de type organizationalPerson et strongAuthenticationUser

a donc comme attributs obligatoires : objectclass, sn, cn et
userCertificate.

Salim Benayoune 36
 Le modèle d’information

 L’agrégation d’objets :
 Si un même attribut se trouve dans plusieurs classes, utilisées par un même objet,
il n’y a aucun moyen de faire la différence entre les valeurs de cet attribut
associées à une classe ou à une autre.

 Exemple :
 si les classes person et strongAuthenticationUser contiennent toutes
les deux l’attribut description, un objet qui serait l’instance de ces deux classes
contiendrait un seul attribut description

 Celui-ci peut avoir une ou plusieurs valeurs, mais il n’y a aucun moyen de rattacher
une valeur à une classe.

 Ceci est dû au fait que le modèle LDAP impose un référentiel commun d’attributs,
indépendamment de toute classe.

Salim Benayoune 37
 Le modèle d’information

 Exemple de classes :
 subschema (Auxiliaire) : permet de décrire l’ensemble des syntaxes, règles de
comparaison, attributs et classes pris en charge par l’annuaire LDAP.
 extensibleObject (Auxiliaire) :
 permet de créer des objets pouvant utiliser n’importe quel attribut décrit dans le
schéma de l’annuaire.
 rarement utilisée ( introduit des objets quelconques dans un annuaire, en ne
respectant aucune règle d’intégrité)
 applicationEntity (structurelle) :
 Décrit une application informatique accessible à travers un réseau d’entreprise
 certificationAuthority (Auxiliaire) :
 Description d’une autorité délivrant des certificats
 device (Structurel) :
 Décrit un équipement quelconque
 groupOfNames (Structurel) :
 Groupe d’objets
Salim Benayoune 38
 Le modèle d’information

 La vérification du schéma de l’annuaire. l’ensemble des vérifications

requises pour s’assurer de la validité des données et de leur conformité au
schéma de l’annuaire sont :
 vérifier que toutes les valeurs d’attributs correspondent bien aux syntaxes
définies pour chacun d’eux (numérique, alphanumérique, DN…) ;
 vérifier que tous les attributs obligatoires des classes de l’objet sont bien
renseignés ;
 vérifier que les autres attributs renseignés sont bien des attributs autorisés et
facultatifs ;
 vérifier que les attributs mono-valeurs ne sont pas renseignés plus d’une fois.

 Tous ces contrôles sont effectués par le serveur d’annuaire avant de réaliser
toute modification ou toute insertion d’objet.

Salim Benayoune 39
 Le modèle de nommage

 L’objectif est de fournir une règle commune permettant de nommer et de

référencer tout objet dans l’annuaire.
 Cette règle doit être indépendante de toute classe

 Deux concepts élémentaires sous-tendent cette règle :

 un espace de noms homogènes ;
 un objet décrivant une personne, un groupe de personnes ou une application, sera
toujours désigné de la même manière.
 l’organisation hiérarchique des données.
 facilite la navigation et la recherche de données.
 facilite la séparation des données dans des partitions différentes, chacune d’elles
étant située sur un serveur.
 facilite également la délégation des droits d’accès

Salim Benayoune 40
 Le modèle de nommage

 Exemple : organisation hiérarchique selon l’endroit géographique

Salim Benayoune 41
 Le modèle de nommage

 Exemple : organisation hiérarchique selon la sémantique

Salim Benayoune 42
 Le modèle de nommage

 L’organisation hiérarchique des données :

 Directory Information Tree (DIT)
 Chaque nœud de l’arbre est un objet, qui peut appartenir à n’importe quelle classe

 Le nombre de branches par nœud et le nombre de niveaux ne sont pas limités

Salim Benayoune 43
 Le modèle de nommage

 Dans un annuaire LDAP il n’y a pas de racine unique

 Le niveau supérieur de chaque arbre est nommé domaine.
 Un annuaire LDAP peut contenir plusieurs domaines

Salim Benayoune 44
 Le modèle de nommage

 LDAP (contrairement à X.500)

 n’impose aucune contrainte relative aux classes d’objets dans la hiérarchie de
l’arbre.
 toute classe peut être utilisée pour la racine de l’arbre
 des contraintes (performance, gestion...) impliqueront de choisir tel ou tel type
de modèle
 Exemple :
 un objet de type organization comme racine de l’arbre, et des objets de type
country comme sous-branches
 un objet de type organizationalUnit, et comme sous-branches des objets
de type organization

Salim Benayoune 45
 Le modèle de nommage

 Le nom des objets : LDAP définit deux concepts pour nommer un objet :
 un nom relatif désigné par RDN (Relative Distinguished Name);
 un nom absolu désigné par DN (Distinguished Name).

 Le RDN est constitué d’un ou plusieurs couples (attribut = valeur).

 Les règles que doit respecter un RDN sont les suivantes :
 un objet ne peut avoir qu’un seul RDN, qui est unique (voir schéma).
 il est préférable d’utiliser un attribut obligatoire comme RDN
 un RDN peut avoir plusieurs couples attributs/valeurs (déconseillé).

Salim Benayoune 46
 Le modèle de nommage

 Exemple :

Salim Benayoune 47
 Le modèle de nommage

 Le nom absolu : DN (Distinguished Name)

 permet de référencer un objet sans ambiguïté, car il est unique dans l’ensemble
de l’annuaire
 Le DN d’un objet est composé de l’ensemble des RDN des nœuds supérieurs, y
compris celui de l’objet lui-même.
 Les RDN sont séparés par des virgules et ils sont classés dans un ordre ascendant.

DN: cn=Pierre DURAND,ou=Employés,ou=Filiale française,o=Entreprise

Salim Benayoune 48
 Le modèle de nommage

 le nombre de niveaux et le nombre de branches n’ont pas beaucoup

d’impacts sur les performances d’un annuaire.
 Cette hiérarchie des objets ne constitue qu’une vue logique des données.

 Le modèle physique utilisé par les serveurs LDAP peut varier d’un éditeur à
l’autre.
 Certains s’appuient sur des bases de données relationnelles, et d’autres sur des
bases de données objet.

 Un DN permet de trouver sans ambiguïté un objet dans un annuaire, mais

ne contient aucune indication sur l’emplacement de l’annuaire lui-même.
 il faut compléter le DN par l’adresse DNS de l’annuaire

Salim Benayoune 49
 Le modèle de nommage

 Nom de domaine DNS et nom de domaine LDAP :

 le RFC 2247, qui explique comment faire correspondre les deux
 Exemple :
 une entreprise souhaite donner accès à son annuaire LDAP via Internet
 l’utilisateur devra
 connaître le nom DNS du serveur d’annuaire ([Link])
 connaître le DN du domaine de l’annuaire pour pouvoir l’interroger
 Y a-t-il un moyen de connaître DN à partir de DNS?
 Solution 1 :
 attribuer le nom de domaine o=[Link] à la racine de l’arbre LDAP
 problème si l’entreprise possède plusieurs annuaires.
 Solution 2 :
 découper le nom de domaine en utilisant l’attribut dc :
 dc=entreprise,dc=fr

Salim Benayoune 50
 Le modèle de services

 Le modèle de services définit une liste de services ou d’opérations que doit

offrir tout serveur d’annuaire.

 Le modèle définit :
 les opérations d’interrogation
 les opérations de comparaison
 les opérations de mise à jour
 les opérations d’authentification et de contrôle
 Les opérations étendus (V3)

Salim Benayoune 51
 Le modèle de services

 La recherche
 Les 8 paramètres requis par cette opération sont les suivants :

Paramètre Description
base object l'endroit de l'arbre où doit commencer la recherche

scope la profondeur de la recherche

derefAliases si on suit les liens ou pas
size limit nombre de réponses limite
time limit temps maxi alloué pour la recherche

attrOnly renvoie ou pas la valeur des attributs en plus de leur type

search filter le filtre de recherche

list of attributes la liste des attributs que l'on souhaite connaître

 LDAP ne fournit pas d’opération de lecture d’entrée.

 Cette opération est simulée par la fonction search avec un search scope égal à base

Salim Benayoune 52
 Le modèle de services

 scope :
 définit la profondeur de la recherche dans le DIT.

Salim Benayoune 53
 Le modèle de services

Salim Benayoune 54
 Le modèle de services

 Les filtres de recherches :

 Le filtre LDAP est comparable au langage SQL
 Plus précisément, à la clause WHERE de SQL
 définit sur quels objets et sur quels attributs doit s’effectuer une recherche
 C’est un ensemble d’assertions combinées à l’aide des opérateurs booléens : ET,
OU et NON.
 Un opérateur booléen s'applique à toutes les opérations qui suivent jusqu'à
l'opérateur suivant.
 Chaque assertion est composée d’un nom d’attribut, d’un opérateur de
comparaison et d’une valeur :
 Une assertion élémentaire de recherche s'écrit sous la forme :
attribut OPERATEUR valeur

 La syntaxe générale d’un filtre est :

(operator(assertion)(assertion)...(operator(assertion)(assertion)...)))

Salim Benayoune 55
 Le modèle de services

 Exemples :
Filtre Syntaxe Interprétation
Approximation (sn~=Benayoune) nom dont la phonétique est
voisine de Benayoune
Egalité (sn=Benayoune) vaut exactement Benayoune
Comparaison (sn>=Benayoune) noms situés alphabétiquement
après Benayoune

Présence (sn=*) toutes les entrées ayant un

attribut sn
Sous-chaîne (sn=Ben*), (sn=*ayo*), (sn=Ben*n*) expressions régulières sur les
chaînes
ET (&(sn=B*) (ou=ASR)) toutes les entrées dont le nom
commence par B et sont au ASR

OU (|(ou=Direction) (ou=Etude)) toutes les entrées dont le service

est Etude ou Direction

Négation (!(tel=*)) toutes les entrées sans attribut

téléphone
Salim Benayoune 56
 Le modèle de services

 Exemples :
 Toutes les personnes ayant leur numéro de téléphone renseigné :

(&(objectclass=person)(telephoneNumber=*))

 Toutes les personnes dont le nom commence par 'A' et n'habitant pas Paris :

(&(objectclass=person)(cn=A*)(!(l=Paris)))

 Toutes les personnes dont le nom ressemble à Febvre (Faivre, Fèvre, Lefebvre,
...):
(&(objectclass=person)(cn~=febvre))

(&(objectclass=person)(cn=*f*vre))
Salim Benayoune 57
 Le modèle de services

 Les filtres étendus :

 Possibilité de considérer les éléments du DN comme faisant partie de l'entrée
elle-même :
attribut:dn:=value

 Exemple :

(ou:dn:=users)

 Possibilité de modifier la règle de comparaison sur un attribut :

attribut:oid-matching-rule:=value
 Exemple : sensibilité à la casse

(cn:[Link]:=Philippe)

Salim Benayoune 58
 Le modèle de services

 La comparaison :
 vérifier si un objet de l’annuaire contient bien une ou plusieurs valeurs données.
 Cette opération est identique à une opération de recherche dans laquelle les
paramètres sont :
 Le DN à comparer
 le périmètre de la recherche : base
 le filtre de la recherche contenant les attributs et les valeurs à comparer,
 la liste des attributs à récupérer égale à l’OID 1.1, qui est un OID inexistant

 Avantage :
 Efficacité
 Si l’on cherche à comparer un attribut qui n’existe pas, l’opération de comparaison
renvoie un code retour précisant que cet attribut n’existe effectivement pas, alors
que l’opération de recherche ne renvoie pas de résultat.

Salim Benayoune 59
 Le modèle de services

 La modification d’objet :
 permet de modifier un objet dans l’annuaire
 Tous les attributs de l’objet peuvent être modifiés à l’exception du DN
 Le DN est modifié par une autre opération
 Les paramètres requis par cette opération :
 DN de l’objet à modifier
 Liste des modifications à effectuer : traitée d’une façon atomique.

 Condition de succès :
 Les modifications demandées doivent respecter le schéma de l’annuaire
 L’identification fournie lors de la connexion doit correspondre à un objet ayant les
droits d’écriture dans l’annuaire
 Les attributs appartenant au DN de l’objet ne pourront pas être supprimés à l’aide
de cette opération.

Salim Benayoune 60
 Le modèle de services

 L’ajout :
 permet d’ajouter un nouvel objet dans l’annuaire
 Les conditions de succès :
1. L’objet parent de l’objet à rajouter doit exister dans l’annuaire
2. Il ne doit pas exister dans l’annuaire un autre objet ayant le même DN.
3. Les attributs renseignés doivent respecter le schéma de l’annuaire.
4. L’identification fournie lors de la connexion doit correspondre à un objet ayant les
droits d’écriture dans l’annuaire sur tous les attributs à rajouter et dans la branche
de l’arbre à mettre à jour.

Salim Benayoune 61
 Le modèle de services

 La suppression :
 permet de supprimer un objet de l’annuaire
 Les conditions de succès :
1. L’objet à supprimer doit exister dans l’annuaire

2. Il ne doit pas y avoir d’objets fils sous l’objet à supprimer.

3. L’identification fournie lors de la connexion doit correspondre à un objet ayant les

droits d’écriture dans l’annuaire sur tous les attributs à supprimer et dans la
branche de l’arbre à mettre à jour.

Salim Benayoune 62
 Le modèle de services

 La modification de DN:
 permet de modifier le DN d’un objet de l’annuaire
 Les paramètres requis :
 DN de l’objet à modifier
 Nouveau RDN: permet de désigner le nouveau RDN de l’objet
 Indicateur de suppression de l’ancien RDN: supprimer l’ancien RDN ou non
 DN de l’objet qui sera le nouveau supérieur : non obligatoire
 Conditions de succès :
 L’objet à modifier doit exister dans l’annuaire
 Le nouveau RDN ne doit pas déjà être attribué pour un autre objet
 Le RDN doit être unique dans la branche de l’arbre où se trouve l’objet.
 En cas de déplacement de l’objet, il ne doit pas avoir d’objets fils.
 Avoir les droits sur l’objet et en cas de déplacement sur les branches concernées.

Salim Benayoune 63
 Le modèle de services

 L’abandon :

 permet d’abandonner une autre opération en cours

 Elle ne peut être utilisée que dans une requête asynchrone

 Le seul paramètre de cette opération est l’identifiant de la requête à abandonner.

 Si les réponses à une requête arrivent en même temps que la soumission de

l’abandon par le client, il est nécessaire de purger celles-ci.

Salim Benayoune 64
 Le modèle de services

 Les extensions :
 LDAP v3 prévoit la possibilité de soumettre à un serveur des opérations ne faisant
pas partie de celles listées précédemment
 Avantage :
 étendre les fonctionnalités d’un serveur d’annuaire tout en restant compatible v3
 Exemple :
 associer une signature électronique à toute modification d’objet
 gestion de l’intégrité des transactions, comme dans une base de données
relationnelles.
 mettre à jour tout un ensemble d’objets simultanément.
 paramètres : l’identifiant de la requête et les éventuelles données associées.
 Certains serveurs d’annuaire LDAP offrent une interface de programmation qui
offre le moyen de développer soi-même le traitement associé à une extension
 Inconvénient : l’exécution de tels services ne sera possible que si le client connaît
leur existence et les paramètres dont ils ont besoin
 Solution : Groupe de travail LDAPEXT
Salim Benayoune 65
 Le modèle de services

 2 types d’objets particuliers :

 Alias
 Referrals
 Alias : référence entre entrées au sein d’un même annuaire
 L’attribut aliasObjectName de l’objet alias a pour valeur le DN de l’entrée pointée.

Salim Benayoune 66
 Le modèle de services

 Le renvoi de référence ou les referrals :

 Lors de la demande d’un service (sauf le service d’abandon ou de déconnexion),
l’annuaire LDAP peut renvoyer une référence ou plusieurs références vers d’autres
annuaires.

 Avantage :
 Distribuer la gestion d’un annuaire entre plusieurs serveurs LDAP distincts
 Chaque serveur gère un sous-ensemble du DIT global
 Permet la montée en charge en gardant de bonnes performances

 Deux cas se présentent :

1. soit la recherche s’effectue dans le même domaine, il s’agit alors d’envoyer une
ou plusieurs références vers des annuaires subordonnés ;
2. soit la recherche s’effectue dans un autre domaine, et il s’agit alors d’envoyer
une référence vers un annuaire de niveau supérieur.
Salim Benayoune 67
 Le modèle de services

 Exemple :

Salim Benayoune 68
 Le modèle de services

 Cas 1 : recherche dans un même domaine

Salim Benayoune 69
 Le modèle de services

 Cas 2 : recherche dans un autre domaine

Salim Benayoune 70
 Le modèle de services

 Gestion de la distribution
 L’attribut ref de l’objet referral a pour valeur l’URL LDAP de l’entrée
désignée.
 Les referrals sont traités au niveau du serveur en LDAP V2, par le client en V3

 Permet dans l’Internet de préserver l’autonomie des serveurs car :

 La bande passante entre un client et serveur et la même qu’entre serveur et serveur
 Les clients sont suffisamment puissants
 Limite : tout le travail incombe à l’utilisateur

 il est possible de préciser le nombre maximal de chaînage possible et le temps

maximal de recherche.

 Identification lors d’un changement de serveur ?

Salim Benayoune 71
 Le modèle de sécurité

 Le modèle de sécurité décrit le moyen de protéger les données de

l’annuaire des accès non autorisés.

 Dans son état actuel, seuls les services d’authentification et de

confidentialité sont pris en compte.
 Les autres services peuvent être offerts à travers des extensions propriétaires

Salim Benayoune 72
 Le modèle de sécurité

 L’authentification :
 LDAP est un protocole avec connexion : l’ouverture de session (bind) s’accompagne
d’une identification et, éventuellement, d’un mot de passe (optionnel en V3).
 Anonymous authentification - accès sans authentification permettant d’atteindre
les données sans restrictions d’accès (V2, V3).
 Root DN authentification - accès administrateur (tous les droits) (V2, V3).
 Mot de passe en clair - un DN plus un password qui transite en clair sur le réseau
(V2, V3).
 Kerberos V4 (V2)
 Mot de passe + SSL (LDAPS) ou TLS - la session est chiffrée et le mot de passe ne
transite plus en clair.
 Certificats sur SSL - échange de certificats SSL (clefs publiques/ privées).

 Simple Authentification and Security Layer (SASL) – mécanisme externe

d’authentification (V3).

Salim Benayoune 73
 Le modèle de sécurité

 La confidentialité :
 traitée à travers le support de SSL (LDAPS) et nécessite l’usage d’un port
spécifique qui est le port 636 au lieu de 389
 inconvénient :
 pas possible de mixer des sessions chiffrées et non chiffrées sur le même port.
 Solution :
 StartTLS (via les extension de LDAP v3) qui permet de négocier l’utilisation de TLS
sur le port standard 389
 Remarque :
 TLS et aussi pris en charge par SASL, mais uniquement pour l’authentification et pas
pour toute la session.
 Le chiffrement LDAP ne concerne que l’échange des données, et pas leur stockage

Salim Benayoune 74
 Le modèle de sécurité

 Le contrôle d’accès :
 Le standard LDAP v3 ne décrit pas de mécanisme permettant de gérer les
habilitations

 La plupart des produits de marché implémentent leurs propres mécanismes de

gestion des habilitations.
 pas d’impact sur l’interopérabilité des clients et des serveurs lors de l’accès aux
données
 problème lorsqu’il s’agit de :
 répliquer ces droits entre différents produits d’annuaires,
 ou encore lorsqu’il s’agit de lire et de mettre à jour ces droits à partir d’une
même interface d’administration (client LDAP)

Salim Benayoune 75
 Le modèle de sécurité

 Le contrôle d’accès :
 La gestion des habilitations consiste à décrire les droits d’accès de certains objets
de l’annuaire sur d’autres objets.
 Cette description se fait à l’aide d’un ensemble de règles que l’on nomme
généralement ACL (Access Control Lists).
 Chaque ACL comprend plusieurs règles, appelées ACI (Access Control Item ou
Information)

 Un ACI décrit un droit d’un ensemble d’objets sur un ensemble d’objets.

 Chaque droit concerne une des opérations décrites dans le standard LDAP
 Les objets à qui l’on donne des droits peuvent être désignés explicitement (par leur
DN par exemple) ou implicitement (par filtre ou selon l’identification)
 Les objets sur qui l’on attribue des droits peuvent, de même que précédemment,
être désignés explicitement ou implicitement

Salim Benayoune 76
 Le modèle de sécurité

 Le contrôle d’accès :
 Règles communes au ACI dans les différents produits du marché :
 Toute habilitation attribuée sur un objet de l’arbre est valable sur tous les objets
sous jacents.
 Toute interdiction est prioritaire à toute autorisation dans une même branche.

Salim Benayoune 77
 Le modèle de sécurité

 Exemple : OpenLDAP

<clause d'accès> ::= access to <objet> [ by <sujet> <action> <contrôle> ]+

<objet> ::= * | [dn[.<dnstyle>]=<dnspec>] [filter=<ldapfilter>] [attrs=<attrlist>]

sujet : * ,anonymous, users ,self

<access> ::= [self]{<level>|<priv>}

<level> ::= none | auth | compare | search | read | write
<priv> ::= {=|+|-}{w|r|s|c|x}+

access to attribute=userPassword
by anonymous auth
by self write
by * none break

Salim Benayoune 78
 Le modèle de duplication

 Définit comment dupliquer l’annuaire sur plusieurs serveurs

 Objectif :
 Supporter la montée en charge
 Résister à une panne d’un serveur ou à une coupure réseau

 La réplication est supportée dans le modèle LDAP par le protocole LDUP

 Le modèle :
 Actuellement, un site maître et des sites esclaves.
 On duplique tout l’arbre ou uniquement un sous-arbre
 Des modèles plus compliqués sont à l’étude
 « on ne duplique que les objets de type personne »
 « on ne duplique que les attributs non confidentiels » (annuaire interne vs. annuaire
externe)

Salim Benayoune 79
 LDIF

 LDAP Data Interchange Format (LDIF) est le standard de représentation des

entrées sous forme texte.

 Utilisé pour afficher ou modifier les données de la base suivant deux modes:
 faire des imports/exports de base,
 faire des modifications sur des entrées.

 Le format utilisé est l’ASCII. Toute valeur d’attribut ou tout DN qui n’est pas
ASCII, est codé en base 64.
 jpegPhoto::/9j/4AAQSkZJRgABAQAAAQABAAD//gBHQ1JFQVRPUjogWFYgVmVyc2lvbiAz
LjEwICBSZXY6IDEyLfgE2Lzk0ICBRdWFsaXR5ID0gNzUsIFNtb290aGluZyA9IDAK/9sAQw
AIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0N
B8nOT04MjwuMzQy/

Salim Benayoune 80
 LDIF

 Mode import :
dn: <distinguished name>
objectClass: <object class>
objectClass: <object class>
[...]
attribute type:<attribute value>
attribute type:<attribute value>
[...]

dn: cn=June Rossi, ou=accounting, o=Ace Industry, c=US

objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
cn: June Rossi
sn: Rossi
givenName: June
mail: rossi@[Link]
userPassword: {sha}KDIE3AL9DK

Salim Benayoune 81
 LDIF

 Mode modification :
dn: distinguished name
changetype identifier
change operation identifier
list of attributes...
-
change operation identifier
list of attributes ...

 Exemple : Ajouter le numéro de téléphone et le nom du manager pour la

personne «Lisa Jangles ».

dn: cn=Lisa Jangles, ou=Sales, o=Ace Industry, c=US

changetype: modify
add: telephonenumber
telephonenumber: (408) 555-2468
-
add: manager
manager: cn=Harry Cruise, ou=Manufacturing, o=Ace Industry, c=US

Salim Benayoune 82
 URLs de LDAP

ldap[s]://<hostname>:<port>/<base_dn>?<attributes>?<scope>?<filter>
<base_dn> : DN de l’entrée qui est le point de départ de la recherche
<attributes> : les attributs que l’on veut consulter
<scope> : la profondeur de recherche dans le DIT à partir du <base_dn>
- base : s’arrête au niveau courant (par défaut)
- one : descend d’un niveau
- sub : parcourt tous les sous-niveaux
<filter> : filtre de recherche, par défaut (objectClass=*)

ldap://[Link]/o=worldcompany?mail,uid?sub?(sn=Smith)

Salim Benayoune 83
 API

 Ces bibliothèques de programmation permettent de créer des applications

annuaire-compatibles.
 exemple :
 Java Naming and Directory Interface (JUNI) -- Java (ORACLE-SUN)
 Active Directory Service Interface (ADSI) -- COM (Microsoft)
 U-M LDAP SDK -- C (UMICH, OpenLDAP)
 Innosoft LDAP Client SDK (ILC-SDK) -- C (InnoSoft)
 Netscape Directory SDK -- Java, C (Netscape)
 PerLDAP Modules -- Perl (Netscape)
 Net- LDAPapi -- PERL (GNU)
 …

Salim Benayoune 84