Quatre defauts mesures dans l'integration Keycloak/LDAP, meme famille : une
valeur declaree d'un cote, consommee de l'autre, rien qui verifie la jonction.
1. Aucune regle ne s'appliquait sur le chemin d'un vrai utilisateur. Sonde :
« abcd » refuse par l'operation etendue LDAP, accepte par Keycloak (204),
puis actif pour l'authentification. Keycloak ecrivait userPassword en
direct (ppolicy aveugle) et le realm n'avait aucune passwordPolicy.
2. ldap_entry ne fait que CREER : la politique etait figee a sa creation. Le
depot disait pwdMustChange TRUE, le serveur FALSE — une reconstruction
from-zero aurait ressuscite la boucle du 2026-08-07. ldap_attrs state=exact
reconcilie la politique et l'overlay (DN lu, pas devine).
3. syncRegistrations absent : un compte cree dans Keycloak n'atteignait jamais
ou=people — acces web, aucune boite, invisible du modele de groupes.
4. Le prenom pointait sur cn (nom complet) : « Administrateur systeme systeme ».
Ajoute roles/resoudre_politique_mdp : LA declaration, traduite en pwdPolicy,
passwordPolicy et anti-force-brute. Les deux roles la consomment sans la
redeclarer.
usePasswordModifyExtendedOp ET validatePasswordPolicy : la seconde est
porteuse, Keycloak se liant en rootDN et slapd n'appliquant pas ses controles
de qualite au rootDN. La premiere seule aurait paru juste sans tenir.
Verification : abcd -> 400 « minimum length 12 » et absent de LDAP ; mot de
passe conforme -> 204 puis ldapwhoami accepte ; POST users -> 201 ET present
dans ou=people. Second passage des deux playbooks : changed=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le realm portait une politique d'acces complete et aucun moyen d'ecrire a qui
que ce soit. Tout oubli remontait donc a l'exploitant, qui n'avait d'autre
choix que de manipuler le mot de passe d'autrui.
- serveur_keycloak/tasks/courriel-realm.yml : reconcilie smtpServer et
resetPasswordAllowed ; hote du relais DERIVE de applications.postfix.hote,
et refus explicite si le plan ne declare pas de MTA.
- passe par l'API d'administration : kcadm.sh accepte les deux formes -s sur
une map, sort en succes et n'ecrit rien (smtpServer reste vide).
- amorcage_acces_courriel redevient a declarer : cette adresse designe une
personne, hors du systeme qu'on amorce ; une boite interne serait illisible
tant qu'on n'a pas l'acces qu'on cherche justement a recuperer.
- autorisation.md §6.6 : le mecanisme, ses deux conditions, et l'ecart
d'adresse laisse par l'ancien mode READ_ONLY de la federation.
Preuve : banniere SMTP lue depuis idm-01, RCPT TO accepte, execute-actions-email
declenche, MTA en starttls -> relay=mx.chezlepro.ca status=sent (250). Second
deploiement changed=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`ldappasswd` ne peut pas le changer : `cn=admin` n'est pas une entree de la base
mais le rootDN declare dans cn=config. Le mot de passe vit dans `olcRootPW` et se
modifie par un bind EXTERNAL. L'echec etait sans degat — l'ancien fonctionnait
toujours, verifie avant de continuer.
Keycloak stocke le mot de passe de LIAISON dans sa base et le masque : la
reconciliation d'hier couvrait l'URL, les DN et le mode, pas `bindCredential`.
Tourner le secret aurait coupe Keycloak de l'annuaire. Comme la valeur est
masquee, la reconciliation passe par une empreinte.
Verifie consommateur par consommateur : synchro LDAP de Keycloak (qui prouve la
liaison), carte LDAP de Postfix, Dovecot actif. Les trois rejouent a changed=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ce compte est le moyen de se changer lui-meme : regenerer la voute d'abord
l'aurait rendu inapplicable — plus rien n'aurait pu s'authentifier pour poser la
nouvelle valeur. L'ordre est inverse : s'authentifier avec l'actuelle, poser la
nouvelle, verifier, PUIS ecrire la voute.
C'est une procedure, pas un redeploiement. Meme contrainte pour
`vault_openldap_admin`, qui reste a faire. Consigne au runbook §6.7, avec le
rappel qu'une verification n'est pas un message de succes.
Verifie : admin (voute) OK, groupe sysadmin et role grafana-admin intacts,
rejeu a changed=0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`realm-admin` (role du client `realm-management`) est attache au GROUPE sysadmin.
Administrer le realm ne passe plus par le compte local. Portee : CE realm, jamais
`master` — le compte de secours reste hors d'atteinte du groupe, et c'est le sens
meme d'un acces de secours (D-40).
Les roles de CLIENT sont un espace de noms distinct : la declaration gagne
`roles_client`. L'API attend l'UUID du client, pas son clientId — interroger par
le nom rendait une erreur, la verification echouait toujours et la tache se
declarait `changed` a chaque passage. Deux passages consecutifs a changed=0.
La boucle de changement de mot de passe : `pwdMustChange: TRUE` signifie « quand
un ADMINISTRATEUR pose un mot de passe, l'utilisateur doit le changer ». Keycloak
ecrit en tant qu'administrateur — chaque changement relaye etait vu comme une
reinitialisation. Incompatible par construction avec un IdP qui relaie.
La contrainte est deplacee la ou l'utilisateur la voit : pwdMustChange FALSE cote
annuaire, action `UPDATE_PASSWORD` posee par Keycloak. J'avais eprouve pwdReset
au niveau LDAP, ou il marche, sans parcourir le chemin complet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
La premiere connexion du sysadmin echouait sur « invalid username or password ».
Ni le jeton ni le compte : `https://auth.<domaine>/` redirige vers `/admin/`, la
console du realm `master`, ou `sysadmin` n'existe pas — il vit dans le realm
applicatif.
Le runbook disait « se connecter a Keycloak » SANS donner d'URL, et l'URL
evidente est la mauvaise. Il nomme desormais les deux consoles :
/realms/<realm>/account/ ton compte sysadmin + jeton
/admin/ Keycloak lui-meme admin + vault_keycloak_admin
L'absence de `pwdFailureTime` cote LDAP etait le vrai indice : aucune tentative
n'atteignait l'annuaire, donc le probleme etait en amont de la validation.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le sysadmin ne pouvait atteindre AUCUNE interface web de la flotte qu'il
administre : le pare-feu de l'hyperviseur n'autorisait le 443 de l'edge que
depuis `+t17-flotte`. Le reseau d'administration est dans `t17-admin`.
L'exploitant arrive par un TROISIEME chemin que rien ne declarait : ni `externe`
(Internet, affaire de la frontiere), ni `flotte` (le tenant). Le runbook de
reprise supposait pourtant qu'on ouvre Keycloak dans un navigateur.
`admin` devient un pair declarable — les reseaux de `nftables_admin_ssh`, deja
source unique de la garde anti-lockout. `serveur_nginx` le declare pour son 443.
L'edge SEUL : ouvrir les services en direct elargirait la surface pour rien.
Erreur de methode de ma part : mon premier test utilisait `/dev/tcp` et concluait
« atteignable ». Faux — la frontiere repond au SYN a la place de la cible. Je
l'avais consigne le matin meme.
`make ca-racine` / `make ca-empreinte` : l'hote de l'AC est derive du groupe
`serveur_step_ca`, et la sortie insiste sur la comparaison d'empreinte. La racine
est un certificat PUBLIC — hors voute, dans le magasin de confiance.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Le module etait sur disque mais jamais charge (seul back_mdb l'etait). Depuis
OpenLDAP 2.5 son schema est INTEGRE au module : aucun .ldif a charger.
La contrainte mord, mesuree sur un compte fraichement amorce :
Insufficient access (50)
Operations are restricted to bind/unbind/abandon/StartTLS/modify password
Le sysadmin peut se connecter et RIEN d'autre que changer son mot de passe. Ce
que la doctrine promettait est garanti techniquement, plus seulement demande.
`pwdMustChange` est ce qui donne son effet a `pwdReset` : sans lui, marquer une
entree n'oblige a rien. La politique apporte aussi longueur minimale 12,
verrouillage apres 5 echecs, historique. `olcPPolicyUseLockout` reste FALSE :
annoncer « compte verrouille » renseignerait un attaquant sur son existence.
Le DN de la base est LU, pas suppose : olcDatabase={1}mdb est l'usage mais
l'index n'est pas garanti.
La detection du role d'amorcage s'est verifiee d'elle-meme : rejoue apres le
chargement, il annonce « Changement FORCE » la ou il disait l'inverse une heure
plus tot.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Cree uid=sysadmin et cn=sysadmin dans LDAP. Prouve sur idm-01 : le compte
s'authentifie, et le second passage ne touche a rien (changed=0, 7 taches
sautees) — idempotence par EXISTENCE, pas par conformite (D-67).
Il suit l'annuaire au lieu de se declarer au plan : il ecrit par `ldapi:///` et
doit tourner sur cet hote. Le declarer comme groupe obligerait chaque instance a
le poser sur le bon hote, et elles ne le nomment pas pareil (idm-01 ici,
id-ldap-01 chez Technolibre) — je l'ai d'abord pose sur infra-pki-01 par erreur.
Trois defauts trouves en le construisant :
1. `pwdReset` n'existe pas dans ce schema (overlay ppolicy non charge) :
l'entree entiere etait rejetee et `no_log` masquait la cause. J'avais suppose
un mecanisme sans verifier. Le role le DETECTE maintenant, et la doctrine ne
promet plus un changement force qui n'a pas lieu.
2. Le mot de passe aurait ete stocke EN CLAIR : `ldap_entry` ecrit userPassword
litteralement. Hache par `slappasswd -h {SSHA}` desormais.
3. `voute.py` ne scannait que roles/<groupe> : un role applique par un playbook
sans etre un groupe echappait au recensement, ce que D-20 interdit. Il suit
maintenant les listes `roles:` des playbooks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
L'authentification etait resolue et gardee ; l'autorisation n'existait nulle
part. `ou=groups` est cree depuis le debut et AUCUN des 29 roles ne le lit ;
`ou=people` est vide.
D-67 contredit DELIBEREMENT la doctrine du depot : partout ailleurs un ecart est
un defaut a corriger, ici il est legitime — c'est le sysadmin qui travaille.
Set-OPS cree UN acces puis se retire. Idempotence par EXISTENCE, pas par
conformite : compte present, aucune action quel que soit son etat. Reconcilier
effacerait le compte cree la veille pour un nouvel employe.
D-65 : les groupes LDAP portent l'autorisation, Keycloak les projette. Dovecot
et Postfix ne savent pas lire un role Keycloak — un seul endroit a administrer.
D-66 : un service nomme un groupe, jamais une personne : revoquer quelqu'un ne
demande pas un deploiement.
Le §6 est un runbook de reprise. Il dit aussi ce qu'il faut regenerer pour que
la livraison soit un vrai transfert : les comptes de secours ont ete generes
pendant le deploiement, et leur auteur y a eu acces.
Sans registre de personnes, aucune donnee personnelle n'entre dans git.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
L'authentification etait resolue et gardee ; l'autorisation n'existait nulle
part. `ou=groups` est cree depuis le debut et AUCUN des 29 roles ne le lit —
toute personne authentifiee obtient le defaut du service.
D-65 : les groupes LDAP portent l'autorisation, Keycloak les projette.
L'argument est mecanique : Dovecot et Postfix ne savent pas lire un role
Keycloak. L'y loger rendrait la moitie courriel aveugle et imposerait deux
modeles de permissions.
D-66 : un service nomme un GROUPE, jamais une personne. Un depart devient une
ligne au plan, sans toucher un service.
Le vocabulaire d'habilitation reste celui du service : une echelle commune
devrait etre traduite partout, et la traduction est ou l'habilitation se perd.
Rien n'est construit : registre, role, meta/acces.yml et P31 restent a ecrire.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
