====== Complément serveur : résolution LLDAP (NSS) + partages NFS ======
Dernière mise à jour : juin 2026
Complète la doc serveur LLDAP. Couvre l'ajout de **sssd en mode NSS-only** sur le serveur (cahute) pour que les partages NFS appliquent les identités/groupes LLDAP, et le piège des **bits spéciaux (setuid/setgid) sur les dossiers** côté NFSv4.
===== Pourquoi sssd sur le serveur =====
Les fichiers des partages appartiennent à des UID/GID (ex. groupe ''partage'' = 301, ''famille'' = 302). Pour qu'un utilisateur **LLDAP** (ex. francois, uid 10000) accède à un partage selon ses groupes, le serveur doit **résoudre** ces identités LLDAP — sinon il ne connaît que ses comptes locaux et l'UID 10000 est un inconnu sans groupes.
**Principe retenu :** sssd en **NSS-only** (résolution des users/groupes) **SANS PAM**. Le login système du serveur reste **local** (compte ''maitre'' + clé SSH), conformément à la règle « les serveurs ne dépendent pas de l'IdM ». sssd ne sert qu'à *résoudre* les identités pour les permissions de fichiers, pas à authentifier.
===== Installation (serveur cahute, Debian Trixie) =====
sudo apt install -y sssd sssd-tools libnss-sss
**Ne PAS installer ''libpam-sss''** (on ne veut pas le login PAM sur le serveur).
===== sssd.conf (serveur, NSS-only) =====
''/etc/sssd/sssd.conf'', permissions **600 root:root**. Différences avec la config client :
* ''services = nss'' uniquement (pas ''pam'')
* ''ldap_tls_cacert'' pointe **directement** vers le cert dans le volume Docker de LLDAP (le serveur héberge LLDAP, inutile de copier le CA ailleurs)
* Reste du mapping **identique** à la config client
[sssd]
services = nss
domains = beafrancois.fr
[nss]
filter_users = root
filter_groups = root
[domain/beafrancois.fr]
id_provider = ldap
access_provider = simple
simple_allow_groups = famille
cache_credentials = True
use_fully_qualified_names = False
ldap_uri = %%ldaps://auth.beafrancois.fr:6360%%
ldap_schema = rfc2307bis
ldap_search_base = dc=beafrancois,dc=fr
ldap_default_bind_dn = uid=binduser,ou=people,dc=beafrancois,dc=fr
ldap_default_authtok = MOT_DE_PASSE_BINDUSER
ldap_tls_cacert = /mnt/stockage/docker/data/lldap/ca-cert.pem
ldap_tls_reqcert = demand
ldap_user_search_base = ou=people,dc=beafrancois,dc=fr?subtree?(uidNumber=*)
ldap_user_object_class = posixAccount
ldap_user_name = uid
ldap_user_uid_number = uidNumber
ldap_user_gid_number = gidNumber
ldap_user_home_directory = homeDirectory
ldap_group_search_base = ou=groups,dc=beafrancois,dc=fr?subtree?(gidNumber=*)
ldap_group_object_class = groupOfNames
ldap_group_name = cn
ldap_group_member = member
ldap_group_gid_number = gidNumber
override_homedir = /home/%u
default_shell = /bin/bash
**⚠️ Piège ''ldap_uri'' :** ne PAS laisser sssd faire l'autodiscovery (il tombe sur ''LDAP: localhost'' et reste Offline). Spécifier explicitement ''%%ldaps://auth.beafrancois.fr:6360%%''. Le serveur doit résoudre ce nom vers LLDAP (lui-même).
sudo chmod 600 /etc/sssd/sssd.conf
sudo chown root:root /etc/sssd/sssd.conf
sudo sssctl config-check
sudo systemctl restart sssd
sudo sssctl domain-status beafrancois.fr # doit afficher Online (PAS "LDAP: localhost")
===== nsswitch (serveur) =====
''/etc/nsswitch.conf'' — ''files'' EN PREMIER (les comptes locaux du serveur restent prioritaires et garantis), ''sss'' en complément :
passwd: files sss systemd
group: files sss systemd
**On ne touche PAS à PAM** sur le serveur. Le login reste local.
Vérification :
getent group famille # famille:*:302:francois,beatrice,corentin,louis,testldap
getent group partage # partage:*:301:francois,beatrice
getent passwd maitre # le compte local doit toujours répondre (files prioritaire)
===== Cohérence des GID (essentiel) =====
Les GID des groupes LLDAP doivent correspondre **exactement** aux GID des fichiers sur le serveur :
* ''partage'' = **301**
* ''famille'' = **302**
* ''multimedia'' = **300**
Si un GID LLDAP diffère du GID des fichiers, l'utilisateur membre du groupe LLDAP n'accède PAS aux fichiers (le GID des fichiers ne correspond à aucun groupe dont il est membre). Aligner les GID dans LLDAP sur ceux des fichiers existants.
Une fois sssd actif et les GID alignés, les **groupes locaux** doublons (''partage'', ''famille''… définis localement sur le serveur) peuvent être supprimés — sss les résout désormais via LLDAP avec les mêmes GID. À faire seulement APRÈS validation de l'accès, en gardant un filet.
===== Configuration NFS =====
Le serveur exporte en **NFSv4 uniquement** (v2/v3 désactivés) avec ''manage-gids''.
''/etc/default/nfs-kernel-server'' :
RPCMOUNTDOPTS="--manage-gids -N 2 -N 3"
* ''--manage-gids'' : le serveur **recalcule** les groupes de l'utilisateur à partir de son UID (via sssd/NSS), au lieu de se fier à la liste envoyée par le client. Indispensable pour que les groupes LLDAP s'appliquent.
* ''-N 2 -N 3'' : désactive NFSv2 et NFSv3 (NFSv4 seul).
Vérifier que le serveur recalcule bien les groupes d'un user LLDAP :
sudo cat /proc/net/rpc/auth.unix.gid/content
# attendu, ex. : 10000 3: 300 301 302 (francois membre de multimedia/partage/famille)
Recharger après changement :
sudo exportfs -ra
sudo systemctl restart nfs-server nfs-mountd
===== ⚠️ PIÈGE MAJEUR — bits setuid/setgid sur les dossiers et NFSv4 =====
**Symptôme vécu :** un utilisateur LLDAP membre du bon groupe accède au partage **en local sur le serveur** (''sudo -u francois ls …'' et ''sudo -u '#10000' ls …'' OK), le serveur calcule bien ses groupes (''auth.unix.gid'' correct), les UID/GID sont bien mappés côté client (pas de nobody) — **mais l'accès via NFS échoue avec EACCES**.
**Cause :** les dossiers du partage portaient des **bits spéciaux** setuid/setgid (mode ''drwsrws---''). Ces bits sur les répertoires provoquent un refus d'accès via NFSv4 alors que le mode Unix « groupe rwx » laisse penser que l'accès est permis. Le serveur local ne s'en formalise pas, la couche NFSv4 si.
**Solution appliquée :** retirer les bits spéciaux (setuid + setgid + sticky) récursivement sur le partage :
sudo chmod -R a-s,a-t /mnt/stockage/partage
* ''a-s'' retire setuid et setgid (pour all)
* ''a-t'' retire le sticky bit
* les permissions rwx normales sont préservées
Après ça, l'accès NFS fonctionne pour les membres du groupe.
**Note :** le ''setgid'' sur un dossier sert normalement à faire hériter le groupe du dossier aux nouveaux fichiers. En le retirant, les nouveaux fichiers prennent le groupe **primaire** du créateur. Comme le groupe primaire des users LLDAP est ''famille'' (302) — partagé — l'accès collectif reste cohérent. Surveiller toutefois que les fichiers créés dans ''partage'' (301) prennent le bon groupe ; si besoin, gérer l'héritage autrement (ACL par défaut) plutôt que par setgid.
===== Diagnostic NFS utile (rappel) =====
* Erreur exacte côté client : ''strace ls /mnt/point/dossier/'' → cherche l'''errno'' (EACCES = permission, ESTALE = handle périmé).
* Voir les groupes recalculés par le serveur : ''cat /proc/net/rpc/auth.unix.gid/content''.
* Vider les caches d'identité NFS du serveur : ''nfsidmap -c'' et ''echo 1 > /proc/net/rpc/auth.unix.gid/flush''.
* Tester l'accès par UID brut (comme NFS le transmet) : ''sudo -u '#10000' ls /chemin'' (différent de ''sudo -u francois'' qui passe par le nom).