---
# 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"
resoudre_annuaire_hote: "id-ldap-01"
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"