Le dernier `porte_par: liste-uid` du catalogue. `roles.ini` porte desormais
`groups = "sysadmin"` ; `serveur_icingaweb2_admins` devient un repli de
depannage, VIDE par defaut.
Le mode SSO complique le montage : les membres d'un `groupOfNames` sont des DN,
alors que `REMOTE_USER` est une chaine. Un backend LDAP supplementaire est
declare — jamais utilise pour authentifier — uniquement pour que `groups.ini`
resolve le nom vers son DN. Sans ce pont, l'habilitation par groupe est
impossible en SSO.
NON PROUVE : la resolution REMOTE_USER -> DN -> appartenance est interne a
Icinga Web 2 ; seule une connexion reelle par le SSO la confirmera.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Chaque role web declare le GROUPE qu'il reconnait et ce qu'il lui accorde. Un
troisieme champ s'est impose en ecrivant : `porte_par` — le mecanisme qui
transporte reellement l'habilitation. Sans lui, les declarations auraient decrit
une chaine inexistante.
Etat mesure : grafana `role-realm` (reel) ; forgejo, nextcloud et keycloak
`aucun` ; icingaweb2 `liste-uid` — il NOMME DES PERSONNES, ce que D-66 interdit.
Le maillon manquant est chez Keycloak : `role_assignments` assigne un role a un
UTILISATEUR, et son propre commentaire l'admettait (« en prod, preferer
l'assignation via groupe d'annuaire »). Sans group-ldap-mapper, les groupes LDAP
n'atteignent jamais les services. Sa meta a donc une autre forme,
`acces_projection` : Keycloak projette au lieu de consommer (D-65).
Defaut corrige : `serveur_icingaweb2_admins` valait "testmail", un compte de
test code en dur dans le moteur qu'aucune instance ne surchargeait — le seul
administrateur declare de la supervision etait un utilisateur inexistant. Il
suit desormais l'uid d'amorcage. Verifie sur mon-01 : users = "sysadmin".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
