runbook : nommer les deux consoles Keycloak

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>

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.<domaine>/` 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/<realm>/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

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.<domaine>/` 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.<domaine>/realms/<realm>/account/` | `sysadmin` + jeton d'amorçage |
+| administrer Keycloak lui-même | `https://auth.<domaine>/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).