Différences

Ci-dessous, les différences entre deux révisions de la page.

--- commun:authentification_lldap_sssd_client_arch [2026/06/28 09:08] – créée francois
+++ commun:authentification_lldap_sssd_client_arch [2026/07/26 09:28] (Version actuelle) – francois
@@ Ligne 30: / Ligne 30: @@
 Points clés du mapping (rappel) :
   * ''ldap_uri = %%ldaps://auth.beafrancois.fr:6360%%''
   * ''ldap_schema = rfc2307bis''
@@ Ligne 82: / Ligne 81: @@
 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
+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
@@ Ligne 103: / Ligne 102: @@
 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 =====
@@ Ligne 177: / Ligne 179: @@
 **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é =====