====== LDAP et mise en place d'une authentification unique ======
Je galère alors faut pas espérer que ce tuto soit au poil.
Il y a longtemps, on((Ok, surtout moi, Zat.)) a écrit [[fr:identification]].
Un seul endroit où s'identifier, ça reste important, mais ce n'est vraiment pas un sujet trivial.
Après moult pérégrinations, installations, désinstallation de rage, serveurs qui passent au lance-flamme etc, nous((Enfin, là, encore pas mal moi, à ce stade... Mais y'a du monde dans la caboche.)) repartons sur cette aventure frustrante, fortes de plus d'expérience.
LDAP est un service très basique d'annuaire. Oui, comme les gros machins en papier qui listaient les noms, prénoms, adresse, numéro de téléphone voir métier.
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.
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.
===== Comprendre un annuaire LDAP =====
Histoire de créer les bons groupes etc.
LDAP est une norme d'annuaire. Il faut comprendre son modèle de nommage et d'organisation avant de le bidouiller.
Il fonctionne selon un modèle hiérarchique, et c'est souvent plus compréhensible de le représenter en schéma (en "arbre") que de façon linéaire.
Voici une représentation :
dc=example,dc=org
├── ou=users
│ ├── uid=arina.aldoru,ou=users,dc=example,dc=org
│ ├── uid=benvai.brisin,ou=users,dc=example,dc=org
├── ou=groups
│ ├── cn=admin,ou=groups,dc=example,dc=org
│ ├── cn=joueuses,ou=groups,dc=example,dc=org
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).
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
* ''dc'' (Domain Component) : le nom de domaine. Un attribut pour chaque composant individuel (un mot, quoi), ainsi on aura ''dc=example,dc=org'' et non ''dc=example.org'' : il faut diviser example.org en composants distinct.
* ''o'' (Organization) : identifie le nom de l'organisation dans l'annuaire. Il peut y avoir plusieurs organisations et les gens faire partie de plusieurs.
* ''ou'' (Organizational Unit) : "unité organisationnelle". Par exemple des groupes, des utilisatrices, des ressources. Dit autrement : "un tas de //trucs//". Il y a des mots-clefs pour cet attribut qui sont "standards", mais on peut en avoir d'autres et mettre ce qu'on veut en valeur : ''ou=Groups'' est standards pour les groupes mais on peut l'écrire en français. Cependant il faut rester cohérent. Et si l'annuaire est destiné à un public international, le mettre en français n'est pas forcément pertinent. Préférez le lojban 8-)
* ''member'' ou ''memberOf'' : Membre d'un groupe. Va établir des relations entre utilisatrices et groups.
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.
* ''givenName'' : prénom.
* ''mail'' : l'adresse mail de l'objet.
* ''uid'' (User Identifier) : identifiant unique pour un utilisateur. Pratique quand vous avez plusieurs Jean Dupont dans le groupe. C'est aussi ce code qu'on va utiliser pour l'authentification.
* additionalName : quand il y a plus d'un nom (clan, famille élargie...).
* prefix/suffix : pour les titres, préfixes et suffixes honorifiques (mr, mme, docteur, etc).
* name : champ plus générique pour le nom
* preferredName / displayName : spécifie le nom à afficher
* Il existe encore d'autres attributs possible...
Localisation :
* ''c'' (Country) : le pays.
* ''l'' (Locality) : localité, ville. Pour localiser un peu plus.
* ''st'' (State) : État ou Province. On reste dans de la description géographique.
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).
**''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.
==== Classes d'objets ====
Les classes d'objets définissent les types d'entrées (ou objets) et les attributs associés à chaque type. Par exemple, quand on a un humain dans la base, on attend en général de pouvoir lui donner un nom et un identifiant.
Il n'y a pas d'attributs strictement obligatoires dans LDAP, mais certaines classes d'objets imposent des attributs minimaux pour une entrée valide.
Je ne vais pas tout lister, c'est juste pour pointer les conventions/attendus :
* ''inetOrgPerson'' (pour les personnes) :
* Obligatoires : ''cn'', ''uid'', ''sn'' (parfois optionnel mais... faut pas y compter)
* Recommandés : ''givenName'', ''mail'', ''displayName'', ''telephoneNumber''
* ''organizationalUnit'' (pour les unité organisationnelle)
* Obligatoire : ''ou''
* Recommandés : ''description''
* ''groupOfNames'' :
* Obligatoires : ''cn'', ''member''
* ''organizationalRole'' (rôles organisationnels comme administrateur, etc.)
* Obligatoires : ''cn'', ''description''
===== Logiciels pour gérer LDAP =====
==== LLDAP ====
Nous avons testé divers trucs, dont [[https://github.com/lldap/lldap|LLDAP]].
Je laisse la doc ici, car la solution est pertinente avec une architecture simple. Le souci et la force de LLDAP est justement dans cette simplicité. Il est possible d'avoir des groupes et des utilisateurs, mais pas des sous-groupes, ni de trop complexifier l'architecture. Dans mon cas, il m'a donc fallu passer à autre chose.
La bonne nouvelle c'est qu'il y a un paquet Debian, bien que ce ne soit pas dans les dépôts officiels. C'est plutôt un avantage dans ce cas précis, car plus à jour.
Pour l'installer on va sur [[https://software.opensuse.org//download.html?project=home%3AMasgalor%3ALLDAP&package=lldap]] (adresse donnée dans le README du dépôt officiel) et on suit les instructions, que je recopie ici mais qu'il faudra vérifier si vous suivez ce tuto dans quelques mois :
echo 'deb http://download.opensuse.org/repositories/home:/Masgalor:/LLDAP/Debian_12/ /' | sudo tee /etc/apt/sources.list.d/home:Masgalor:LLDAP.list
curl -fsSL https://download.opensuse.org/repositories/home:Masgalor:LLDAP/Debian_12/Release.key | gpg --dearmor | sudo tee /etc/apt/trusted.gpg.d/home_Masgalor_LLDAP.gpg > /dev/null
sudo apt update
sudo apt install lldap
La configuration se fait ensuite sur ''/etc/lldap/lldap_config.toml''. Tout lire et pester un peu. Notre version commentée sera sans doute ici à un moment, quand j'aurais la foi pour l'y mettre et mieux comprendre ce que j'ai mis.
Veillez à installer tout ça sur un container **sans** apache/nginx. LLDAP se débrouille tout seul.
Ensuite, tout simplement :
sudo lldap run
Rendez-vous sur l'adresse de votre site et hop : ça marche, vous avez une interface web pour bidouiller un annuaire LDAP. Ce qui vous fais une belle jambe à ce stade.
=== En cas d'erreur ===
J'avais bidouillé encore et encore, et à un moment j'ai eu l'erreur suivante :
Error: A key_seed was given, but a key file already exists at `server_key`. Which one to use is ambiguous, aborting.
Il ne dit évidement pas où est ce "server_key" et malgré la purge du paquet, le reboot, etc, ça reste. Faites la commande suivante :
sudo find / -name "server_key" 2>/dev/null
Dans mon cas, j'avais lancé LLDAP avec mon user de base, et ce fichier était dans mon home...
==== 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.
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...
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 :
ldapsearch -x -LLL -H ldap://localhost -b "dc=example,dc=org"
Dans mon cas, avec l'installation par défaut et un "domaine" appelé ''ldap.local'' :
# 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
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 :
└── 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
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.
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.
=== 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 :
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: 256
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 ''ldapsearch -Y external -H ldapi:/// -b dc=ldap,dc=local'' ) et en admirant le résultat avec ''tail -f /var/log/syslog''.
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
=== 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 :
dn: cn=module,cn=config
cn:module
objectclass: olcModuleList
objectclass: top
olcmoduleload: memberof.la
olcmodulepath: /usr/lib/ldap
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
Puis on injecte ces fichiers :
ldapadd -Y EXTERNAL -H ldapi:/// -f memberof_act.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f memberof_conf.ldif
Pour vérifier la configuration, au choix, une de ces commandes dans le terminal :
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"
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 :
dn: cn=module,cn=config
cn: module
objectclass: olcModuleList
objectclass: top
olcmoduleload: refint.la
olcmodulepath: /usr/lib/ldap
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
Injection
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f refint_act.ldif
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f refint_conf.ldif
Vérification, et vérification de la configuration :
ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcModuleList"
ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcRefintConfig"
== 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...) :
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
Puis on crée les fichiers :
dn: cn=module,cn=config
cn: module
objectclass: olcModuleList
objectclass: top
olcModuleLoad: auditlog.la
olcmodulepath: /usr/lib/ldap
dn: olcOverlay=auditlog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAuditLogConfig
olcOverlay: auditlog
olcAuditlogFile: /var/log/openldap/auditlog.log
Injection :
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f auditlog_act.ldif
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f auditlog_conf.ldif
Vérification :
ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcModuleList"
ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcAuditLogConfig"
== 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 :
dn: cn=module,cn=config
cn: module
objectclass: olcModuleList
objectclass: top
olcModuleLoad: unique.la
olcmodulepath: /usr/lib/ldap
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 (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".
* La portée (''?sub'') précise que cela s'applique aux sous-arbres.
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
Injection :
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f unique_act.ldif
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f unique_conf.ldif
Vérification :
ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcModuleList"
ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b "cn=config" "Objectclass=olcUniqueConfig"
== 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 ===
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).
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.
C'est vraiment la partie la plus compliquée : faire un schéma et trouver les bons attributs à chaque morceau.
=== 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 =====
==== LDAP Tool Box Project (LTB) ====
[[https://ltb-project.org/documentation/index.html|LDAP Tool Box project]] (abrégé LTB) fourni une base ldap et divers petits outils simplifiants la gestion du truc. Simplifier reste toujours un grand mot quand on parle de LDAP.
Ça n'empêche pas qu'on a besoin d'Openldap à côté, ces outils viennent en complément. Si j'ai bien compris.
La documentation officielle est suffisament bonne pour l'installation des paquets suivant son système, et installer via un paquet, c'est toujours sympa. Ensuite c'est plus light sur comment peupler l'annuaire.
Les commandes "slapd*" se font en root.
LTB utilise l'outil ''slapd-cli''. Après l'installation, voyons voir ce qui tourne :
# slapd-cli status
slapd-cli: [INFO] Using /usr/local/openldap/etc/openldap/slapd-cli.conf for configuration
slapd-cli: [INFO] LDAP Tool Box slapd-cli script version 3.5
slapd-cli: [INFO] Process OpenLDAP is running (PID 87890)
slapd-cli: [INFO] Detected OpenLDAP version: slapd 2.6.9 (Nov 25 2024 23:00:00)
slapd-cli: [INFO] Listening to services ldap://*:389 ldaps://*:636 ldapi://%2Fvar%2Frun%2Fslapd%2Fldapi
slapd-cli: [INFO] Process usage: 0.0% CPU / 0.5% MEM
slapd-cli: [INFO] Detected suffix: dc=my-domain,dc=com
C'est rassurant que ça marche, mais pas très aidant pour notre annuaire personnalisé. La configuration va se faire dans le dossier ''/usr/local/openldap/etc/openldap'' ; on peut s'appuyer sur d'autres tutoriels concernant uniquement openldap pour trouver quoi faire.
LTB a choisi d'utiliser ''/usr/local/openldap/'' et de ne pas installer dans ''/etc/openldap''.
> L'installation se trouve sous /usr/local/openldap, afin d'éviter les conflits avec l'installation OpenLDAP existante. En particulier, nous n'interférons pas avec les bibliothèques du système LDAP, qui sont liées par de nombreux autres programmes.
> --- //[[https://ltb-project.org/documentation/openldap-packages.html|Traduction auto de la doc de LTB]]//
Il faut donc adapter les chemins quand on utilise ledit outil.
===== Au delà de l'annuaire, la connexion (Oauth2 ? OpenID ?) =====
La plupart des logiciels peuvent utiliser directement les informations de LDAP : il suffit de renseigner l'adresse de l'annuaire, sa structure etc et hop : vos utilisatrices peuvent se connecter avec les mêmes identifiants et phrase de passe partout. Ce qui est pratique mais n'enlève pas l'agacement de se connecter sur 10 CMS différents.
Pour ça, on ajoute une surcouche à LDAP. Il existe énormément de méthodes, mais Oauth2 est sans doute celui qui sera le mieux reconnu par les divers CMS et le plus souple.
C'est des concepts bien velus, mais heureusement quelqu'un a réussi à expliquer ça bien dans une vidéo, avec une très bonne métaphore : [[https://www.youtube.com/watch?v=YdShQveywpo|concernant les accès dans un hôtel]]. C'est vraiment une ressource à voir pour se sentir un peu moins dépassé !
Par contre LLDAP ne suffit pas à gérer ça. Il faut installer un autre frontend qui va aussi avoir en backend de quoi servir Oauth2. On va donc avoir un serveur Oauth2, qui va papoter avec notre serveur LDAP, qui vont permettre (ou pas) aux utilisatrices de se connecter d'office une fois qu'elles ont été identifiée à un moment.
Il y a plusieurs options, et je n'y suis pas encore, mais dans les concurrents :
* https://kanidm.com/ : semble léger, en rust, y'en a ici qui l'aiment bien ;)
* LemonLDAP::NG ? J'ai un doute s'il fournit vraiment le serveur Oauth.
* Authelia : a l'air d'une terrible machine de guerre. Mais moins que Keyclock (et en même temps, peut-on faire plus affreux ?).
* Autre ?
{{tag>syadmin}}