FLASH INFORMATIQUE FI

Avoir une identité unique dans un réseau hétérogène


LDAP et Linux à la rescousse !




Vittoria REZZONICO

Pascal JERMINI


La solution idéale : LDAP

La solution NIS n’étant pas satisfaisante, nous nous sommes tournés vers ce qui nous semblait être une technologie prometteuse : LDAP (voir à ce sujet, l’ article de Claude Lecommandeur dans le flash info 9/01 : http://dit-archives.epfl.ch/FI01/fi-9-1/9-1-page5.html). Voilà : nous avons maintenant utilisé tous les éléments du titre de l’article ! Il semblerait donc que cette solution marche !

Première étape : un serveur LDAP. Dans le monde OpenSource, le plus fameux est OpenLDAP [4]. Il offre de bons services et de nouvelles versions sont régulièrement disponibles. La configuration du serveur est assez simple, et après avoir fait migrer les utilisateurs dans la base de données LDAP il ne reste plus qu’à configurer les machines clientes. Pour les machines Linux la procédure est rapidement mise en oeuvre : le système PAM permet de choisir la source d’authentification. Il existe à ce sujet plusieurs pages Web décrivant la procédure : en voici une parmi tant d’autres http://www.imaginator.com/ simon/ldap/.

Irix peut poser des problèmes, surtout avec les anciennes versions (antérieures à la version 6.5.13) : le service nscd n’était pas en mesure de communiquer correctement avec le serveur LDAP. Une mise à jour résout le problème.

Après cela la marche à suivre est simple : le fichier /etc/nsswitch.conf permet de choisir la source d’authentification, et le fichier /var/ns/ldap.conf contient les informations telles que l’adresse du serveur LDAP. Dans ce même fichier il y a une modification subtile et importante à faire : la ligne regsub USERPASSWORDCRYPT\ doit être transformée en regsub USERPASSWORDcrypt\.

Pour Solaris, l’article se trouvant à l’adresse http:/ /www.ypass.net/solaris8/openldap/ explique pas à pas la démarche à suivre pour configurer un client tournant sous Solaris 8.

Il reste maintenant à intégrer les machines tournant sous Windows 2000 ou XP. Cela est beaucoup plus laborieux : Windows ne gère pas les login directement sur un serveur LDAP. Il faut pour cela passer à travers un serveur de domaine, lequel obtiendra les informations d’authentification sur le serveur LDAP. Le logiciel de référence en matière d’intégration de Windows dans un environnement Unix est Samba [5].

Figure 1 : résumé des dépendances entre les différents services présents sur le serveur.

Samba : le pont entre deux mondes très différents

La version standard de Samba (2.2.2) a un support très limité du protocole LDAP, ce qui en fait un piètre candidat comme serveur de domaine. Il existe heureusement une branche alternative à Samba, appelée Samba-TNG [6] (Samba The Next Generation). Cette version diffère de celle standard sur plusieurs points : support avancé pour LDAP, contrôleur de domaine Windows assez complet, mais ce n’est qu’une version alpha. Ceci veut dire que le logiciel n’a pas la stabilité de Samba 2.2.2 (version qui a désormais fait ses preuves dans le domaine de la stabilité et des performances) et certaines fonctionnalités ne sont pas implémentées. Malgré la jeunesse de Samba-TNG, nous n’avons constaté aucun problème majeur de stabilité : le serveur a tourné pendant plusieurs semaines d’affilée, sans le moindre pépin. Le service a temporairement été interrompu pour une toute autre raison : un défaut du matériel a imposé l’arrêt de la machine. Un autre problème de Samba-TNG est son incapacité de servir comme serveur de fichiers : ses performances dans ce domaine sont très limitées. De plus ses performances en tant que serveur WINS sont plutôt décevantes, il vaut mieux se rabattre sur Samba 2.2.2 pour ce service, où il est beaucoup plus mûr et plus testé.

Il est néamoins possible de contourner le problème en installant les deux versions de Samba en parallèle comme expliqué plus tard.

Lors de la configuration de Samba-TNG il est indispensable d’inclure le support LDAP ainsi que les capacités de contrôleur de domaine. Le premier se définit avant la compilation, tandis que le deuxième est un paramètre du fichier smb.conf (paramètre domain logons = yes). Pour que Samba-TNG se comporte comme un contrôleur de domaine il ne faut pas oublier de spécifier le partage Netlogon, défini toujours dans le fichier smb.conf de cette manière, par exemple :

[netlogon]
comment = The domain logon service
path = /home/samba/netlogon
writeable = no
locking = no

Samba-TNG repose sur une architecture basée sur plus de dix daemons, chacun avec sa tâche bien spécifique. Un des utilitaires qui va être très pratique pour l’administrateur du domaine NT est appelé samedit(8). C’est un outil de commandes en ligne, mais qui malheureusement montre certains défauts de Samba-TNG : certaines de ses commandes ne marchent pas (le serveur renvoie des messages d’erreur), et l’effacement d’un utilisateur ou d’une machine n’est pas supporté. Cela est un problème relativement mineur : on peut écrire un script en bash ou en un quelconque autre langage pour l’effacement d’une entrée dans le serveur LDAP.

Mots de passe synchronisés : l’atout majeur de l’identité unique

L’un des atouts de l’identité unique est bien évidemment la possibilité d’avoir un même mot de passe sur toutes les machines, soient-elles Windows ou Unix. Naturellement Unix et Windows n’utilisent pas le même système de hachage des mots de passe, ce qui pose quelques problèmes. Il existe une solution à ce problème, qui malheureusement n’est efficace que partiellement et qui donne un avantage aux machines Unix : on peut remplacer le programme classique passwd(1) qui permet le changement des mots de passe par un script, qui génère les deux types de hachages et qui les stocke aux bons endroits sur le serveur LDAP [7]. Pourquoi cette méthode n’est-elle pas efficace à 100% ? D’une part, il faut installer les outils clients LDAP sur les machines Unix (ou au moins l’outil ldapmodify(1), qui permet de modifier des clés de la base de données LDAP) et d’autre part, la synchronisation des mots de passe ne fonctionnera pas lorsque l’on demandera un changement depuis une machine Windows. La raison est qu’en utilisant l’utilitaire fourni avec Windows (celui accessible par Ctrl+Alt+Del -> Change password...) le mot de passe est haché avant d’être envoyé au contrôleur de domaine (sécurité oblige !), et ce dernier ne sera pas capable de revenir en arrière (trouver le mot de passe à partir du hachage, fort heureusement !). Il n’a donc aucun moyen de connaître le mot de passe Windows qui devrait ensuite être haché en format Unix.

Encore une remarque assez importante : les scripts présentés en [7] sont conçus pour être utilisés avec des mots de passe hachés avec l’algorithme MD5, et non pas avec l’algorithme crypt(), encore très diffus. Nous avons dû modifier les scripts afin de tourner avec l’algorithme crypt(), essentiellement à cause des machines tournant sous Irix.

La machine Windows dit bonjour à un serveur Unix !

Pour qu’une machine Windows 2000 ou XP rejoigne le domaine il faut d’abord créer un compte-machine sur le contrôleur de domaine, et ensuite utiliser sur le client la méthode habituelle (click droit sur My Computer -> Properties -> Onglet -> Computer Name -> Network ID). Il est possible qu’il faille attendre une minute ou deux avant de voir la boîte de dialogue Welcome to domain MYDOMAIN : ceci est bon signe !

Nous n’avons pas eu l’occasion de tester cette procédure sur des machines Windows NT 3.51 ou 4.0, mais à notre connaissance il n’y a aucun problème spécifique à ces deux versions.

Il y a tout de même quelques subtilités particulières à certaines versions de Windows. Le premier cas est Windows 2000 SP2 (et ultérieurs ?) : cette version n’est pas en mesure de charger et sauvegarder correctement les informations des profils utilisateurs (message Access denied). On contourne ceci en spécifiant l’option : nt acl support = no pour le partage contenant les profils des utilisateurs.

Le deuxième cas problématique est Windows XP : les machines tournant sous ce système d’exploitation joignent sans problème le domaine mais les utilisateurs ne peuvent pas faire le login (message disant qu’aucun contrôleur de domaine n’a été trouvé). Ici aussi une solution existe mais elle doit être mise en oeuvre sur la machine cliente elle-même. Il faut modifier la clé suivante du registre : HKLM\System\ CurrentControlSet\Services\Netlogon\parameters\ requiresignorseal doit valoir 0 au lieu de 1. Une fois la modification effectuée, les utilisateurs peuvent faire le login.

Garder sa propre personnalité : répertoires personnels centralisés

Si l’on désire partager des fichiers (ou bien avoir des répertoires personnels centralisés) vers des machines Windows, il est nécessaire d’avoir les deux versions de Samba en parallèle. La mise en place d’un tel système n’est pas triviale : il faut créer une interface réseau virtuelle et instruire un des deux serveurs Samba à se mettre à l’écoute sur l’interface virtuelle (par exemple en utilisant dans le fichier smb.conf une directive de configuration similaire à celle-ci : interfaces = 192.168.100.254). Deux serveurs Samba signifient deux fichiers de configuration bien distincts : le premier contenant la configuration du serveur de fichiers et le deuxième celle du contrôleur de domaine. Les paramètres-clés du fichier smb.conf de Samba 2.2.2 qui permet l’échange des données de sécurité entre le serveur de fichiers et le contrôleur de domaine sont les suivants :

security = domain
password server = SERVEUR_SAMBA_TNG

Voir la référence [8] pour une marche à suivre détaillée sur la mise en oeuvre de deux serveurs Samba en parallèle.

Il est important de remarquer une finesse que permet un serveur de fichier central utilisé par Windows et par Unix : l’utilisateur a accès à exactement les mêmes fichiers, qu’il travaille sous Windows ou sous Unix. Ceci est particulièrement intéressant, étant donné que cela évite des va-et-vient avec des disquettes, des sessions FTP interminables, etc.

La mise en place des répertoires personnels centralisés sous Unix ne diffère guère de la méthode utilisée dans un environnement NIS : il suffit d’utiliser des utilitaires tels que automount ou autofs. Il est possible de stocker les maps de automount dans la base de données LDAP. Nous n’avons pas essayé cette possibilité en raison de l’ancienneté de la version de automount dont nous disposons. Dans notre cas nous avons utilisé NFS comme protocole de distribution de fichiers.

Sous Windows par contre, cette opération est simple : il faut juste spécifier le chemin réseau vers le répertoire de l’utilisateur dans son profile stocké sur le serveur.

Si on met toutes ces informations ensemble...

La figure 1 montre les dépendances entre les services et les machines clientes. La communication entre les deux serveurs Samba est due au fait que Samba 2.2.2 obtient les informations sur les utilisateurs ainsi que leurs droits d’accès depuis le contrôleur de domaine (Samba TNG). Il faut remarquer que le serveur Samba 2.2.2 est enregistré sur le domaine comme étant une machine normale : ceci est nécessaire pour une communication entre les deux serveurs Samba.

Limitations

Actuellement ce système d’authentification présente plusieurs problèmes : la synchronisation des mots de passe se fait dans une seule direction. En changeant son propre mot de passe depuis Windows, on n’aura pas changé le mot de passe sous Unix, alors qu’en effectuant la même opération sous Unix le mot de passe Windows sera lui aussi changé. Ceci ne pose pas de problèmes si la plate-forme principale est Unix.

Et les Mac dans tout ça ? Malheureusement nous ne disposons d’aucune machine Mac ou MacOS X pour tester notre implémentation, donc nous ne pouvons pas émettre d’avis.

Il est donc tout à fait possible de faire cohabiter plusieurs systèmes d’exploitation et d’avoir une identité unique sur tout le réseau, sans devoir débourser de grosses sommes d’argent et sans mettre en oeuvre du matériel complexe. Il est vrai que Samba-TNG n’est pas ce qu’il y a de plus performant en matière de contrôleur de domaine, mais pour un réseau relativement petit il se défend assez bien. Il s’améliore de version en version, et son but est de pouvoir remplacer complètement une machine Windows 2000 Server pour la gestion d’un domaine.

Le système LDAP s’est avéré globalement un excellent choix pour la gestion centralisée des utilisateurs et des machines : plus besoin de se rappeler d’un mot de passe différent sur chaque machine et, surtout, il a permis l’intégration de stations de travail Windows 2000 / XP dans un réseau Unix.

Quelques jours avant la clôture de la rédaction de cet article une nouvelle version de Samba (branche classique, version 2.2.3) a été publiée. Parmi les nouveautés remarquables il faut citer le support LDAP amélioré. Nous n’avons pas encore eu le temps de l’essayer mais ceci est prévu sous peu. Pour ce qui concerne la version TNG, il n’y a pas de nouvelles releases mais on peut suivre le développement via CVS.

Références

  1. http://www.linux.org
  2. http://www.freebsd.org
  3. Le client s’appelle Nisgina (http://www.ldv.ei.tum.de/software/nisgina/). Nous ne savons pas quelles sont ses performances, ni si il marche vraiment !
  4. http://www.openldap.org
  5. http://www.samba.org ou http://samba.epfl.ch
  6. http://www.samba-tng.org
  7. http://www.mami.net/univr/tng-ldap/howto/
  8. http://www.deschner.de/gd/dual_samba.html


Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.