1. Lightweight Directory Access Protocol (LDAP)
Un annuaire, quesako ?
LDAP est un protocole d'accès à un annuaire X.500, normalisé à la fin des
années 1990 ; X.500 étant une norme monstrueuse pour la gestion d'annuaire sur
des réseaux ISO (vous connaissez les couches ISO ?, ou encore les protocoles
réseaux ISO comme DECnet Phase V ou plus proche de nous ISO/DSA de
Bull).
LDAP, donc, dont l'acronyme est Lightweight Directory Access Protocol,
a très rapidement évolué de l'accès à un annuaire X.500 à la gestion complète
d'un annuaire pour les environnements non X.500. C'est ainsi que sont sortis les
annuaires de Netscape et que tout le monde a suivi. Dans le camp du libre,
OpenLDAP est un projet qui a démarré en août 1998, sur la base de la mise en
œuvre de LDAP réalisée par l'Université du Michigan.
Un annuaire, pour quoi faire ?
Un annuaire permet de stocker des données légèrement typées, organisées
selon des classes particulières et présentées dans un arbre. L'exemple le plus
commun, dont il tire son nom est l'annuaire de personnes. Mais on peut y stocker
bien d'autres choses : des comptes Unix, des données personnelles (ce qu'on peut
trouver dans un carnet d'adresses, mais aussi les photos des personnes, etc.), des
données sur des objets plus ou moins abstraits, comme des données
d'identification, des certificats (la distribution de listes de révocation de certificat
peut se faire par LDAP), un parc matériel, et plus généralement tout ce qui peut
être nommé et à qui on peut attacher des informations. Voyons comment
procéder après une petite introduction, et comment Perl va pouvoir nous aider.
Dimitri LEMBOKOLO 1
2. Différences entre un annuaire et un SGBD
Le principe de l'annuaire n'est pas à confondre avec une base de données
relationnelle dont l'objectif est différent. Un annuaire est d'abord conçu pour
recevoir beaucoup plus de requêtes en lecture qu'en écriture. Une base de
données a d'autres objectifs comme un typage fort et une rapidité d'accès en
lecture comme en écriture.
Un annuaire permet donc de stocker des objets, auxquels on peut attacher
des attributs (qui sont typés), organisés dans un arbre. Il existe une
représentation normalisée des données des objets, le format LDIF.
Un autre avantage des annuaires sur les bases de données est la facilité de
mise en œuvre de la réplication. En gros, à chaque modification dans l'annuaire
(qui sont minimes par rapport aux accès en lecture, rappelons-le), ces
modifications sont journalisées et reportées dans les annuaires secondaires, ou
esclaves.
Sur ce dernier point, si l'on fait un parallèle avec les DNS, le
fonctionnement est un peu différent : il n'y a pas la notion de transfert de zones
(on prend toute la base de données pour l'envoyer à son collègue), mais juste la
notification d'un changement (avec la matière du changement). Nous verrons
plus loin que la mise en œuvre de la réplication est relativement simple, mais
nécessite une initialisation manuelle. Un script peut faciliter la chose.
LDAP organise les données de manière arborescente (DIT). Un exemple
d'arborescence est représenté par le schéma suivant:
dc=dimi,dc=sn
ou=télécoms,dc=dimi,dc=sn ou=informatique,dc=dimi,dc=sn
ou=réseaux intelligent,ou=télécoms,dc=dimi,dc=sn
uid=espy,ou=réseaux intelligent,ou=télécoms,dc=dimi,dc=sn
Dimitri LEMBOKOLO 2
3. Fonctionnement
Le protocole LDAP est un système client/serveur. Lorsqu'un client LDAP
se connecte au serveur, il peut soit consulter des informations ou y apporter des
modifications. Dans le cas d'une modification, le serveur vérifie d'abord si le client
est autorisé à effectuer des changements puis met à jour ou ajoute les informations.
La description des comptes utilisateurs et des groupes répond à la norme posix. En
d'autres termes, les informations contenues dans les fichiers /etc/passwd,
/etc/shadow et /etc/group retrouvent leur équivalent dans la structure de base de
données LDAP. C'est ce que l'on appelle schéma.
LDAP écoute sur le port 389.
La maitrise de LDAP passe par la connaissance de certains termes.
Entrée : correspond à une seule unité dans un répertoire LDAP.
Chaque entrée est référencée ou identifiée par son nom distinctif ou
DN unique.
Attributs : ce sont les éléments d'information directement associés à
l'entrée. Parmi les attributs courants utilisés pour les personnes,
figurent les numéros de téléphone et adresses électroniques.
Certains attributs sont obligatoires, tandis que d'autres sont facultatifs.
Une classe d'objets définit les attributs obligatoires et ceux facultatifs. Les
définitions des classes d'objets dans les différents fichiers sont placés dans le
répertoire /etc/openldap/schema.
Les données contenues dans l'annuaire sont présentées dans un certain
format: il s'agit du format LDIF (LDAP Data Interchange Format - RFC 2849).
Toute itération avec un annuaire se fait par le biais de ce format: ajout,
modification, interrogation, suppression. Dans ce format, chaque entrée
constitue un paragraphe et au sein de chaque paragraphe, chaque ligne constitue
un attribut.
Installation et configuration de LDAP
Pour installer LDAP, lancer dans le terminal:
# yum install openldap openldap-servers openldap-clients
Dimitri LEMBOKOLO 3
4. Configuration du serveur
Le fichier de configuration du serveur est /etc/openldap/slapd.conf, donc on
l’édite.
# vim /etc/openldap/slapd.conf
A ce niveau il faut:
Définir la base de notre annuaire ;
Préciser le Distinguished Name (DN) de l'administrateur de
l'annuaire ;
Préciser le mot de passe de l'administrateur.
Dimitri LEMBOKOLO 4
5. Configuration du client
Le fichier de configuration du client est /etc/openldap/ldap.conf.
# vim /etc/openldap/ldap.conf
Il doit être modifié comme suit:
Le fichier /etc/ldap.conf doit également être modifié avec les paramètres.
# vim /etc/ldap.conf
ssl no
tls_cacertdir /etc/openldap/cacerts
pam_password md5
Dimitri LEMBOKOLO 5
6. Nous allons maintenant (re)démarrer le service:
Format de données LDIF
LDIF : LDAP Data Interchange Format. C'est le format de fichier
permettant le chargement et la mise à jour de données dans un annuaire LDAP.
Fichiers ldif
Dans le répertoire /etc/openldap, nous allons créer trois fichiers : l'un qui
nous permettra d'insérer les informations concernant la racine (racine.ldif ou
root.ldif pour mon cas), un autre permettra d'insérer les informations relatives
aux unités organisationnelles (ou.ldif) et un autre pour les utilisateurs (user.ldif
ou utilisateurs.ldif pour mon cas).
root.ldif
Nous verrons plus loin ce que sont les classes d'objets (objectClass).
Disons simplement pour le moment qu'une classe définit les différents attributs
qu'un objet peut ou doit posséder.
Le DN est le distinguished name, à savoir le nom de l'objet dans
l'annuaire. C'est ce nom qui permet de retrouver de façon unique un objet dans
l'arbre des objets. Un objet possède donc toujours un DN, qui reprend
son RDN (relative dn). Ici, le RDN de dc=dimi, dc=sn.
Notez aussi que des espaces peuvent apparaître dans un DN, ils ne sont
pas significatifs autour des virgules, et que si un DN est unique sur l'annuaire, il
n'en est pas de même pour le RDN. Sauf chez Microsoft dans Active Directory
Server. Mais aussi dans POSIX où il vaut mieux éviter d'avoir deux comptes
ayant le même UID (au sens LDAP) dans l'arbre des comptes. Le tout est de
savoir ce que l'on fait.
Dimitri LEMBOKOLO 6
7. Classes d'objets
Quelques classes d'objets :
o : organization.
Cette classe permet de définir le nom de la société ou association qui gère
l'annuaire. Elle peut constituer une racine pour ce même annuaire, avec
des ou en dessous.
ou : organizationalUnit.
Un sous-ensemble d'une organisation. On pourrait le traduire en français
par un service, une entité, un secteur d'une société.
dc : domainComponent.
Composant de nom de domaine (au sens DNS du terme).
Le sn ou dimi dans dimi.sn
person : schéma standard pour une personne.
Elle permet de définir une personne par son nom et son prénom
(aminima), ainsi que, de façon optionnelle, un mot de passe, un numéro de
téléphone, et une description de la personne.
Les classes d'objets permettent donc de regrouper les objets de même
type, avec un plus par rapport à une base de données : un objet peut appartenir à
plusieurs classes en même temps. Ce qui permet de fusionner, autour du même
nom, des données de person, de posixAccount (cette personne a un compte
Unix), de sambaSamAccount (elle a aussi un compte Samba), etc.
Un point à garder en mémoire est que les classes peuvent être de plusieurs
types : ABSTRACT, STRUCTURAL et AUXILIARY. Dans la pratique, on
utilisera essentiellement les deux dernières. Ce typage va nous permettre de
définir des héritages entre classes.
Le type ABSTRACT permet juste de définir une classe dont doivent
dériver d'autres classes. Une classe de type ABSTRACT ne peut avoir aucune
instance d'objet dans l'annuaire.
Le type STRUCTURAL permet de définir une classe qui dérive d'une
autre, la classe racine étant la classe top (elle-même de typeABSTRACT). Le
Dimitri LEMBOKOLO 7
8. point important ici est que dans l'instanciation d'un objet (dans son écriture
LDIF, par exemple), on doit spécifier l'entière hiérarchie des classes. Comme ici
dans notre exemple, où le domain descend de top. Ce mécanisme est peut-être
un peu contraignant (surtout si vous avez à migrer un annuaire OpenLDAP 2.0
vers un 2.1 ou un 2.2, car la version 2.0 ne vous obligeait pas à spécifier toute la
hiérarchie d'objets), mais permet une chose importante : ne pas mélanger
torchons et serviettes. Imaginez en effet que nous ayons à définir des
utilisateurs, mais aussi des groupes. Cela ferait mauvais effet de ne serait-ce que
pouvoir mélanger les genres, et d'avoir un objet qui soit à la fois un groupe et un
utilisateur. Mais comme les classes afférentes aux groupes et utilisateurs sont
structurelles, elles ne peuvent donc être mélangées.
Il existe le dernier type de classe, AUXILIARY, qui permet de s'affranchir
de ce mécanisme d'héritage, et d'attribuer des données complémentaires
(« auxiliaires » dirait-on en bon franglais) à un objet.
Pour en finir avec les classes, sachez que bon nombre de classes sont
définies en standard dans un certain nombre de RFC (comme les RFC 2252 et
2256). Si l'on fait un parallèle (pas si anodin que ça) avec SNMP, on peut
considérer les classes comme des MIB SNMP (cf. Linux Magazine France n°43
d'octobre 2002), que l'on peut créer soi-même, ou dont on peut utiliser les MIB
standards comme la MIB-II (RFC 1213).
Les attributs et les types
Les attributs sont donc définissables pour un objet en fonction de la classe
à laquelle l'objet appartient.
Le typage est relativement faible contrairement à un SGBD. Ou plutôt, il
sert un autre dessein : l'interopérabilité. Les types sont en effet spécifiques aux
annuaires, et permettent de stocker essentiellement des données
alphanumériques, voire des données binaires. Mais il n'est pas complètement
dans le rôle de l'annuaire de vérifier ces types. Sur un SGBD, si.
Il existe une cinquantaine de types de données, certains génériques,
comme « DirectoryString » (chaîne de caractères UTF-8), « INTEGER » ou
« Binary String », d'autres limités à des usages spécifiques, comme « DN »
(Distinguished Name, le nom d'un objet dans un annuaire) ou « JPEG » (image
au format JPEG). Tous les types sont définis dans la RFC 2252. Nous verrons
plus loin, dans l'écriture d'un schéma, que ces syntaxes (le nom des types LDAP)
sont référencées par des OID (oui, les mêmes OID ASN-1 que pour SNMP,
mais dans un espace de nommage différent).
Dimitri LEMBOKOLO 8
9. ou.ldif
utilisateurs.ldif
Schéma
L'endroit où se définissent attributs et classes d'objets, qu'ils soient
standards ou de votre fait, s'appelle un schéma.
Si vous avez un OpenLDAP à votre disposition, via les paquetages
standards de votre distribution Linux, vous pouvez y jeter un coup d'œil. Ils sont
dans /etc/openldap/schema/ ou dans /usr/share/openldap/schema/. Au pire,
un locate schema vous dira où ils se trouvent.
Dimitri LEMBOKOLO 9
10. Insertion de données LDIF
Pour insérer les données définies plus haut, la simple commande suivante
suffit :
Insertion de root.ldif
L'option -c permet de continuer sur des erreurs (un enregistrement défini
dans le fichier LDIF est déjà présent dans l'annuaire). L'option -x permet de
s'affranchir de l'authentification SASL1, et n'avoir qu'à spécifier le mot de
passe. -D indique le DN du compte qui se connecte. -W fera
que ldapadd demandera le mot de passe du Manager. Enfin, -f indiquera le nom
du fichier LDIF à insérer.
Insertion des ou.ldif
Insertion des utilisateurs.ldif
Dimitri LEMBOKOLO 10
1 Simple Authentication and Security Layer (signifiant « Couche
d'authentification et de sécurité simple » ou SASL)
12. Tout comme phpmyadmin, nous avons phpldapadmin pour gérer de façon
conviviale notre annuaire LDAP en mode graphique.
PHPLDAPADMIN
PHPLDAPADMIN étant une application web, il peut être utilisé de
n'importe où. Il faut bien entendu avoir démarré httpd au préalable.
Pour l'installation, lancer « yum install phpldapadmin ».
# yum install phpldapadmin
Ensuite, dans un navigateur, taper l'URL http://localhost/phpldapadmin
puis nous avons l'interface :
Se connecter en tant que Manager:
Dimitri LEMBOKOLO 12
13. Une fois connectée nous remarquons à gauche la présence de
l'arborescence que nous pouvons modifier à notre guise.
Dans le modèle proposé par LDAP, les serveurs réplicas ne détiennent
que des copies des données de la base originale. Les modifications ne doivent
être faîtes que sur le serveur principal et propagées ensuite sur les serveurs
réplicas.
Plusieurs applications nécessitant une authentification peuvent être
couplées avec un annuaire LDAP comme on le ferait avec une base de données
classique. Nous allons procéder au couplage http/ldap pour permettre aux
utilisateurs de LDAP de se connecter à une page web sécurisée puis le couplage
proftp/ldap pour permettre aux utilisateurs de LDAP de se connecter au serveur
ftp afin de télécharger des fichiers.
Dimitri LEMBOKOLO 13
14. Couplage LDAP http
Dans le fichier /etc/httpd/conf/httpd.conf ajoutez les lignes suivantes:
Ensuite créez le répertoire inscription dans /var/www/html/ puis
redémarrer httpd « service httpd restart ».
# service httpd restart
Dans le navigateur, tapez l'URL http://192.168.1.70/inscription puis vous
aurez la fenêtre:
Dimitri LEMBOKOLO 14
15. Nous remarquons que cette méthode nous permet aisément de n'autoriser
que les utilisateurs se trouvant dans notre annuaire à accéder au contenu du
dossier inscription.
Dimitri LEMBOKOLO 15