URL: https://linuxfr.org/users/peb--2/journaux/gestion-de-ldap-sous-debian-openldap Title: Gestion de LDAP sous Debian : OpenLDAP Authors: PEB Date: 2013年06月20日T03:55:36+02:00 License: CC By-SA Tags: ldap, openldap, slapd, postgresql, debian et explication Score: 57 Il y a quelques mois, j'avais, sur un wiki, rédigé un tutoriel sur les bases LDAP. Souvent laissées de côté au profit de SGBDR (système de gestion de base de données relationnelles), considérés comme plus classiques (MySQL, PostgreSQL, ...), les bases LDAP peuvent parfois s'avérer pratiques. Je me propose donc de faire une présentation de ce type de bases de données ici. Je ne cherche pas à inciter les gens à s'en servir, j'utilise moi-même bien plus souvent PostgreSQL, mais lorsqu'on administre plusieurs machines sous Debian (par exemple), on peut parfois se rendre compte que LDAP peut être très utile. Volontairement, je vais tenter de ne pas être trop technique ici, je parlerai de technique dans un autre journal. LDAP, c'est quoi ? =========== LDAP est un acronyme signifiant Lightweight Directory Access Protocol. Il s'agit d'un protocole d'accès et de gestion d'annuaires (distants ou non). Pragmatiquement, c'est un système de base de données sous forme d'arbre. Chaque entrée de la base est un nœud, possédant des attributs (qui définissent ses caractéristiques), éventuellement des nœuds enfants, et souvent, un nœud parent (seul le nœud racine n'a pas de parent). LDAP est hiérarchisé, cela signifie qu'un nœud ne peut pas avoir plus d'un parent (on ne peut y accéder depuis la racine que par un chemin). Contrairement à ce que l'on peut voir dans un SGBDR, un attribut dans un nœud peut avoir zéro, une, _ou plusieurs_ valeurs (qui n'a pas essayé de trouver une solution propre pour qu'un compte utilisateur dans une base type SQL puisse avoir plusieurs adresses mail par exemple). La structure hiérarchisée de LDAP impose que chaque nœud ait un identifiant unique, appelé DN (Distinguished Name), qui correspond à un chemin d'accès. Cet identifiant est en fait la concaténation de l'identifiant du nœud parent avec un identifiant propre au nœud courant. Voici un exemple de (toute petite) base LDAP, où l'on représente juste les nœuds. ![Simple représentation LDAP](http://pimeys.fr/peb/nimages/ldap/simple_ldap.png) Par exemple, ici, le nœud me concernant a pour DN uid=peb,ou=users,dc=localdomain. Il peut contenir des informations, mais elles ne seront pas visibles ici. Les informations que peuvent contenir un nœud dépend du type d'objet que celui-ci doit représenter. Par exemple, un nœud peut représenter un utilisateur système, un groupe posix, une entreprise, une catégorie (dans un forum, par exemple), une machine. En fonction de cela, on voudra qu'il contienne des informations adaptées (adresse IP, nom, prénom, mot de passe, adresse MAC, ...). À ce titre, une base LDAP intègre dans sa configuration des schémas. La plupart sont classiques et livrés tels quels. Souvent, quand on utilise une base LDAP, on ajoutera à ces schémas un ou plusieurs schémas faits maison, qui définiront les objets dont on a besoin, en plus des types d'attributs et d'objets déjà existants. Là où j'utilise LDAP, on a un schéma pour représenter les adhérents de notre association, leurs machines, etc... Voici un exemple du contenu d'un nœud. dn: aid=3775,ou=data,dc=crans,dc=org objectClass: adherent objectClass: cransAccount objectClass: posixAccount objectClass: shadowAccount aid: 3775 charteMA: TRUE chbre: 404 cn: PEB droits: RTech droits: Bureau gecos: PEB,,, gidNumber: 100 homeDirectory: peb loginShell: /bin/zsh mail: peb@example.com mailAlias: taiste@example.com nom: B prenom: PE uid: peb uidNumber: 2573 userPassword: {SSHA}xwEP3a1xdO003bBeKfykI4gMbeGiT3kV On a donc des couples attributs/valeurs, stockés dans un nœud, qui le caractérisent. Certains, tels dn et objectClass, se trouvent dans tout nœud. D'autres sont propres au type de nœud (défini par l'attribut objectClass). LDAP, pourquoi ? =========== Outre le fait que certaines choses se représentent mieux sous forme d'arbre que dans une base de données relationnelle, il y a des raisons pratiques d'utiliser LDAP sous Debian : la compatibilité avec les autres logiciels. Imaginons, vous administrez une vingtaine de machines sous Debian, et vous êtes quatre ou cinq administrateurs, plutôt que de créer des utilisateurs locaux, vous pourriez par exemple installer un serveur LDAP sur une de ces machines, le configurer, créer des utilisateurs dedans, et installer le paquet nslcd sur les autres machines. Celles-ci iraient alors demander au serveur LDAP les informations de connexion pour les utilisateurs qu'elles ne connaissent pas, et feraient le nécessaire pour qu'ils puissent se connecter. Ainsi, plus besoin de créer vingt fois le même utilisateurs, plus besoin de changer son mot de passe partout, etc. Seul défaut : si le serveur LDAP est dans les choux, plus personne ne peut se connecter avec son compte LDAP sur les machines. Il faut soit prévoir des utilisateurs locaux, soit utiliser le compte root (lui doit toujours être local). PAM et LDAP s'interfacent bien, donc (PAM et PostgreSQL aussi, mais le module développé à cet effet avait tendance à crasher, sous squeeze...), mais ce n'est pas tout ! LDAP et postfix s'interfacent également bien (donc votre MX peut aller lire dans une (ou plusieurs) bases LDAP si un utilisateur existe, et lui délivrer des messages), LDAP et dovecot (POP/IMAP), LDAP et django s'interfacent bien, LDAP et Moinmoin s'interfacent bien, SOGo/Roundcube/Horde et LDAP s'interfacent bien, en fait, dans l'ensemble, la plupart des services qu'on peut souhaiter avoir et LDAP s'interfacent bien. Pourquoi s'en priver ? LDAP, c'est difficile ? =========== L'approche de LDAP nécessite un peu plus de doigté que l'approche de PostgreSQL ou MySQL. Déjà, comme pour ceux-ci, il y a une syntaxe à apprendre : la syntaxe LDIF (pour LDAP Data Interchange Format), mais la configuration est plus technique, elle nécessite dans un premier temps d'écrire un fichier de configuration puis de l'incorporer avec une commande dans la base de configuration (la configuration des diverses bases LDAP sur un serveur est stockée dans... une base LDAP), après avoir choisi les schémas qui vous intéressent. Une fois la configuration faite, il faut créer une première base de données pour y stocker des données. Pour cela, il faut encore faire de la configuation, choisir le type de base de donnée (hdb, bdb, ...). Il faut la peupler, sachant que par défaut, il n'existe pas une command-line spécifique comme psql ou mysql. On peut installer des outils (ldap-tools, shelldap, etc) pour faciliter la navigation. Essentiellement, la difficulté réside dans le fait que l'approche est différente des SGBD habituels, et dans la légèreté du protocole qui oblige à faire pas mal de choses à la main. Il faut savoir que la plupart des langages de programmation comportent une librairie pour communiquer avec les bases LDAP, cela diminue certaines difficultés que l'on pourrait croiser. LDAP n'est donc pas extrêmement difficile en soi, mais impose de s'adapter et de découvrir de nouvelles choses. Je proposerai prochainement une approche plus technique, entres autres comment installer et configurer un serveur LDAP. (paquet slapd sous debian) Un peu de doc ========== [en] [OpenLDAP](http://www.openldap.org/), le site du projet OpenLDAP. [en] [Zytrax](http://www.zytrax.com/books/ldap/), un très bon site avec pas mal d'infos. [en] [Ubuntu](https://help.ubuntu.com/10.04/serverguide/openldap-server.html) propose également une doc. Ce dernier lien a d'ailleurs donné : [fr] [Doc LDAP sur Ubuntu](http://doc.ubuntu-fr.org/openldap-server) Bonne lecture !

AltStyle によって変換されたページ (->オリジナル) /