\documentclass[a4paper,11pt]{report} \input{../includes/headers_global.tex} \def\sitename{Debian GNU/Linux :: Serveur } \def\shorttitre{LDAP - MDS} \def\titre{Annuaire LDAP - MDS} \def\autheur{Matthieu Vogelweith} \def\subject{Mise en place d'un annuaire LDAP / MDS sous Debian GNU/Linux} \def\keywords{Debian, Linux, Matthieu, Vogelweith, Serveur, Etch, LDAP, MDS, AJAX, annuaire} \input{../includes/headers.tex} \begin{document} \renewcommand{\bibname}{R\'ef\'erences} \begin{titlepage} \maketitle \end{titlepage} \chapter*{Résumé} 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 multi-critè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) sous l'impulsion d'une équipe de l'université du Michigan (logiciel U-M LDAP). L'objectif de ce document est de détailler l'installation d'un serveur OpenLDAP \cite{openldap} complet piloté par le MDS (\textbf{M}andriva \textbf{D}irectory \textbf{S}erver \cite{mds}) ainsi que les bases de son administration. Les différentes pages disponibles dans cette rubrique utiliseront dans la mesure du possible cet annuaire pour réaliser l'authentification des utilisateurs.\\ \input{../includes/licence.tex} %\input{licence.tex} \tableofcontents \chapter{Serveur OpenLDAP} \section{Installation des paquets} L'implémentation LDAP la plus répandue actuellement dans le monde libre est OpenLDAP, disponible dans le paquet Debian "slapd". On peut également installer le paquet "ldap-utils" qui fournit quelques outils permettant de manipuler les annuaires. \vspace{1em} \begin{lstlisting} # aptitude install slapd ldap-utils \end{lstlisting} \vspace{1em} Lors de la configuration de slapd, debconf demande simplement le mot de passe administrateur de l'annuaire. Il utilise ensuite le nom de domaine configuré sur la machine pour définir la racine de l'annuaire LDAP. Par exemple, si la machine locale s'appelle \textbf{ldap.example.org}, debconf va construire une arborescence LDAP ayant pour racine \textbf{dc=example,dc=org}. Les fichiers de configurations se trouvent dans le répertoire "/etc/ldap/". On trouve, entre autre, le fichier \textbf{slapd.conf} qui est le fichier de configuration du démon et \textbf{ldap.conf} qui est le fichier de configuration pour les utilitaires installés précédemment avec le paquet ldap-utils. La configuration initiale générée par debconf permet déjà de faire un premier test pour vérifier que le serveur fonctionne bien. On peut par exemple utiliser la commande \textbf{slapcat} qui va afficher le contenu de l'annuaire au format LDIF. Pour l'instant l'annuaire n'est pas très consistant, mais par la suite, il est préférable de re-diriger la sortie standard de slapcat dans less afin de pouvoir exploiter le résultat de la commande. \vspace{1em} \begin{lstlisting} # slapcat | less \end{lstlisting} \vspace{1em} Notons que cette commande affiche un dump de l'annuaire sur la sortie standard en utilisant directement des fichiers de. Elle permet donc de visualiser le contenu de l'annuaire mais ne valide en aucun cas que le service fonctionne correctement. L'interrogation de l'annuaire en utilisant le protocole TCP dédié à cet effet avec la commande "ldapsearch" est décrite plus loin. \section{Configuration du démon} Avant de commencer à remplir et utiliser l'annuaire, il faut configurer une base et définir les droits d'accès. Toute cette configuration se fait dans \textbf{slapd.conf}. Ce fichier est divisé en plusieurs parties : d'abord une partie générale pour la configuration du démon puis une partie spécifique à chaque annuaire hébergé sur le serveur. Dans un premier temps, il n'est pas nécessaire de faire de modifications dans la partie générale, debconf s'est chargé de faire une configuration minimale en fonction des réponses données lors de l'installation du paquet. On peut cependant examiner rapidement une section intéressante du fichier de configuration, la définition des ACLs : \vspace{1em} \begin{lstlisting} access to attrs=userPassword by dn="cn=admin,dc=example,dc=org" write by anonymous auth by self write by * none access to dn.base="" by * read access to * by dn="cn=admin,dc=example,dc=org" write by * read \end{lstlisting} \vspace{1em} La configuration ci-dessus permet à l'administrateur d'éditer l'ensemble de l'annuaire alors que les utilisateurs anonymes peuvent simplement y accéder en lecture seule. \section{Support SSL} Par défaut, le démon \textbf{slapd} n'est actif qu'en mode "normal" sur le port 389. Pour permettre le support SSL, if faut bien sûr générer un certificat SSL qui permettra de s'assurer de l'authenticité du service et de chiffrer/déchiffrer les communications. Dans le cas du serveur LDAP, on peut créer le fichier de configuration \textbf{/etc/ssl/slapd.cnf} ci-dessous : \vspace{1em} \begin{lstlisting} [ req ] default_bits = 2048 default_keyfile = privkey.pem distinguished_name = req_distinguished_name prompt = no string_mask = nombstr x509_extensions = server_cert [ req_distinguished_name ] countryName = FR stateOrProvinceName = France localityName = Strasbourg organizationName = Example organizationalUnitName = LDAP Server commonName = ldap.example.org emailAddress = ldapmaster@example.org [ server_cert ] basicConstraints = critical, CA:FALSE subjectKeyIdentifier = hash keyUsage = digitalSignature, keyEncipherment extendedKeyUsage = serverAuth, clientAuth nsCertType = server nsComment = "LDAP Certificate" \end{lstlisting} \vspace{1em} La génération du certificat se fait ensuite avec la commande suivante : \vspace{1em} \begin{lstlisting} # openssl req -x509 -new \ -config /etc/ssl/slapd.cnf \ -out /etc/ssl/certs/slapd.pem \ -keyout /etc/ssl/private/slapd.key \ -days 730 -nodes -batch \end{lstlisting} \vspace{1em} Pour activer le support SSL de ce démon, il faut maintenant modifier la directive \textbf{SLAPD\_SERVICES} du fichier /etc/default/slapd. Par exemple, pour que le démon soit disponible en mode normal et en mode SSL, il faut utiliser la configuration suivante : (Notons qu'en mode SSL, le démon écoute sur le port 636) \vspace{1em} \begin{lstlisting} SLAPD_SERVICES="ldap:/// ldaps:///" \end{lstlisting} \vspace{1em} Il faut ensuite indiquer l'emplacement du certificat et de la clé SSL dans le fichier /etc/ldap/slapd.conf : \vspace{1em} \begin{lstlisting} TLSCertificateFile /etc/ssl/certs/slapd.pem TLSCertificateKeyFile /etc/ssl/private/slapd.key \end{lstlisting} \vspace{1em} Attention à bien positionner les droits pour les fichiers pour que le démon \textbf{slapd} puisse lire correctement la clé : \vspace{1em} \begin{lstlisting} # chgrp openldap /etc/ssl/private/slapd.key # chmod g+r /etc/ssl/private/slapd.key \end{lstlisting} \vspace{1em} Comme toujours, il faut maintenant redémarrer le service pour que les modifications soient prise en compte. \vspace{1em} \begin{lstlisting} # /etc/init.d/slapd restart \end{lstlisting} \vspace{1em} On peut faire une rapide vérification en utilisant \textbf{nmap} : en principe la commande doit indiquer que le serveur écoute sur les ports 389 et 636 (ldap et ldapssl). \vspace{1em} \begin{lstlisting} # nmap 127.0.0.1 -p 389,636 \end{lstlisting} \vspace{1em} \section{Quelques tests} L'annuaire est maintenant disponible sut le port 389 en TCP et de manière chiffrée sur le port 636 en TCP. Pour valider le bon fonctionnement du service, on peut interroger l'annuaire avec la commande \textbf{ldapsearch} fournie par le paquet \textbf{ldap-utils} installé précédemment. Par exemple, pour faire une requête LDAP : \vspace{1em} \begin{lstlisting} # ldapsearch -x -H ldap://ldap.example.org -b "ou=Users,dc=example,dc=org" "(objectclass=*)" \end{lstlisting} \vspace{1em} Pour utiliser le mode SSL avec ldapsearch, il faut dans un premier temps ajouter la ligne suivante dans le fichier /etc/ldap/ldap.conf pour ignorer la vérification du certificat : \vspace{1em} \begin{lstlisting} TLS_REQCERT allow \end{lstlisting} \vspace{1em} Il suffit maintenant de reprendre la même requête en modifiant l'URI et en ajoutant l'option -Z : \vspace{1em} \begin{lstlisting} # ldapsearch -x -H ldaps://ldap.example.org:636 -Z -b "ou=Users,dc=example,dc=org" "(objectclass=*)" \end{lstlisting} \vspace{1em} \chapter{Gestion de l'annuaire : Mandriva Directory Server} \section{Présentation} La gestion d'un annuaire LDAP avec les outils fournis dans le paquets \textbf{ldap-utils} devient vite très complexe si l'annuaire nécessite des modifications régulières (ajout d'utilisateurs, de contacts, ...). Le MDS (\textbf{M}andriva \textbf{D}irectory \textbf{S}erver \cite{mds}) propose donc une solution ergonomique en AJAX permettant de gérer l'annuaire le plus simplement possible. Outre la simplicité d'administration, le MDS propose plusieurs plugins afin de gérer les services associés à l'annuaire comme Samba, Postfix Bind ou DHCPD. Ce chapitre détaille donc l'installation de base du MDS, simplement pour permettre la gestion des utilisateurs des groupes. L'installation, la configuration et l'utilisation des différents plugins seront détaillés dans les pages dédiées aux différents services. \section{Préparation} Le MDS n'est pas encore disponibles des les dépôts officiels de Debian, il faut donc ajouter un dépôt spécifique dans /etc/apt/sources.list : \vspace{1em} \begin{lstlisting} # Mandriva Directory Server deb http://mds.mandriva.org/pub/mds/debian etch main \end{lstlisting} \vspace{1em} Reste maintenant à mettre à jour la liste des paquets disponibles avec la commande suivante : \vspace{1em} \begin{lstlisting} # aptitude update \end{lstlisting} \vspace{1em} \section{Installation de base} \vspace{1em} \begin{lstlisting} # aptitude install mmc-agent mmc-web-base \end{lstlisting} \vspace{1em} - Configuration de l'accès à l'annuaire LDAP dans /etc/mmc/plugins/base.ini \vspace{1em} \begin{lstlisting} ... \end{lstlisting} \vspace{1em} - Création d'un utilisateur \section {NSS - Name Service Switch} \vspace{1em} \begin{lstlisting} # aptitude install libnss-ldap \end{lstlisting} \vspace{1em} En premier lieu, on indique à NSS qu'il faut chercher les utilisateurs dans l'annuaire LDAP. Pour cela, il suffit d'éditer le fichier \textbf{/etc/nsswitch.conf} et de modifier les trois lignes ci-dessous. Notons qu'avec la configuration suivante, le système va d'abord utiliser les listes d'utilisateurs locales (/etc/passwd, /etc/group, ...) avant de chercher dans l'annuaire. Ceci permet d'utiliser les deux types de comptes simultanément et permet d'éviter les problèmes en cas d'indisponibilité du serveur LDAP. \vspace{1em} \begin{lstlisting} passwd: files ldap group: files ldap shadow: files ldap \end{lstlisting} \vspace{1em} Maintenant que NSS sait qu'il faut utiliser LDAP pour chercher les utilisateurs qui ne sont pas déclarer localement, il faut configurer le module libnss-ldap pour lui donner les paramètres du serveur LDAP à utiliser. Si vous avez répondu correctement aux questions de debconf, la configuration doit être opérationnelle. On peut cependant vérifier les trois lignes suivantes dans le fichier \textbf{/etc/libnss-ldap.conf} : \vspace{1em} \begin{lstlisting} host 127.0.0.1 base dc=example,dc=org ldap_version 3 \end{lstlisting} \vspace{1em} Si tout c'est passé correctement, on peut maintenant consulter les informations d'un utilisateur LDAP en exécutant la commande suivante : \vspace{1em} \begin{lstlisting} # getent passwd matthieu matthieu:x:1000:1000:Matthieu Vogelweith:/home/matthieu/:/bin/bash \end{lstlisting} \vspace{1em} Pour information, le paquet \textbf{nscd} a peut-être été installé en même temps que la librairie libnss-ldap. Ce paquet permet de mettre en cache les requêtes de NSS vers LDAP afin de minimiser la charge de l'annuaire. En conséquence, si de nombreuses modifications sont faites pendant la période de test du serveur, les résultats peuvent être erronés. Sur un système en production, notamment si Samba utilise l'annuaire, il est fortement conseillé de supprimer ce paquet afin de ne pas obtenir des comportements inexplicables lors de l'accès à l'annuaire. \chapter{Configuration des clients} Maintenant que l'annuaire est en place et qu'il contient quelques utilisateurs, il faut configurer les clients qui souhaitent utiliser cet annuaire. Si l'annuaire a bien été conçu, il peut être utilisé pour beaucoup de fonction différentes. La première étant l'authentification. L'avantage de LDAP est qu'on peut l'utiliser comme support d'authentification pour un grand nombre de services et avoir ainsi une base des utilisateurs centralisée. \section {Authentification sur l'annuaire LDAP} Actuellement, la plupart des applications utilisent une librairie pour obtenir des informations sur les utilisateurs et une autre pour réaliser leurs authentifications. La première tâche est confiée à NSS (\textbf{N}ame \textbf{S}ervice \textbf{S}witch) qui se charge de fournir une liste des utilisateurs, des groupes, etc. L'authentification est par contre confiée à PAM (\textbf{P}luggable \textbf{A}uthentication \textbf{M}odule) qui va alors vérifier la validité des identifiants et proposer différentes actions a exécuter lorsqu'un utilisateur s'authentifie. Pour authentifier un utilisateur sur un annuaire LDAP, il faut donc ajouter le support LDAP à NSS et à PAM. Ceci est réalisé grâce aux deux librairies \textit{libnss-ldap} et \textit{libpam-ldap}. Le système est maintenant capable de chercher des utilisateurs dans l'annuaire, il ne reste plus qu'a les authentifier par l'intermédiaire de PAM. \subsection {PAM - Pluggable Authentication Module} \vspace{1em} \begin{lstlisting} # aptitude install libpam-ldap \end{lstlisting} \vspace{1em} Comme pour la librairie \textit{libnss-ldap}, la configuration est normalement opérationnelle suite aux questions de debconf mais on peut toujours vérifier les éléments suivants dans le fichier \textbf{/etc/pam\_ldap.conf} : \vspace{1em} \begin{lstlisting} host 127.0.0.1 base dc=example,dc=org ldap_version 3 rootbinddn cn=admin,dc=example,dc=org pam_password crypt \end{lstlisting} \vspace{1em} - configuration de /etc/pam.d/common-account \vspace{1em} \begin{lstlisting} account sufficient pam_ldap.so account required pam_unix.so try_first_pass \end{lstlisting} \vspace{1em} - configuration de /etc/pam.d/common-auth \vspace{1em} \begin{lstlisting} auth sufficient pam_ldap.so auth required pam_unix.so nullok_secure try_first_pass \end{lstlisting} \vspace{1em} - configuration de /etc/pam.d/common-password \vspace{1em} \begin{lstlisting} password sufficient pam_ldap.so password required pam_unix.so nullok obscure min=4 max=8 md5 try_first_pass \end{lstlisting} \vspace{1em} En principe, il est maintenant possible de s'authentifier correctement sur une machine cliente en utilisant un des utilisateurs créés dans l'annuaire. Il est également possible de modifier le mot de passe de chacun en utilisant la commande bien connue \textbf{password} : le mot de passe sera mis à jour directement dans l'annuaire. Il manque maintenant une chose essentielle : les répertoires des utilisateurs. En effet lors de la création des utilisateurs dans l'annuaire, on spécifie un chemin de \textbf{homeDir} mais a aucun moment ce répertoire n'a été créé : c'est l'objet de la section suivante. \section{Carnet d'adresses} On peut maintenant utiliser cette base comme annuaire au premier sens du terme, pour les clients mails par exemple. En effet il est maintenant très simple de demander aux clients mails de remplir le carnet d'adresse avec l'annuaire LDAP. Avec Thunderbird, par exemple, il faut ouvrir le carnet d'adresse puis ajouter un Repertoire LDAP ( Menu Fichier->Nouveau ). On peut télécharger l'annuaire complet ou rester en mode connecté. \chapter{Gestion des environnements complexe} - Utilisation de plusieurs agents\\ - Gestion des réseaux multi-sites avec le MDS\\ \chapter{Replication LDAP avec SyncRepl} \section{Configuration du maître} Dans /etc/ldap/slapd.conf \vspace{1em} \begin{lstlisting} # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. rootdn "cn=admin,dc=example,dc=org" moduleload syncprov sessionlog 123 500 overlay syncprov syncprov-checkpoint 50 5 syncprov-sessionlog 50 \end{lstlisting} \vspace{1em} Reste enfin à redémarrer le service sur l'annuaire maître pour que la réplication fonctionne. \vspace{1em} \begin{lstlisting} # /etc/init.d/slapd restart \end{lstlisting} \vspace{1em} \section{Configuration des esclaves} Coté esclave, il est existe deux méthodes de réplication lorsqu'on utilise SyncRepl : \begin{itemize} \item \textbf{refreshOnly} : L'esclave se met à jour périodiquement en utilisant les données du maître. Par exemple, il se connecte une fois par jour pour vérifier si des données ont été modifiées. \item \textbf{refreshAndPersist} : L'esclave conserve une connexion persistante avec l'annuaire maître et les données sont répliquées en temps réel lors de chaque modification sur le maître. \end{itemize} L'exemple ci-dessous décrit la configuration d'un esclave en mode "refreshAndPersist" qui présente beaucoup plus d'intérêt à mon sens. \vspace{1em} \begin{lstlisting} index entryUUID,entryCSN eq rootdn "cn=admin,dc=example,dc=org" syncrepl rid=421 provider=ldap://ip_du_serveur_LDAP_maitre:389 type=refreshAndPersist retry="60 +" searchbase="dc=example,dc=org" schemachecking=on bindmethod=simple binddn="cn=admin,dc=example,dc=org" credentials=mon_mot_de_passe \end{lstlisting} \vspace{1em} Cette configuration impose la vérification des schémas grâce à l'option \textbf{schemachecking=on}. Il faut donc impérativement que l'ensemble des schémas utilisés sur le maître soient disponible sur les esclaves. Une méthode rapide peut-être de copier simplement tous les schémas du maître avec une commande du type : \vspace{1em} \begin{lstlisting} # scp root@ip_du_serveur_LDAP_maitre:/etc/ldap/schema/*.schema /etc/ldap/schema/ \end{lstlisting} \vspace{1em} Bien évidemment, il reste à modifier le fichier slapd.conf pour correspondre à la configuration du maître. Il faut notamment modifier les paramètres suivants : \begin{itemize} \item La liste des schémas utilisés (include /etc/ldap/schema/nom\_du\_schema) \item Le suffix de l'annuaire (par exemple "dc=example,dc=org) \item Les ACLs si le DN de l'administrateur LDAP est différent. \end{itemize} Contrairement à slurpd, avec SyncRepl l'annuaire esclave ne doit pas nécessairement être identique à l'annuaire maître lorsque l'on démarre la réplication. La méthode la plus simple est donc de supprimer complètement les données existantes sur l'esclave et de démarrer ensuite la réplication. De cette façon, au démarrage du démon, syncrepl va copier l'intégralité de l'annuaire maître sur l'esclave. \vspace{1em} \begin{lstlisting} # /etc/init.d/slapd stop # rm /var/lib/ldap/* # /etc/init.d/slapd start \end{lstlisting} \vspace{1em} Avec cette configuration, le client établi une connexion persistante vers l'annuaire maître et synchronise l'annuaire en temps réel. Il est possible de vérifier que la connexion est bien établie avec la commande netstat : \vspace{1em} \begin{lstlisting} # netstat -naptu | grep "ESTABLISHED.*slapd" \end{lstlisting} \vspace{1em} Le résultat de cette commande doit montrer une connexion TCP établie entre l'adresse IP de l'esclave et l'adresse IP du maître sur le port 389. \section{Écriture depuis un réplica} La réplication proposée par OpenLDAP < 2.4.0 est une réplication de type maître / esclave. C'est à dire qu'il n'est possible de faire des modifications que sur le maître. Pour contourner le problème, il est possible d'indiquer à un esclave de transmettre les demandes d'écriture à l'annuaire maître. Pour cela, il suffit d'ajouter la ligne suivante dans le fichier /etc/ldap/slapd.conf de l'esclave : \vspace{1em} \begin{lstlisting} updateref ldap://ip_du_serveur_LDAP_maitre:389 \end{lstlisting} \vspace{1em} \chapter{Quelques outils} \section{slapcat} L'utilitaire slapcat déjà été utilisé pour vérifier le contenu de l'annuaire dans cette page. Il peut également servir à générer un dump de l'annuaire pour réaliser des sauvegardes par exemple. La commande ci-dessous génère par exemple undump de l'annuaire et l'enregistre dans un fichier daté : \vspace{1em} \begin{lstlisting} # slapcat > `date +ldap_dump_%Y%m%d_%H%M%S` \end{lstlisting} \vspace{1em} \section{ldappasswd} Le mot de passe de l'administrateur LDAP renseigné lors de la configuration du paquet \textbf{slapd} est toujours modifiable en utilisant la commande suivante (en remplaçant "new\_passwd" et "old\_passwd" par les valeurs désirées) : \vspace{1em} \begin{lstlisting} # ldappasswd -s new_passwd -D "cn=admin,dc=example,dc=org" -w old_passwd -x cn=admin,dc=example,dc=org \end{lstlisting} \vspace{1em} Notons que la commande \textbf{ldappasswd} est fournie pour le paquet \textbf{ldap-utils}. \section{ldapvi} Pour les adeptes de l'éditeur VI, il existe un outils très intéressant permettant d'éditer le contenu d'un annuaire LDAP avec VI : \textbf{ldapvi}. Il est disponible dans les dépôts officiels Debian dans le paquet du même nom : \vspace{1em} \begin{lstlisting} # aptitude install ldapvi \end{lstlisting} \vspace{1em} Il est alors possible d'éditer l'annuaire sans être obliger de générer un fichier LDIF et d'utiliser les commandes ldapmodify ou ldapadd. Par exemple, pour éditer un annuaire avec un accès total, utilisez la commande suivante : \vspace{1em} \begin{lstlisting} # ldapvi --discover --host xxx.xxx.xxx.xxx --user "cn=admin,dc=example,dc=org" --password "ldap_password" \end{lstlisting} \vspace{1em} Pour appliquer les modifications, il suffit de quitter VI avec la commande habituelle : \textbf{ESC :wq}. Notons que ldapvi peut être utiliser avec n'importe quel éditeur de texte, il suffit de le définir dans le variable d'environnement EDITOR. \clearpage \nocite{*} \bibliographystyle{unsrt} \bibliography{\jobname} %\ifpdf %\else %\chapter{Vos commentaires} %\fi \end{document}