====== Client sssd (Arch / CachyOS) — login système via LLDAP ======

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

===== Installation =====

<code bash>
sudo pacman -S sssd
</code>
(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'').

===== Certificat CA =====

<code bash>
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
</code>

===== sssd.conf =====

**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)

<code bash>
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
</code>

===== NSS (à faire à la main sur Arch) =====

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

<code>
passwd: files sss systemd
group:  files [SUCCESS=merge] sss [SUCCESS=merge] systemd
</code>

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 :
<code bash>
sudo systemctl restart sssd
getent passwd francois     # doit afficher uid=10000 gid=302 ... /usr/bin/zsh
</code>

===== PAM (à faire à la main sur Arch) =====

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

**Sauvegarder d'abord :**
<code bash>
sudo cp /etc/pam.d/system-auth /etc/pam.d/system-auth.bak
</code>

**⚠️ 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) :
<code>
#%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
</code>

**⚠️ 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é.

===== Pièges spécifiques Arch =====

==== su ne teste PAS sss ====

''/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''.

==== ssh : KbdInteractiveAuthentication ====

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.

==== faillock (verrouillage après échecs) ====

Les tentatives ratées répétées verrouillent le compte (''account locked''). Débloquer :
<code bash>
sudo faillock --user francois --reset
sudo faillock --user francois            # vérifier (liste vide = OK)
</code>

===== Bascule d'un compte local en collision (cas francois) =====

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

  - **Créer un compte admin local de secours** (autre nom) AVANT toute manip, et valider son sudo :
<code bash>
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
</code>
  (sur Arch, sudo = groupe ''wheel'' ; vérifier ''%wheel ALL=(ALL) ALL'' dans ''/etc/sudoers.d/'')

  - **Sauvegarder** les infos du compte local avant suppression (filet) :
<code bash>
getent passwd francois >> ~/francois-backup.txt
getent group francois >> ~/francois-backup.txt
</code>

  - **Supprimer le compte local SANS ''-r''** (préserve le home) — en étant connecté en beafrancois, pas en francois :
<code bash>
sudo pkill -u francois 2>/dev/null
sudo userdel francois          # le home /home/francois reste intact
</code>

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

  - **Réattribuer le home** au nouvel UID LLDAP (les fichiers étaient à l'ancien UID 1000) :
<code bash>
sudo chown -R 10000:302 /home/francois
</code>

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

===== Tests de validation =====

<code bash>
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)
</code>

**Bind direct** (pour isoler un souci d'auth : si le bind marche mais pas le login, le problème est PAM, pas LDAP) :
<code bash>
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
</code>

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

===== GNOME Keyring : déverrouillage automatique avec LDAP/sssd (CachyOS) =====

=== Symptôme ===
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 :
<code>
journalctl -b | grep -i gkr-pam
  → gkr-pam: no password is available for user
  → gkr-pam: couldn't unlock the login keyring.
</code>

=== Cause ===
''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).

=== Procédure complète ===

== 1. PAM : forward_pass (le fix principal) ==
Dans ''/etc/pam.d/system-auth'', ajouter ''forward_pass'' à la ligne auth pam_sss :
<code>
auth  [success=2 default=ignore]  pam_sss.so  try_first_pass forward_pass
</code>

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

== 2. Vérifier la pile PAM de GDM ==
''/etc/pam.d/gdm-password'' doit contenir (présent par défaut) :
<code>
auth      optional  pam_gnome_keyring.so
password  optional  pam_gnome_keyring.so use_authtok
session   optional  pam_gnome_keyring.so auto_start
</code>

== 3. Désactiver le lancement par socket systemd (global, tous utilisateurs) ==
Le daemon doit être lancé par PAM, pas par systemd. Poste multi-utilisateurs → mask **global** :
<code>
sudo ln -s /dev/null /etc/systemd/user/gnome-keyring-daemon.socket
sudo ln -s /dev/null /etc/systemd/user/gnome-keyring-daemon.service
</code>
//(équivalent d'un ''systemctl --user mask'' appliqué à tous les utilisateurs du poste)//

== 4. Purger les trousseaux désalignés (par utilisateur) ==
Depuis un TTY, session graphique fermée :
<code>
cd ~/.local/share/keyrings/
rm -f *.keyring          # supprime les trousseaux chiffrés avec l'ancien mdp
echo -n "login" > default
</code>
(''user.keystore'' peut rester ; sauvegarder les .keyring avant si secrets à récupérer)

== 5. Relogin et validation ==
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.

<code>
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
</code>

=== Notes ===
  * É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).

===== Sécurité =====

  * 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).