Pourquoi cette leçon existe
En 2.5, je vous ai déconseillé de brancher vos applications directement sur vos contrôleurs de domaine. Je ne me dédis pas.
Mais il y a des situations où l’on n’a pas le choix : pas d’IdP dans l’organisation, pas de mandat pour en déployer un, ou une décision qui ne vous appartient pas. Dans ces cas-là, une liaison LDAP correctement configurée reste infiniment préférable à des comptes locaux gérés à la main — et l’objet de cette leçon est de la faire proprement.
Si vous avez configuré l’OIDC en 2.6, vous pouvez sauter cette leçon. Gardez simplement en tête qu’elle existe : le jour où vous devrez brancher un outil d’infrastructure qui ne sait pas faire d’OIDC, les principes exposés ici s’appliqueront.
Deux modes, un seul recommandé
Forgejo propose deux variantes de liaison LDAP.
LDAP via BindDN — Forgejo se connecte à l’annuaire avec un compte de service, recherche l’utilisateur, puis tente de s’authentifier avec le mot de passe saisi. C’est le mode à retenir : il permet de filtrer, de rechercher sur plusieurs attributs et de synchroniser.
LDAP simple auth — Forgejo construit directement le DN de l’utilisateur à partir d’un modèle. Pas de compte de service, mais une rigidité qui le rend peu utilisable en Active Directory, où les utilisateurs sont répartis dans plusieurs unités d’organisation.
Nous partons sur BindDN.
Le compte de service
C’est la première chose à créer, et c’est là que se joue une partie de la sécurité du montage.
Créez un compte dédié, uniquement pour cet usage. Pas un compte d’administration existant, pas un compte partagé entre applications.