Table des matières

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 : 

[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 :

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"

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

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)