Nuage

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== 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) =====

<code bash>
sudo apt install -y sssd sssd-tools libnss-sss
</code>
**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

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

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

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

===== nsswitch (serveur) =====

''/etc/nsswitch.conf'' — ''files'' EN PREMIER (les comptes locaux du serveur restent prioritaires et garantis), ''sss'' en complément :

<code>
passwd: files sss systemd
group:  files sss systemd
</code>

**On ne touche PAS à PAM** sur le serveur. Le login reste local.

Vérification :
<code bash>
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)
</code>

===== 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'' :
<code>
RPCMOUNTDOPTS="--manage-gids -N 2 -N 3"
</code>
  * ''--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 :
<code bash>
sudo cat /proc/net/rpc/auth.unix.gid/content
# attendu, ex. : 10000 3: 300 301 302   (francois membre de multimedia/partage/famille)
</code>

Recharger après changement :
<code bash>
sudo exportfs -ra
sudo systemctl restart nfs-server nfs-mountd
</code>

===== ⚠️ 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 :
<code bash>
sudo chmod -R a-s,a-t /mnt/stockage/partage
</code>
  * ''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).