Laurent, prof de Mathématiques et PRI (Personne Ressource Informatique), essaye de permettre aux 17 postes clients Ubuntu de la salle informatique du collège de s'authentifier auprès d'un serveur LDAP et de monter les partages et le home distant de l'utilisateur.

Dans notre tentative de proposer Ubuntu comme système d'exploitation des ordinateurs utilisés au collège, nous travaillons depuis quelques temps à la connexion des stations à notre serveur de domaine du réseau pédagogique. Ce billet est à la fois un moyen pour nous de mémoriser nos paramétrages mais également de partager notre expérience sur ce thème.

Notre réseau pédagogique comprend un seul serveur de domaine et de fichiers qui permet aux utilisateurs de se connecter aux stations et d'accéder aux partages du serveur en fonction de leur profil.

Le système proposé par notre académie aux collèges est pour l'instant un serveur ALPES basé sur une RED HAT 9 avec LDAP 3 et SAMBA 2. Je précise tout de suite que je n'ai pas la main sur ce serveur car c'est une configuration dont les réglages sont centralisés par le Rectorat. L'interface web à laquelle j'accède me permet quand même de gérer la partie utilisateurs de LDAP, les partages et les droits dessus, les login script et divers paramétrages standards.

L'annuaire LDAP contient l'ensemble des élèves et des professeurs pour un accès individualisé.

Pour Windows, l'utilisateur qui se connecte au domaine est authentifié par LDAP et différents partages sont mappés dans Poste de Travail grâce à Samba : un répertoire personnel au nom de l'utilisateur, un partage public, un partage classe, etc. avec différents droits.

Nous cherchons donc à réaliser avec Ubuntu l'authentification par LDAP sur la station et le montage du répertoire personnel de l'utilisateur ainsi que des autres partages. Les deux objectifs sont liés mais mes lectures m'ont appris qu'il existe plusieurs façon d'y arriver et je n'ai malheureusement pas encore toutes les réponses à mes questions. Avant de rentrer dans les détails, je rappelle que nous avons fait le choix de déployer Ubuntu Edgy au collège.

J'ai démarré en me basant sur la documentation LDAP Client d'Ubuntu-fr.

Sur un poste, je me connecte avec le compte qui m'a servi à installer Ubuntu.

Étape 1 : installation des paquets pour un client LDAP

sudo apt-get install libpam-ldap libnss-ldap

Comme indiqué, des renseignements complémentaires sont demandés mais difficile de savoir si c'est pour pam ou nss au début…

• Adresse IP de mon serveur: « IPServeur »
• Ma base de LDAP du genre o=qqch, c=qqch: « BaseLDAP »
• version LDAP: 3

Je choisis de ne pas créer de base locale et ma base LDAP n'a pas besoin d'authentification.

Si je modifie le fichier /etc/nsswitch.conf comme indiqué

passwd: files ldap

group:  files ldap

shadow: files ldap

ou comme vu ailleurs :

passwd: compat ldap

group:  compat ldap

shadow: compat ldap

Dans ces deux cas, les commandes ci-dessous ne renvoient rien du tout : 

sudo id un_utilisateur_ldap

sudo getent passwd un_utilisateur_ldap

sudo getent group un_group_ldap

En fouillant, je me suis rendu compte que rien n'avait été modifié dans le fichier /etc/libnss-ldap.conf lors de l'installation des paquets alors que dans un précédent essai sur une Ubuntu Dapper, ce fichier contenait exactement les données renseignées dans la phase d'installation des paquets.

J'ai donc rajouté manuellement dans /etc/libnss-ldap.conf aux lignes concernées 

• Adresse IP de mon serveur: « IPServeur »
• Ma base de LDAP du genre o=qqch, c=qqch: « BaseLDAP »
• Commenter par un # la ligne rootbind (pas besoin d'authentification pour consulter mon LDAP)
• Port 389
• Bind-Policy soft (Ce réglage n'apparaît pas dans l'article ldap-client d'Ubuntu.fr mais est sur la documentation d'Ubuntu.com

Une fois ces changements effectués, j'obtiens cette fois des réponses cohérentes des commandes id, getent passwd, getent group mais ces réponses ne sont cherchées que localement sur le poste, je n'y trouve pas ce qui devraient être cherché dans LDAP.

J'ai donc à nouveau modifié le fichier /etc/nsswitch.conf comme ci-dessous :

passwd: ldap compat files

group:  ldap compat files

shadow: ldap compat files

A partir de là, j'obtiens des réponses cohérentes pour les 3 commandes précédentes aussi bien avec des utilisateurs locaux (dont le compte n'existe que sur la machine) qu'avec des utilisateurs LDAP (dont les comptes n'existent pas sur la machine mais sur le serveur).

Étape 2 : configuration de PAM

C'est là que ça se gâte car les documentations sont nombreuses mais la plupart du temps spécifiques à des installations particulières ou très denses, Pingoo par exemple, ou PAM.

Les exemples ne manquent pas non plus sur le forum d'Ubuntu-fr mais les discussions concernent des époques, des versions, des situations bien différentes et il est difficile de s'y retrouver… dommage j'en avais trouvé un sujet qui correspondait exactement à ce que je cherche…

J'en ai même trouvé une où on change temporairement les dépôts pour installer les paquets PAM et NSS de Feisty… C'est très déconcertant…

Voilà où j'en suis :

dans /etc/pam.d/common-account :

account sufficient   pam_ldap.so

account required     pam_unix.so

Dans /etc/pam.d/common-auth :

auth  sufficient pam_ldap.so

auth  required   pam_unix.so use_first_pass

Dans /etc/pam.d/common-password :

password  sufficient pam_ldap.so md5

password  required   pam_unix.so nullok obscure min=4 max=8 md5

Dans /etc/pam.d/common-session :

session required      pam_unix.so

session required      pam_mkhomedir.so  skel=/etc/skel/

session optional      pam_ldap.so

Là où je suis encore mauvais, c'est que je n'ai pas la moindre idée de ce qu'implique ces réglages et je ne vois donc pas ce que signifie tel ou tel choix d'option.

D'ailleurs, heureusement que je conserve une connexion avec un utilisateur administrateur du poste en faisant mes essais car un réglage faux et la connexion n'est plus possible même pour root. J'ai fait pas mal de restaurations de système avant de comprendre…

Avec tous ces réglages, la connexion d'un compte local fonctionne mais un compte LDAP renvoie la connexion a échouée…

Si j'enlève la ligne :

session required        pam_mkhomedir.so  skel=/etc/skel/

j'ai un message d'erreur qui me dit que l'utilisateur devrait avoir un home sur /home/disque1/users/login_utilisateur qui n'existe pas et donc la connexion ne peut se faire.

Ce qui est rassurant, c'est que le chemin /home/disque1/users/login_utilisateur, il est forcément allé le lire dans LDAP.J'ai fait un essai en biaisant : j'ai créé un répertoire login_utilisateur sur le poste avec les droits qui vont bien et là mon utilisateur a pu s'authentifier avec son mot de passe LDAP mais son home était le répertoire local que j'ai créé manuellement et non le répertoire sur le serveur…

Je pense que je brûle mais je dois encore résoudre les problèmes suivants :

• Faire en sorte qu'Ubuntu utilise le home qui est sur le serveur à la connexion à la station ... Pour cela, je dois sûrement lui faire créer le home de l'utilisateur à la première connexion avec mkhomedir.so et le chemin qu'il attend et ensuite faire en sorte qu'il aille sur le home du serveur.
• Renseignements pris auprès des initiés, le service NFS n'est pas activé sur mon serveur. Il pourrait l'être mais je préfère éviter les singularités sur mon serveur qui risqueraient de poser des problèmes lors des mises à jour qui sont centralisées et réalisées à distance. Sans rentrer dans le détail, je préfère m'en tenir pour l'instant à des réglages que je peux faire moi-même donc je reste au niveau des stations.
• Au lieu de NFS, je peux utiliser SAMBA pour monter les partages des utilisateurs. Là, il faut que je creuse car getent group est capable de donner les groupes d'un utilisateur donné; je pense qu'il doit exister un moyen d'automatiser la connexion des partages de façon individuelle, peut être au moyen d'un script à la connexion qui utiliserait getent group pour avoir la liste des groupes d'un utilisateur donné et les monter avec smb.

Les suggestions sont évidemment bienvenues…