Un annuaire LDAP utilise une structure arborescente. Tous les enregistrements (ou objets) de l'annuaire ont une position définie au sein de cette hiérarchie. Celle-ci est connue sous le nom d'arbre d'informations d'annuaire (Directory Information Tree ou DIT. Le chemin complet vers l'enregistrement souhaité permettant de l'identifier de manière unique est le nom distingué (Distinguished name) ou DN. Les différents nœuds du chemin vers cet enregistrement sont des noms distingués relatifs (Relative Distinguished Name) ou RDN. Les objets peuvent généralement être rattachés à deux types distincts :
Ces objets peuvent contenir à leur tour d'autres objets. Ces
classes d'objet sont Root (élément racine de
l'arborescence qui n'existe pas réellement), c (pays,
de l'anglais country), ou (unité
d'organisation, de l'anglais organizational unit) et
dc (composant de domaine, de l'anglais domain
component). Ce type d'objets peut également être comparé aux
répertoires (dossiers) du système de fichiers.
Ces objets sont localisés à l'extrémité d'une branche. Aucun
autre objet ne leur est rattaché. Les exemples sont
person, InetOrgPerson et
groupofNames.
Un élément racine root se trouve à la tête de
l'arborescence. Vous pouvez lui rattacher au niveau suivant au choix
c (pays), dc (composant de domaine) ou
o (organisation). Les relations à l'intérieur d'une
arborescence LDAP sont illustrées par l'exemple ci-après illustré
dans Figure 29.1, « Structure d'un annuaire LDAP ».
L'illustration décrit un Directory Information
Tree fictif. Elle représente les enregistrements (entries) sur
trois niveaux. Chaque enregistrement est représenté dans l'illustration par
un rectangle. Le nom distingué (Distinguished
Name) complet de l'employé de SUSE fictif, Geeko Linux est en l'occurrence
cn=Geeko Linux,ou=doc,dc=suse,dc=de. Il est formé en
ajoutant le RDN cn=Geeko Linux au DN de l'enregistrement
précédent ou=doc,dc=suse,dc=de.
Les types d'objets qu'on a décidé a priori d'enregistrer dans le DIT sont décrits par un schéma. Le type correspondant à un objet est défini par la classe d'objet. Celle-ci définit les attributs qui doivent ou qui peuvent être rattachés à l'objet concerné. Par conséquent, un schéma doit comporter les définitions de toutes les classes d'objets ainsi que les attributs utilisés dans le scénario de mise en œuvre souhaité. Il existe un certain nombre de schémas utilisables de manière générale (voir RFC 2252 et 2256). Il est également possible, toutefois, de créer des schémas personnalisés ou d'en utiliser plusieurs sur une base de complémentarité, lorsque cela est requis par l'environnement dans lequel le serveur LDAP doit être mis en œuvre.
Tableau 29.1, « Classes d'objets et attributs fréquemment utilisés » donne un aperçu des classes d'objet
de core.schema et de
inetorgperson.schema utilisées dans l'exemple, y
compris les attributs obligatoires requis et les valeurs d'attributs
admises.
Tableau 29.1. Classes d'objets et attributs fréquemment utilisés
|
Classe d'objet |
Signification |
Exemple d'enregistrement |
Attributs requis |
|---|---|---|---|
|
dcObject |
domainComponent (éléments constituant le nom du domaine) |
suse |
dc |
|
organizationalUnit |
organizationalUnit (unité d'organisation) |
doc |
ou |
|
inetOrgPerson |
inetOrgPerson (données nominatives pour intranet ou Internet) |
Geeko Linux |
sn et cn |
Exemple 29.1, « Extrait de schema.core (les lignes ont été numérotées pour plus de clarté) » montre un extrait d'une instruction de schéma avec des explications.
Exemple 29.1. Extrait de schema.core (les lignes ont été numérotées pour plus de clarté)
...
#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) )
...L'exemple présente le type d'attribut
organizationalUnitName et la classe d'objet
correspondante organizationalUnit. La ligne 1 énumère le
nom de l'attribut, son OID (identificateur d'objet, Object
Identifier) (numérique) ainsi que la forme abrégée de
l'attribut.
La ligne 2 introduit avec DESC une brève
description de l'attribut. Le RFC correspondant sur lequel est basée la
définition y est également mentionné. SUP à la ligne 3
renvoie à un type d'attribut hiérarchiquement de niveau supérieur auquel cet
attribut est rattaché.
La définition de la classe d'objet
organizationalUnit commence à la ligne 4 par la
définition d'attribut avec un OID et le nom de la classe d'objet. La ligne 5
comporte une brève description de la classe d'objet. À la ligne 6,
l'enregistrement SUP top spécifie que cette classe
d'objet n'est la sous-classe d'aucune classe d'objet. La ligne 7, commençant
par MUST, énumère tous les types d'objets
obligatoirement présents dans un objet de type
organizationalUnit. La ligne 8 énumère, après
MAY, tous les types d'attributs pouvant être utilisés
dans cette classe d'objet.
Vous trouverez une excellente introduction à l'utilisation des
schémas dans la documentation OpenLDAP. Lorsque OpenLDAP est installé, vous
la trouverez à l'emplacement
/usr/share/doc/packages/openldap2/admin-guide/index.html.