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:
parent
c79aae200d
commit
c21ed62237
2 changed files with 49 additions and 4 deletions
26
CHANGELOG.md
26
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
|
||||
|
|
|
|||
|
|
@ -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).
|
||||
|
|
|
|||
Loading…
Reference in a new issue