From c21ed62237b65c51627100af5c1b73bb12e359b1 Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Fri, 7 Aug 2026 17:48:43 -0400 Subject: [PATCH] runbook : nommer les deux consoles Keycloak MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit La premiere connexion du sysadmin echouait sur « invalid username or password ». Ni le jeton ni le compte : `https://auth./` 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//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 --- CHANGELOG.md | 26 ++++++++++++++++++++++++++ docs/autorisation.md | 27 +++++++++++++++++++++++---- 2 files changed, 49 insertions(+), 4 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 9d5b1e5..945fa5f 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -2,6 +2,32 @@ ## 2026-08-06 — le chemin nord-sud devient dérivable +### « invalid username or password » — c'était la porte, pas le mot de passe + +Première tentative de connexion du sysadmin : refusée. Ni le jeton ni le compte n'étaient en +cause — vérifié dans l'ordre : `ldapwhoami` avec le jeton retourne le DN, le compte n'est ni +verrouillé ni en échec (`pwdFailureTime` absent), et Keycloak voit `sysadmin` activé et +fédéré. + +**`https://auth./` redirige vers `/admin/`** — la console d'administration du realm +`master`, où `sysadmin` n'existe pas. Il vit dans le realm applicatif. Keycloak répond donc +« identifiants invalides » : exact, et parfaitement trompeur. + +Le runbook disait « se connecter à Keycloak » **sans donner d'URL**, et l'URL évidente est la +mauvaise. C'est un défaut du document, pas de la manipulation. Il nomme désormais les deux +consoles et dit laquelle sert à quoi : + +``` +/realms//account/ ton compte, tes accès sysadmin + jeton +/admin/ administrer Keycloak admin + vault_keycloak_admin +``` + +**L'absence de trace d'échec côté LDAP était le vrai indice.** `pwdFailureTime` vide signifiait +qu'aucune tentative n'atteignait l'annuaire — donc que le problème était en amont de la +validation, pas dedans. Chercher d'abord *où* la requête s'arrête vaut mieux que présumer *ce +qui* est faux. + + ### Le sysadmin ne pouvait atteindre aucune interface web Depuis le poste d'administration, `auth.chezlepro.internal` ne répondait pas — ni aucun autre diff --git a/docs/autorisation.md b/docs/autorisation.md index 3f288d0..06f0672 100644 --- a/docs/autorisation.md +++ b/docs/autorisation.md @@ -112,7 +112,26 @@ n'est pas optionnel. > possible** — c'est la clé de voûte au sens propre, et la première chose à sauvegarder > hors de la machine. -### 6.2 Faire confiance à l'AC interne +### 6.2 Deux consoles Keycloak, et la racine mène à la mauvaise + +**C'est le piège de la première connexion.** `https://auth./` redirige vers `/admin/` +— la console d'administration du realm **`master`**. Le compte `sysadmin` n'y existe pas : il +vit dans le realm applicatif. Keycloak répond alors *« invalid username or password »*, ce qui +est exact et parfaitement trompeur — le mot de passe est bon, c'est la porte qui ne l'est pas. + +| Ce que tu veux faire | URL | Compte | +|---|---|---| +| **ton compte, tes accès** | `https://auth./realms//account/` | `sysadmin` + jeton d'amorçage | +| administrer Keycloak lui-même | `https://auth./admin/` | `admin` + `vault_keycloak_admin` | + +La première ligne est celle de la reprise. C'est là que le changement de mot de passe te sera +imposé, et c'est cette connexion qui **importe ton groupe dans le realm** — sans elle, les +habilitations sur Grafana, Forgejo et Nextcloud restent câblées mais jamais exercées. + +La seconde reste le compte local de secours : administrer le realm ne passe pas encore par le +groupe (`meta/acces.yml` de `serveur_keycloak` le signale, `porte_par: aucun`). + +### 6.3 Faire confiance à l'AC interne Les interfaces web portent des certificats de l'autorité interne, qu'aucun navigateur ne connaît. Récupérer la racine et **son empreinte** : @@ -136,7 +155,7 @@ Firefox a son propre magasin : *Paramètres → Certificats → Autorités → I La racine est un certificat **public** — elle n'a rien à faire dans la voûte, et tout à faire dans le magasin de confiance de qui administre. -### 6.3 Où administrer quoi +### 6.4 Où administrer quoi | Ce que tu veux faire | Où | Comment | |---|---|---| @@ -147,7 +166,7 @@ dans le magasin de confiance de qui administre. La troisième ligne est la seule qui passe par Set-OPS. Les deux premières t'appartiennent et **le dépôt ne les touchera plus jamais**. -### 6.4 Si tu te fermes dehors +### 6.5 Si tu te fermes dehors Les comptes locaux de chaque service existent, sont en voûte, et leur formulaire n'est pas annoncé (`authentification.md` §3). L'accès de secours passe par `sudo` sur l'hôte : @@ -161,7 +180,7 @@ occ user:resetpassword Et si LDAP lui-même est en panne, ces trois commandes fonctionnent quand même : elles ne dépendent ni de Keycloak, ni de l'annuaire. C'est le sens de D-40. -### 6.5 Ce que tu dois changer en priorité +### 6.6 Ce que tu dois changer en priorité 1. **Le mot de passe d'amorçage** — imposé dès la première connexion, tu n'as pas le choix (§3).