7. Meta recherche
La [rfc2251] dans sa section 3.4 a prévu un
mécanisme permettant de découvrir les extensions, les
contrôles et le schéma d'un serveur annuaire. Cela permet au
client d'interagir au mieux avec un serveur, en évitant, par exemple, de
créer ou de modifier des objets de façon illégale vis
à vis du schéma, ou bien de ne demander que les contrôles
et les opérations étendues implémentées par le
serveur.
a. Le Root DSE
Pour obtenir des informations sur les capacités d'un
annuaire il faut interroger une entrée spéciale qui s'appelle le
Root DSE. Cette entrée n'a aucun DN, et doit être
récupérée avec le filtre (objectclass=*). Elle ne
doit pas être retournée autrement que par une requête avec
ce filtre et dont le base_dn est vide. Elle peut être soumise à
des restrictions de contrôle d'accès. La [rfc2251] précise
que le serveur pourrait autoriser la modification des attributs de cette
entrée, mais Openldap lui ne le permet pas.
Voici la liste des attributs d'un Root DSE définis par
[rfc2251] :
|
namingContexts
|
Liste des suffixes gérés par le serveur
|
|
subschemaSubentry
|
DN de l'entrée subschema. Cette entrée contient une
description du schéma gérée par le serveur. Cet attribut
peut être absent si le serveur ne gère pas lui même des
entrées schéma. Il est multiple, dans le cas où le serveur
gère plusieurs annuaires, chacun ayant son propre schéma
|
|
altServer
|
Serveur à contacter si le serveur ne répond plus
|
|
supportedExtension
|
Liste des opérations étendues supportées
|
|
supportedControl
|
Liste des contrôles supportés
|
|
supportedSASLMechanisms
|
Liste des fonctionnalités SASL supportées
|
|
supportedLDAPVersion
|
Version du protocole LDAP supportée par le serveur
|
Tableau 9: attributs du Root
DSE
b. Les entrées
subschema
Nous venons de voir comment récupérer un certain
nombre d'information sur un annuaire, et en particulier comment
récupérer le DN des entrées subschema. Comme le Root DSE,
les entrées subschema sont des entrées particulières d'un
serveur, qui ne sont pas placées sous la racine de l'annuaire. Ces
entrées décrivent le schéma supporté par le
serveur, c'est à dire la liste des objets, des attributs, des
règles de comparaison, etc. qu'il connaît. Il est possible,
d'après la [rfc2251] de modifier ses entrées, mais ce n'est pas
obligatoire pour respecter la version 3 de la norme LDAP.
La section 3.2.2 de cette RFC définit la liste des
attributs d'une entrée subschema. Certains attributs sont obligatoires,
d'autres pas. Cette liste est la suivante:
|
cn
|
Cet attribut doit être le RDN de l'entrée subschema.
Cet attribut est obligatoire dans une entrée subschema
|
|
objectClass
|
Il s'agit des classes de l'entrée subschema. Il doit au
moins contenir les valeurs top et subschema. Cet attribut est
obligatoire dans une entrée subschema
|
|
objectClasses
|
Cet attribut multivalué contient les classes
gérées par le serveur. Il a autant de valeurs que de classes
gérées. Cet attribut est obligatoire dans une entrée
subschema
|
|
attributeTypes
|
Cet attribut multivalué contient les attributs
gérés par le serveur. Il a autant de valeurs que d'attributs
gérés. Cet attribut est obligatoire dans une entrée
|
|
matchingRules
|
Liste des règles de comparaison gérées par
le serveur. Cet attribut a autant de valeur que de règles, et n'est pas
obligatoire
|
|
matchingRuleUse
|
Usage des règles de comparaison. Il y a autant de valeurs
de cet attribut que de règles de comparaison. Et pour chaque
règle, une valeur contient la liste des attributs sur lesquels elle
s'applique. Cet attribut n'est pas obligatoire
|
|
ldapSyntaxes
|
Liste des syntaxes supportées par le serveur. Cet attribut
n'est pas obligatoire
|
Tableau 10: les entreés
subschema
Les attributs dITStructureRules,
dITContentRules, nameForms existent aussi, et
sont optionnels. Ils ne sont pas supportés par Openldap. Ils
décrivent des règles sur l'arbre informationnel.
| 
