Daniel Allaire
ba70b80197
Cree uid=sysadmin et cn=sysadmin dans LDAP. Prouve sur idm-01 : le compte
s'authentifie, et le second passage ne touche a rien (changed=0, 7 taches
sautees) — idempotence par EXISTENCE, pas par conformite (D-67).
Il suit l'annuaire au lieu de se declarer au plan : il ecrit par `ldapi:///` et
doit tourner sur cet hote. Le declarer comme groupe obligerait chaque instance a
le poser sur le bon hote, et elles ne le nomment pas pareil (idm-01 ici,
id-ldap-01 chez Technolibre) — je l'ai d'abord pose sur infra-pki-01 par erreur.
Trois defauts trouves en le construisant :
1. `pwdReset` n'existe pas dans ce schema (overlay ppolicy non charge) :
l'entree entiere etait rejetee et `no_log` masquait la cause. J'avais suppose
un mecanisme sans verifier. Le role le DETECTE maintenant, et la doctrine ne
promet plus un changement force qui n'a pas lieu.
2. Le mot de passe aurait ete stocke EN CLAIR : `ldap_entry` ecrit userPassword
litteralement. Hache par `slappasswd -h {SSHA}` desormais.
3. `voute.py` ne scannait que roles/<groupe> : un role applique par un playbook
sans etre un groupe echappait au recensement, ce que D-20 interdit. Il suit
maintenant les listes `roles:` des playbooks.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
44 lines
1.8 KiB
Markdown
44 lines
1.8 KiB
Markdown
# 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.
|