Chapitre 1 : Gestion centralisée et

annuaires

1.1 Introduction.

1.1.1 Gestion centralisée et annuaire

La généralisation de l'usage d'applications informatiques dans la gestion d'une entreprise ou d'une

organisation a conduit à multiplier les bases de données nécessaires au bon fonctionnement de ces
applications. Un des enjeux de la pérennité de cette évolution est de pouvoir regrouper les
informations, en particulier nominatives, dans un ensemble cohérent pour ne pas stocker des
informations non synchronisées ou contradictoires. Par exemple, lorsqu'une personne quitte une
entreprise, elle doit être supprimée de l'annuaire téléphonique, mais aussi de la liste de gestion de la
paie et ne doit pas non plus conserver des accès informatiques aux postes de l'entreprise. Toutes ces
opérations liées à des bases de données doivent être faites dans un laps de temps réduit. L'objectif
est alors de trouver un moyen de centraliser efficacement ces informations et de permettre la fusion
de ces multiples bases de données dans un unique ensemble appelé annuaire informatique.

Par exemple, une école peut avoir besoin de :

un fichier Microsoft Excel contenant la liste du personnel administratif
une base Microsoft Access du personnel enseignant
un fichier Microsoft Excel des numéros de téléphone des personnels
un fichier /etc/passwd des comptes Unix des utilisateurs
un fichier /etc/aliases (ou Sympa) de listes de Mail
un fichier Samba sur le serveur UNIX des utilisateurs Windows
d'autres bases MySQL, Oracle, maps NIS,…

Un annuaire va pouvoir regrouper toutes ces informations et surtout s'interfacer avec les
applications qui utilisent ces données.
Par exemple, comment envoyer un mail contenant leurs nouvelles coordonnées de compte UNIX, à
l'ensemble du personnel administratif sachant que l'administrateur système ne les connaît que par
leur nom et prénom. Un annuaire va permettre de faire cette opération sans que l'opérateur ait à
intervenir manuellement.

1
1.1.2Concept d'annuaire

Un annuaire informatique est un service permettant d'accéder à des informations relatives à des
personnes, des machines (ou d'autres ressources) de manière organisée (arborescente).
L'objectif est de maintenir de façon cohérente et contrôlée une grande quantité de données.

Ce n'est pas exactement un système de gestion de base de données (SGBD) dans lequel le schéma
des données stockées est défini pour résoudre un certain problème. Ce schéma est connu des
applications et les objets sont généralement complexes, stockés dans différentes tables ayant des
relations entre elles (base de données relationnelle). Un langage spécifique permet la lecture et mise
à jour des tables (requêtes SQL, …).

Les différences principales entre un annuaire et un SGBD sont :

pas de liens de dépendances entre les objets stockés dans un annuaire
les objets peuvent être distribués sur plusieurs annuaires pour assurer une meilleure disponibilité
le schéma de stockage des données est standardisé pour assurer un partage des données
Les attributs peuvent être multi-valués
les applications de l'annuaire n'ont pas besoin de connaître la structure interne des données stockées
un annuaire est principalement consulté en lecture et optimisé pour cela

Les caractéristiques d’un annuaire sont donc :

Optimisé pour la lecture : mémoire cache si modifications rares
Modèle distribué de stockage : ajout de données par plusieurs services
Extension des informations stockées : nouvelles catégories d ’enregistrement
Fonctionnalités de recherche avancées
Réplication entre serveurs : redondance pour un service plus rapide et plus fiable, un annuaire
pouvant être consulté sur une version répliquée car les modifications sont rares

1.1.3Utilisation d'un annuaire pour l'authentification centralisée

Avec la multiplication des applications demandant une authentification (messagerie, serveurs de

fichiers, site WEB...) il est devenu difficile de retenir toutes les indications de login/passwd, surtout
si on prend en compte des contraintes fortes de sécurité (password long et varié). La mise en place
d'un système d'authentification centralisée et unique répond à ces impératifs de confort et de
sécurité.
Les systèmes basés sur des annuaires LDAP sont actuellement les plus courants. Ils sont constitués
d'un serveur LDAP stockant, parmi d'autres informations, toutes les indications nécessaires à
l'authentification. Ce serveur LDAP est interrogé automatiquement par les applications serveur
(WEB, messagerie...) auxquelles tentent d'accéder les utilisateurs. Ces applications vont
communiquer par un module interne client LDAP avec le serveur LDAP.

2
 Client Protocole Serveur Serveur
applicatif : LDAP
Applicatif : Applicatif : LDAP
Web, WEB, Mail...
Mail... HTTP, POP,
IMAP... +Client LDAP

1.2 Annuaire LDAP.

1.2.1 Présentation
LDAP (Lightweight Directory Access Protocol) a été initialement présenté comme un protocole à
destination des postes de travail. Il a été proposé à l'IETF en 1995. Il est l'héritier de l'annuaire
X500 (proposée par l'ISO), un standard conçu par les opérateurs télécom pour interconnecter leurs
annuaires téléphoniques. X500 est basé sur le modèle OSI.
LDAP peut être vu comme une adaptation de X500 à Internet (même modèle de schéma, …), mais
simplifié dans un premier temps. Il est basé sur la pile de protocoles TCP/IP (Port TCP 389 du
serveur).

Le standard ne concerne pas le contrôle d'accès aux données de l'annuaire, il ne définit pas non plus
le moyen de stockage des données. La version actuelle est la version 3 [RFC 3377][RFC4510]. Elle
définit 9 opérations fondamentales. De nombreux compléments sont aussi publiés : RFC 2251 à
2256, RFC 2829 à 2830, RFC 2849...

1.2.2Principes

Les objectifs principaux sont de :

• fournir aux utilisateurs des informations fiables, facilement accessibles
• permettre aux utilisateurs de mettre à jour eux-mêmes leurs informations personnelles
• rendre les informations accessibles de façon contrôlée
• faciliter le nomadisme des utilisateurs
• éviter la redondance d'informations : un seul annuaire pour l'ensemble des services
• faciliter la gestion (administration) des postes de travail, des équipements réseau
• ne pas remettre en cause les applications existantes...

LDAP est d'abord un protocole permettant à un client d'interroger un serveur. Il y a donc une
normalisation d’un ensemble de messages. Mais pour garantir l'interopérabilité, il n'y a pas de
précision sur le stockage des données, à charge au serveur LDAP de transformer le format de
stockage interne des données en directives normalisées lors de l'échange avec le client. Plusieurs
formats internes peuvent d'ailleurs être possibles sur un serveur (bdb, hdb...).

3
 Requêtes et Format Stockage
réponses LDAP interne des
Client Serveur
LDAP LDAP données
BdD

La RFC 2251 définit 2 modèles pour LDAP :

Un modèle de protocole : c'est à dire les relations client/serveur
Un modèle de données qui va permettre de structurer les informations de manière identique pour les
différents postes.
Pour ne pas mélanger les données et les types potentiels, il existe aussi une version plus évoluée
avec 4 modèles (ou même 5) :
Un modèle d'information (les types de données)
Un modèle de nommage (l'organisation des données)
Un modèle fonctionnel (les éléments d'échange client/serveur)
ainsi que deux fonctionnalités ajoutés :
Un modèle de sécurité (définissant les droits d'accès aux données)
Un modèle de réplication : c'est à dire la répartition de la base sur plusieurs serveurs

Dans cette deuxième version, le modèle d'information définit les structures et types des
informations contenues dans l'annuaire. Cela ressemble aux déclarations de type dans un langage
informatique. C'est une description générale des données applicables à plusieurs usages.

Le modèle de nommage décrit comment l'information est organisée et référencée : chaque entrée
doit être définie de manière unique par un nom : DN (Distinguished Name).

Ce DN est la concaténation de RDN (Relative Distinguished Name) qui est un attribut spécifique à
valeur unique à un niveau de l’arbre.
Cette concaténation donne un nom complet unique de type :
DN:cn=adminposte5, ou=poste5, dc=istase2003, dc=fr

Il est constitué des RDN ou=poste5 et cn=adminposte5, la racine du nom étant dc=istase2003,dc=fr.
Il est construit sous forme d’arbre (DIT : directory information tree). Une entrée d’annuaire est un
nœud de l’arbre, chaque nœud possède des attributs. La forme de l'arbre est spécifique à une
application, ce qui permet au client et au serveur d'interagir.

Le modèle fonctionnel correspond au protocole : c'est la liste et la syntaxe des requêtes permettant
l'interrogation de la base et la mise à jour des informations. C’est le protocole LDAP.
Le modèle de sécurité permet de gérer l'authentification des clients, la vérification des droit
d ’accès, ceci depuis LDAPv3. Certaines fonctionnalités ne sont pas normalisées.

1.2.3 Le modèle d'information

Un annuaire est modélisé par un schéma LDAP qui va déterminer les objets utilisables dans
l'annuaire. Un schéma LDAP définit une liste des classes d'objets, les types des attributs et leur

4
syntaxe répondant aux normes de l'Object Management Group (OMG). Ils sont standardisés
(IANA) : pour permettre l'interopérabilité entre logiciels et surtout l'interfaçage avec les
applications clientes (Samba, …). Quoi qu'il en soit, il est possible de rajouter des schémas
spécifiques pour utiliser LDAP dans des environnements non standard.

Les classes d'objets modélisent des objets réels : un compte Unix (posixAccount), une organisation
(o), un département (ou), un personnel (organizationPerson), une imprimante (device), …
ou abstraits : l'objet père de tous les autres (top), …
Une classe d'objet est définie par : un nom, un OID, des attributs obligatoires, des attributs
optionnels, un type (structurel, auxiliaire ou abstrait).

Exemple :
objectclass ( [Link] NAME 'person'
DESC 'RFC2256: a person'
SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description )
)

Un attribut est défini lui aussi par un nom et un identifiant d’objet unique (OID), l'OID est attribué
par l’IANA sous la forme d'une suite de nombres (exemple : [Link].4.1.65234.23 décrit ISO ; org ;
dod ; internet ; private ; company ; « istase » ; cours …).
La définition du type de l'attribut (Attributetype) va spécifier la syntaxe de cet attribut et son
utilisation via des règles de comparaison. Dans l'exemple ci-dessous : « SYNTAX
[Link].4.1.1466.[Link]{32768} » précise que l'attribut est de type chaîne de caractères,
« caseIgnoreSubstringsMatch » précise qu'il ne faut pas tenir compte de la casse des lettres et des
espaces.

Exemples :
attributetype ( [Link] NAME 'name'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX [Link].4.1.1466.[Link]{32768} )

attributetype ( [Link] NAME ( 'sn' 'surname' )

DESC 'RFC2256: last (family) name(s) for which the entity is known by'
SUP name )

attributetype ( [Link] NAME ( 'c' 'countryName' )

DESC 'RFC2256: ISO-3166 country 2-letter code'
SUP name SINGLE-VALUE )

Les noms des attributs les plus courants ont des abréviations :
cn : common name
dc : domain component
sn : surname
Il y a alors deux noms séparés par un espace dans la déclaration NAME.

Certains attributs sont toujours présents dans les objets :

L’attribut objectClass est toujours présent car c'est lui qui donne le type de l'objet sans lequel on ne
pourrait connaître les autres attributs nécessaires et autorisés.

5
De même le pseudo attribut dn (Distinguished name) est toujours présent.

Un attribut peut-être mono ou multivalué s'il est présent plusieurs fois. Un objet peut-donc cumuler
les types s'il a plusieurs objectClass.

1.2.4 Le modèle de nommage

L'annuaire est construit sous forme arborescente, cet arbre est décrit par le DIT (directory
information tree). Chaque instanciation d'objets est placée dans cet arbre avec un certain nombre de
valeurs d'attributs. Il contient les données de l'annuaire (il correspondrait à la déclaration de
structures et à l'affectation des valeurs des champs dans un programme informatique).

Le DIT est décrit dans des fichiers ldif qui vont construire l'annuaire interne par traduction.

Format LDIF : LDAP Interchange format (RFC 2849) :

C'est un format texte, chaque entrée est séparée par un retour à la ligne. La première ligne est le
nom de l'entrée (association de l'attribut dn avec le chemin dans l'arbre), les suivantes sont aussi des
associations entre attributs et valeurs, seuls les attributs définis dans le schéma peuvent être utilisés.

Exemple de DIT et sa description LDIF :

dn: dc=istase2003, dc=fr

objectClass: domain
dc:istase2003

dn: ou=prof, dc=istase2003, dc=fr dc=istase2003, dc=fr

objectclass: organizationalUnit
ou : prof

dn:cn=jacquet,ou=prof ,dc=istase2003, dc=fr ou=prof

cn:jacquet
givenName : Jacquet Gérard
ObjectClass : person cn=jacquet
ObjetcClass:inetOrgPerson
telephoneNumber:0477915723
mail : jacquet@[Link] DIT équivalent à l'exemple
manager:cn=dir,dc=istase,dc=fr

En fait, le nom de l'entrée dn un attribut toujours présent en première ligne, il a comme valeur la
position dans l'arbre de l'instance de l'objet (différents rdn séparés par des virgules)..

Il peut y avoir plusieurs entrées dans un fichier ldif, elles doivent être construites de manière
arborescente ordonnée. Par exemple, « dn:cn=adminposte5, ou=poste5, dc=istase2003, dc=fr » ne
peut être créé si le « dn:ou=poste5,dc=istase,dc=fr » ne l'est pas.

6
1.2.5 Le modèle fonctionnel : protocole LDAP

Il définit les échanges entre client et serveur, d'un point de vue des commandes disponibles, de
leurs arguments et de la syntaxe de la PDU.

LDAP définit 9 opérations de base regroupées en trois catégories :

- Les commandes de connexion au service : bind, unbind, abandon (le client abandonne la requête
en cours)
- Les commandes de mises à jour des entrées de l'annuaire : add, delete, modify, Modify DN
(rename)
- Les commandes d'interrogation : recherche (search) et comparaison (compare) d'entrées

LDAPv3 est conçu pour être extensible sans avoir à modifier la norme. Il permet l'ajout
d'opérations en plus des 9 de base (Extended Operation). Il permet aussi l'ajout de paramètres
associés à une opération.

Le format de transport des données n'est pas de l'ASCII comme SMTP, HTTP, … C'est un
encodage LBER : Lightweight Basic Encoding Rules. Le protocole LDAP utilise ASN1 + BER.

ASN1 (Abstract Syntax Notation One) : 1993

Il est aussi utilisé par SNMP. C'est un standard de représentation formelle de message. Un
compilateur permet de traduire le message pour l ’envoyer. Il comprend des types prédéfinis, une
syntaxe proche de celle du langage C (C like).

Exemple :
Nom ::= SEQUENCE {
name PrintableString (SIZE (1..30)),
address PrintableString (SIZE (1..60)),
moreaddress PrintableString (SIZE (1..30)) OPTIONAL,
zipcode NumericString (SIZE (5))}

BER (Basic Encoding Rules) X690 de l ’UIT

C'est la syntaxe de transfert qui est le résultat de la traduction d’ASN1. C'est un encodage de format
TLD (type length data ou type-longueur-valeur) ou ILC (Identifier Length Content).

Chaque champ a comme longueur 1 ou plusieurs octets.

Le champ Identifier se décompose en 3 parties : la classe, la forme, et le numéro de référence.

Exemple de champ Identifier :
01000011
01 Class : Application
0 Forme : Primitive
0 0011 : Tag Number ou Application Number : SearchRequest)

Le premier champ (Class) a 4 valeurs :

00 : Universal
01 : Application
10 : Context Specific
11 : Private

7
Le deuxième (Form) a seulement 2 valeurs : Primitive (0) ; Constructed (1)

Le troisième champ va dépendre de la classe, par exemple pour la classe Universal :

0 0001 : Boolean ; 0 0010 : Integer ; 0 0011 : Bitstring ; 0 0100 : OctetString ; 0 0110 : OID ...

1.2.6Le modèle de sécurité

les mécanismes de sécurité sont définis dans une couche séparée : cela permet d'utiliser des
méthodes d'authentification externes.
Les mécanismes de sécurité comprennent :
les méthodes d'authentification pour se connecter à l'annuaire (qui peut se connecter à l'annuaire et
comment)
les mécanismes de règles d'accès aux données (une fois connecté, à quoi peut-on accéder et avec
quels droits)
les mécanismes de chiffrement des transactions

1.2.7Le modèle de réplication

Il définit les échanges de la connexion Serveur/Serveur. Le service de réplication (replication
service) a beaucoup évolué avec LDAPv3 passant d'un mécanisme géré par le démon slurpd à
plusieurs possibilités géré par syncrepl. Ce service de réplication consiste à recopier
périodiquement le contenu d'un annuaire LDAP d'une machine sur une autre afin d'avoir une
redondance nécessaire pour garantir une bonne continuité de service.
Il est aussi possible de créer des liens entre différents annuaires (referral service) : cette fonction est
définie dans LDAPv3.

1.2.8Utilisation de LDAP
Les différents domaines d’application possibles des annuaires LDAP sont :
Les applications système (authentification, information sur les utilisateurs...)
Les applications Intranet/Extranet
Les applications Internet
Les bases de données

Les applications systèmes

L’annuaire utilisé pour servir aux besoins des services réseaux tels que l’authentification,
le contrôle d’accès, la localisation des imprimantes ou des serveurs de fichier.
Dans ce cas, il est étroitement lié au système d’exploitation.
De plus en plus de fabricants se tournent vers le standard LDAP pour l’implanter dans leur système.
Exemple : Windows 2000, Novell, Solaris, Linux...

Exemple : authentification avec Samba

Serveur SAMBA
Requête avec module LDAP
NetBIOS
login/mot de
Client passe Serveur Client Serveur
Windows SAMBA8 LDAP LDAP
Requêtes et
réponses LDAP
1.3OpenLDAP sous Linux Debian

1.3.1 Présentation.

OpenLDAP est un serveur LDAP Opensource développé à partir de 1998. Il est distribué sous
forme de code source, mais est disponible compilé par exemple sur la plupart des distributions
Linux et existe aussi sous Windows. C'est un des serveurs LDAP le plus utilisé. Il propose un
démon permettant de traiter les requêtes LDAP, de bibliothèques servant à gérer le protocole, ainsi
que des utilitaires. La base de données associée est libre et dépend des plate-formes support et des
choix du gestionnaire (Berkeley Database – Bdb - par exemple et par défaut sous Debian Linux).

1.3.2 Le serveur OpenLDAP sous Debian Linux

Un serveur LDAP a besoin de plusieurs éléments pour fonctionner :

– un démon (programme résident) qui va répondre aux requêtes des clients.
– Un ou des fichiers de configuration lu au démarrage du démon et qui vont paramétrer le
fonctionnement du serveur.
– Des schémas LDAP qui vont servir de contrôle pour que la base LDAP respecte des
contraintes de formatage. Ces schémas sont en général stockés dans des fichiers.

OpenLDAP fonctionne sur un serveur Debian à partir du démon slapd lancé comme un service par
systemctl. (systemctl restart slapd).
Le fichier de configuration au lancement du démon est soit le fichier /etc/ldap/[Link] (c'est un
fichier texte) soit un ensemble de fichiers LDIF sous le répertoire slapd.d s'il existe.
La configuration par défaut gère l'accès à des bases de données de type bdb. L'administrateur va
ajouter aux fichiers un certain nombre d'informations, en particulier pour chaque arborescence DIT,
une nouvelle base de données. Des exemples sont en général proposés dans le fichier. Ce fichier
peut aussi contenir des fichiers inclus permettant de séparer certaines étapes de la configuration.
Les fichiers schémas sont stockés dans le sous-répertoire /etc/ldap/schemas. Le fichier [Link]
est obligatoirement utilisé, les autres sont utilisable à la demande, il faut insérer à ce moment là leur
nom au bon endroit du fichier de configuration. Ces fichiers doivent être consultés chaque fois
qu'un problème de syntaxe LDAP est retourné par le serveur.

Avant le lancement du serveur, on adapte le fichier de configuration pour l'application envisagée.

Puis on lance le serveur en vérifiant dans les fichiers de Log que tout c'est bien passé.
Après lancement initial du serveur LDAP, on procède au peuplement de la base de données via la
création d'un fichier ldif (au format texte) créé par l'administrateur et exportation vers la base de
données via une commande ldapadd (ou ldapmodify). La modification ou le complément de la base
peut se faire ensuite à n'importe quel moment par les mêmes commandes. L'effacement se fait
quant à lui par ldapdelete qui prend comme argument principal un fichier texte contenant les dn à
effacer dans l'ordre inverse de leur dépendance. La vérification ou le test peut se faire par
ldapsearch qui va reproduire le fonctionnement d'une fonction cliente et ainsi permettre une mise au
point plus simple.

9
Avec cette méthode, l'ajout, la modification ou la suppression d'objets LDAP se fait serveur en
fonctionnement, car on fait les modifications en tant que client, elles sont donc prises en comptes
immédiatement. Des commandes équivalentes existent pour faire les mêmes choses serveur arrêté,
elles se nomment slapadd, slapmodify et slapdelete.

A chaque modification des fichiers de configuration, le serveur doit être relancé (systemctl restart
slapd), ceci permet d'avoir un serveur fonctionnant avec les bons paramètres. Attention, de bien
utiliser restart qui arrête le serveur avant de le relancer, sinon il peut y avoir plusieurs instances de
serveurs LDAP fonctionnant avec des paramètres différents.

1.3.3 Un client simple sous Debian

Chaque application utilisant LDAP est un client LDAP. Du fait de l'interopérabilité de LDAP, le
client peut être hébergé sur une machine ayant un SE différent.

Sous Debian, sa configuration se fait via un fichier de configuration commun (quelle que soit
l'application) /etc/ldap/[Link]. Il n'est pas relié à un démon mais va être consulté à chaque
lancement de commandes clientes.
Le fichier de configuration contient au minimum :
La définition du serveur LDAP par son URI (ou l'adresse IP du serveur en l'absence de DNS)
Sa base (le début de l'arborescence)

Sous Linux, un client LDAP simple peut-être installé afin de tester le serveur. Il va permettre, via
plusieurs commandes spécifiques (ldapcompare, ldapsearch...) de tester simplement le
fonctionnement d'une interrogation LDAP. En fait les commandes permettant d'ajouter des
informations à la base LDAP, de les supprimer sont aussi basées sur le même fichier. C'est à dire
qu'au démarrage au moins, le client LDAP doit aussi être configuré sur le serveur. Depuis des
versions plus récentes, les mêmes commandes mais nommées slpadadd… permettent de travailler
directement sur le serveur sans que celui-ci soit lancé (ces commandes sont spécialement
intéressantes pour construire des scripts au niveau du serveur car elles ne nécessitent pas un
lancement préalable).

1.3.4 Usage avec les applications.

L'utilisation de la base LDAP par une application serveur (Web, Mail...) va se faire suivant le même
principe que l'application cliente simple. En ajoutant des modules supplémentaires à l'application
serveur, celle-ci va devenir client LDAP. Par exemple, un serveur Web utilisant LDAP pour
l'authentification va être client LDAP d'un serveur LDAP pouvant se situer sur la même machine ou
sur une autre machine.

Il faut alors bien veiller à ce que les schémas utilisés soient ceux demandées par l'application
serveur et que le DIT inclus bien les différents objets et attributs nécessaires. C'est en général la
principale difficulté de mise en oeuvre de LDAP.

Le reste de la configuration concerne le serveur d'application.

Par exemple, sous Apache, il faut ajouter les modules dynamiques authnz_ldap.load et [Link] en
créant des liens symboliques sous le répertoire /etc/apache2/mods-enabled vers ces fichiers
contenus dans le répertoire /etc/apache2/mods-available par la commande :
ln -s /etc/apache2/mods-available/xxx /etc/apache2/mods-enable/xxx

10
De même il faut modifier les fichiers de configuration en y ajoutant les lignes permettant de
prendre en compte le client LDAP, sous Apache il est nécessaire de rajouter au fichier de
configuration du site :

<Directory /home/webdir/dir_ldap>
...
AuthType Basic
AuthBasicProvider ldap
AuthName « LDAP Directory »
AuthzLDAPAuthoritative off
AuthLDAPURL ldap://adresseIP/dc=istase,dc=fr
AuthLDAPBindDN « uid=root,ou=admin,dc=istase,dc=fr »
AuthLDAPBindPassword admintest
Require valid-user
</Directory>

L'adresse IP le DN de login et le mot de passe doivent bien entendu correspondre à la machine

serveur LDAP. Les applications clientes peuvent soit passer par le fichier de configuration par
défaut de ldap (/etc/ldap/[Link]) soit par une configuration locale à l'application : ce qui est le
cas ici pour le serveur Apache.

Dans certains cas, il est nécessaire de compléter le schéma LDAP avec des fichiers de schéma
supplémentaires, afin de trouver dans l'annuaire les objets nécessaires au bon fonctionnement de
l'application cliente. Lorsque l'application cliente interfère directement avec le système
d'exploitation (authentification LDAP sous UNIX au lieu des fichiers habituels), il faut être très
prudent car cela peut compromettre le fonctionnement complet du système.

1.3.5Réplication

Le fonctionnement de la réplication est défini dans le fichier [Link] que ce soit au niveau du
fournisseur (provider) ou du consommateur (consumer).

La syntaxe de ces fichiers de configuration est stricte : les tabulations (ou l'espace en début de
ligne) permet une continuation de la ligne précédente.

Un service supplémentaire doit être lancé côté serveur via un module :

moduleload syncprov

Il faut positionner cette directive à la suite des autres directives de même type.
(Exemples de configuration tirés de la documentation d'OpenLdap)

Exemple de fichiers de configuration [Link] côté provider :

database bdb
suffix dc=Example,dc=com
rootdn dc=Example,dc=com
directory /var/ldap/db
index objectclass,entryCSN,entryUUID eq

11
 overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

On ajoute à une configuration de base uniquement les 3 dernières lignes : il permet de configurer le
rythme des synchronisation (toutes les 10 minutes ou les 100 écritures).

Exemple de fichier de configuration côté client (consommateur) :

database hdb
suffix dc=Example,dc=com
rootdn dc=Example,dc=com
directory /var/ldap/db
index objectclass,entryCSN,entryUUID eq

syncrepl rid=123
provider=ldap://[Link]
type=refreshOnly
interval=[Link]
searchbase="dc=example,dc=com"
filter="(objectClass=organizationalPerson)"
scope=sub
attrs="cn,sn,ou,telephoneNumber,title,l"
schemachecking=off
bindmethod=simple
binddn="cn=syncuser,dc=example,dc=com"
credentials=secret

La configuration du client est un peu plus complexe, il faut le définir en particulier comme client
du serveur provider et déterminer quels éléments sont recopiés. Les lignes du début sont déjà
présentes dans la configuration de la base de données.

Pour le mettre en œuvre, il faut bien entendu remplacer les éléments entre guillemets par les bonnes
valeurs !

On peut aussi gérer 2 serveurs miroir, les 2 serveurs ayant alors un fonctionnement équilibré, une
modification sur l'un sera répliquée sur l'autre et vice-versa :

MirrorMode node 1:

# Global section
serverID 1
# database section

# syncrepl directive
syncrepl rid=001
provider=ldap://[Link]
bindmethod=simple
binddn="cn=mirrormode,dc=example,dc=com"

12
 credentials=mirrormode
searchbase="dc=example,dc=com"
schemachecking=on
type=refreshAndPersist
retry="60 +"
mirrormode on

MirrorMode node 2:

# Global section
serverID 2
# database section

# syncrepl directive
syncrepl rid=001
provider=ldap://[Link]
bindmethod=simple
binddn="cn=mirrormode,dc=example,dc=com"
credentials=mirrormode
searchbase="dc=example,dc=com"
schemachecking=on
type=refreshAndPersist
retry="60 +"
mirrormode on

La commande retry permet de contrôler les essais (60 : délai en cas de problème ; + : nombre
d'essais infini).

13
 TP n°2 Module OptRx1

1.4 TP N°2 : Annuaire LDAP

Objectifs du TP:
Mise en œuvre d’un serveur LDAP : OpenLDAP,
L'usage de ce serveur par des serveurs d'application sera traité dans les TP les concernant.

Ressources nécessaires au TP
Durant le TP, vous allez utiliser un PC client Windows et deux PC sous Debian Linux, l'un
pour le service LDAP, l'autre comme client.

Phase 1 : Configuration du serveur LDAP et constitution de la base de données

1. Configurer le serveur LDAP en éditant le fichier /etc/ldap/[Link]. Définir une nouvelle
base de données pour votre usage :
database bdb
suffix « dc=istase,dc=fr »
rootdn « uid=root,ou=admin,dc=istase,dc=fr »
rootpw admintest

2. Lancer le service LDAP : systemctl restart slapd. Bien vérifier que le démon est lancé,
certaines erreurs conduisent à un arrêt sans message.

3. Vérifier le port d'écoute par la commande netstat -natup |grep -e LISTEN

4. Construire la base de données. Créer un fichier LDIF dans lequel vous insérerez les
définitions de base de l'arborescence et celle de l'utilisateur root appartenant à l'unité
d'organisation admin :
dn:dc=istase,dc=fr
objectclass: dcobject
objectclass:organization
o: istase directory service
dc: istase

dn:ou=admin,dc=istase,dc=fr
objectclass: OrganizationalUnit
ou: admin

dn: uid=root,ou=admin,dc=istase,dc=fr
Objectclass: InetOrgPerson
cn: root
sn:root
uid: root
userPassword : admintest

5. Toute opération sur la base de données, même à partir du serveur, passe par une interface
client, vous devez donc configurer, sur le serveur LDAP, le client LDAP, en utilisant le
fichier de configuration /etc/ldap/[Link].
URI ldap://[Link]
BASE dc=istase,dc=fr

14
 6. Lancer la traduction du fichier LDIF pour être inséré dans la base hdb.
ldapadd -x -D « uid=root,ou=admin,dc=istase,dc=fr » -W -f /tmp/[Link]
Si vous voulez ajouter des entrées en utilisant le fichier ldif initial de manière incrémentale il
faut utiliser l'option -c dans ldapadd (ou ldapmodify)

7. Vérifier le contenu de la base de données par la commande :

ldapsearch -x « filtre » (objectclass=* pour tout).

8. Entrer les informations complémentaires dans la base concernant les utilisateurs user1,
user2 et user3 en les plaçant directement sur le domaine dc=istase, dc=fr dans une classe
d'objet de type « person ». Vérifier dans les fichiers de schéma les attributs obligatoires et
autorisés ([Link]). Modifier les entrées pour qu'elles soient acceptées par le serveur
LDAP.

9. Vérifier la bonne insertion par la commande ldapsearch.

10. Déplacer ces éléments (user1, user2 et user3) dans une unité d'organisation de nom
« standarduser ». On pourra utiliser la commande :
ldapdelete -v -x -D « DN root » -W -f /tmp/[Link]
en remplissant le fichier avec les DN à détruire dans l'ordre inverse de leur création.
Bien penser aussi à remplacer « DN root » par sa valeur !

11. Vérifier le contenu de la base complète. Puis vérifier le contenu de la base à partir du point
dn:ou=standarduser,dc=istase,dc=fr avec l'option -b de ldapsearch.

Phase 2 : Consultation du serveur LDAP par un client générique

1. Configurer le client LDAP sous le deuxième poste linux en modifiant le fichier
/etc/ldap/[Link]. : URI ldap://adresse IP du poste serveur
BASE dc=istase,dc=fr

2. Tester l'interrogation LDAP à partir de ce poste distant par ldapsearch -x objectclass=*.

Pourquoi cela marche-t-il sans préciser l'adresse du serveur ? Visualiser les trames
échangées.
3. A partir des trames capturées, analyser le format des échanges LDAP d'un point de vue
global, puis dans le détail du codage binaire.
4. Tester un enregistrement avec la fonction ldapcompare -x DistingishName attribut:value.
Visualiser les trames échangées.
5. Faire une opération de même type à partir d'un client Windows en utilisant le browser
Softera.

Phase 3 : Réplication
1. Configurer le serveur LDAP actuel pour qu'il devienne provider, et le client Linux pour qu'il
devienne un serveur esclave (consumer). Visualiser les échanges et les Log.
2. Elever le rang du deuxième serveur LDAP pour qu'il fonctionne en miroir avec le premier.
Visualiser les échanges.

15