Daniel Allaire
419ecaba63
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>
34 lines
1.6 KiB
Markdown
34 lines
1.6 KiB
Markdown
# resoudre_politique_mdp
|
|
|
|
Rôle **utilitaire** (non déployable) : porte *la* déclaration de la politique de mot de
|
|
passe et la traduit dans les deux dialectes qui doivent l'appliquer.
|
|
|
|
| Dialecte | Consommateur | Sortie |
|
|
|---|---|---|
|
|
| `pwdPolicy` (ppolicy) | `serveur_openldap` | `resoudre_politique_mdp_ldap` |
|
|
| `passwordPolicy` du realm | `serveur_keycloak` | `resoudre_politique_mdp_keycloak` |
|
|
| anti-force-brute du realm | `serveur_keycloak` | `resoudre_politique_mdp_brute` |
|
|
|
|
## Pourquoi
|
|
|
|
Les règles n'existaient que côté LDAP. LDAP ne sait que **refuser** — il ne dit jamais à
|
|
l'écran *pourquoi*. Keycloak, lui, ne validait rien : `passwordPolicy` était vide. Chacun
|
|
déléguait la vérification à l'autre.
|
|
|
|
Mesuré le 2026-08-08 avec un compte sonde, le même mot de passe `abcd` :
|
|
|
|
```
|
|
opération étendue LDAP → Constraint violation (19) — "Password fails quality checking policy"
|
|
Keycloak reset-password → 204, puis ldapwhoami avec "abcd" : accepté
|
|
```
|
|
|
|
Deux causes empilées : Keycloak écrivait `userPassword` **directement** en tant que rootDN,
|
|
donc l'overlay `ppolicy` n'interceptait rien ; et le realm n'avait aucune politique propre.
|
|
La correction tient aux deux bouts — `usePasswordModifyExtendedOp` côté fédération, et la
|
|
politique projetée ici.
|
|
|
|
## Ce que ce rôle ne fait pas
|
|
|
|
Il ne compare pas les deux dialectes après coup. Ils ne sont pas équivalents : `pwdCheckQuality`
|
|
d'OpenLDAP délègue à un module externe, `notUsername`/`notEmail` de Keycloak sont des règles
|
|
précises. La garantie porte sur la **source**, pas sur une équivalence terme à terme.
|