Dernière mise à jour : juin 2026

État : validé sur CachyOS (portable-tuxedo) — login en ligne fonctionnel via sssd.

Voir la doc serveur pour LLDAP/réseau/UID-GID, et la doc client Debian pour les détails communs sssd. Cette page ne couvre que les spécificités Arch/CachyOS (NSS et PAM ne se configurent PAS automatiquement, contrairement à Debian).

sudo pacman -S sssd

(tire les modules NSS/PAM nécessaires ; pam_sss.so dans /usr/lib/security/)

Pour les tests LDAP en ligne de commande : sudo pacman -S openldap (fournit ldapsearch).

sudo mkdir -p /etc/ssl/lldap
sudo scp maitre@192.168.1.9:/mnt/stockage/docker/data/lldap/ca-cert.pem /etc/ssl/lldap/ca-cert.pem
sudo chmod 644 /etc/ssl/lldap/ca-cert.pem
sudo chown root:root /etc/ssl/lldap/ca-cert.pem

Identique à la config Debian (voir doc client Debian pour le fichier complet et le détail des options). Emplacement /etc/sssd/sssd.conf, permissions 600 root:root obligatoires.

Points clés du mapping (rappel) :

• ldap_uri = ldaps://auth.beafrancois.fr:6360
• ldap_schema = rfc2307bis
• ldap_user_object_class = posixAccount / ldap_group_object_class = groupOfNames / ldap_group_member = member
• access_provider = simple + simple_allow_groups = famille
• cache_credentials = True + offline_credentials_expiration = 0 (dans [pam])
• ldap_user_shell = unixShell + default_shell = /bin/bash (fallback)
• PAS de auto_private_groups, PAS de groupes privés (groupe primaire = famille 302)

sudo chmod 600 /etc/sssd/sssd.conf
sudo chown root:root /etc/sssd/sssd.conf
sudo sssctl config-check        # doit retourner 0 issue
sudo systemctl enable --now sssd
sudo sssctl domain-status beafrancois.fr   # doit afficher Online

Arch ne modifie PAS /etc/nsswitch.conf automatiquement. Éditer :

passwd: files sss systemd
group:  files [SUCCESS=merge] sss [SUCCESS=merge] systemd

Le [SUCCESS=merge] sur group permet de fusionner les appartenances locales ET LLDAP (un user peut cumuler ses groupes système locaux et ses groupes LLDAP).

Vérifier :

sudo systemctl restart sssd
getent passwd francois     # doit afficher uid=10000 gid=302 ... /usr/bin/zsh

Arch n'a PAS pam-auth-update. Éditer /etc/pam.d/system-auth à la main.

Sauvegarder d'abord :

sudo cp /etc/pam.d/system-auth /etc/pam.d/system-auth.bak

⚠️ POINT CRITIQUE — try_first_pass (pas use_first_pass) : Avec use_first_pass, pam_sss attend un mot de passe déjà mis en cache par un module précédent ; dans la stack Arch (faillock + systemd_home), ce cache n'est pas peuplé au bon moment → pam_sss reçoit un mot de passe vide → Invalid credentials(49) / échec d'auth. Utiliser try_first_pass (redemande le mot de passe si absent du cache).

/etc/pam.d/system-auth (version validée) :

#%PAM-1.0

auth       required                    pam_faillock.so      preauth
-auth      [success=3 default=ignore]  pam_systemd_home.so
auth       [success=2 default=ignore]  pam_sss.so           try_first_pass forward_pass
auth       [success=1 default=bad]     pam_unix.so          try_first_pass nullok
auth       [default=die]               pam_faillock.so      authfail
auth       optional                    pam_permit.so
auth       required                    pam_env.so
auth       required                    pam_faillock.so      authsucc

-account   [success=2 default=ignore]  pam_systemd_home.so
account    [success=1 default=ignore]  pam_sss.so
account    required                    pam_unix.so
account    optional                    pam_permit.so
account    required                    pam_time.so

-password  [success=2 default=ignore]  pam_systemd_home.so
password   sufficient                  pam_sss.so
password   required                    pam_unix.so          try_first_pass nullok shadow
password   optional                    pam_permit.so

-session   optional                    pam_systemd_home.so
session    required                    pam_limits.so
session    required                    pam_unix.so
session    optional                    pam_mkhomedir.so     skel=/etc/skel umask=0077
session    optional                    pam_sss.so
session    optional                    pam_permit.so

⚠️ Ligne pam_mkhomedir.so indispensable : sur Arch, rien ne crée le home d'un utilisateur LLDAP à la première connexion (contrairement à Debian où pam-auth-update coche « create home dir »). Sans cette ligne dans la phase session, le login réussit mais le home n'existe pas. skel=/etc/skel copie les fichiers de base, umask=0077 rend le home privé.

/etc/pam.d/su appelle pam_unix.so en dur (il n'inclut system-auth que pour password). Donc su - <user_ldap> échoue toujours, même avec une config sss correcte — ce n'est PAS un bon test. Tester avec un vrai login : TTY (Ctrl+Alt+F3) ou ssh.

Pour que su fonctionne aussi avec sss (optionnel), remplacer dans /etc/pam.d/su les lignes auth/account/session required pam_unix.so par include system-auth.

Si l'auth ssh par mot de passe échoue alors que pam_sss est bien appelé, vérifier /etc/ssh/sshd_config.d/99-archlinux.conf : KbdInteractiveAuthentication doit être à yes (sinon ssh ne transmet pas le mot de passe à PAM correctement). sudo systemctl restart sshd après modif.

Les tentatives ratées répétées verrouillent le compte (account locked). Débloquer :

sudo faillock --user francois --reset
sudo faillock --user francois            # vérifier (liste vide = OK)

Quand un compte local porte le même nom qu'un compte LLDAP mais avec un UID différent (local 1000 vs LLDAP 10000) :

1. Créer un compte admin local de secours (autre nom) AVANT toute manip, et valider son sudo :

sudo useradd -m -G wheel,network,audio,storage,video,libvirt,users,rfkill,lp,sys -s /bin/bash beafrancois
sudo passwd beafrancois
# se déconnecter, se reconnecter en beafrancois, vérifier : sudo whoami -> root

(sur Arch, sudo = groupe ''wheel'' ; vérifier ''%wheel ALL=(ALL) ALL'' dans ''/etc/sudoers.d/'')

1. Sauvegarder les infos du compte local avant suppression (filet) :

getent passwd francois >> ~/francois-backup.txt
getent group francois >> ~/francois-backup.txt

1. Supprimer le compte local SANS -r (préserve le home) — en étant connecté en beafrancois, pas en francois :

sudo pkill -u francois 2>/dev/null
sudo userdel francois          # le home /home/francois reste intact

1. Installer/configurer sssd (ci-dessus) pour que francois LLDAP (uid 10000) soit résolu.

1. Réattribuer le home au nouvel UID LLDAP (les fichiers étaient à l'ancien UID 1000) :

sudo chown -R 10000:302 /home/francois

1. Valider le login francois (TTY ou ssh) puis l'offline.

getent passwd francois        # uid=10000 gid=302 ... /home/francois /usr/bin/zsh
id francois                   # groupes : 302(famille) + secondaires éventuels
ssh francois@localhost        # login en ligne (vrai vecteur, PAS su)

Bind direct (pour isoler un souci d'auth : si le bind marche mais pas le login, le problème est PAM, pas LDAP) :

LDAPTLS_CACERT=/etc/ssl/lldap/ca-cert.pem ldapsearch -x \
  -H ldaps://auth.beafrancois.fr:6360 \
  -D "uid=francois,ou=people,dc=beafrancois,dc=fr" -w 'MDP' \
  -b "dc=beafrancois,dc=fr" "(uid=francois)" dn

Offline (réseau coupé, vrai login TTY/ssh) — après un login en ligne réussi qui peuple le cache. Voir doc client Debian pour la procédure détaillée et le piège MPG.

Après migration vers l'auth LDAP (LLDAP + sssd), le trousseau ne se déverrouille plus au login. Pop-ups en boucle : « The login keyring did not get unlocked » ou « Choose password for new keyring » (déclenchées par toute appli utilisant le Secret Service : Nextcloud, Signal, etc.)

Diagnostic dans les logs :

journalctl -b | grep -i gkr-pam
  → gkr-pam: no password is available for user
  → gkr-pam: couldn't unlock the login keyring.

pam_sss authentifie mais ne transmet pas le mot de passe aux modules PAM suivants. pam_gnome_keyring n'a donc jamais le mot de passe pour créer/déverrouiller le trousseau login. Aggravé par gnome-keyring-daemon démarré par le socket systemd user (hors session PAM, sans mot de passe).

Dans /etc/pam.d/system-auth, ajouter forward_pass à la ligne auth pam_sss :

auth  [success=2 default=ignore]  pam_sss.so  try_first_pass forward_pass

⚠ Garder un shell root ouvert (TTY) pendant l'édition d'un fichier PAM.

/etc/pam.d/gdm-password doit contenir (présent par défaut) :

auth      optional  pam_gnome_keyring.so
password  optional  pam_gnome_keyring.so use_authtok
session   optional  pam_gnome_keyring.so auto_start

Le daemon doit être lancé par PAM, pas par systemd. Poste multi-utilisateurs → mask global :

sudo ln -s /dev/null /etc/systemd/user/gnome-keyring-daemon.socket
sudo ln -s /dev/null /etc/systemd/user/gnome-keyring-daemon.service

(équivalent d'un systemctl –user mask appliqué à tous les utilisateurs du poste)

Depuis un TTY, session graphique fermée :

cd ~/.local/share/keyrings/
rm -f *.keyring          # supprime les trousseaux chiffrés avec l'ancien mdp
echo -n "login" > default

(user.keystore peut rester ; sauvegarder les .keyring avant si secrets à récupérer)

Reconnexion GDM complète (mot de passe LDAP). PAM crée alors login.keyring chiffré avec le mot de passe LDAP et le déverrouille automatiquement.

ls ~/.local/share/keyrings/            # login.keyring doit exister
journalctl -b | grep -i gkr-pam        # plus de "no password is available"
secret-tool store --label=test test k  # stocke sans pop-up de déverrouillage
ssh-add -l                             # si keyring utilisé comme agent SSH : doit répondre

• Étapes 1–3 : une fois par poste. Étape 4 : pour chaque utilisateur du poste.
• Ne jamais créer le trousseau login à la main (Seahorse) : laisser PAM le créer, sinon l'auto-unlock est aléatoire.
• Le mot de passe du trousseau = mot de passe de session, toujours. Synchronisé automatiquement si le changement de mdp passe par PAM.
• Ne pas démasquer les services systemd du keyring : le mask fait partie du fix (sinon le daemon redémarre hors PAM et le conflit revient).

• Garder le compte admin local de secours (beafrancois) hors LLDAP — accès garanti si l'annuaire est indisponible.
• offline_credentials_expiration = 0 (cache illimité) → LUKS recommandé sur le portable (un portable volé jamais reconnecté garde l'accès indéfiniment).