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>
This commit is contained in:
Daniel Allaire 2026-08-07 17:48:43 -04:00
parent c79aae200d
commit c21ed62237
2 changed files with 49 additions and 4 deletions

View file

@ -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

View file

@ -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).