SlideShare une entreprise Scribd logo
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
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
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
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
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
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
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
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
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
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)
Affichage des enregistrements
      Un extrait de ce qui est affiché.




Dimitri LEMBOKOLO                         11
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
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
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
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

Contenu connexe

DOCX
Configuration ldap
PDF
PPT
CRFCB AMU_evolutions-catalogage_091213_RDA
PPT
Les 4 normes de description archivistique
PPT
Metadonnees Introduction
PDF
La description contextuelle des archives
PPTX
Ead indexation
Configuration ldap
CRFCB AMU_evolutions-catalogage_091213_RDA
Les 4 normes de description archivistique
Metadonnees Introduction
La description contextuelle des archives
Ead indexation

Tendances (15)

PPT
PDF
Les éléments d'indexation dans la DTD-EAD
PDF
Informatique documentaire - Cours Licence pro bib 2013
PDF
Introduction à l'informatique documentaire - 2011
PDF
Cours de C++, en français, 2002 - Cours 3.4
PDF
Introduction à l'informatique documentaire
PPT
Interopérabilité et échanges de données pour les archives
PPT
Dublin Core
PDF
Xml elgarrai 2020
PPT
Introduction à XML
PPTX
07 big data sgbd
PPT
Description archivistique
PPTX
10 big data hadoop
PDF
Modèles de données et langages de description ouverts 2021-2022 - 2
PPT
XML Avancé : DTD, XSD, XPATH, XSLT, XQuery
Les éléments d'indexation dans la DTD-EAD
Informatique documentaire - Cours Licence pro bib 2013
Introduction à l'informatique documentaire - 2011
Cours de C++, en français, 2002 - Cours 3.4
Introduction à l'informatique documentaire
Interopérabilité et échanges de données pour les archives
Dublin Core
Xml elgarrai 2020
Introduction à XML
07 big data sgbd
Description archivistique
10 big data hadoop
Modèles de données et langages de description ouverts 2021-2022 - 2
XML Avancé : DTD, XSD, XPATH, XSLT, XQuery
Publicité

En vedette (20)

PDF
Implémentation d'openvpn
PDF
Installation de fedora 11
PDF
Rapport bluetooth
PDF
Installation de wink sous fedora
PDF
Installation et configuration d'ads 2003
PDF
Messagerie
PDF
Installation de windows 2003serveur
PDF
VPNIPSec site to site
PDF
Configuration dns
PDF
Dhcp sous fedora 11
PDF
Tuto VP IPSEC Site-to-site
PDF
GNS3, VoIP, ToIP
PDF
Openfire + Active Directory sur Windows 2008 R2
PDF
Tuto Serveur Vocal Interactif (SVI ou IVR)
PDF
Installation cisco call manager 6.0
PDF
Comment enlever un mot de passe admin win 7 sans logiciel
PDF
Directory Servers and LDAP
PDF
Installation et configuration de openfire
PDF
PDF
Tutoriel nat pat
Implémentation d'openvpn
Installation de fedora 11
Rapport bluetooth
Installation de wink sous fedora
Installation et configuration d'ads 2003
Messagerie
Installation de windows 2003serveur
VPNIPSec site to site
Configuration dns
Dhcp sous fedora 11
Tuto VP IPSEC Site-to-site
GNS3, VoIP, ToIP
Openfire + Active Directory sur Windows 2008 R2
Tuto Serveur Vocal Interactif (SVI ou IVR)
Installation cisco call manager 6.0
Comment enlever un mot de passe admin win 7 sans logiciel
Directory Servers and LDAP
Installation et configuration de openfire
Tutoriel nat pat
Publicité

Similaire à Lightweight directory access protocol (20)

PDF
cours8.pdf
PDF
Mise en place d’un gestionnaire d’annuaire
PPTX
LDAP meaning and what we have used .pptx
PPTX
Pres4777777777777777777entationLDAP1.pptx
PPT
Presentation dublincore l3
PDF
Alphorm.com Formation Active directory 2019 : Configuration et Bonne pratiques
PPT
Metadonnees et SID
ODP
SL2009 - Identity Management Cycle - LDAP synchronization and WebSSO
PPTX
code4lib 2011 : choses vues et entendues par l'ABES
PPTX
ORACLE.pptx fromation genie logiciel accele
PPTX
ORACLETEDORACLEDEVELOPPEMENTWEBCJEK.pptx
PPTX
Sudoc, Calames, theses.fr et le Web de données
PPTX
Cours_Linux_S1_Partie 2.pptx
PPTX
Elastic serach
PDF
Delta lake - des data lake fiables a grande échelle
PDF
Notes de cours et tp - Administation Systèmes
PDF
Cl484 g formation-ibm-db2-10-1-for-linux-unix-and-windows-quickstart-for-expe...
PPTX
Concepts et langages des Bases de Données Relationnelles.pptx
PDF
Framework Hibernate
cours8.pdf
Mise en place d’un gestionnaire d’annuaire
LDAP meaning and what we have used .pptx
Pres4777777777777777777entationLDAP1.pptx
Presentation dublincore l3
Alphorm.com Formation Active directory 2019 : Configuration et Bonne pratiques
Metadonnees et SID
SL2009 - Identity Management Cycle - LDAP synchronization and WebSSO
code4lib 2011 : choses vues et entendues par l'ABES
ORACLE.pptx fromation genie logiciel accele
ORACLETEDORACLEDEVELOPPEMENTWEBCJEK.pptx
Sudoc, Calames, theses.fr et le Web de données
Cours_Linux_S1_Partie 2.pptx
Elastic serach
Delta lake - des data lake fiables a grande échelle
Notes de cours et tp - Administation Systèmes
Cl484 g formation-ibm-db2-10-1-for-linux-unix-and-windows-quickstart-for-expe...
Concepts et langages des Bases de Données Relationnelles.pptx
Framework Hibernate

Lightweight directory access protocol

  • 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)
  • 11. Affichage des enregistrements Un extrait de ce qui est affiché. Dimitri LEMBOKOLO 11
  • 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