LDAP et paramétrages de connexion des stations Ubuntu

closeCet article a été publié il y a 7 ans 1 mois , il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

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…

  14 commentaires

14 commentaires

  1. Franck dit :

    J’avais réalisé un projet de fac ou une machine sous debian centralisait les connexions de machines Linux et Windows. les homes étaient montés sous windows et linux sans soucis (Samba oblige ;p) et l’authentification fonctionnait avec LDAP. On avait fait une doc. Je vais tâcher de te trouver ça.

  2. Ramsès PERRIN dit :

    Je vais tenter de vous mettre en relation avec les gens qui m’ont aidé à installer Ubuntu sur la 6.06 dapper, il pourront sans doute faire quelque chose pour la 6.10 edgy. Courage !
    Moi aussi, j’ai horriblement galéré avant d’y arriver mais quel bonheur d’utilisation désormais !
    Ca en vaut réellement la peine.

  3. kor dit :

    Bonjour,

    J’ai vu le post sur le planet ubuntu, je me permet de donner mon rapport de stage sur la mise en place d’un tel serveur.

    ( cf le lien en homepage )

  4. Bonjour,

    J’ai mis en place dans une société un serveur Ldap installé sur une Ubuntu server et l’authentification de 10 postes sur ce serveur LDAP.
    Si vous me donnez une adresse email, je veux bien vous envoyer mes fichiers de config.
    Le home du serveur est monté au démarrage et si celui-ci n’existe pas il est crée automatiquement.

  5. Yves dit :

    Merci beaucoup pour toutes ces propositions d’aide.

    @Franck: Si vous retrouvez la doc, on est preneur.

    @Ramsès PERRIN: Merci, toute aide est bienvenue.

    @kor: Merci pour votre rapport de stage « Mise en place d’un serveur d’authentification LDAP/Samba ».

    @Vandenbussche Lionel: Merci, je vous ai envoyé un courriel avec mon adresse email et celle de Laurent.

  6. alexpat dit :

    Pour le montage automatique des partages en début de session je te propose d’utiliser libpam-mount. Tu trouveras la documentation sur http://www.coagul.org.

    Bàt,
    Alexandre

  7. Laurent dit :

    Merci à tous pour vos indications et documentations. Je n’ai pas encore pu mettre tout ça en pratique cette semaine faute de temps mais je manquerais pas de vous tenir au courant dans un prochain billet.

  8. Nico dit :

    [quote]
    session required pam_unix.so
    session required pam_mkhomedir.so skel=/etc/skel/
    session optional pam_ldap.so
    [/quote]
    Je ferai plutot
    [quote]
    session sufficient pam_ldap.so
    session optional pam_mkhomedir.so skel=/etc/skel/
    session required pam_unix.so
    [/quote]
    Bonne chance :-)

  9. Séverin dit :

    bonjour
    j’essaye de configurer une station linux pour se connecter à un serveur ldap. Et j’ai un problem je ne peut pas me connecter si j’ai pas crée l’utilisateur en local. De plus en se connectant avec un utilisateur en local, je suis connecté au shell local et non celui du serveur ldap

    Impossible de trouver l’origine du problem

  10. Eric dit :

    Bonjour.
    Je suis dans le même cas de figure que vous, je suis en cours d’installation de 6 poste en salle des profs pour un lycée de perpignan. Mon serveur LDAP est un scribe et la version que j’ai choisie et aussi une ubuntu. J’ai trouvé une documentation que explication assez précisement la configuration, certe est est relative à scribe mais elle est applicable sur un autre serveur. A ce jour j’ai reussi une athentification LDAP avec un partage NFS uniquement sur Mandriva 2006.

    ftp://eole.orion.education.fr/doc-pdf/scribe/doc_clients_linux.pdf

  11. Eric dit :

    excusez les fautes il est 1h58…

  12. Yves dit :

    Bonjour Eric,
    Depuis, ce problème a été résolu et la procédure est détaillée dans un autre billet:
    http://www.gesnel.fr/ubuntu/2007/05/30/integration-de-clients-ubuntu-dans-un-reseau-avec-ldap/

  13. aderj dit :

    salut ,
    je voudrais bien avoir la documentation sur les etapes de montage d’un projet d,implementation d’un LDAP avec le plus de detail possible , j’en ai besoin urgent !!!

    mon adresse courriel :aderj07@gmail.com

    merci d’avance

  14. Laurent dit :

    Désolé aderj mais tous les LDAP que j’ai utilisés (dans ALPES ou SambaEdu) étaient « tout prêt » …Il fallait juste les alimenter avec des fichiers d’utilisateurs …

Laisser un commentaire