Configurer des clients Linux pour OpenLdap/NFS

Disposant d’un serveur opérationnel proposant les services OpenLdap et NFS dont nous avons détaillé l’installation dans le cadre du projet CHATONS :

Création d’un CHATONS – 2/5 : déploiement du LAPP

[ez-toc]

Configuration utilisée

Gnome (Flashback?)

KD Plasma

Authentification LDAP

Tutoriel un peu daté de help.ubuntu.com [en] : LDAPClientAuthentication

Un autre plus récent chez Computing for Geeks : Configure LDAP Client on Ubuntu 22.04|20.04|18.04|16.04

Install. de base

Comme d’habitude, nous commençons par installer les applicatifs nécessaires :

sudo apt-get install ldap-auth-client nscd libpam-ldap ldap-utils

Pendant le processus d’installation, plusieurs questions nous sont posées, dans ce cas précis il est recommandé de renseigner une adresse IP, et utiliser ldap:// au lieu de ldapi:/// : ldap://192.168.69.10/

Le DN (Distinguished Name) de la base : dc=landinux,dc=org

Préférer la dernière version 3 :

Répondre par l’affirmative à la question Make local root Database admin

Et par la négative à la suivante Does the LDAP database require login?

Puis les identifiants de l’admin de la base : cn=admin,dc=landinux,dc=org

Il est demandé de saisir le mot de passe admin :

Fichiers modifiés

Il conviendra de vérifier les fichiers de configuration suivants :

/etc/ldap/ldap.conf : Config. générale client LDAP
/etc/libnss-ldap.conf : utilisé par le démon nscd
/etc/pam_ldap.conf : utilisé par PAM (Plugable Auth Module), semblable au précédent
/etc/pam_ldap.secret : contient le mot-de-passe cn=admin ; doit avoir pour permissions : 600 (-rw——-)

Configuration

Une fois cette installation terminée, il conviendra de modifier le fichier /etc/nsswitch.conf en y ajoutant ldap comme méthode :

passwd: files systemd ldap
group: files systemd ldap
shadow: files ldap

Puis il est temps d’aller configurer PAM (Pluglable Authentification Module).

Entres-autres, si l’on veut que le répertoire utilisateur soit crée lors de la première connexion , on précisera les conditions de création du répertoire utilisateur par défaut, à savoir issu du répertoire standard /etc/skel.
Ceci devrait être modifié lors de la mise en production …
Donc, vers la fin du fichier /etc/pam.d/common-session :

# and here are more per-package modules (the "Additional" block)
[...]
session optional pam_ldap.so
session [success=ok default=ignore] pam_ldap.so minimum_uid=1000
session optional pam_mkhomedir.so skel=/etc/skel umask=077

Et à ajouter dans /etc/pam.d/common-password :

# here are the per-package modules (the "Primary" block)
[...]
password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass

Il peut éventuellement être utile de redémarrer le serveur nscd :

sudo service nscd restart

Il nous reste à vérifier que les utilisateurs et groupes présents dans l’annuaire LDAP remontent :

getent passwd | grep test
test::10001:20001:UserTest:/home/test:/bin/bash
test2::10002:20001:User Test:/home/test2:/bin/bash

getent group | grep membres
membres:*:20001:membres

En cas de problème, il est utile de surveiller le journal des authentifications :

sudo tail -f /var/log/auth.log
May 6 21:06:02 ll01 nscd: nss_ldap: failed to bind to LDAP server ldapi:///192.168.69.10: Can't contact LDAP server
May 6 21:06:02 ll01 nscd: nss_ldap: reconnecting to LDAP server…
May 6 21:06:02 ll01 nscd: nss_ldap: could not connect to any LDAP server as cn=admin,dc=landinux,dc=org - Can't contact LDAP server

Test fonctionnel

Afin d’être certain que la base d’authentification est fonctionnelle, depuis un autre ordinateur, nous tentons une connections SSH sur le poste client concerné, avec un utilisateur issu de l’annuaire LDAP , nommé vulgairement « test2« :

ssh test2@ll01

test2@ll01's password:
Creating directory '/home/test2'.
Welcome to Ubuntu 22.04.2 LTS (GNU/Linux 5.19.0-41-generic x86_64)
[...]

Les identifiants sont acceptés, ce qui est bon signe !

Nous jetons un coup d’œil sur notre nouveau dossier personnel :

pwd
/home/test2

ls -a ~/
. .. .bash_logout .bashrc .cache .profile

On peut s’amuser à faire des comparaisons avec le dossier /etc/skel présent sur le poste client (ce point restant à éclaircir pour la mise en production …)

diff /home/test2/.profile /etc/skel/.profile

diff /home/test2/.bashrc /etc/skel/.bashrc

Enfin nous testons une ouverture de session graphique avec ce même identifiant depuis ce poste client ; et c’est un succès !

Ceci constitue au passage une belle occasion de configurer un profil utilisateur par défaut qui pourra par la suite être propagé …

TRUC

Hélas il nous reste un chaînon manquant : le dossier utilisateur, dans l’exemple : /home/test2 se trouve stocké sur le client ll01, et ce n’est pas ce que nous souhaitons.
Nous fermons la session de cet utilisateur, éventuellement nous copions le contenu de son profil utilisateur vers /etc/skel pour en faire un modèle.

Dans le chapitre suivant, nous allons régler ce problème en permettant l’accès au répertoire /home du serveur via un montage NFS …

Montage NFS

Instalation & config.

apt install libnfs-utils nfs-common

ça pas bon, pas ici (côté serveur) :

sudo systemctl start nfs-kernel-server.service

Problèmes avec le snap (Ubuntu 22)

Bien que le journal /var/log/syslog indique :

May  7 15:33:46 ll02 snapd[5254]: profile.go:336: snapd enabled NFS support, additional implicit network permissions granted

Certaines applications (firefox, chromium, …) refusent de se lancer. En lançant par ex. firefox depuis un terminal :

firefox
cannot open path of the current working directory: Permission denied

Le journal /var/log/syslog est bien peu bavard :

May  7 17:32:29 ll02 systemd[2186]: Started snap.firefox.firefox.cdb09dbe-6bc1-4c35-a7f9-5fb4ff48689d.scope.

Après de nombreuses recherches, ce souci reste à éclaircir pour pouvoir utiliser la distribution Ubuntu …