Lightweight Directory Access Protocol (LDAP)

Structuration de l'annuaire par schéma

Définir son propre schéma

Pour mettre en place un annuaire LDAP, trois étapes principales sont nécessaires :

La définition du schéma se fait généralement selon certaines conventions qui sont soit définies dans la norme LDAP, soit dans des documents associés (par exemple les noms d'attributs pour la gestion de comptes POSIX), soit proposés par les solutions propriétaires comme Microsoft Active Directory.

Par exemple, dans AD, le nom de l'utilisateur est définit par l'attribut SAMaccountName, alors que dans les conventions LDAP pour POSIX, il est stocké dans l'attribut uid.

De manière générale, les conventions suivantes sur les classes d'objets s'appliquent :

Classe Types d'informations associées
organization (structural) Racine de l'annuaire LDAP, ou d'une des entreprises de l'annuaire LDAP si l'annuaire référence plusieurs entreprises (comme une maison mère et ses filiales).
organizationalUnit (structural) Pour les unités structurantes de l'annuaire, qui sont placées soit directement comme enfant d'une entrée organisation, soit comme enfant d'une autre unité organisationnelle.
inetOrgPerson (structural) Utilisé pour décrire un utilisateur du système d'information.
groupOfUniqueNames (structural) Pour définir un groupe référençant plusieurs entrées du LDAP de type inetOrgPerson. Utilisé par exemple pour créer des groupes d'étudiants par matière (pour une école), ou pour identifier les utilisateurs d'un logiciel en particulier (un groupe par logiciel ou par rôle au sein d'un logiciel par exemple).
posixAccount (auxiliaire) Utilisée pour définir les attributs nécessaires à la description d'un compte POSIX (tous les attributs permettant de remplacer le fichier /etc/passwd d'Unix).

Schéma spécifique à des applications

Certaines applications sont conçues pour augmenter le schéma des annuaires LDAP en ajoutant ses propres classes auxiliaires, et ses propres attributs. Ceci est spécialement utilisé par les applications de messagerie, pour les architectures PKI, ou encore pour toute application nécessitant l'ajout d'informations qui sont très rarement écrites mais fréquemment lues.

Du point de vue du développeur, tant que cela est possible, il est préférable d'éviter de rendre son application dépendante d'une modification de schéma. En effet, les administrateurs de l'annuaire sont souvent réticents à accorder des droits en écriture à un compte, ou à apporter des modifications au schéma de celui-ci.

Cependant, certaines applications imposent ces modifications. Il appartient alors à l'administrateur de vérifier le contenu des modifications apportées au schéma, et de valider ou non l'installation du logiciel, comme c'est le cas pour n'importe quel logiciel. La configuration de LDAP doit donc faire partie du plan de déploiement des applications d'entreprise.

Définir sa hiérarchie

Il n'y a pas de "bonnes pratiques" générales pour définir la hiérarchie de son annuaire LDAP. Cependant, on observe globalement ces conventions :

Entrée Description
dc=nom_entreprise,dc=type_entreprise Racine de l'annuaire, avec nom_entreprise le nom de l'entreprise (ou ses initiales) et type_entreprise un code parmi edu, net, org, com ou un code pays ISO. Enfant du DSE Root.
ou=groups Unité organisationnelle contenant la liste des groupes (groupOfUniqueNames) auxquels les utilisateurs peuvent appartenir. Enfant de la racine de l'annuaire.
ou=... Généralement, les administrateurs créent une unité organisationnelle par type d'utilisateur, pour distinguer le personnel administratif, du personnel technique, des intervenants externes, des applications... De plus, vous pouvez aussi créer une OU pour stocker les informations sur les ressources du réseau (adresses MAC, adresses IP, ordinateurs, serveurs, imprimantes, routeurs...).

Un exemple de hiérarchie est défini dans la présentation associée à cet exposé.

Suite [Architecture Réseau et Intégration] >>>