# 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.