Commit graph

6 commits

Author SHA1 Message Date
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
69536a2b1a openldap : charge ppolicy — le jeton d'amorcage devient a usage unique
Le module etait sur disque mais jamais charge (seul back_mdb l'etait). Depuis
OpenLDAP 2.5 son schema est INTEGRE au module : aucun .ldif a charger.

La contrainte mord, mesuree sur un compte fraichement amorce :

  Insufficient access (50)
  Operations are restricted to bind/unbind/abandon/StartTLS/modify password

Le sysadmin peut se connecter et RIEN d'autre que changer son mot de passe. Ce
que la doctrine promettait est garanti techniquement, plus seulement demande.

`pwdMustChange` est ce qui donne son effet a `pwdReset` : sans lui, marquer une
entree n'oblige a rien. La politique apporte aussi longueur minimale 12,
verrouillage apres 5 echecs, historique. `olcPPolicyUseLockout` reste FALSE :
annoncer « compte verrouille » renseignerait un attaquant sur son existence.

Le DN de la base est LU, pas suppose : olcDatabase={1}mdb est l'usage mais
l'index n'est pas garanti.

La detection du role d'amorcage s'est verifiee d'elle-meme : rejoue apres le
chargement, il annonce « Changement FORCE » la ou il disait l'inverse une heure
plus tot.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-07 13:52:00 -04:00
867e2f8cdc Découplage instance : realm centralisé + vars génériques
Fin des dernières poches de 'codé en dur' liées à l'instance d'origine :
- realm SSO centralisé sur l'intrant identite_realm (defaut chezlepro,
  retro-compatible) ; les 4 rôles (keycloak/forgejo/grafana/oauth2_proxy)
  en dérivent. Expose dans la GUI (panneau Intrants).
- vars brandees renommees generiques : chezlepro_timezone -> fuseau_horaire,
  chezlepro_organisation -> organisation (chrony, openldap, GUI, docs).

Aucune reference fonctionnelle aux anciens noms. Le moteur ne porte plus le
nom d'un tenant. Technolibre a son propre realm (technolibre).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-05 00:47:44 -04:00
1edd205d13 serveur_openldap : TLS via step_ca + organisation en intrant (code prod)
- TLS LDAPS/STARTTLS : pont du cert step_ca (client_pki, root:root 600)
  vers /etc/ldap/tls lisible par openldap ; script + unité path systemd
  qui re-synchronise et recharge slapd au renouvellement ; olcTLS* dans
  cn=config ; SLAPD_SERVICES expose ldaps://. Dégrade proprement sans cert.
- Organisation : intrant chezlepro_organisation (remplace « Exemple Inc »).

Validé statiquement (ansible-lint, syntax) ; déploiement réel à suivre.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-02 07:27:43 -04:00
bbcf087904 Câbler les secrets des rôles à leur variable de voûte (vault_*)
Les rôles à secrets déclaraient serveur_X_password: "" avec la variable
de voûte seulement en commentaire — aucun mapping réel. Remplir la voûte
ne branchait donc rien (secret vide → assertion échoue).

Les 12 secrets des 8 rôles pointent maintenant vers leur source :
  serveur_X_password: "{{ vault_X | default('') }}"
Comportement inchangé si la voûte est vide ; branché dès qu'elle a le
secret. Prouvé : assertion step_ca passe avec vault_step_ca_password.
Chaque instance remplit ses vault_* ; aucun mapping par instance.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-01 21:29:18 -04:00
Alliance Boreale
3dd3f43ad8 Set-OPS — moteur d'ecosystemes numeriques souverains (Alliance Boreale) 2026-06-24 20:17:46 -04:00