2026-06-24 20:17:46 -04:00
|
|
|
---
|
|
|
|
|
serveur_openldap_paquets:
|
|
|
|
|
- slapd
|
|
|
|
|
- ldap-utils
|
|
|
|
|
- python3-ldap # requis par community.general.ldap_entry sur la cible
|
|
|
|
|
|
|
|
|
|
serveur_openldap_service: "slapd"
|
|
|
|
|
|
|
|
|
|
# Identite de l'annuaire.
|
|
|
|
|
serveur_openldap_domaine: "{{ domaine_interne }}"
|
2026-07-05 00:47:44 -04:00
|
|
|
serveur_openldap_organisation: "{{ organisation | default('Organisation') }}"
|
2026-06-24 20:17:46 -04:00
|
|
|
# Base DN derivee du domaine interne (ex. acme.local -> dc=acme,dc=local).
|
|
|
|
|
serveur_openldap_base_dn: "dc={{ serveur_openldap_domaine.split('.') | join(',dc=') }}"
|
|
|
|
|
serveur_openldap_admin_dn: "cn=admin,{{ serveur_openldap_base_dn }}"
|
|
|
|
|
|
|
|
|
|
# Secret OBLIGATOIRE (Ansible Vault).
|
2026-07-01 21:29:18 -04:00
|
|
|
serveur_openldap_admin_password: "{{ vault_openldap_admin | default('') }}" # rempli depuis la voute (vault_openldap_admin)
|
2026-06-24 20:17:46 -04:00
|
|
|
|
|
|
|
|
# Unites organisationnelles de base.
|
|
|
|
|
serveur_openldap_ou:
|
|
|
|
|
- people
|
|
|
|
|
- groups
|
2026-07-02 07:27:43 -04:00
|
|
|
|
|
|
|
|
# --- TLS (LDAPS + STARTTLS) via le certificat d'hote step_ca ---
|
|
|
|
|
# Requiert l'integration client_pki sur le noeud (fournit le cert + le renouvellement).
|
|
|
|
|
serveur_openldap_tls_actif: true
|
|
|
|
|
# Certificat SOURCE depose par client_pki (root:root 600, illisible par openldap).
|
|
|
|
|
serveur_openldap_tls_source_cert: "/etc/step/certs/{{ ansible_fqdn | default(ansible_hostname) }}.crt"
|
|
|
|
|
serveur_openldap_tls_source_cle: "/etc/step/certs/{{ ansible_fqdn | default(ansible_hostname) }}.key"
|
|
|
|
|
serveur_openldap_tls_source_ca: "/etc/step/certs/root_ca.crt"
|
|
|
|
|
# Emplacement PONT, lisible par openldap ; resynchronise a chaque renouvellement.
|
|
|
|
|
serveur_openldap_tls_dir: "/etc/ldap/tls"
|
|
|
|
|
# Services slapd exposes (ldaps ajoute pour le TLS ; ldapi pour l'admin local).
|
|
|
|
|
serveur_openldap_services: "ldap:/// ldaps:/// ldapi:///"
|
2026-08-07 13:52:00 -04:00
|
|
|
|
|
|
|
|
# --- Politique de mot de passe (overlay ppolicy) ------------------------------
|
|
|
|
|
# Sans cet overlay, `pwdReset` n'existe pas dans le schema : le changement force a
|
|
|
|
|
# la premiere ouverture est impossible, et rien ne contraint la qualite ni ne
|
|
|
|
|
# verrouille apres des echecs repetes. Mesure le 2026-08-07 : seul `back_mdb`
|
|
|
|
|
# etait charge. Voir docs/autorisation.md §3.
|
|
|
|
|
#
|
|
|
|
|
# Depuis OpenLDAP 2.5, le schema ppolicy est INTEGRE au module : aucun fichier
|
|
|
|
|
# `.ldif` a charger, contrairement a 2.4.
|
|
|
|
|
serveur_openldap_ppolicy_actif: true
|
|
|
|
|
|
|
|
|
|
# `pwdMustChange` est ce qui donne son effet a `pwdReset` : sans lui, marquer une
|
|
|
|
|
# entree n'oblige a rien. Les deux vont ensemble.
|
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
|
|
|
# Les REGLES elles-memes ne sont plus declarees ici : elles vivent dans
|
|
|
|
|
# `resoudre_politique_mdp`, qui les traduit AUSSI pour Keycloak. Tant qu'elles
|
|
|
|
|
# n'existaient que de ce cote, Keycloak n'en validait aucune et le chemin que
|
|
|
|
|
# prend un vrai utilisateur ne verifiait rien (mesure du 2026-08-08).
|
|
|
|
|
# Laisser vide ; ne surcharger que pour ajouter un attribut pwd* hors politique.
|
|
|
|
|
serveur_openldap_ppolicy_extra: {}
|
2026-08-07 13:52:00 -04:00
|
|
|
|
|
|
|
|
# Reglages de l'OVERLAY lui-meme (pas de la politique). `HashCleartext` hache un
|
|
|
|
|
# mot de passe recu en clair au lieu de le stocker tel quel : filet de securite si
|
|
|
|
|
# un client oublie de hacher.
|
|
|
|
|
# `UseLockout` laisse volontairement a FALSE : dire « ce compte est verrouille »
|
|
|
|
|
# renseigne un attaquant sur l'existence du compte. L'utilisateur legitime voit
|
|
|
|
|
# « identifiants invalides » et attend la duree de verrouillage.
|
|
|
|
|
serveur_openldap_ppolicy_hash_cleartext: true
|
|
|
|
|
serveur_openldap_ppolicy_use_lockout: false
|