25.2. Structure d'une arborescence LDAP

Les annuaires LDAP possèdent une structure arborescente. Toutes les entrées (appelées objets) de l'annuaire ont une position définie au sein de cette hiérarchie. Cette hiérarchie est appelée DIT (directory information tree), ou arborescence d'informations d'annuaire. Le chemin complet menant à une entrée et permettant de l'identifier sans ambiguïté est appelé nom distinctif ou DN (distinguished name). Un noeud unique situé le long du chemin vers cette entrée est appelé nom distinctif relatif ou RDN (relative distinguished name). Les objets peuvent généralement être affectés à l'un des deux types possibles :

conteneur

Ces objets peuvent eux-mêmes contenir d'autres objets. Les classes d'objet correspondantes sont root (élément racine de l'arborescence, qui n'existe pas réellement), c (pays), ou (unité organisationnelle) et dc (composant de domaine). Ce modèle est comparable aux répertoires (dossiers) d'un système de fichiers.

feuille

Ces objets se situent en bout de branche et n'ont pas d'objets subordonnés. On peut citer par exemple person, InetOrgPerson ou groupofNames.

Au sommet de la hiérarchie d'annuaire se trouve l'élément racine root. Celui-ci accepte les éléments subordonnés de type c (pays), dc (composant de domaine) ou o (organisation). Les relations au sein d'une arborescence d'annuaire LDAP deviennent plus évidentes à la lumière de l'exemple suivant, illustré dans la Figure 25.1, « Structure d'un annuaire LDAP ».

Figure 25.1. Structure d'un annuaire LDAP

Structure d'un annuaire LDAP

L'organigramme complet comprend une arborescence d'informations d'annuaire fictive. Les entrées sont représentées sur trois niveaux. Chaque entrée correspond à une case sur l'image. Le nom distinctif complet et valide de l'employé SUSE fictif Geeko Linux est cn=Geeko Linux,ou=doc,dc=suse,dc=de dans ce cas. Il est formé par adjonction du nom distinctif relatif (RDN) cn=Geeko Linux au nom distinctif (DN) de l'entrée précédente ou=doc,dc=suse,dc=de.

La détermination globale des types d'objets pouvant être stockés dans la DIT est effectuée suivant un modèle. Le type d'un objet est déterminé par la classe d'objet. La classe d'objet détermine les attributs devant ou pouvant être affectés à l'objet concerné. Le modèle doit par conséquent contenir des définitions de toutes les classes d'objets et attributs utilisés dans le scénario d'application désiré. Il existe peu de modèles communs (reportez-vous à RFC 2252 et à 2256). Il est néanmoins possible de créer des modèles personnalisés ou d'utiliser plusieurs modèles se complétant mutuellement si l'environnement dans lequel le serveur LDAP doit fonctionner l'exige.

La Tableau 25.1, « Classes d'objets et attributs couramment utilisés » offre un petit aperçu des classes d'objets de core.schema et inetorgperson.schema utilisées dans l'exemple, comprenant les attributs requis et les valeurs d'attributs valides.

Tableau 25.1. Classes d'objets et attributs couramment utilisés

Classe d'objets

Signification

Exemple d'entrée

Attributs obligatoires

dcObject

domainComponent (nommez les composants du domaine)

suse

dc

organizationalUnit

organizationalUnit (unité organisationnelle)

doc

ou

inetOrgPerson

inetOrgPerson (données associées à une personne pour l'intranet ou Internet)

Geeko Linux

sn et cn

Exemple 25.1, « Extrait de schema.core  » montre un extrait d'une directive de modèle avec des explications (la numérotation des lignes sert aux explications).

Exemple 25.1. Extrait de schema.core

#1 attributetype (2.5.4.11 NAME ( 'ou' 'organizationalUnitName')
#2        DESC 'RFC2256: organizational unit this object belongs to'
#3        SUP name )

...
#4 objectclass ( 2.5.6.5 NAME 'organizationalUnit'
#5        DESC 'RFC2256: an organizational unit'
#6        SUP top STRUCTURAL
#7        MUST ou
#8 MAY (userPassword $ searchGuide $ seeAlso $ businessCategory 
    $ x121Address $ registeredAddress $ destinationIndicator 
    $ preferredDeliveryMethod $ telexNumber 
    $ teletexTerminalIdentifier $ telephoneNumber 
    $ internationaliSDNNumber $ facsimileTelephoneNumber 
    $ street $ postOfficeBox $ postalCode $ postalAddress 
    $ physicalDeliveryOfficeName
    $ st $ l $ description) )
...

Le type d'attribut organizationalUnitName et la classe d'objet correspondante organizationalUnit servent ici d'exemple. La ligne 1 indique le nom de l'attribut, son OID unique (identificateur d'objet) (numérique) et l'abréviation de l'attribut.

La ligne 2 donne une brève description de l'attribut avec DESC. La requête RFC correspondante, sur laquelle la définition est basée, est également mentionnée ici. Dans la ligne 3, SUP indique un type d'attribut générique auquel appartient cet attribut.

La définition de la classe d'objet organizationalUnit commence à la ligne 4, comme pour la définition de l'attribut, avec un OID et le nom de la classe d'objet. La ligne 5 contient une brève description de la classe d'objet. L'entrée SUP top dans la ligne 6 indique que cette classe d'objet n'est pas subordonnée à une autre classe d'objet. La ligne 7, qui commence par MUST, répertorie tous les types d'attributs qui doivent être utilisés en association avec un objet de type organizationalUnit. La ligne 8, introduite par MAY, répertorie tous les types d'attributs qui sont autorisés en association avec cette classe d'objet.

Une très bonne introduction à l'utilisation de modèles est disponible dans la documentation sur OpenLDAP. Si elle est installée, vous la trouverez dans /usr/share/doc/packages/openldap2/admin-guide/index.html.