History

Daniel Allaire 419ecaba63 identite : une declaration de politique de mot de passe, deux executants 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>		2026-08-08 06:28:10 -04:00
..
defaults	identite : « mot de passe oublie » — raccord SMTP derive du plan	2026-08-08 06:08:06 -04:00
tasks	identite : une declaration de politique de mot de passe, deux executants	2026-08-08 06:28:10 -04:00
README.md	amorcage_acces : le role qui cree UN acces puis se retire	2026-08-07 13:42:27 -04:00

README.md

amorcage_acces — l'accès initial du sysadmin

Crée un compte (uid=sysadmin) et un groupe (cn=sysadmin) dans LDAP, une seule fois, pour que l'exploitant puisse prendre la main. Puis se retire.

Ce qu'il ne fait pas

Ce n'est pas un gestionnaire de comptes. Après son passage, créer, suspendre ou réaffecter relève d'une personne — pas du dépôt (D-67, docs/autorisation.md).

Idempotence par existence, pas par conformité

C'est ce qui distingue ce rôle de tous les autres du dépôt.

compte absent  → créé, secret généré en voûte, changement forcé
compte présent → AUCUNE action, quel que soit son état

Un compte présent est laissé strictement intact : ni mot de passe, ni groupes, ni attributs. Il a pu être renommé, promu, déplacé — c'est le droit de celui qui exploite.

Partout ailleurs dans Set-OPS, un écart entre le déclaré et le réel est un défaut à corriger. Ici, l'écart est le travail du sysadmin. Réconcilier effacerait le compte créé la veille pour un nouvel employé.

Le secret d'amorçage

vault_sysadmin_amorcage est généré — le dépôt en est la source, puisque personne n'existe encore pour le choisir. Mais ce n'est jamais le mot de passe de quelqu'un : pwdReset impose son changement à la première ouverture.

Sans ce changement, l'auteur du déploiement connaîtrait le mot de passe du sysadmin.

Où il s'exécute

Sur l'hôte qui porte serveur_openldap — il écrit par ldapi:///, socket locale. La connexion à l'annuaire est dérivée par resoudre_annuaire, jamais écrite.

Après

docs/autorisation.md §6 est le runbook de reprise : où administrer quoi, comment se rouvrir si on se ferme dehors, et ce qu'il faut régénérer pour que la livraison soit un vrai transfert.