• 2 heures
  • Moyenne

Mis à jour le 08/01/2019

Modèle d'information

Connectez-vous ou inscrivez-vous gratuitement pour bénéficier de toutes les fonctionnalités de ce cours !

L'arborescence d'informations (DIT)

LDAP présente les informations sous forme d'une arborescence d'informations hiérarchique appelée DIT (Directory Information Tree).

Arborescence expliquée
Arborescence expliquée
  • L'entrée est l'unité de base d'un annuaire (DSE, Directory Service Entry). Elle correspond à une branche de l'arborescence.

  • Chaque entrée correspond à un objet appelé objectClass, par exemple une personne, un objet matériel, des paramètres, …

  • Cet objectClass est constituée d'un ensemble de paires clés/valeurs appelées attributs obligatoires ou facultatifs.

  • Les types d'attributs sont des règles de codage et de correspondance, qui détermine les types données et les comparaisons à appliquer lors d'une recherche.

  • Le schéma c'est l'ensemble des définitions d'objets et d'attributs qu'un serveur LDAP peut gérer. Cela permet de définir si un attribut peut avoir une ou plusieurs valeurs et/ou de les regrouper par objet (objectclass) pour définir s'ils sont obligatoires ou pas.

DN et RDN

Une entrée est indexée par un nom distinct (DN, distinguished name) permettant d'identifier de manière unique un élément. Un DN se construit en prenant le nom de l'élément, appelé Relative Distinguished Name (RDN, c'est-à-dire le chemin de l'entrée par rapport à un de ses parents), et en lui ajoutant l'ensemble des nom des entrées parentes.

Le DN et le RDN est comparable au chemin d'un fichier dans un répertoire. Le DN, c'est le chemin complet. Il est unique mais n'est pas figé. Il permet de déterminer la place dans l'arbre de l'entrée, car il concatène les RDN au-dessus de lui, mais l'entrée peut être déplacée, et le DN donc redéterminé.

Dans l'exemple d'arborescence ci-dessus :

  • DN (Distinguished Name) : uid=Jean-Christian Ranu,ou=users,dc=cogip,dc=fr

  • RDN (Relative Distinguished Name) : uid=Jean-Christian Ranu

Le RDN peut avoir plusieurs valeurs, comme un clé primaire composite (faite de plusieurs champs) dans un SGBD.

Imaginons qu'il y ait à la COGIP des personnes ayant le même nom (Jean Martin), placé sous le même parent (ou=users). Ni le cn (common name), ni l'ou (organisational unit) ne serait unique. La combinaison des deux en revanche donne un RDN unique. Il faut dans ce cas séparer les valeurs par "+".

# 1ere personne
dn: cn:Jean Martin+ou:ventes,ou=users,dc=cogip,dc=fr
cn: Jean Matin ou:ventes
[...]
.
# 2eme personne
dn cn:Jean Martin+ou:compta,ou=users,dc=cogip,dc=fr
cn: Jean Martin
ou: compta
[...]

Les attributs

Une entrée peut avoir un ou plusieurs attributs. Il est séparé de sa valeur par ":" et peut avoir plusieurs valeurs. Il est alors sur plusieurs lignes avec des valeurs différentes.

dn: cn:Jean Martin+ou:ventes,ou=users,dc=cogip,dc=fr
objectClass: person
cn: Jean Matin
ou:ventes
[...]
telephoneNumber: +33 1 02 03 04 05
telephoneNumber: +33 9 08 07 06 05
[...]

Chaque entrée est constituée d'un ensemble d'attributs. Il existe deux types d'attributs :

  • Les attributs normaux : ceux-ci sont les attributs habituels (nom, prénom, ...) caractérisant l'objet 

  • Les attributs opérationnels : ceux-ci sont des attributs auxquels seul le serveur peut accéder afin de manipuler les données de l'annuaire (dates de modification, ...)

Les classes d'objets

L'objectClass est un regroupement d'attributs qui définit une entrée, comme une classe en POO a des propriétés qui représentent l'objet. Ces attributs sont obligatoires ou facultatifs.

objectClass est lui-même un attribut obligatoire d'une entrée, qui peut avoir un ou plusieurs objectClass. Ces classes d'objet définissent la présence de tous les attributs d'une entrée.

dn: cn:Jean-christian Ranu,ou=users,dc=cogip,dc=fr
objectClass: person

objectClass: posixAccount

Le caractère obligatoire ou facultatif des attributs, ainsi que le type de classe, sont définis dans les schémas.

Il existe 3 types de classe d'objet.

  • Structurelle : représente un objet réel, tel que personne, domaine ou entité... Chaque entrée doit avoir au moins 1 classe d'objet structurelle dans l'attribut objectClass.

  • Auxiliaire : sert à compléter les informations d'une classe structurelle. Elle ne peut pas être employé seule.

  • Abstraite : comme en POO,  elle ne peut être qu'étendue par une autre classe d'objet, et ne peut pas être utilisée directement.

Les schémas

De le même façon que les objectClass regroupe les attributs, les schéma listent tous les objectClass disponibles. Un annuaire peut avoir plusieurs schémas (chargés au démarrage de LDAP).

Les schémas définissent aussi la correspondance, la syntaxe et les types d'attributs. Il est également possible d'ajouter son propre schéma, et donc de nouveaux objets.

Type d'attribut

Chaque type d'attribut doit être identifié par un OID. Chaque type d'attribut doit avoir au moins un attribut SUP, si aucune syntaxe (SYNTAX) n'est spécifiée, on prend alors celle du supertype

attributetype ( 2.5.4.20 NAME 'telephoneNumber'
DESC 'An integer uniquely identifying a user in a domain'
EQUALITY telephoneNumberMatch
SUBSTR telephoneNumberSubstringMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 )

L'OID de telephoneNumber est 2.5.4.20. La valeur est évaluée avec telephoneNumberMatch, et doit contenir ce que spécifié dans telephoneNumberSubstringMatch. 1.3.6.1.4.1.1466.115.121.1.50 correspond à la syntaxe du n° de téléphone, exemple: +1 234 567 8901.

Liste des propriétés utilisées pour définir un type d'attribut

NAME

Nom du type d'attribut

DESC

Description

OBSOLETE

indique si le type d'attribut est actif

SUP

définit le supertype

EQUALITY

Type d'égalité à mettre en œuvre lors d'une recherche

ORDERING

Correspondance de tri

SUBSTR

Correspondance de subtring

SYNTAX

OID de la syntaxe, et nombre maxi de caractère entre accolade {}

SINGLE-VALUE

restreint à une seule valeur

COLLECTIVE

si type d'attribut est collectif

NO-USER-MODIFICATION

l'utilisateur ne peut pas le modifier

USAGE

indique l'application

objectClass

Comme les attributs, l'objectClass est toujours identifié par un OID.

( 2.5.6.6 NAME 'person'
 SUP top
 STRUCTURAL
 MUST ( sn $ cn )
 MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

La classe person étend la classe top et est une classe structurelle, c'est-à-dire qu'elle représente un objet réel. Les attributs sn et cn sont obligatoires; Les autres userPassword, telephoneNumber, seeAlso, description sont facultatifs.

Liste des propriétés utilisées pour définir un objectClass

NAME

Nom de la classe

Type d'objet

STRUCTURAL, ABSTRACT, AUXILIARY (cf. Les classes d'objet)

DESC

Description de la classe

OBSOLETE

spécifie que cette classe ne doit plus être utilisée

AUX

Liste les classes auxquelles cet objet peut appartenir

MUST

regroupe les attributs d'un objectClass qui doivent être présent, ou au moins une valeur.

MAY

liste les attributs facultatifs.

NOT

Liste les attributs qui ne doivent pas être utilisés

SUP

Classe parent étendue. (toutes les entrées héritent directement ou indirectement de la class top).

Le format LDIF

Pour importer/exporter les données ainsi que la configuration du serveur, un format a été défini (RFC 2849) : LDIF (LDAP Data Interchange Format).

  • les commentaires commencent par "#", et s'étendent sur une seule ligne

  • Une entrée forme un paragraphe, et un fichier LDIF ne s'affranchit pas des schémas, qui valident une entrée.

  • Chaque ligne constitue un attribut.

  • Comme vu auparavant, les attributs sont constitués d'une clé et d'une valeur séparée par ":".

Prenons l'exemple de Jean-Christian Ranu pour faire une entrée dans un fichier LDIF pour import.

 dn: cn=Jean-Christian Ranu,ou=ventes,dc=cogip,dc=fr
 objectClass: top
 objectClass: person
 objectClass: organizationalPerson
 objectClass: inetOrgPerson
 cn: Jean-Christian Ranu
 cn: JC Ranu
 displayName: Jean-Christian Ranu
 sn: Ranu
 givenName: Jean-Christian
 initials: JCR
 title: manager, product development
 uid: jcranu
 mail: jc.ranu@cogip.fr
 telephoneNumber: +33 1 02 03 04 05
 mobile: +33 6 78 90 01 02
 o: COGIP
 ou: ventes
 departmentNumber: 2604
 employeeNumber: 42
 employeeType: full time
 preferredLanguage: fr, en-gb;q=0.8, en;q=0.7
 labeledURI: http://www.cogip.fr/users/jcranu
Exemple de certificat de réussite
Exemple de certificat de réussite