Vous êtes sur la page 1sur 25

TP-Services d’annuaire LDAP

Dans le cadre de la mise en place d'un environnement numérique de travail, une grande quantité
d’informations relatives aux acteurs sont manipules. Ces informations doivent être stockes dans une
base d'informations afin d'en assurer la cohérence, la sécurité, l’accessibilité et la centralisation.
Ainsi la base d'information étant beaucoup plus sollicité en lecture, nous avons porter notre choix
sur les annuaires LDAP qui sont repûtes être performant pour les accès en lecture. Pour une
homogénéité de la représentation des données dans un annuaire LDAP .
Un annuaire LDAP est une base d'information ou une base de données non relationnelles.
La comparaison d'un annuaire LDAP par rapport à une base de données rationnelles est que :
• Dans un annuaire les données sont organisés sous forme d'arborescence appelé DIT
( Directory Information Tree) ;
• Un annuaire est beaucoup plus orienté recherche que mise à jour ;
• Un annuaire est lent en mise à jour (en écriture)
• Chaque information (object) dans un annuaire est identifiée par son dn (Distinguished
Name).

Quelques cas d'utilisation d'un annuaire LDAP


Un annuaire LDAP peut être utiliser comme :
• Un carnet d'adresse (Nom, Prenom, mot de passe, email, telephone)
• Un système d'information des employés d'une entreprise
• Une base des comptes utilisateurs unix
• Un Support d'information pour l'authentification wi-fi

Présentation des schémas


Définition
Les annuaires permettent de stocker et de gérer des identités, on y trouve des objets représentants
des personnes et des attributs permettant d’identifier et de définir la personne comme le nom,
prénom, téléphone...
L’ensemble des types d’objets possible dans l’annuaire, et pour chaque objet l’ensemble des
attributs utilisables est défini dans l’annuaire.
Parfois il arrive qu’on veuille stocker dans l’annuaire des informations de nature particulières pour
les besoins propres à ses applications. Si le schéma d’origine ne le permet pas, on peut réaliser une
extension de schéma. L’extension de schéma consiste à définir pour un annuaire de nouveaux types
d’objets, ou de nouveaux attributs pour un type d’objet existant.
Le type de chaque objet (unité organisationnelle, utilisateur, groupe, etc.) est appelé classe. Une
classe d’objet se définit par l’ensemble des attributs qui la compose .
Le schéma
L'ensemble des définitions relatives aux objets s'appelle le schéma. Le schéma décrit les classes
d'objets, leurs types d'attributs et leur syntaxe.

Les attributs
Une entrée de l'annuaire contient une suite de couples types d'attributs - valeurs d'attributs. Les
attributs sont caractérisés par :
• Un nom qui l'identifie
• Un Object Identifier (OID) qui l'identifie également
• S'il est mono ou multi-valué
• Une syntaxe et des règles de comparaison
• Un indicateur d'usage
• Un format ou une limite de taille de valeur qui lui est associée
Les attributs décrivent généralement des caractéristiques de l'objet, ce sont des attributs dits
normaux qui sont accessibles aux utilisateurs (ex : attribut givenname). Certains attributs sont dits
opérationnels car ils ne servent qu'au serveur pour administrer les données (ex : attribut
modifytimestamp).
Une entrée est indexée par un nom distinct (DN, distinguished name) permettant d’identifier de
manière unique un élément de l’arborescence. Un DN se construit en prenant le nom de l’élément,
appelé Relative Distinguished Name (RDN, c'est-à-dire le chemin de l’entrée par rapport à un de
ses parents), et en lui ajoutant l’ensemble des noms des entrées parentes. Il s’agit d’utiliser une série
de paires Attribut/valeur permettant de repérer une entrée de manière unique.

Les classes d'objets


Les classes d'objets modélisent des objets réels ou abstraits en les caractérisant par une liste
d'attributs optionnels ou obligatoires. Une classe d'objet est définie par :
• Un nom qui l'identifie
• Un OID qui l'identifie également
• Des attributs obligatoires
• Des attributs optionnels
Le type d'une classe est lié à la nature des attributs qu'elle utilise.
• Une classe structurelle correspond à la description d'objets basiques de l'annuaire : les
personnes, les groupes, les unités organisationnelles... Une entrée appartient toujours au
moins à une classe d'objet structurelle.
• Une classe auxiliaire désigne des objets qui permettent de rajouter des informations
complémentaires à des objets structurels. Par exemple l'objet mailRecipient rajoute les
attributs concernant la messagerie électronique d'une personne.
• Une classe abstraite désigne des objets basiques de LDAP comme les objets top ou alias.
Les classes d'objets forment une hiérarchie, au sommet de laquelle se trouve l'objet top. Chaque
objet hérite des propriétés (attributs) de l'objet dont il est le fils. On peut donc enrichir un objet en
créant un objet fils qui lui rajoute des attributs supplémentaires.
On précise la classe d'objet d'une entrée à l'aide de l'attribut objectClass. Il faut obligatoirement
indiquer la parenté de la classe d'objet en partant de l'objet top et en passant par chaque ancêtre de
l'objet. Par exemple, l'objet inetOrgPerson a la filiation suivante :

• L’objet person a comme attributs : commonName, surname, description, seeAlso,


telephoneNumber, userPassword.

• L'objet fils organizationalPerson ajoute des attributs comme : organizationUnitName,


title, postalAddress...

• L'objet petit-fils inetOrgPerson lui rajoute des attributs comme : mail, labeledURI, uid
(userID), photo ...

Une entrée peut appartenir à un nombre non limité de classes d'objets. Les attributs obligatoires sont
dans ce cas la réunion des attributs obligatoires de chaque classe.
Exemples de classes d'objets
Entry Type Required Attributes Optional Attributes
• CommonName (cn) • BusinessCategory
• surname (sn) • carLicense
• objectClass • departmentNumber
• description
• employeeNumber
• facsimileTelephone
• Number
• givenName
• mail
InetOrgPerson (defines entries • manager
for a person) • mobile
• organizationalUnit (ou)
• pager
• postalAddress
• roomNumber
• secretary
• seeAlso
• telephoneNumber
• title
• labeledURI
• uid
• BusinessCategory
• description
organizationalUnit (defines • facsimileTelephoneNumber
entries for organizational units) • ou • location (1)
• objectClass • postalAddress
• seeAlso
• telephoneNumber
• BusinessCategory
• description
• ou • facsimileTelephoneNumber
organization (defines entries • objectClass • location (1)
for organizations units) • postalAddress
• seeAlso
• telephoneNumber

Le Distinguish Name
Chaque entrée est référencée de manière unique dans le DIT par son distinguished name (DN). Le
DN représente le nom de l'entrée sous la forme du chemin d'accès à celle-ci depuis le sommet de
l'arbre. On peut comparer le DN au path d'un fichier Unix.
Le DN représente le chemin absolu d'accès à l'entrée. Comme pour le système de fichier Unix,
on peut utiliser un relative distinguished names (RDNs) pour désigner l'entrée depuis une position
déterminée de l'arbre. Par exemple, à partir de la position ou=CarnetAdresse,dc=ec2lt, dc=sn
,uid=ALLIER=>RDN.

LDIF
LDAP Data Interchange Format (LDIF) permet de représenter les données LDAP sous format texte
standardisé, il est utilisé pour afficher ou modifier les données de la base. Il a vocation à donner une
lisibilité des données pour le commun des mortels.
LDIF est utilisé dans deux optiques :
• faire des imports/exports de base
• faire des modifications sur des entrées.
• La forme générale est :

Une entrée de type personne se présente de la manière suivante :

Maintenant nous allons renseigner l’annuaire, pour renseigner l’annuaire nous avons besoins des
fichiers ldif, on utilisera ces fichiers pour insérer la racine, l’unité organisationnelle et les
utilisateurs. Voyez cela comme organigramme d’une entreprise. Un fichier LDIF (LDAP Data
Interchange Format, ou format d'échange de données de LDAP) est un fichier textuel portable
décrivant le contenu (ou une partie de celui-ci) d'une base de données LDAP afin de pouvoir
intégrer les données dans n'importe quel autre serveur LDAP.
Création de la racine sous le nom de racine.ldif

L'envoi de la racine de l'annuaire LDAP :

# ldapadd xW D ''cn=admin,dc=ec2lt,dc=sn'' f /etc/ldap/racine.ldif


TP1 : installation slapd et ldap-utils et paramétrage basique du serveur à travers le fichier
slapd.conf

# aptget install slapd ldaputils phpldapadmin

Le dossier de configuration de l'annuaire LDAP est /etc/ldap. Nous allons opter pour l'ancienne
configuration par le fichier slapd.conf, il faut au préalable renommer le dossier /etc/ldap/slapd.d/
en /etc/ldap/slapd.d.old

# cd /etc/ldap/
# mv /etc/ldap/slapd.d/ /etc/ldap/slapd.d.old
# updatedb
# locate slapd.conf
# /usr/share/doc/slapd/examples/slapd.conf /etc/ldap

Editons le fichier /etc/ldap/slapd.conf pour le paramètre :


Les paramètres :
1) type de base de données : hdb, hbm, et dbm
2) nom de la racine ou la base DN de l'annuaire (exemple suffix: dc=ec2lt,dc=sn )
3) Administrateur de l'annuaire ( exemple rootdn: cn=admin,dc=ec2lt,dc=sn)
4) mot de passe de l'administrateur( exemple rootpw: passer )
5) droits accès ( donner le dn de la personne qui a droit de lecture/écriture sur l'annuaire).
Enregistrer et redémarrer le service LDAP avec la commande :
# service slapd restart
TP2 : Installation slapd et ldap-utils et paramétrage avec la nouvelle méthode sans le fichier
ldif.

Lors de l'installation il vous sera demander de donner et de confirmer le mot de passe de


l'administrateur de l'annuaire :

Configuration de l'annuaire LDAP

Pour la nouvelle méthode de configuration de l'annuaire il suffit de lancer la commande suivante et


de donner les paramètres:
# dpkp-reconfigure slapd
Vous optez pour non pour que vous puissiez faire la configuration
On renseigne le nom de domaine qui sera la base DN de l'annuaire :

On donne le nom de l'organisation ou de l'entreprise :

On donne le mot de passe et la confirmation de l'administrateur de l'annuaire :


L'activation du module HDB recommandée et le choix de la base de données HDB qui une version
améliorée de BDB :
Une fois le choix effectué on purge la base de données:

On a choisit de ne pas déplacer de base de données tout simplement on n'a pas de base de données à
déplacer :
On autorise la version 2 du protocole LDAP pour accepter les programmes qui ne gèrent pas encore
la version 3 du protocole LDAP :

redémarrer le service slapd et tester la configuration

# service slapd restart


TP3 : Implémentation d'un carnet d'adresse avec LDAP

LDAP peut être utilisé comme un carnet d'adresse qui une base de données dans lequel son
utilisateur note les informations nécessaires pour contacter les personnes qu'il fréquente.
Pour chacune de ces personnes, on indique habituellement quelques renseignements standards qui
permettent d'associer son identité (nom et prénom) à un moyen de la contacter (adresse, numéro de
téléphone fixe ou mobile, numéro de fax, adresse électronique.

Création de l’unité organisationnelle sous le nom de ou.ldif

Création d'une entrée sous le nom user.ldif

L'envoi des informations dans l'annuaire se fait avec les commandes suivantes :
# ldapadd xW D ''cn=admin,dc=ec2lt,dc=sn'' f /etc/ldap/ou.ldif
# ldapadd xW D ''cn=admin,dc=ec2lt,dc=sn'' f /etc/ldap/user.ldif

Voici la liste deux entrées de notre carnet d'adresse :


TP4 : Implémentation un système d'information des employés d'une entreprise
Ce domaine d'application permet de mettre en œuvre une base d'information concernant des
différents employés d'une entreprise avec un numéro matricule de chaque employé.
Nous allons créer une unité organisationnelle nommée employes dans la racine de l'annuaire et
renseigner quelques employés.
Création de l’unité organisationnelle sous le nom de employes.ldif

Alimentation de l'annuaire :

Création d'une entrée pour un employé donné user.ldif

Après création des employés avec leurs informations nous allons alimenter l'annuaire :
Voici quelques entrées avec chacun un numéro de matricule qui identifie l'employé :
TP5 : Création des comptes utilisateurs dans un annuaire LDAP
Ce domaine d'application nous permet de stocker les différents comptes systèmes dans un
annuaire LDAP et pouvoir ouvrir des sessions avec ces derniers. Sachant qu'un compte
système doit avoir certains paramètres obligatoires (login, password, uid, guid,dossier de
connexion et un shell de connecion).
Pour implémentation nous allons créer une unité organisationnelle (users) dans lequel on
aura les différents comptes utilisateurs et une autre unité organisationnelle (groupes) dans
lequel on aura les groupes utilisateurs :

Après création on alimente l'annuaire avec le fichier ldif

Affichage des entrées précédentes depuis l'annuaire LDAP :


Il reste la création des groupes utilisateurs :

On enregistre les différents groupes de l'annuaire :

Après avoir créer les groupes nous passons à la création des comptes utilisateurs :
L'envoi des informations des comptes dans l'annuaire LDAP :

Pour visualiser les différents comptes utilisateurs et groupes on exécute la commande


suivante :
On peut aussi afficher les différents comptes utilisateurs et groupes via l'interface graphique
de phpldapadmin :
Configuration du NSS
Configurons l’outil NSS pour prendre en compte les informations contenues dans LDAP
(par défaut NSS tient compte uniquement des comptes systèmes).
Le système NSS (Name Service Switch, ou multiplexeur de service de noms, est un système
modulaire pour définir ou récupérer les informations des annuaires système. Pour utiliser
LDAP comme une source de données NSS, il faut mettre en place le paquet libnss-ldap :
Installation du paquet NSS
• Libnss-ldap-gère les login
• Libpam-ldap-gère les mots de passe
# apt-get install libnss-ldap

Configuration de NSS
Éditons le fichier /etc/nsswitch

Configuration de client LDAP


Pour se passer de l’option –h lors de la manipulation des utilitaires (ldapadd, ldapsearch ...)
sur le client il faut renseigner le fichier /etc/ldap.conf en donnant l'adresse IP de l'annuaire,
le dn de l'administrateur et son mot de passe.

Redémarrer le service libnss-ldap :


Test de fonctionnement:
Nous maintenant nous pouvons ouvrir des sessions avec nos différents comptes systèmes
enregistrés dans l'annuaire :

Cette section permettra aux applications d'effectuer les authentifications nécessaires à partir
des données de la base LDAP.
Configuration du PAM
PAM (Pluggable Authentication Module), ou module d'authentification enfichable) est une
bibliothèque modulaire centralisant les mécanismes d'authentification, d’initialisation de
sessions et de gestion des mots de passe.
Interface du module
Il existe quatre types d'interfaces pour les modules PAM, chacune correspondant à un aspect
différent du processus d'autorisation:
auth : Cette interface de module sert à authentifier l'utilisateur. Elle demande par exemple
la saisie d'un mot de passe pour lequel elle vérifie la validité.
account : Cette interface de module sert à vérifier que l'accès est bien autorisé. Par
exemple, elle peut vérifier si un compte utilisateur a expiré ou non, ou bien si l'utilisateur est
autorisé à se connecter à un moment donné de la journée.
password : Cette interface de module sert à définir et vérifier les mots de passe.
session : Cette interface de module sert à configurer et gérer des sessions d'utilisateurs. Les
modules ayant cette interface peuvent également effectuer des tâches supplémentaires
requises pour autoriser l'accès, comme par exemple pour monter le répertoire personnel d'un
utilisateur ou activer sa boîte aux lettres.
Indicateurs de contrôle
Lorsqu'ils sont appelés, tous les modules PAM donnent un résultat indiquant soit la réussite,
soit l'échec.
Il existe quatre types d'indicateurs de contrôle prédéfinis, à savoir :
required : Le module doit être vérifié avec succès pour que l'authentification puisse se
poursuivre.
Si la vérification d'un module de type required échoue, l'utilisateur n'en est pas averti tant
que tous les modules associés à cette interface n'ont pas été vérifiés.
requisite : Le module doit être vérifié avec succès pour que l'authentification puisse se
poursuivre. Cependant, si la vérification d'un module de type requisite échoue, l'utilisateur
en est averti immédiatement par le biais d'un message lui indiquant l'échec du premier
module de types required ou requisite.
sufficient : En cas d'échec, les vérifications de modules sont ignorées. Toutefois, si la
vérification d'un module de type sufficient est réussie et qu'aucun module précédent de type
required n'a échoué, aucun autre module de ce type n'est nécessaire et l'utilisateur sera
authentifié auprès du service.
optional :Les vérifications de modules sont ignorées. Un module de type optional ne
devient nécessaire que pour la réussite d'une authentification lorsque aucun autre module ne
référence l'interface.
Après installation libpam-ldap, les fichiers /etc/pam.d/common-auth, /etc/pam.d/common-
password, et /etc/pam.d/common-account sont configurer par défaut mais on pourrai
éventuellement les adaptés a nos besoins.
Maintenant reste à créer et à monter automatique le répertoire de base des utilisateurs.

Installation
# apt-get install libpam-ldap

Configuration
On édite le fichier
# vim /etc/pam.d/common-session

On ajoute la ligne suivante à la fin du fichier /etc/pam.d/common-session


Test de connexion avec un utilisateur de l'annuaire: