Académique Documents
Professionnel Documents
Culture Documents
M. Jean DIOKH
Un annuaire électronique est une base de donnée spécialisée, dont la fonction première est de
retourner un ou plusieurs attributs d'un objet grâce à des fonctions de recherche multicritères.
Contrairement à un SGBD, un annuaire est très performant en lecture mais l'est beaucoup moins en
écriture. Sa fonction peut être de servir d'entrepôt pour centraliser des informations et les rendre
disponibles, via le réseau à des applications, des systèmes d'exploitation ou des utilisateurs.
Lightweight Directory Access Protocol (LDAP) est né de la nécessaire adaptation du protocole DAP
(protocole d'accès au service d'annuaire X500 de l'OSI) à l'environnement TCP/IP. Initialement frontal
d'accès à des annuaires X500, LDAP est devenu en 1995, un annuaire natif (standalone LDAP)
Les différents annuaires sont référencés par un système de nommage hiérarchique. Un annuaire est
structuré par une arborescence hiérarchique appelé le Directory Information Tree (DIT). Il est composé
d’entrées, eux même composés de classe d'objets possédant des attributs contenants les données.
L'organisation des classes d'objet est définit par un schéma.
1.3 Schéma
Le schéma représente la définition des classes d'objet, de leur dépendances, de leur attributs, la
syntaxe autorisé pour ces attributs, ainsi qu'une caractérisation de ces données pour faciliter les
opérations de recherche (chiffre, lettre, sensible à la casse, données binaires, etc ...)
Le schéma peut être défini à part dans un fichier texte ou dans l'annuaire lui-même dans les versions
récentes.
1.4 Le protocole LDAP
La norme X500 ne prévoyant pas à l’origine de protocole d’interrogation des annuaires, une
proposition de protocole a été faite en 1993 par l’université du Michigan pour un créer un protocole
qui, fonctionnant sur TCP/IP, assurerait des requêtes simples à un annuaire X500 : c’était la naissance
de LDAP (Leightweight Directory Access Protocol). Les annuaires X500 en place durent donc
implémenter une couche serveur pour le protocole LDAP afin de pouvoir répondre aux requêtes des
clients exploitant ce nouveau protocole.
Rapidement, le succès du protocole LDAP fut tel qu’on oublia le rôle fondateur de X500 pour ne plus
parler que d’annuaires LDAP. Et on parle aujourd’hui d’annuaire LDAP pour tout annuaire capable de
répondre à des requêtes LDAP. Les éléments de structure et de dénominations X500 ont néanmoins
perduré et on parle toujours d’objets, de conteneurs et de schéma.
LDIF (LDAP Data Interchange Format - Format d’échange des données LDAP) a pour objet de
permettre l’exportation ou l’importation des données depuis ou vers un annuaire LDAP. LDIF décrit un
format de fichier texte qui contient tout ou partie des données d’un annuaire LDAP. On peut y
mentionner l’intégralité des objets et de leurs attributs, ou seulement une sélection. Le format LDIF
est employé par de nombreux utilitaires LDAP.
dn: nom_distinctif
attribut1: valeur1
attribut2: valeur2
...
attributn: valeurn
Il est tentant de considérer LDIF comme un format privilégié pour échanger des données d’un annuaire
vers un autre, en cas de migration ou d’échanges de données. En fait, les fichiers LDIF décrivent les
objets d’un annuaire conformément à son schéma, et il est bien rare que deux annuaires différents
présentent rigoureusement le même schéma. Pour ces raisons, le format LDIF n’est en général utilisé
que pour manipuler les données d’un même annuaire, dans le cas d’une sauvegarde par exemple. Les
solutions de méta-annuaires qui permettent ce type de synchronisation exploitent généralement un
format plus ouvert comme le format XML.
2 Mise en œuvre d’un annuaire avec OpenLDAP
OpenLDAP est l’implémentation de serveur LDAP open source la plus courante sur les systèmes Linux.
Si elle manque cruellement de convivialité par rapport à ses équivalents commerciaux, elle n’en est
pas moins répandue dans toutes sortes d’implémentation qui vont de la centralisation de
l’authentification à la gestion de comptes et carnets d’adresses pour les messageries.
1.6 Installation
Le service openldap est géré par un script normalisé dans le répertoire /etc/init.d. Son nom est
variable et dépend de la distribution. L’ambiguïté vient du fait que le protocole applicatif est LDAP,
alors que le nom de l’exécutable est slapd et le nom du produit applicatif openldap.
1.8 Configuration
On se déplace dans de le dossier /etc/openldap et on fait appel à la commande sed, l’éditeur de flux.
New password:
{SSHA}HAGynLYDPwej3WD41BfUcI0xP6jJvrzC
[root@srv-diokh openldap]#
NB : dans le fichier slapd.conf, une ligne commençant par un espace est la continuité de la ligne
précédente.
rootdn "cn=Manager,dc=test,dc=sn"
rootpw {SSHA}HAGynLYDPwej3WD41BfUcI0xP6jJvrzC
access to *
by dn.exact="cn=Manager,dc=test,dc=sn" read
by * none
URI ldap://192.168.1.20/
BASE dc=test,dc=sn
3 Outils en ligne de commande LDAP
dn: dc=test,dc=sn
objectclass: organization
objectclass: dcObject
o: test
dc: test
Requête simple:
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
[root@srv-diokh openldap]#
Requête simple sans l'affichage des commentaires
dn: ou=informatique,dc=test,dc=sn
objectclass: organizationalUnit
ou: informatique
dn: ou=telecoms,dc=test,dc=sn
objectclass: organizationalUnit
ou: telecoms
dn: cn=telecoms,dc=test,dc=sn
objectclass: posixGroup
cn: telecoms
gidNumber: 1000
dn: uid=jean,ou=telecoms,dc=test,dc=sn
objectclass: account
objectclass: posixAccount
objectclass: shadowAccount
uid: jean
userPassword: passer
uidNumber: 1000
gidNumber: 1000
cn: Jean DIOKH
homeDirectory: /home/jean
loginShell: /bin/bash
La recherche se fait avec la commande ldapsearch du client. La commande utilise les mêmes
options que la commande ldapadd. Le résultat de la recherche est affiché au format LDIF avec
des détails. L’ajout de l’option -L affiche le résultat au format LDIFv1, une seconde option –L
élimine les commentaires et la troisième option -L pour omettre la version.
On a aussi l'option -s base, one, sub , children pour définir le niveau de la rechercher:
dn: ou=telecoms,dc=test,dc=sn
objectClass: organizationalUnit
ou: telecom
ou: telecoms
dn: cn=telecoms,ou=telecoms,dc=test,dc=sn
objectClass: posixGroup
cn: telecoms
gidNumber: 1000
[root@srv-diokh openldap]#
3.6 Les filtres
Pour avoir des informations sur l'entrée qui a pour uid jean :
dn: <distinguishedname>
changetype: <[modify|add|delete|modrdn]>
replace: <attributetype>
<attrdesc>: <value1>
Vérification
[root@srv-diokh openldap]# ldapsearch -x -LLL "(uid=jean)" descriptiondn:
uid=jean,ou=telecoms,dc=test,dc=sn
description: Cours Linux
[root@srv-diokh openldap]#
Suppression d'un attribut
dn: uid=jean,ou=telecoms,dc=test,dc=sn
changetype: modify
delete: description
Vérification
[root@srv-diokh openldap]# ldapsearch -x -LLL "(uid=jean)" descriptiondn:
uid=jean,ou=telecoms,dc=test,dc=sn
[root@srv-diokh openldap]#
dn: uid=user4,ou=informatique,dc=test,dc=sn
uid: user4
dn: uid=user1,ou=informatique,dc=test,dc=sn
uid: user1
dn: uid=user2,ou=informatique,dc=test,dc=sn
uid: user2
dn: uid=user3,ou=informatique,dc=test,dc=sn
uid: user3
[root@srv-diokh openldap]#
delete.ldif:
uid=user2,ou=informatique,dc=test,dc=sn