par Quand on commence à avoir un certain nombre d’applications et donc, un certain nombre de bases utilisateur, cela devient vite compliqué à la fois pour l’administration, mais également pour les utilisateurs (plusieurs logins, mots de passe, etc..).
Il est donc temps de se poser la question de la centralisation de ses utilisateurs dans un seul référentiel. On pourrait très bien se service d’une base SQL, mais il existe un autre type de service bien plus adapté à ce genre d’usage : OpenLDAP, un annuaire LDAP (Lightweight Directory Access Protocol), dérivé des vénérables annuaires X500.
Article révisé en octobre 2022
I – Présentation
L’idée est de faire en sorte qu’un utilisateur puisse se connecter avec un login/mdp et qu’en fonction d’appartenance à des groupes, de présence d’attributs, etc.. il ait l’accès ou non aux applications, services, etc…
Je parlais un peu avant de la possibilité de faire cela avec un serveur SQL. Cependant, effectuer l’authentification en passant par le LDAP offre un avantage non négligeable : la rapidité. En effet, la particularité d’un ldap par rapport à un SGBD est l’optimisation pour la lecture. Une requête sera traité bien plus rapidement par LDAP que par MYSQL.
Dans un environnement avec de nombreuses authentifications concomitantes la différence peut se faire sentir en terme de charge. Et pour terminer avec les avantages du LDAP pour l’authentification, c’est que cela s’intégrera parfaitement dans un futur contexte AAA (Authentication, Authorization, Accounting).
Je ne vais pas faire un cours magistral sur le protocole LDAP (on trouve de nombreuses doc sur la toile), retenez simplement que c’est donc très pratique mais pas forcement simple à prendre en main.
Ce qu’il faut savoir :
Les informations sont stockées dans une structure en arborescence (différent en ce point par exemple d’un SGBD qui stocke les informations de manière relationnelle.
Avec OpenLDAP vous avez la liberté de définir complètement l’arborescence vous-même. On l’appelle « Directory Information Tree » (DIT).
Dans la grande majorité des articles sur OpenLDAP, on trouve la classique arborescence avec les OU People et Group.
Dans notre exemple, nous allons faire un peu plus complexe en prévision du futur.Nous allons commencer par un nœud racine dc=debugo,dc=fr contenant trois nœuds sous la racine:
ou=group,dc=debugo,dc=fr : elle contiendra elle même deux OU :
- ou=sysgroup,ou=group,dc=debugo,dc=fr qui contiendra les groupes systèmes (groupe d’accès à des applications).
- ou=workgroup,ou=group,dc=debugo,dc=fr qui contiendra les groupes de travail en fonction de mes clients (par ex un groupe par client pour le partage via le cloud ou FTP (articles à venir).
ou=people,dc=debugo,dc=fr : deux sous OU la aussi :
- ou=debugo,ou=people,dc=debugo,dc=fr pour les comptes utilisateurs privés.
- ou=client,ou=people,dc=debugo,dc=fr pour les comptes de mes clients.
ou=system,dc=debugo,dc=fr : OU qui contiendra les comptes systèmes permettant de lire les mots de passe des utilisateurs ldap.
Une chose à savoir, à partir de la version 2.3, la façon de configurer OpenLDAP a changé : on passe d’une configuration dans un fichier (slapd.conf) à une configuration elle même dans une base LDAP (dans l’arbre cn=config). L’avantage est conséquent : il est possible de modifier la configuration sans arrêter et redémarrer le service (ce qui dans le cas d’un gros annuaire peut être très long).
Pour se faire, nous mettrons nos différents paramétrages dans des fichiers ldif, que nous injecterons dans le serveur, sans le couper, et ce, dans le but de modifier sa configuration à chaud.
Bref, voila pour la présentation de cette série de tutoriels.
II – Contenu de la série
I – Installation et configuration
III – Peuplement de l’annuaire
V – Sauvegarde et restauration
VIII – Les ACLs
IX – Les Index
X – Monitoring
XI – Création d’un schéma personnel
