Différences

Ci-dessous, les différences entre deux révisions de la page.

--- fr:ldap [2025/01/01 13:17] – [Overlays] memberoff zatalyz
+++ fr:ldap [2025/09/20 20:14] (Version actuelle) – Et revoir l'organisation de l'article zatalyz
@@ Ligne 12: / Ligne 12: @@
 C'est bien la seule chose de basique, parce que ça se corse très vite. Mais c'est la logique de base qu'il faut garder en tête.
-Donc, il y a généralement un backend LDAP qui stocke les informations, et un frontend qui permet de les manipuler (idéalement une interface web).
+Concernant l'architecture logiciel, il y a généralement un backend LDAP qui stocke les informations, et un frontend qui permet de les manipuler (idéalement une interface web). Mais on peut aussi avoir uniquement le backend qu'on manipule via le terminal. Enfin, divers logiciels peuvent se connecter à cet annuaire pour utiliser ses informations : par exemple se connecter à Dokuwiki et au forum en utilisant un compte unique, stocké dans LDAP.
+<WRAP center round tip 100%>
+Techniquement, rien n'empêche d'avoir plusieurs frontend (ou clients) qui peuvent manipuler le backend. Le point délicat étant que les clients ont parfois des attentes spécifiques sur l'organisation du serveur LDAP, alors même que ce dernier permet "n'importe quoi" (ce qui est sa force et sa faiblesse).
+Mais il se trouve aussi que les frontend permettent de gérer d'autres choses, par exemple le lien avec OpenID ou Oauth. Or un système de connexion unifié ergonomique va demander de rajouter d'autres protocoles.
+</WRAP>
+<WRAP center round info 100%>
+Attention : LDAP est avant tout un service d'annuaire.
+J'ai passé un temps fou à comprendre ce que ça impliquait...
+Il ne gère pas les cookies, le temps qu'on peut rester connecté, et si on se logue à un endroit cela ne se répercute pas sur tous les CMS.
+Chaque CMS va demander à l'annuaire des informations précises :
+  * Telle personne essaye de se connecter, est-ce qu'elle utilise le bon couple login/pass ?
+  * Quelles sont les groupes dont elle fait partie ? Suivant ces infos le CMS gère de son côté les droits d'accès, d'écriture, etc.
+Il s'agit uniquement de consulter les informations, chaque CMS le faisant "de son côté" !
+D'autres protocoles (dont OpenID, Oauth) sont dans un échange, par exemple pour dire "Cette personne est connectée, on va la noter comme connectée pour tous nos CMS et ainsi, dans cette session, elle n'a pas besoin de re-rentrer ses mots de passe entre le wiki et le forum", et peuvent même gérer diverses permissions directement.
+Ces protocoles et LDAP sont indépendants (chacun peut fonctionner seul) mais peuvent aussi être combinés. C'est une architecture plus complexe, mais qui permet aussi plus de possibilité, en particulier dans les infra comme les nôtres où nous avons énormément de CMS et de sous-groupes d'utilisatrices.
+Pourquoi utiliser LDAP et pas uniquement par un de ces protocoles ? Parce que LDAP est une brique vraiment très basique, bien intégrée "partout" (ou presque), et qu'il est facile de s'y connecter. Les autres protocoles sont nombreux, parfois pas adapté à tous les cas d'usages ; LDAP en dessous permet de vraiment unifier de façon large la gestion des utilisatrices.
+</WRAP>
 ===== Comprendre un annuaire LDAP =====
@@ Ligne 35: / Ligne 62: @@
 </code>
+Cet arbre se lit de la façon suivante : "arina.aldoru" fait partie d'une section appelé "users", laquelle est reliée au domaine "example.org". Et le groupe nommé "admin" fait partie d'une section appelé "groupe", elle aussi rattachée au domaine "example.org".
 ==== Attributs ====
 Chaque donnée dans l'annuaire est un **objet** (par exemple, une identité), à laquelle divers **attributs** sont reliés. Ces attributs et la façon dont ils sont reliés aux objets obéit à une syntaxe particulière. Les attributs par défaut montrent à quel point LDAP est héritier d'une culture impérialiste bien précise. Mais bon, on peut quand même l'adapter à nos besoins et ajouter des attributs pour améliorer les choses. Et on peut supprimer ce qui ne nous sert pas, tant que ce n'est pas requis par la classe d'objet (cf chapitre suivant).
-Ce qui suit **n'est pas exhaustif**. C'est juste le plus commun dans ce qu'on peut croiser.
+Les attributs sont les caractères avant le signe ''='' et l'objet ce qui suit, donc c'est toujours écrit de cette façon :
+  attribut=objet
+Il y a énormément d'attributs possibles. Ce qui suit **n'est pas exhaustif**. C'est juste le plus commun dans ce qu'on peut croiser. Il est même possible de définir ses propres attributs...
 Organisation et groupes
@@ Ligne 50: / Ligne 81: @@
 Identification des personnes :
   * ''cn'' (Common Name) : un nom commun, donc pour désigner une personne ou un objet spécifique (tel que "OrdiBureau").
-  * ''sn'' (Surname) : non, pas "surnom, c'est de l'anglais. C'est le nom de famille.
+  * ''sn'' (Surname) : non, pas "surnom", c'est de l'anglais. C'est le nom de famille.
   * ''givenName'' : prénom.
   * ''mail'' : l'adresse mail de l'objet.
@@ Ligne 67: / Ligne 98: @@
 Autre
   * ''objectClass'' : Classe d'objet. Définit des règles pour l'entrée, par exemple ''objectClass=inetOrgPerson'' pour un objet de type utilisatrice.
+  * ''description'' : permet de décrire (haha). Parfois utile quand les noms sont un peu flou, mais ne pas en abuser car cela alourdis vite la base. Cela permet aussi de compenser le fait qu'il n'y a pas de "commentaire" dans l'annuaire ldap lui-même (mais on peut en mettre dans les fichiers ldif).
+<WRAP center round info 100%>
+**''o'', ''ou'', ''cn'' ou autre ?**
+''o'' et ''ou'' sont à considérer comme des "dossiers", pouvant contenir encore plusieurs arbres. ''o'' est plutôt en amont, par exemple pour désigner les diverses associations hébergés par le même annuaire.
+''cn'' est utilisé pour nommer les groupes qui vont contenir des membres, des entités nommées, là où ''ou'' est réservé à l'organisation hiérarchique de l’annuaire. Par exemple on aura plutôt "ou=groups" et "cn=modératrices", "modératrices" étant un sous-groupe de "groups" et ayant la liste des personnes pouvant faire de la modération.
+Ceci reste des conventions mais va simplifier la gestion de l'annuaire dans le temps.
+</WRAP>
 ==== Classes d'objets ====
@@ Ligne 85: / Ligne 127: @@
     * Obligatoires : ''cn'', ''description''
+==== Peupler son annuaire ====
+Ici, c'est un peu spécial. Et surtout LE point où juste copier ne peut pas suffire.
+Il est très important de définir une hiérarchie propre à son organisation. Dans notre cas, l'annuaire est celui d'une association qui héberge d'autres associations, qui elles-mêmes peuvent héberger divers projets. Et certaines membres font partie de plusieurs assos. D'où mon "ldap.local" comme nom principal. Après m'être bien pris la tête, je vais donc avoir deux grandes branches : d'un côté "user" qui liste tout ce qui peut se connecter, de l'autre "organisation" qui va lister les divers groupes et sous-groupes (dont dépendent ensuite les droits d'accès).
+<WRAP center round help 100%>
+Je n'ai pas encore tranché sur deux cas :
+  * Les non-humains, comme [[user:pendorid|Pendorid]]. On a quelques services qui auront sans doute besoin d'accès spécifiques. J'imagine que ce sera une classe sous "user", sans doute "daemon" histoire de s'amuser.
+  * l'usage des pseudos. Autant je trouve important qu'on aie un seul compte pour s'identifier (et retrouver son mot de passe) autant je comprend fort bien qu'on veuille pousser sur git avec son nom d'état civil mais dire des bêtises sur le forum avec un pseudo (le premier pouvant servir au niveau professionnel, le second non). Là, je ne suis pas certaine qu'un sous-groupe d'user soit pertinent, peut-être que ce sera propre aux organisations. Quoi qu'il en soit, ici l'attribut ''associatedPerson'' sera très utile.
+En attendant, je vais avoir un arbre intitulé ''ou=people,ou=user,dc=ldap,dc=local'' afin si besoin de bien séparer les types d'utilisatrices. Mais ça se questionne.
+</WRAP>
+<WRAP center round todo 60%>
+C'est vraiment la partie la plus compliquée : faire un schéma et trouver les bons attributs à chaque morceau.
+</WRAP>
 ===== Logiciels pour gérer LDAP =====
@@ Ligne 124: / Ligne 183: @@
 ==== OpenLDAP ====
-C'est LE backend de référence. Ça fait le café, d'après les chamanes des profondeurs les plus lointaines de la Crypte.
+Cette partie de l'article devenait un peu obèse, donc je renvoie vers un article dédié : [[fr:openldap]].
-  sudo apt install slapd ldap-utils
-La configuration par défaut s'appuie sur le FQDN de la machine. Avant de tout bidouiller, vérifions...
+OpenLDAP est LE backend de référence. Ça fait le café, d'après les chamanes des profondeurs les plus lointaines de la Crypte. Dès qu'on commence à avoir des besoins un peu personnalisé, on a besoin de ça. Mais c'est aussi un sacré mastodon un peu effrayant. Ça va bien se passer...
-  sudo slapcat | grep dn:
-Le résultat devrait être "dn: dc=example,dc=org" (ou autre domaine). Si c'est ce que vous voulez, parfait. Sinon, ''dpkg-reconfigure slapd'', répondre "non" à "Omit OpenLDAP server configuration?" et ensuite adapter le reste. À la fin, à la question "Do you want the database to be removed when slapd is purged?", répondre "Oui".
-On peut admirer la base de son annuaire avec la commande suivante :
-<code>ldapsearch -x -LLL -H ldap://localhost -b "dc=example,dc=org"</code>
-Dans mon cas, avec l'installation par défaut et un "domaine" appelé ''ldap.local'' :
-<code># ldapsearch -x -LLL -H ldap://localhost -b "dc=ldap,dc=local"
-dn: dc=ldap,dc=local
-objectClass: top
-objectClass: dcObject
-objectClass: organization
-o: ldap.local
-dc: ldap
-</code>
-Concernant la structure et la configuration d'Openldap, cela reste assez difficile à lire au début mais c'est assez "logique" pour s'apprendre au fil des manipulations.
-Un petit coup de ''tree /etc/ldap/'' permet de voir qu'on a deux types de fichiers : ''.schema'' et ''.ldif''. Et des noms de dossiers étranges, qui utilisent en fait la syntaxe de ldap. L'une des parties qu'on va bidouiller est ici :
-<code>
-└── slapd.d
-    ├── cn=config
-    │   ├── cn=module{0}.ldif
-    │   ├── cn=schema
-    │   │   ├── cn={0}core.ldif
-    │   │   ├── cn={1}cosine.ldif
-    │   │   ├── cn={2}nis.ldif
-    │   │   └── cn={3}inetorgperson.ldif
-    │   ├── cn=schema.ldif
-    │   ├── olcDatabase={0}config.ldif
-    │   ├── olcDatabase={-1}frontend.ldif
-    │   └── olcDatabase={1}mdb.ldif
-    └── cn=config.ldif
-</code>
-Ce qui est dans le dossier ''cn=config'' concerne... la configuration. Autrefois il y avait un fichier "/etc/ldap/sldap.conf", si je comprend bien ce n'est plus trop d'actualité. Mais on n'édite pas directement les ldif ici, il faut passer par l'utilitaire ldapmodify.
-Dans la suite du document, nous allons donc écrire nos documents "ldif", puis les injecter dans l'annuaire avec cette commande "ldapmodify". Il est conseillé de bosser dans un répertoire dédié (par exemple ''/root/ldap/conf/'') histoire de tout nettoyer à la fin avec un petit "rm -R". Ou de garder trace des bidouilles effectuées.
-<WRAP center round tip 100%>
-En fait, LDAP étant un vieux dinosaure utilisé très largement, l'usage de "/etc/ldap/sldap.conf" reste possible. C'est cependant déconseillé et considéré comme une pratique obsolète depuis la version 2.3. L'usage du fichier de configuration "sldap.conf" demande un redémarrage du service à chaque modification, alors que la modification de la configuration dans l'arbre ldap lui-même (via ces fichiers ldif dans "cn=config" est immédiatement pris en compte.
-Cela semble anodin lors des tests, mais un gros annuaire peut mettre beaucoup de temps à redémarrer... Alors autant prendre l'habitude des bonnes pratiques, même si la syntaxe pique les yeux.
-</WRAP>
-=== Avoir des logs plus bavards ===
-Pour avoir des logs plus complets, il va falloir l'activer. On commence par copier le truc actuel, qu'on va bidouiller avant de réinjecter :
-  # ldapsearch -Y external -H ldapi:/// -b cn=config "(objectClass=olcGlobal)" olcLogLevel -LLL > log.ldif
-Ce fichier "log.ldif" est assez court par défaut, il contient deux lignes :
-  * ''dn: cn=config'' : ça veut dire que c'est de la configuration (ne pas bidouiller ce nom !)
-  * ''olcLogLevel: none'' : "olcLogLevel" c'est le niveau de log, forcément "none" c'est pas bavard... Au choix :
-    * -1 : enable all debugging
-    * 0 : no debugging
-    * 1 : trace function calls
-    * 2 : debug packet handling
-    * 4 : heavy trace debugging
-    * 8 : connection management
-    * 16 : print out packets sent and received
-    * 32 : search filter processing
-    * 64 : configuration file processing
-    * 128 : access control list processing
-    * 256 : stats log connections/operations/results
-    * 512 : stats log entries sent
-    * 1024 : print communication with shell backends
-    * 2048 : print entry parsing debugging
-On va faire ceci :
-<code txt log.ldif>
-dn: cn=config
-changetype: modify
-replace: olcLogLevel
-olcLogLevel: 256
-</code>
-On injecte avec la commande suivante :
-# ldapmodify -Y EXTERNAL -H ldapi:/// -f log.ldif
-On peut vérifier le résultat avec ça :
-# ldapsearch -Y external -H ldapi:/// -b cn=config "(objectClass=olcGlobal)" olcLogLevel
-Ou simplement en faisant une requête avec slapd (par exemple ''<nowiki>ldapsearch -Y external -H ldapi:/// -b dc=ldap,dc=local</nowiki>'' ) et en admirant le résultat avec ''tail -f /var/log/syslog''.
-<WRAP center round info 100%>
-J'ai des trucs dans ''/var/log/syslog'' parce que [[https://alinea.ninm.net/dokuwiki/pratique:informatique:systemd_error#avoir_des_vrais_journaux_de_log|je demande à systemd de m'écrire ce genre de log]]. Et il y a moyen de paramétrer pour que ce soit dans un fichier de log propre à slapd, mais bon, à ce stade, ça me suffit.
-On retrouve les logs propres à slapd **aussi** dans journalctl :
-  journalctl -eu slapd.service
-</WRAP>
-=== Overlays ===
-> Les overlays sont des fonctionnalités supplémentaires qui se rajoutent. [[https://blog.debugo.fr/openldap-overlays/|(Source)]]
-La doc complète est sur https://www.openldap.org/doc/admin26/overlays.html ; je ne documente ici que ce qui nous est utile.
-La configuration demande plusieurs fichiers : un pour l'activation (utile juste une fois), l'autre pour la configuration (donc pouvant changer avec le temps).
-== MemberOf ==
-Cela permet de lister plus facilement de quels groupes une utilisatrice est membre.
-Créer les documents suivants :
-<code txt memberof_act.ldif >
-dn: cn=module,cn=config
-cn:module
-objectclass: olcModuleList
-objectclass: top
-olcmoduleload: memberof.la
-olcmodulepath: /usr/lib/ldap
-</code>
-<code txt memberof_conf.ldif>
-dn: olcOverlay=memberof,olcDatabase={1}mdb,cn=config
-changetype: add
-objectClass: olcMemberOf
-objectClass: olcOverlayConfig
-objectClass: olcConfig
-objectClass: top
-olcOverlay: memberof
-olcMemberOfDangling: ignore
-olcMemberOfRefInt: TRUE
-olcMemberOfGroupOC: groupOfNames
-olcMemberOfMemberAD: member
-olcMemberOfMemberOfAD: memberOf
-</code>
-Puis on injecte ces fichiers :
-<code bash root>
-ldapadd -Y EXTERNAL -H ldapi:/// -f memberof_act.ldif
-ldapadd -Y EXTERNAL -H ldapi:/// -f memberof_conf.ldif
-</code>
-Pour vérifier la configuration, au choix, une de ces commandes dans le terminal :
-<code>
-ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcModuleList"
-tree /etc/ldap/slapd.d/
-ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcmemberOf"</code>
-Pour chercher tous les groupes dont Truc est membre :
-  ldapsearch -xLLL  "(uid=truc)" memberof
-== Cohérence de l'annuaire lors de suppression d'entrées ==
-Cela évitera d'avoir des membres fantômes qui ne sont plus liés à rien. Si une utilisatrice est supprimée, alors elle le sera aussi des groupes dans lesquels elle était. Si un groupe se retrouve vide, l'admin y est automatiquement ajouté (ce qui évitera des erreurs).
-Créer les fichiers suivants :
-<code txt refint_act.ldif>
-dn: cn=module,cn=config
-cn: module
-objectclass: olcModuleList
-objectclass: top
-olcmoduleload: refint.la
-olcmodulepath: /usr/lib/ldap
-</code>
-<code txt refint_conf.ldif>
-dn: olcOverlay=refint,olcDatabase={1}mdb,cn=config
-objectClass: olcConfig
-objectClass: olcOverlayConfig
-objectClass: olcRefintConfig
-objectClass: top
-olcOverlay: refint
-olcRefintAttribute: memberof member manager owner
-olcRefintNothing: cn=admin,dc=ldap,dc=local
-</code>
-Injection
-<code>ldapadd -Q -Y EXTERNAL -H ldapi:/// -f refint_act.ldif
-ldapadd -Q -Y EXTERNAL -H ldapi:/// -f refint_conf.ldif</code>
-Vérification, et vérification de la configuration :
-<code>ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcModuleList"
-ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcRefintConfig"
-</code>
-== Enregistrer les modifications de l'annuaire ==
-Ce qui pourra être utile pour savoir ce qui s'est passé.
-On commence par créer le dossier où cela s'écrira (automatique suivant comment on a configuré ses logs par ailleurs...) :
-<code>
-mkdir /var/log/openldap
-touch /var/log/openldap/auditlog.log
-chmod 755 /var/log/openldap
-chmod 755 /var/log/openldap/auditlog.log
-chown openldap:openldap /var/log/openldap
-chown openldap:openldap /var/log/openldap/auditlog.log
-</code>
-Puis on crée les fichiers :
-<code txt auditlog_act.ldif>
-dn: cn=module,cn=config
-cn: module
-objectclass: olcModuleList
-objectclass: top
-olcModuleLoad: auditlog.la
-olcmodulepath: /usr/lib/ldap
-</code>
-<code txt auditlog_conf.ldif>
-dn: olcOverlay=auditlog,olcDatabase={1}mdb,cn=config
-objectClass: olcOverlayConfig
-objectClass: olcAuditLogConfig
-olcOverlay: auditlog
-olcAuditlogFile: /var/log/openldap/auditlog.log
-</code>
-Injection :
-<code>
-ldapadd -Q -Y EXTERNAL -H ldapi:/// -f auditlog_act.ldif
-ldapadd -Q -Y EXTERNAL -H ldapi:/// -f auditlog_conf.ldif
-</code>
-Vérification :
-<code>
-ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcModuleList"
-ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcAuditLogConfig"
-</code>
-== Unicité des attributs ==
-C'est par exemple pour que les UID attribués à chacune soit bien uniques. Ou qu'une adresse mail ne soit liée qu'à une seule personne. Éviter les doublons sur les attributs évitera des erreurs, voir des exploits, et améliore les recherches.
-Créer les fichiers suivants :
-<code txt unique_act.ldif>
-dn: cn=module,cn=config
-cn: module
-objectclass: olcModuleList
-objectclass: top
-olcModuleLoad: unique.la
-olcmodulepath: /usr/lib/ldap
-</code>
-Attention ici, remplacez ''dc=ldap,dc=local'' par votre DC. Notez aussi qu'on va forcer l'unicité uniquement sur quelques attributs :
-  * L'uid, qui doit absolument être unique... utilisé dans la base elle-même, c'est du "texte"
-  * L'uidNumber, qui est forcément un nombre, sert entre autre quand il y a une utilisatrice linux liée (identifiant numérique utilisé par le système)
-  * le mail (<wrap help>utilisé pour récupérer son mot de passe, mais à voir avec la possibilité d'avoir plusieurs "pseudo" pour une seule personne... Pour le moment, on reste en "unique".</wrap>
-  * La portée (''?sub'') précise que cela s'applique aux sous-arbres.
-<code txt unique_conf.ldif>
-dn: olcOverlay=unique,olcDatabase={1}mdb,cn=config
-objectClass: olcOverlayConfig
-objectClass: olcUniqueConfig
-olcOverlay: unique
-olcUniqueUri: ldap:///ou=people,dc=ldap,dc=local?uid?sub
-olcUniqueUri: ldap:///ou=people,dc=ldap,dc=local?mail?sub
-olcUniqueUri: ldap:///ou=people,dc=ldap,dc=local?uidNumber?sub
-</code>
-Injection :
-<code>
-ldapadd -Q -Y EXTERNAL -H ldapi:/// -f unique_act.ldif
-ldapadd -Q -Y EXTERNAL -H ldapi:/// -f unique_conf.ldif
-</code>
-Vérification :
-<code>ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcModuleList"
-ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcUniqueConfig"
-</code>
-== Autres ==
-Contrairement à [[https://blog.debugo.fr/openldap-overlays/|Debuguo]], je n'ai pas paramétré la partie sur la politique de mot de passe (Overlay Policy) parce que je ne sais pas encore quels contraintes vont être amenées par Oauth et compagnie, et aussi parce que je ne touche à ce genre de chose qu'après discussion avec mon expert favori (coucou Tycho !). Ceci dit, de ce que j'en lis, je pense que je finirais par l'ajouter (de toute façon, avant que ce soit en prod...).
-=== Peupler son annuaire ===
-<WRAP center round todo 60%>
-Todo : Créer l'annuaire plus en détail, l'administrer, le structurer, etc.
-</WRAP>
-=== Plus de doc ===
-Voir https://blog.debugo.fr/openldap-serie/ ; je n'ai pas vu l'intérêt de trop redonder ses infos. Il détaille plus de choses sur le fonctionnement de l'annuaire.
 ===== Outils complémentaires =====