Mathieu Benoit
bff1396af3
Le defaut `id-ldap-01` tenait des que le plan se taisait : la derivation depuis `applications.<app>.hote` etait sautee, et le role batissait `ldaps://<ce nom>` — une machine qui n est dans aucun plan. Le consommateur echouait au premier bind, apres un deploiement passe au vert de bout en bout. La derivation avait ete ajoutee pour corriger exactement cela ; le defaut est reste et ramenait l ancien comportement. Il est desormais vide, et une assertion refuse AU DEPLOIEMENT. Une instance garde le droit de poser l hote explicitement : ce qui disparait est la valeur DEVINEE, pas la surcharge. Assisted-by: Claude Opus 5
39 lines
2.2 KiB
YAML
39 lines
2.2 KiB
YAML
---
|
|
# Hôte qui sert l'annuaire (OpenLDAP) — DÉRIVÉ du plan (`applications.openldap.hote`),
|
|
# pas écrit. Un seul point de vérité valait mieux que la répétition dans chaque rôle, mais
|
|
# une valeur écrite finit par ne plus désigner personne : `id-ldap-01` ne correspondait à
|
|
# aucune machine du plan (l'annuaire vit sur `idm-01`), et Postfix ne pouvait pas se lier.
|
|
# Constaté le 2026-08-07. Le repli ci-dessous ne sert que si le plan est muet.
|
|
resoudre_annuaire_app: "openldap"
|
|
# VIDE, ET C'EST LE DEFAUT LUI-MEME QUI ETAIT LE PIEGE. Un nom ecrit ici tient des
|
|
# que le plan se tait : la derivation est sautee, le role bâtit
|
|
# `ldaps://<ce nom>.<domaine>`, et le consommateur echoue a l'execution sur
|
|
# « Unable to bind » en nommant une machine qui n'est dans aucun plan.
|
|
#
|
|
# La correction qui a introduit la derivation depuis le plan a laisse ce defaut en
|
|
# place ; il ramene donc l'ancien comportement chaque fois que l'application n'est
|
|
# pas au plan. Vide, l'assertion qui suit refuse AU DEPLOIEMENT, la ou le nom
|
|
# devine ne se voyait qu'au premier bind.
|
|
#
|
|
# Une instance garde le droit de le poser explicitement : ce qui disparait est la
|
|
# valeur DEVINEE, pas la surcharge.
|
|
resoudre_annuaire_hote: ""
|
|
resoudre_annuaire_port: 636
|
|
resoudre_annuaire_encryption: "ldaps"
|
|
# COMPTE DE LIAISON — CHAQUE CONSOMMATEUR A LE SIEN (2026-09-13).
|
|
#
|
|
# Ce defaut valait `admin` : les quatre consommateurs se liaient donc avec le compte
|
|
# d'administration de l'annuaire. C'est le rootDN, et slapd lui fait CONTOURNER TOUTES
|
|
# LES ACL — y compris ses propres controles de qualite de mot de passe. Un seul secret,
|
|
# quatre services, tous les droits sur l'arbre, pour ce qui est trois fois sur quatre une
|
|
# simple lecture.
|
|
#
|
|
# Le rôle etait deja pret : `bind_cn` et `secret` sont des variables. Il ne manquait que
|
|
# les comptes, leurs droits, et que chaque consommateur nomme le sien.
|
|
#
|
|
# LE DEFAUT N'EST PLUS UN COMPTE QUI MARCHE. Un consommateur qui ne nomme pas le sien se
|
|
# lierait comme `cn=inconnu,ou=services,...`, qui n'existe pas : l'echec est immediat et
|
|
# lisible, au lieu de reussir avec tous les droits.
|
|
resoudre_annuaire_bind_ou: "services"
|
|
resoudre_annuaire_bind_cn: "inconnu"
|
|
resoudre_annuaire_secret: "vault_ldap_bind_inconnu"
|