Module user Ansible : créer, modifier, supprimer des utilisateurs

ansible.builtin.user: gère les utilisateurs Linux : création, modification (shell, home, groupes), hashage de password, suppression. C'est le module n°1 pour l'onboarding de membres d'équipe et le provisioning de comptes applicatifs.

Options critiques RHCE 2026 : name:, state:, shell:, groups: + append:, password: (avec password_hash), uid:, comment:, remove: sur state: absent.

Ce que vous allez apprendre

Créer un utilisateur avec home, shell, groupes secondaires.
Hasher un password avec password_hash('sha512') pour le stockage idempotent.
Distinguer groups: + append: true (ajouter) vs groups: seul (remplacer, danger).
Forcer un uid: précis pour les comptes système / applicatifs (cohérence multi-hôtes).
Supprimer un compte avec remove: true (qui supprime aussi le home).

Prérequis

Avoir become: true configuré (création d'user nécessite root).
Avoir lu Module group, créer le groupe avant l'user qui le référence.

Création basique

- name: Creer alice
  ansible.builtin.user:
    name: alice
    comment: "Alice, admin RHCE 2026"
    shell: /bin/bash
    state: present

À la première exécution : useradd alice -c "Alice, admin RHCE 2026" -s /bin/bash est lancé. Ansible crée le home /home/alice/, génère un groupe primaire alice (UID = GID = premier libre ≥ 1000).

Idempotence : 2e run → changed=0. Ansible vérifie chaque attribut et n'agit que sur ce qui diffère.

Groupes secondaires : la règle `append: true`

Le piège n°1 du module user: est l'oubli de append: true lors de la modification.

# ❌ DANGER : remplace TOUS les groupes secondaires
- name: Gérer le compte bob
  ansible.builtin.user:
    name: bob
    groups: [video]

# ✅ CORRECT : ajoute video sans toucher aux autres
- name: Gérer le compte bob
  ansible.builtin.user:
    name: bob
    groups: [video]
    append: true

Sans append: true, si bob était dans [wheel, docker, sudo], après la 1ère tâche il est uniquement dans video. Bob a perdu wheel et docker sans alerte.

Règle : pour modifier les groupes d'un utilisateur existant, toujours append: true. La seule exception : remise à zéro intentionnelle des droits (offboarding).

Password hashé (et l'idempotence)

# Pattern naif (casse l idempotence)
- name: Gérer le compte charlie
  ansible.builtin.user:
    name: charlie
    password: "{{ 'PasswordEnClair' | password_hash('sha512') }}"

Sans salt fixe, password_hash('sha512') génère un hash différent à chaque run → tâche toujours changed.

Pattern propre (RHCE) : générer le hash une fois et le stocker dans host_vars/ (avec Vault).

# host_vars/db1.lab.yml (chiffre avec ansible-vault)
charlie_password_hash: "$6$randomsalt$hashvalue..."

# Dans le playbook :
- name: Gérer le compte charlie
  ansible.builtin.user:
    name: charlie
    password: "{{ charlie_password_hash }}"

Pour générer le hash en CLI :

mkpasswd -m sha-512 'PasswordEnClair'
# ou
python3 -c "import crypt; print(crypt.crypt('PasswordEnClair', crypt.mksalt(crypt.METHOD_SHA512)))"

update_password: on_create complète le pattern : ne touche au password que si l'user est nouvellement créé, pas s'il existe déjà.

UID forcé pour les comptes système

- name: Compte applicatif deploy avec UID 2000
  ansible.builtin.user:
    name: deploy
    uid: 2000
    group: deploy
    home: /opt/deploy
    create_home: true
    shell: /bin/bash

Pourquoi forcer l'UID ? Sur 50 hôtes, useradd auto-attribue le premier UID libre. Si web1 a deploy=1001 et web2 a deploy=1002, un fichier monté en NFS appartenant à 1001 sera inaccessible par deploy sur web2.

uid: force la cohérence. Si l'UID est déjà pris par un autre user, la tâche failed (pas de collision silencieuse).

Convention RHEL :

UID < 1000 : comptes système (system: true).
UID 1000-2000 : utilisateurs humains.
UID 2000+ : comptes applicatifs (réservé par convention).

Modification d'un user existant

Tous les attributs sauf name peuvent être modifiés :

- name: Changer le shell de alice
  ansible.builtin.user:
    name: alice
    shell: /bin/zsh

- name: Modifier le commentaire
  ansible.builtin.user:
    name: alice
    comment: "Alice, promue lead admin"

Ansible exécute usermod -s /bin/zsh alice et usermod -c "..." alice. Idempotent : 2e run → ok si valeurs identiques.

Suppression : avec ou sans le home

# Suppression sans nettoyer le home (defaut)
- name: Gérer le compte charlie
  ansible.builtin.user:
    name: charlie
    state: absent
    remove: false

# Suppression complete (home + spool mail)
- name: Gérer le compte charlie
  ansible.builtin.user:
    name: charlie
    state: absent
    remove: true

remove: false (défaut) = userdel charlie → home /home/charlie/ conservé. Pattern d'audit-friendly : on peut récupérer les fichiers du compte supprimé.

remove: true = userdel -r charlie → home + mail supprimés. Pour le nettoyage final après archivage des données.

Pièges courants

Symptôme	Cause	Fix
Bob a perdu ses droits sudo après modif	Oubli de `append: true` sur `groups:`	Toujours `append: true` en modification
`changed=1` à chaque run sur le password	`password_hash` sans salt fixe	Stocker le hash dans `host_vars/` (Vault)
Conflit d'UID entre hôtes	Pas de `uid:` forcé	Forcer `uid:` sur les comptes applicatifs
Home reste après `state: absent`	`remove: false` (défaut)	Ajouter `remove: true` pour nettoyer
Tâche failed "uid already exists"	UID déjà utilisé par un autre user	Choisir un UID libre, ou résoudre le conflit

À retenir

name: est la clé d'identification, ne jamais modifier.
groups: + append: true pour ajouter, pas remplacer.
password: = hash SHA-512, idéalement stocké dans host_vars/ (Vault).
uid: forcé sur les comptes système / applicatifs (cohérence multi-hôtes).
remove: true sur state: absent pour supprimer le home.
Création de groupe AVANT création de l'user qui le référence.

Mettre en pratique

La perte silencieuse de groupes secondaires ne se voit qu'en relisant le compte une fois le playbook terminé. Le lab vous fait créer un groupe puis plusieurs comptes sur une machine réelle : un administrateur rattaché à un groupe existant, un compte porteur d'un UID forcé, et un compte applicatif dont le home sort de /home. La vérification interroge la cible pour confirmer chaque UID attribué, les groupes secondaires conservés, le home et le shell attendus.

Module user : créer, modifier et supprimer des comptes

$ dsoxlab run modules-utilisateurs-user

Environnement : VM·Durée : ~35 min

Validé : l'état du système est vérifié après reboot, pas la commande tapée.

Première fois ? Qu'est-ce que dsoxlab et comment l'installer

dsoxlab est la ligne de commande qui prépare un environnement jetable (un shell isolé ou une VM), déroule le scénario du lab, puis vérifie l'état réel du système et calcule un score. Rien n'est installé ni cassé sur votre poste de travail.

Installer la CLI dsoxlab, une seule fois :

uv tool install dsoxlab   # ou : pipx install dsoxlab
git clone https://github.com/stephrobert/ansible-training.git
cd ansible-training

Lancer ce lab, puis valider votre travail :

dsoxlab run modules-utilisateurs-user
dsoxlab check modules-utilisateurs-user

Voir tous les labs : dsoxlab list-labs. Suivre sa progression : dsoxlab progress.

Pour aller plus loin

Module authorized_key : provisionner les clés SSH des comptes que vous venez de créer, avec leurs restrictions.
Module sudoers : donner à ces comptes des droits d'élévation limités aux seules commandes nécessaires.
Module getent : lire passwd et group sur la cible pour conditionner une tâche à l'existence d'un compte.