Vous êtes sur la page 1sur 48

Mise en place d’une solution LTSP et Windows Terminal Server

Didier SEGURA, Antoine LABAUD

20 f´evrier 2007

Table des mati`eres

1 Introduction

3

1.1 Pr´esentation du TER

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3

1.2 LTSP : qu’est-ce que c’est ?

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

3

1.3 Terminal Server : qu’est ce que c’est ?

.

.

.

.

.

.

.

.

.

.

.

.

.

3

1.4 Solution

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

4

2 Principe de fonctionnement

 

5

2.1 D´efinir les ressources appropri´ees

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

6

2.1.1 Une quantit´e de m´emoire vive appropri´ee

.

.

.

.

.

.

.

6

2.1.2 Un r´eseau bien dimensionn´e

 

6

2.2 Les diff´erentes ´etapes du d´emarrage d’un client l´eger .

.

.

.

.

6

2.3 Les m´ecanismes d’authentification

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

10

2.3.1 Authentification pour une session Windows .

.

.

.

.

.

11

2.3.2 Authentification pour une session Linux

 

.

.

.

.

.

.

.

.

12

3 Installation des serveurs

 

13

3.1 Pr´eliminaires

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

13

3.2 Installation du serveur LTSP

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

13

3.3 Installation du serveur Windows 2003

.

.

.

.

.

.

.

.

.

.

.

.

.

14

4 Le serveur Terminal Serveur

 

15

4.1 Configuration de l’Active Directory

 

15

4.2 Configuration des profils itin´erants

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

17

4.3 Configuration du Terminal Server

 

18

5 Le serveur LTSP

 

19

5.1 Configuration du service DHCP

 

19

5.2 Configuration du service LTSP

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

21

5.2.1

Modification du fichier lts.conf

.

.

.

.

.

.

.

.

.

.

.

.

.

21

6 Int´egration du serveur LTSP au domaine Active Directory 24

6.1 Qu’est-ce que Winbind ?

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

24

6.2 Configuration du serveur SAMBA

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

25

6.2.1

Installation de SAMBA et de Winbind

 

25

1

6.2.2

Modification du fichier /etc/smb.conf

 

.

.

.

.

.

.

.

.

.

25

6.3 Installation du client Kerberos

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

26

6.4 Int´egration du serveur LTSP `a l’Active Directory

.

.

.

.

.

.

.

28

6.5 Configuration de Winbind

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

29

6.5.1 Le fichier nsswitch.conf

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

29

6.5.2 Le module PAM

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

30

6.5.3 Les 4 groupes de modules

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

30

6.5.4 Les indicateurs de contrˆole de PAM

.

.

.

.

.

.

.

.

.

.

31

6.5.5 Configuration du fichier /etc/pam.d/login

 

31

6.5.6 Configuration du fichier /etc/pam.d/system-auth

 

32

6.5.7 Configuration du fichier /etc/security/pam mount.conf

32

6.6 Gestion des mots de passe des utilisateurs

 

.

.

.

.

.

.

.

.

.

.

.

33

6.6.1

Changement d’un mot de passe

 

33

7 Supervision du r´eseau SNMP

 

35

7.1 Installation de Cacti

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

35

7.2 Configuration de Cacti

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

35

7.2.1 Configuration du serveur MySQL

 

36

7.2.2 Configuration du fichier /usr/share/cacti

 

.

.

.

.

.

.

.

36

7.2.3 Programmation de la r´ecup´eration des statistiques :

 
 

Crontab

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

37

7.2.4 Administration et supervision des serveurs

 

37

8 Installation d’un PROXY

 

41

8.1 Pr´esentation du service Squid

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

41

8.2 Configuration du service Squid

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

42

8.3 Configuration de SquidGuard

 

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

.

44

2

Chapitre 1

Introduction

1.1 Pr´esentation du TER

Le but du TER est la mise en place d’une solution permettant l’utilisa- tion de machines obsol`etes au sein d’un r´eseau. Cette mise en oeuvre utilisera un serveur Linux LTSP ainsi qu’un serveur Windows 2003 avec le service Terminal Serveur. L’utilisateur final devra pouvoir basculer dans l’envi- ronnement de son choix, `a savoir Linux ou Windows, grˆace `a une simple combinaison de touches, le tout sans red´emarrage. L’administration du parc doit, pour des raisons de commodit´e, ˆetre centralis´ee et unique.

1.2 LTSP : qu’est-ce que c’est ?

LTSP est l’abr´eviation de « Linux Terminal Server Project » ou projet de serveur de terminaux Linux. C’est une suite logicielle qui permet de fournir des environnements identiques `a plusieurs stations de travail. Tous ces environnements sont ´ex´ecut´es par le serveur, ce qui permet de recycler de vieilles machines en les convertissant en terminaux X. Cela r´eduit les coˆuts et la maintenance, surtout dans un milieu o`u chaque station doit avoir le mˆeme environnement de travail (´ecoles, entreprises,

1.3 Terminal Server : qu’est ce que c’est ?

C’est un ensemble de logiciels qui permet `a plusieurs membres du r´eseau d’ex´ecuter des programmes directement sur le serveur plutˆot que sur leurs propres postes, baptis´es `a l’occasion clients l´egers. En effet, l’utilisateur a l’impression d’utiliser les applications du serveur comme si elles ´etaient sur son propre poste. En r´ealit´e, ces applications sont ex´ecut´ees sur le serveur et affich´ees sur le poste client par l’interm´ediaire d’une fenˆetre. Tous les traitements li´es `a l’application sont effectu´es sur le serveur. Le poste client se contente d’afficher des images transmises par le serveur. Cet outil pr´esente un

3

int´erˆet majeur li´e `a une r´eduction importante de l’administration. La gestion est centralis´ee. A la diff´erence du syst`eme LTSP, le client l´eger Terminal serveur n´ecessite un syst`eme d’exploitation pour ex´ecuter le programme TSE. LTSP, quant `a lui, charge un syst`eme d’exploitation l´eger sur le client par le biais du r´eseau.

1.4

Solution

La solution que nous avons ´etudi´ee consiste `a ex´ecuter un client l´eger Terminal Serveur sur un terminal X charg´e par LTSP. Un client l´eger d´emarrera par le r´eseau en PXE 1 si la carte r´eseau le permet. Le syst`eme d’exploitation lui sera envoy´e par TFTP 2 grˆace au partage NFS 3 au niveau du serveur. Seul le serveur ex´ecutera des tˆaches, tous les clients l´egers ne feront qu’effectuer des requˆetes d’entr´ees (clavier, souris) et des affichages. Lorsque l’utilisateur d´esirera ouvrir une session Windows, il lui suffira d’utiliser le client l´eger Terminal Serveur. L’utilisation telle quelle de syst`emes Linux et Windows sur le mˆeme r´eseau n´ecessite une gestion s´epar´ee des comptes utilisateurs. Pour y rem´edier, les comptes des utilisa- teurs sous les diff´erents syst`emes devront ˆetre synchronis´es. Nous utiliserons pour cela l’annuaire Active Directory pour la gestion ainsi que l’outil Winbind pour la synchronisation.

1 Le boot PXE est un acronyme pour ”Preboot Execution Environment” (Environne- ment d’Ex´ecution Avant le boot). PXE est une technologie qui est utilis´ee pour d´emarrer un PC `a distance `a travers un r´eseau. PXE est support´e par le syst`eme BIOS mais la carte r´eseau doit ´egalement supporter cette fonctionnalit´e. Lorsqu’un client l´eger est d´emarr´e, il ne poss`ede aucun syst`eme d’exploitation. S’il est ´equip´e d’une carte r´eseau avec PXE, il va pouvoir communiquer avec un serveur LTSP. Le serveur lui fournira une adresse IP grˆace au service DHCP qui tourne sur l’interface eth0 (LAN). Apr´es l’obtention d’une adresse IP, le client t´el´echargera le noyau Linux fournit par le TFTP. Une fois le noyau charg´e. Le client l´eger va acc´eder `a une arborescence distante, via le r´eseau, pour monter le syst`eme de base. 2 Trivial File Transfert Protocol ou Protocole simplifi´e de transfert de fichiers 3 Network File System, signifiant Syst`eme de fichiers en r´eseau

4

Chapitre 2

Principe de fonctionnement

Avant de mettre en place une telle solution, il est important de connaˆıtre les ressources dont nous avons besoin pour faire fonctionner le tout de mani`ere optimale. Tout d’abord voici l’architecture r´eseau que nous avons utilis´ee pour r´ealiser le projet :

r´eseau que nous avons utilis´ee pour r´ealiser le projet : Fig. 2.1 – Architecture de notre

Fig. 2.1 – Architecture de notre r´eseau

5

2.1 D´efinir les ressources appropri´ees

2.1.1 Une quantit´e de m´emoire vive appropri´ee

Le service LTSP est un gros consommateur de m´emoire vive. La quantit´e de m´emoire vive n´ecessaire est variable et d´epend du nombre de machines `a g´erer. Elle se calcule de la mani`ere suivante :

M´emoire totale = 256Mo + ( 50Mo * nombre de terminaux ) La m´emoire est donc un facteur limitant pour l’emploi de ces technologies. Il faudra pr´evoir une quantit´e de RAM en fonction de la taille du parc que l’on souhaite mettre en place.

2.1.2 Un r´eseau bien dimensionn´e

Dans notre environnement LTSP, chaque client l´eger est connect´e au switch, qui est lui mˆeme connect´e au serveur. Cela signifie que tout le trafic r´eseau se fait entre le switch et le serveur. Il faut donc mettre en place un lien le plus rapide possible entre le switch et le serveur pour que le r´eseau ne soit pas un facteur limitant. Pour une utilisation en production il sera donc crucial d’adapter les perfor- mances du r´eseau en fonction de l’utilisation souhait´ee. Un lien minimum de 1Gbit vers le serveur ainsi qu’un lien `a 100Mbit vers chaque client l´eger est conseill´e pour une utilisation fluide.

2.2 Les diff´erentes ´etapes du d´emarrage d’un client l´eger

Nous allons vous pr´esenter les diff´erentes ´etapes du chargement du syst`eme `a partir d’un client l´eger. Ces ´etapes d´ecrites en d´etails ci-dessous permettent de mieux assimiler le fonctionnement de l’int´eraction Client/Serveur LTSP.

1. La premi`ere ´etape est le chargement du noyau Linux en m´emoire du client l´eger. Ceci est r´ealis´e par le biais du r´eseau grˆace `a un bootrom (ou Etherboot) contenu dans la carte r´eseau, le PXE. Celui-ci ´emet tout d’abord une requˆete DHCP pour configurer son interface r´eseau, puis t´el´echarge le noyau Linux se trouvant sur le serveur TFTP.

2. Une fois le noyau Linux charg´e dans la m´emoire du client l´eger, il commence `a s’ex´ecuter.

6

3. Le noyau va initialiser l’ensemble du syst`eme et de tous les p´eriph´eriques qu’il peut reconnaˆıtre.

4. Pendant le chargement du noyau, une image de disque virtuel est ´egalement charg´ee en m´emoire du client l´eger. Un argument de la ligne de commande root=/dev/ram0 du fichier de configuration demande au noyau de monter cette image comme racine de son syst`eme de fi- chiers.

5. Le script /linuxrc s’ex´ecute alors et commence par un balayage (scan) du bus PCI du client l´eger dans le but de rechercher une carte r´eseau. Chaque composant PCI trouv´e est compar´e aux descriptions stock´ees dans le fichier /etc/niclist. En cas d’´egalit´e, le nom du module-driver correspondant `a la carte r´eseau trouv´ee est renvoy´e par le script, et ce module est charg´e en m´emoire.

6. Un petit module client DHCP appel´e dhclient est ensuite lanc´e. Il lance une nouvelle requˆete au serveur DHCP. Cette requˆete est n´ecessaire pour r´ecup´erer des informations n´ecessaires au syst`eme Li- nux que la premi`ere requˆete du bootrom ne pouvait retourner.

7. Lorsque le dhclient re¸coit une r´eponse du serveur, il ex´ecute le script /etc/dhclient-script. Ce script r´ecup`ere les informations renvoy´ees et configure l’interface eth0.

8. Jusqu’`a cette ´etape, le syst`eme de fichiers ´etait un disque virtuel en RAM. Le script /linuxrc va maintenant monter un nouveau syst`eme de fichiers sur sa racine (root) via NFS. Le r´epertoire export´e par NFS depuis le serveur vers le client l´eger est en principe /opt/ltsp/i386. Cette op´eration ne peut ˆetre r´ealis´ee en montant directement ce r´epertoire sur /. Il doit d’abord ˆetre mont´e sur /mnt, puis la commande pi- vot root est lanc´ee. pivot root va ´echanger la racine courante (le disque virtuel) avec le nouveau syst`eme de fichiers. Lorsque cela est termin´e, le r´epertoire export´e par NFS est mont´e sur / et l’ancienne racine est mont´ee sur /oldroot.

9. Une fois le montage et l’´echange de racine effectu´es, le script /linuxrc a termin´e son travail. Le programme /sbin/init s’ex´ecute alors. Init va lire le fichier /etc/inittab et mettre en place l’environnement du client l´eger.

10. Le script rc.sysinit cr´ee un nouveau disque virtuel en m´emoire (ram- disk) de 1 Mo, destin´e `a contenir toutes les donn´ees et informations de-

7

vant ˆetre ´ecrites ou modifi´ees par la suite (disque en lecture/´ecriture). Ce disque virtuel est mont´e en tant que /tmp sur le syst`eme de fi- chiers local du client l´eger.

11. Le fichier lts.conf est examin´e, et tous les param`etres en rapport avec

le client l´eger en cours d’initialisation sont export´es comme variables

d’environnement. Le script rc.sysinit les utilisera par la suite.

12. L’interface r´eseau loopback est ensuite configur´ee. Il s’agit de l’inter- face ”interne” ayant pour adresse IP 127.0.0.1.

13. Si l’ex´ecution locale d’applications est activ´ee, le r´epertoire /home du serveur est export´e via NFS pour ˆetre mont´e sur le r´epertoire /home du client l´eger, afin que les applications puissent avoir acc`es aux r´epertoires personnels des utilisateurs.

14. Lorsque le script rc.sysinit est termin´e, le contrˆole revient au pro- gramme /sbin/init, qui va alors changer le niveau d’ex´ecution (run- level) de sysinit `a 5. Ceci aura pour effet de lancer toutes les autres commandes sp´ecifi´ees dans le fichier /etc/inittab.

15. Par d´efaut, le fichier inittab contient des lignes demandant l’ex´ecution du script /etc/screen session sur tty1, tty2 et tty3 (Terminaux in- ternes). Il est donc possible d’utiliser trois sessions simultan´ees sur le client l´eger. Le type de ces sessions est contrˆol´e par les param`etres SCREEN 01, SCREEN 02 et SCREEN 03 que l’on trouve dans le fi- chier de configuration lts.conf de LTSP.

16. Si le param`etre SCREEN 01 de lts.conf a pour valeur startx, le script /etc/screen.d/startx est ex´ecut´e, ce qui lancera l’interface graphique XWindow sur le client l´eger.

17. Dans le fichier lts.conf, il existe un param`etre appel´e XSERVER.

Si ce param`etre est absent, ou a pour valeur ”auto”, le script startx

tente de d´etecter automatiquement quelle est la carte vid´eo du client l´eger.

18. Le fichier XF86Config est cr´e´e en fonction des param`etres trouv´es dans le fichier de configuration /etc/lts.conf.

19. Une fois le fichier XF86Config cr´e´e, le script startx lance le serveur

X correspondant avec ce nouveau fichier de configuration.

8

20. Le serveur X lance alors une requˆete XDMCP 1 au serveur LTSP, qui ouvre un ´ecran de login.

21. Arriv´e `a ce stade, l’utilisateur peut s’identifier et se connecter (login) au serveur. Une fois authentifi´e, l’utilisateur a enfin acc`es `a une nou- velle session graphique sur le serveur et `a tous les programmes install´es sur ce dernier.

Une fois l’utilisateur authentifi´e, tous les programmes seront ex´ecut´es sur le serveur, et seule leur sortie sera affich´ee sur l’´ecran du client l´eger. Toutes les ressources n´ecessaires `a l’utilisation du syst`eme seront donc `a la charge du serveur LTSP. C’est l’avantage d’une telle solution : la possibilit´e de recycler un vieux parc informatique `a moindre coˆut, `a condition d’avoir un serveur LTSP suffisamment puissant et un r´eseau local robuste.

1 X Display Manager Control Protocol (XDMCP) permet d’acc´eder `a un ordinateur distant en utilisant son environnement graphique

9

2.3 Les m´ecanismes d’authentification

Voici une vue globale du m´ecanisme d’authentification lorsqu’un utilisateur souhaite se connecter `a une session Linux, ou `a une session Windows Ter- minal Server. La seule et unique base de donn´ees est l’Active Directory, il contient tous les utilisateurs et leurs mots de passe. Ainsi, on peut uni- formiser l’acc`es `a des ressources partag´ees (dossiers, lecteurs, imprimantes, etc) sous diff´erents syst`emes d’exploitation, grˆace `a une gestion centralis´ee des utilisateurs et des mots de passe.

`a une gestion centralis´ee des utilisateurs et des mots de passe. Fig. 2.2 – Principe d’authentification

Fig. 2.2 – Principe d’authentification

10

2.3.1 Authentification pour une session Windows

2.3.1 Authentification pour une session Windows Fig. 2.3 – M´ecanisme d’authentification pour une session Windows

Fig. 2.3 – M´ecanisme d’authentification pour une session Windows

On voit ici les diff´erents protocoles qui entrent en jeu lorsqu’un client l´eger est d´emarr´e. Pour ouvrir une session Windows, il faut donc d´ej`a avoir va- lid´e la premi`ere ´etape qui est le d´emarrage du client l´eger (chargement du noyau Linux)(avec NFS) jusqu’au chargement complet du syst`eme distant Serveur X compris (XDMCP) . Il suffit ensuite de faire CTRL + ALT + F2 pour lancer le script ”rdesktop” 2 . On lance alors une communication utilisant le protocole RDP vers le Ter- minal Server Windows 2003. Le m´ecanisme d’authentification est donc simplement celui qui est propre `a Windows, c’est `a dire une v´erification du compte utilisateur au sein de l’Active Directory.

11

2.3.2 Authentification pour une session Linux

2.3.2 Authentification pour une session Linux Fig. 2.4 – M´ecanisme d’authentification pour une session Linux Le

Fig. 2.4 – M´ecanisme d’authentification pour une session Linux

Le m´ecanisme d’authentification pour une session Linux utilise Win- bind. Nous d´etaillerons par la suite le fonctionnement de Winbind. Sachez pour le moment que le serveur LTSP en utilisant Winbind, r´ecup`ere les comptes des utilisateurs de l’Active Directory dans son environnement. Il importe en quelque sorte les comptes utilisateurs, tout en laissant la charge de l’authentification `a l’Active Directory. Ainsi, lorsqu’un utilisateur veut se connecter dans une session Linux, une demande est envoy´ee au serveur LTSP qui la transmet imm´ediatement `a l’Active Directory. Si la r´eponse est positive, l’utilisateur est authentifi´e.

12

Chapitre 3

Installation des serveurs

3.1 Pr´eliminaires

L’adresse IP globale de notre r´eseau est 192.168.0.0/24. Le serveur LTSP se verra attribuer l’adresse 192.168.0.1 pour le r´eseau local et une adresse attribu´ee dynamiquement pour l’interface WAN (ex : DHCP par fournisseur d’acc`es Internet). Nous avons choisi um2.local comme nom de domaine et le contrˆoleur de domaine sera le serveur Windows 2003. Son adresse IP sera 192.168.0.2. Le mat´eriel utilis´e nous a ´et´e prˆet´e par le LIRMM. Les deux serveurs sont des Pentiums IV 2,8 Ghz, avec 512 Mo de DDR, et 80 Go pour le disque dur. Ces machines sont suffisantes pour la mise en place d’une maquette, mais nous verrons que les services sont gourmands en ressources, et que pour un parc informatique important, l’emploi de serveurs plus puissants est requis.

3.2 Installation du serveur LTSP

Apr`es avoir test´e diff´erentes distributions, dont notamment la prom´eteuse Edubuntu (bas´ee sur un syst`eme Debian) nous nous sommes aper¸cus que les scripts nous permettant d’utiliser le service Terminal Server `a par- tir des clients l´egers ne fonctionnaient pas. Nous avons donc cherch´e une distribution int´egrant un environnement LTSP pr´econfigur´e et permettant d’exploiter l’utilitaire rdesktop en natif. Notre choix s’est finalement port´e sur une distribution Redhat `a savoir la Fedora Core 5, int´egrant d´ej`a l’en- vironnement LTSP et l’outil rdesktop pour les connexions vers les serveurs Terminal Server. Nous ne d´etaillerons pas l’installation proprement dite d’une Fedora Core 5. Elle est tout ce qu’il y a de plus classique, et de plus largement docu- ment´ee sur Internet. Nous noterons seulement que, lors de l’installation, il est n´ecessaire de s´electionner l’option ”Installer un serveur LTSP”. La configuration des interfaces r´eseaux se fait en accord avec la configuration

13

du r´eseau que nous avons ´enonc´ee plus haut dans les ”pr´eliminaires”. Pour que notre serveur LTSP fonctionne, il nous faut ´egalement mettre en place diff´erents services notamment :

XDMCP : XDMCP permet d’acc´eder `a un ordinateur distant utili- sant son environnement graphique comme si vous ´etiez connect´e di- rectement dessus.

DHCP : DHCP est un protocole de configuration automatique pour les ordinateurs utilisant TCP/IP, utilis´e par LTSP pour assigner les adresses IP aux stations.

NFS : NFS est un protocole permettant l’acc`es `a un disque dur distant via le r´eseau qui est utilis´e par LTSP pour monter un syst`eme de base sur les stations.

TFTP : TFTP est un protocole simple de transfert de fichiers qui est utilis´e par LTSP pour transf´erer le noyau de d´emarrage aux stations. Nous d´etaillerons ces services un peu plus bas.

3.3 Installation du serveur Windows 2003

Pour assurer les fonctionnalit´es Terminal Server, il est n´ecessaire d’ins- taller un Windows serveur, dans notre cas Windows 2003 en version En- treprise. Nous avons ensuite param´etr´e le serveur pour qu’il soit Contrˆoleur du domaine ’UM2.local’. Nous avons ensuite rajout´e le rˆole ”Terminal Server”. Ci-dessous se trouvent les d´etails importants de l’installation.

14

Chapitre 4

Le serveur Terminal Serveur

4.1 Configuration de l’Active Directory

Terminal Serveur 4.1 Configuration de l’Active Directory Fig. 4.1 – Installation de l’Active Directory

Fig. 4.1 – Installation de l’Active Directory

L’installation du rˆole Active Directory commence en cliquant sur D´emarrer Outils d’Administration G´erer votre serveur. Cela lance l’as- sistant de gestion du serveur. Il faut ensuite suivre l’assistant comme indiqu´e ci-dessous :

15

– ”Ajouter ou Supprimer un rˆole” et cliquer sur ”Suivant”.

– S´electionner ”Configuration Personnalis´ee” et cliquer sur ”Suivant”.

– S´electionner ”Controleur de Domaine (Active Directory)” et cliquer sur ”Suivant”.

– Cliquer sur ”Suivant” jusqu’`a temps d’arriver sur l’”Assistant d’Ins- tallation Active Directory”. S’assurer que ”Contrˆoleur de do- maine pour un nouveau domaine” soit s´electionn´e et cliquer sur

Suivant”.

– Cliquer sur ”Suivant” pour cr´eer un nouveau ”Domaine dans une forˆet”.

– Choisissez UM2.local comme nouveau domaine et cliquer sur ”Suivant”. Garder ”UM2” comme nom de domaine netbios et cliquer sur ”Suivant” jusqu’`a ”DNS Registration Diagnostics”.

– Choisissez ”Installer et configurer un serveur DNS sur cet or- dinateur, et configurer cet ordinateur pour utiliser ce serveur DNS comme serveur DNS pr´efer´e” et cliquer sur ”Suivant”.

– Garder les param`etres par d´efaut pour ”Permissions” et cliquer sur

Suivant”.

– Donner un mot de passe `a utiliser pour le Mode de Restauration Ac- tive Directory et cliquer sur ”Suivant” jusqu’`a ce que l’installation

commence.

– Cliquer sur ”Terminer” et red´emarrer votre ordinateur.

– Apr`es le red´emarrage, l’assistant vous informe que votre serveur est maintenant contrˆoleur de domaine. Cliquer sur ”Terminer

.

16

4.2 Configuration des profils itin´erants

4.2 Configuration des profils itin´erants Fig. 4.2 – Configuration des profils itin´erants Pour pouvoir utiliser

Fig. 4.2 – Configuration des profils itin´erants

Pour pouvoir utiliser un syst`eme de profils itin´erants, nous avons tout d’abord cr´e´e un r´epertoire destin´e au stockage des comptes de nos utilisa- teurs. Celui ci est nomm´e ltsp et il est partag´e entre tous les utilisateurs qui ont un acc´es total. Ces utilisateurs font tous partie du groupe ”Utilisateurs du Domaine”. Attention, ils ont un acc´es total sur le r´epertoire, mais pas sur son contenu ! On place ensuite le fichier logon.bat dans le r´epertoire netlogon en par- tage sur le serveur Windows 2003. Ce fichier va nous permettre de monter le r´epertoire personel Linux propre `a chaque utilisateur, et l’acc`es `a un espace commun `a tous les utilisateurs pour autoriser l’´echange de fichiers par exemple.

logon.bat :

@echo off net use y : ”\\ltsp\UM2\%USERNAME%” net use h : ”\\exchange-um2\commun”

On peut ensuite cr´eer autant d’utilisateurs que l’on veut en cliquant sur D´emarrer Outil d’Administration Utilisateurs et ordinateurs Active Directory. Voici la proc´edure de cr´eation d’un nouvel utilisateur avec un profil itin´erant :

17

– Developper ”um2.local” et faire un clic droit sur ”Utilisateur” puis Nouveau Utilisateur

– Une fois que l’utilisateur est cr´e´e, faire un clic droit dessus et ”Propri´et´es

– Dans l’onglet ”Profil” , assurez-vous que vous avez ce qui suit :

– Chemin du Profil : \\nom ou IP du serveur AD\ltsp\%USERNAME%

– Script d’ouverture de session : logon

– Connecter en Z :

– To : \\nom ou IP du serveur AD\ltsp\%USERNAME%

– Cliquer sur ”OK” et si vous avez un message qui vous dit de cr´eer le dossier manuellement, alors cliquer sur ”OK

4.3 Configuration du Terminal Server

Afin d’utiliser le service Terminal Serveur, il est n´ecessaire de l’ins- taller. Cela s’effectue grˆace `a l’assistant de gestion du serveur (cliquer sur D´emarrer Outils d’Administration G´erer votre Serveur). Il faut ensuite suivre l’assistant comme pr´ecis´e ci-dessous :

– ”Ajouter ou Supprimer un rˆole” et cliquer sur ”Suivant

– S´electionner ”Configuration personnalis´ee” et cliquer sur ”Suivant

– S´electionner ”Terminal server” et cliquer sur ”Suivant

– Cliquer sur ”Suivant” pour commencer l’installation du service ter- minal. Si l’assistant vous demande de fermer les programmes ouverts, faites-le et cliquez sur ”OK

Par d´efaut l’utilisation de Terminal Serveur est limit´ee `a 120 jours. Pour une utilisation prolong´ee, il est n´ecessaire d’acqu´erir des licences ”tscal”. En effet, apr`es le red´emarrage, l’assistant vous avertit qu’il arrˆetera d’ac- cepter les connexions des clients non licenci´es au bout de 120 jours. Chaque client devra alors poss`eder sa licence ”tscal” pour pouvoir se connecter au Terminal Server. Pour une utilisation en production, il sera n´ecessaire d’installer un serveur de licence et d’acheter ces ”tscal”.

18

Chapitre 5

Le serveur LTSP

5.1 Configuration du service DHCP

LTSP n´ecessite pour le d´emarrage d’un serveur DHCP. Celui-ci va fournir une adresse IP aux clients mais va ´egalement les renseigner sur les adresses du routeur, du serveur DNS, du serveur TFTP et le chemin du r´epertoire `a t´el´echarger. Fichier de configuration du DHCP /etc/dhcp/dhcpd.conf :

default-lease-time 21600 ; max-lease-time 21600 ; ddns-update-style none ; allow booting ; allow bootp ; option subnet-mask 255.255.255.0 ; option broadcast-address 192.168.0.255 ; option routers 192.168.0.1 ; option domain-name-servers 192.168.0.1 ; next-server 192.168.0.1 ; option domain-name ”um2.local” ; option root-path ”192.168.0.1 :/opt/ltsp/i386” ; option option-128 code 128 = string ; option option-129 code 129 = text ; option option-221 code 221 = text ; authoritative ;

shared-network WORKSTATIONS {

subnet 192.168.0.0 netmask 255.255.255.0 {

range dynamic-bootp 192.168.0.100 192.168.0.150 ;

19

use-host-decl-names on ; option log-servers 192.168.0.1 ;

if substring (option vendor-class-identifier, 0, 9) = ”AAPLBSDPC”

{

filename ”yaboot” ;

option vendor-class-identifier ”AAPLBSDPC” ;

}

elsif substring (option option-221, 0, 5) = ”Apple”

{

filename ”yaboot” ;

option vendor-class-identifier ”AAPLBSDPC” ;

}

#

Intel PXE

elsif substring (option vendor-class-identifier, 0, 9) =”PXEClient”

{

#

NOTE : kernels are specified in

/tftpboot/lts/pxe/pxelinux.cfg/ filename ”/lts/pxe/pxelinux.0” ;

}

#

default to an i386 BOOTP image

else

{

filename ”/lts/vmlinuz.ltsp” ;

}

if substring (option vendor-class-identifier, 20, 3) = ”ppc” { option root-path ”192.168.0.1 :/opt/ltsp/ppc” ;

}

else {

option root-path ”192.168.0.1 :/opt/ltsp/i386” ;

}

}

}

On a d´efini ici une plage d’adresses IP pour les clients l´egers comprise entre 192.168.0.100 et 192.168.0.150. La passerelle par d´efaut pour les clients l´egers sera 192.168.0.1, et le domaine sera ”um2.local”. Le serveur DHCP est capable de d´etecter `a quel type de poste client il a affaire, PC

20

ou Power PC. Selon le mod`ele de la carte r´eseau, par le biais de l’adresse MAC, il est en effet capable de d´eterminer quel est le type d’architecture du client. En cons´equence, il indiquera au client le chemin des fichiers `a t´el´echarger sur le serveur TFTP. Notre serveur LTSP est donc multi-plateformes, on pourra faire d´emarrer une machine MAC (ancien iMac par exemple) par le r´eseau. Le syst`eme Linux sera bas´e sur l’architecture PPC, et non l’architecture i386 r´eserv´ee `a des processeurs type Intel.

5.2 Configuration du service LTSP

Maintenant, nous devons configurer le service LTSP pour que les ma- chines clientes puissent obtenir un ´ecran de connexion Windows (en fai- sant CTRL + ALT + F2) ainsi qu’un ´ecran de connexion Linux (en faisant CTRL + ALT + F1). Cela s’effectue au travers du fichier ”/opt/ltsp/i386/etc/lts.conf ” sur le serveur LTSP.

5.2.1 Modification du fichier lts.conf

La configuration des param`etres des clients LTSP se fait dans les fichiers lts.conf. Il y a un fichier de configuration par architecture (PC ou PPC). Il existe beaucoup d’options pour configurer les clients l´egers. Ici nous avons d´efini de mani`ere g´en´erique une liste d’options que nous expliquerons. Le fichier lts.conf se trouve dans le r´epertoire /opt/ltsp/i386/etc/ pour l’ar- chitecture Intel. Il faudra aussi le modifier dans le r´epertoire /opt/ltsp/ppc/etc/ pour l’architecture PPC (iMac). Pour l’architecture i386, il faudra modifier le fichier de cette fa¸con :

[Default] SERVER = 192.168.0.1 XRAMPERC = 90 XSERVER = ”vesa” X4 MODULE 01 = glx X4 MODULE 02 = vnc

MODULE 01 = usb-uhci

MODULE 02 = mousedev

MODULE 03 = usbmouse

X

MOUSE PROTOCOL = ”auto”

X

USBMOUSE PROTOCOL = ”auto”

X

MOUSE DEVICE = ”/dev/psaux”

X

USBMOUSE DEVICE = ”/dev/input/mice”

21

X

MOUSE RESOLUTION = 400

X

USBMOUSE RESOLUTION = 400

X

MOUSE BUTTONS = 3

X

USBMOUSE BUTTONS = 3

USBEMULATE 3 BUTTONS = ”off”

XkbSymbols = ”fr(pc105)” XkbModel = ”pc105” XkbLayout = ”fr” USE XFS = N

LOCAL APPS = N

SCREEN 01 = startx

SCREEN 02 = rdesktop RDP SERVER = 192.168.0.2

RDP OPTIONS = -f -k fr -a 16 -d UM2

LOCAL STORAGE = Y

LTSPFSD OPTIONS=””

SNMPD = N SOUND = Y SOUND DAEMON = ”nasd”

VOLUME = 75

Pour l’architecture ppc, il faudra modifier le fichier de cette fa¸con :

[Default] SERVER = 192.168.0.1 XSERVER = ”nv” MODULE 01 = usb-uhci

MODULE 02 = mousedev

MODULE 03 = usbmouse

X

MOUSE PROTOCOL = ”auto”

X

USBMOUSE PROTOCOL = ”auto”

X

MOUSE DEVICE = ”/dev/psaux”

X

USBMOUSE DEVICE = ”/dev/input/mice”

X

MOUSE RESOLUTION = 400

X

USBMOUSE RESOLUTION = 400

X

MOUSE BUTTONS = 3

X

USBMOUSE BUTTONS = 3

USBEMULATE 3 BUTTONS = ”off”

XkbSymbols = ”fr(pc105)” XkbModel = ”pc105” XkbLayout = ”fr” USE XFS = N

LOCAL APPS = N

SCREEN 01 = startx

22

LOCAL STORAGE = Y

LTSPFSD OPTIONS=””

SNMPD = N SOUND = Y SOUND DAEMON = ”nasd”

VOLUME = 75

Le param`etre SERVER indique le serveur LTSP que l’on va utiliser pour le chargement du serveur X. Le param`etre XSERVER permet de d´efinir le pilote de la carte graphique de la machine cliente que l’on va charger en m´emoire. Nous l’avons forc´e `a VESA pour des raisons de compatibilit´e avec toutes les machines clientes, mais il est possible de fixer sa valeur `a ”AUTO”.

Des modules graphiques peuvent ˆetre ´egalement charg´es, comme GLX, ou VNC dans les champs X4 MODULE 0X. GLX permet par exemple d’exploiter l’acc´el´eration 3D dans certaines applications. On peut sp´ecifier le type de clavier qu’on va utiliser. Ceci se fait en d´efinissant les param`etres XkbSymbols = ”fr(pc105)”,XkbModel = ”pc105” et XkbLayout = ”fr”.

Les param`etres SCREEN 0X permettent de sp´ecifier des scripts sur chaque touche FX (o`u X est le num´ero de la touche). Ainsi pour se connec- ter sur une session Windows en Terminal Server, il suffit de faire CTRL + ALT + F2 pour basculer sous Windows. Et pour revenir dans une ses- sion Linux, il suffit de faire CTRL + ALT + F1. Les param`etres RDP permettent de sp´ecifier quel serveur TSE nous allons utiliser. Ici, nous utilisons le serveur 192.168.0.2. Le param`etre RDP OPTIONS sp´eficie les options `a passer comme arguments au script rdesktop. Ici, nous lui sp´ecifions que nous voulons un affichage plein ´ecran (-f), un clavier en fran¸cais (-k fr), que nous souhaitons un affichage en seize millions de cou- leurs (-a 16) et que le domaine est UM2. Il est possible d’activer l’agent SNMP sur tous les clients l´egers pour super- viser l’ensemble du r´eseau, pour cela il suffit d’activer le param`etre SNMPD `a Y.

Pour l’architecture PPC, le script rdesktop ne fonctionne pas, et il de- vient impossible de basculer directement dans une session Windows. Le probl`eme vient d’une incompatibilit´e du serveur graphique X11. Il est ce- pendant possible de se connecter `a une session Terminal Serveur sous son environnement Linux avec le logiciel tsclient.

23

Chapitre 6

Int´egration du serveur LTSP au domaine Active Directory

Active Directory est au coeur des syst`emes Microsoft Windows, c’est lui qui est en charge de la gestion des comptes utilisateurs, des authen- tifications, mais aussi d’un grand nombre de ressources. Active Directory repose sur diff´erents protocoles r´eseaux :

DNS (r´esolution de noms)

LDAP (interrogation de l’annuaire)

Kerberos V (authentification, distribution de tickets)

NTP (synchronisation date et heure des machines)

SMB/CIFS (partage des ressources)

Pour se connecter `a un contrˆoleur de domaine Windows 2003 Service Pack 1 depuis un poste UNIX, une version 3.0.14a de Winbind est n´ecessaire.

6.1 Qu’est-ce que Winbind ?

Winbind est une fonctionnalit´e de Samba permettant aux utilisateurs dont le compte est enregistr´e dans une base de donn´ees d’un domaine Win- dows (Active Directory) de s’authentifier sous un syst`eme UNIX. Ceci conduit `a un environnement unifi´e dans lequel un compte utilisateur peut ˆetre conserv´e soit sur un syst`eme UNIX, soit sur un contrˆoleur de domaine Windows NT/2000/XP. Il en r´esulte une plus grande facilit´e de gestion des comptes car les adminis- trateurs ne doivent plus faire attention `a la synchronisation et `a la coh´erences des syst`emes. Grˆace `a ce syst`eme, les utilisateurs ont la possibilit´e d’avoir acc`es `a des ressources partag´ees Linux ou Windows. Cela est rendu possible grˆace `a cette authentification et au fait que le serveur Linux est int´egr´e au domaine.

24

6.2 Configuration du serveur SAMBA

Voici un petit r´ecapitulatif de la configuration que nous avons utilis´ee :

– nom du domaine court : UM2

– nom du domaine long : UM2.local

– nom du contrˆoleur de domaine : echange-um2

– nom de la machine `a int´egrer : ltsp

– nom du compte administrateur : Administrateur

6.2.1 Installation de SAMBA et de Winbind

On va installer, si ce n’est pas d´ej`a fait par d´efaut, les paquetages samba et winbind sur le serveur LTSP.

yum install samba

yum install webmin

6.2.2 Modification du fichier /etc/smb.conf

Il faut savoir que pour r´ealiser cette op´eration, le respect des majuscules et des minuscules est important. La premi`ere ´etape consiste `a modifier la section ”[global]” du fichier /etc/samba/smb.conf

[global] security = ads idmap gid = 16777216-33554431 idmap uid = 16777216-33554431 workgroup = UM2 netbios name = LTSP server string = LTSP domain master = No encrypt passwords = true realm = UM2.LOCAL password server = exchange-um2.um2.local template homedir = /home/UM2/%U template shell = /bin/bash winbind enum users = Yes winbind enum groups = Yes

25

winbind use default domain = Yes winbind nested groups = Yes winbind separator = + pam password change = yes obey pam restrictions = yes socket options = TCP NODELAY SO RCVBUF=8192 SO SNDBUF=8192 client signing = Yes dns proxy = No os level = 20 max log size = 50 log level = 3 log file = /var/log/samba3/log.%m load printers = yes wins proxy = no wins support = true preferred master = no

Quelques explications concernant les param`etres sp´ecifi´es dans le fichier smb.conf. L’idmap uid assure les correspondances des UIDs entre le serveur Linux et Active Directory L’idmap gid assure les correspondances des GIDs entre le serveur Linux et Active Directory Le param`etre winbind enum user = yes permet de lister les utilisateurs au d´emarrage de Winbind Le param`etre winbind enum groups = yes permet de lister les groupes au d´emarrage de Winbind Le param`etre winbind separator = + sert `a sp´ecifier le caract`ere de s´eparation domaine/nom d’utilisateur (ex : DOMAINE+utilisateur) Le param`etre winbind use default domain = yes permet d’´eviter de saisir le nom de domaine `a chaque connexion d’un utilisateur. Ainsi, `a la place de saisir : UM2\didier, il suffira de saisir comme login : ”toto” car on utilisera le nom de domaine par d´efaut. Le param`etre template shell = /bin/bash permet de d´efinir le shell par d´efaut pour chaque utilisateur. Le param`etre template homedir = /home/UM2/%U d´efinit le r´epertoire home par d´efaut d’un utilisateur provenant d’un Active Directory. Le home est ici /home/UM2/%U, %U sera remplac´e automatiquement par le nom de login de l’utilisateur.

26

6.3 Installation du client Kerberos

Le protocole Kerberos est le protocole de s´ecurit´e principal par d´efaut pour les authentifications r´ealis´ees dans un domaine de type Windows

2000/2003.

Il permet aux utilisateurs d’acc´eder aux ressources r´eseau `a partir de la mˆeme ouverture de session. Le service Kerberos se trouve dans chaque contrˆoleur de domaine et les clients Kerberos sur les autres ordinateurs Windows.

Lorsqu’un utilisateur veut acc´eder `a un partage r´eseau, le service Kerbe- ros va v´erifier l’identit´e du client. Le client ne pourra confirmer son identit´e qu’en demandant au service Kerberos un ticket qui lui permettra de confir- mer son identit´e. Une fois le ticket re¸cu, l’utilisateur pourra alors acc´eder au service r´eseau voulu.

Le service Kerberos s’appelle le KDC (Key Distribution Center) et se trouve comme nous l’avons dit pr´ec´edemment dans chaque contrˆoleur de domaine qui stocke les informations relatives aux comptes. Le ticket ´emis au client par un KDC s’appelle un TGT (Ticket Granting Ticket). Le TGT permet au syst`eme client d’acc´eder au TGS (Ticket Granting Service) se trouvant dans le contrˆoleur de domaine. Ce TGS permettra l’´emission d’un ticket de service au client. C’est ce ticket de ser- vice que le client pr´esentera au service r´eseau demand´e.

Pour fonctionner avec notre contrˆoleur de domaine Active Directory, il nous faut donc installer un client Kerberos sur le serveur LTSP. Il est donc n´ecessaire de configurer un client Kerberos afin de valider l’iden- tit´e du serveur LTSP dans le r´eseau Microsoft. Celui-ci dialoguera avec le serveur AD pour effectuer des demandes de ”tickets” au KDC qui seront utilis´ees pour assurer l’authenticit´e et la s´ecurit´e des communications.

La configuration du client Kerberos du client Linux se fait dans le fi- chier /etc/krb5.conf. On obtient ceci :

[libdefaults] default realm = UM2.LOCAL

ticket lifetime = 24h

clockskew = 300 dns lookup realm = true dns lookup kdc = true forwardable = yes

[realms]

27

UM2.LOCAL = { kdc = 192.168.0.2 :88 admin server = 192.168.0.2 :749

default domain = 192.168.0.2

}

[domain realm] .um2.local = UM2.LOCAL um2.local = UM2.LOCAL [logging]

kdc = FILE :/var/log/krb5kdc.log admin server = FILE :/var/log/kadmin.log default = FILE :/var/log/krb5lib.log

La modification du fichier /etc/hosts est ´egalement essentielle afin de faire fonctionner Kerberos :

127.0.0.1 ltsp.um2.local ltsp

Il faut ensuite red´emarrer les services Samba et Winbind pour prendre en compte les modifications.

– samba : /etc/init.d/smb restart

– winbind : /etc/init.d/winbind restart

Pour cr´eer le compte machine et faire partie de Active Directory de Windows 2000/2003, Kerberos doit tout d’abord ˆetre initialis´e pour le serveur membre souhaitant faire partie du domaine Active Directory. Pour cr´eer un ticket administratif pour Kerberos, nous allons ex´ecuter ”kinit” afin d’obtenir un ticket et de le stocker dans un fichier cache de certificats d’identit´e :

kinit Administrateur Password for Administrateur@UM2.LOCAL : ****

Puis nous allons utiliser ”klist” afin de visualiser la liste des certificats d’identit´e dans le cache :

klist Ticket cache : FILE :/tmp/krb5cc 0 Default principal : Administrateur@UM2.LOCAL Valid starting Expires Service principal 01/05/07 18 :08 :43 01/06/07 18 :08 :43 krbtgt/UM2.LOCAL@UM2.LOCAL

28

On peut ensuite utiliser ”kdestroy” pour d´etruire le cache ainsi que les certificats qu’il contient.

6.4 Int´egration du serveur LTSP `a l’Active Direc- tory

Nous allons pouvoir maintenant rattacher le serveur LTSP au domaine Active Directory. Pour cela, il faut taper les commandes suivantes :

net ads join -U Administrateur Administrateur’s password : ******* Using short domain name – UM2 Joined ’LTSP’ to realm ’UM2.LOCAL’

Nous allons ensuite v´erifier que l’int´egration sur serveur LTSP a bien fonc- tionn´e. Voici quelques commandes que l’on peut utiliser apr`es int´egration d’un domaine :

- liste des utilisateurs du domaine :

wbinfo -u administrateur invit´e krbtgt didier antoine

- liste des groupes du domaine :

wbinfo -g BUILTIN+administrators BUILTIN+users

- v´erifier qu’un utilisateur en particulier soit correctement reconnu :

wbinfo -a didier%SonMotDePasse plaintext password authentication succeeded challenge/response password authentication succeeded

Maintenant que notre serveur LTSP est rattach´e `a notre domaine UM2, nous devons ´editer quelques fichiers pour que winbind fonctionne correc- tement. Winbind permet de ”mapper” les utilisateurs d’un domaine pour qu’ils soient accessibles par Samba, sans que les utilisateurs UNIX existent r´eellement.

29

6.5 Configuration de Winbind

6.5.1 Le fichier nsswitch.conf

L’int´erˆet de WinBind est de pouvoir ”importer” des comptes Active Directory au sein d’un environnement Linux. Il faut alors, dans le fichier ”/etc/nsswitch.conf ”, qui g`ere la base des utilisateurs du serveur LTSP sur des fichiers ou des bases de donn´ees locales, indiquer l’utilitaire Winbind qui va g´erer la transition de l’authentification avec l’Active Directory.

/etc/nsswitch.conf :

# Partie concernant la gestion des comptes passwd : files winbind shadow : files winbind groups : files winbind

Une fois la modification effectu´ee, nous allons relancer le service winbind. /etc/init.d/winbind restart

6.5.2 Le module PAM

PAM `a quoi ¸ca sert ?

Le syst`eme PAM est un ensemble de modules permettant de g´erer diff´erentes authentifications sur un syst`eme Linux. Chaque module cor- respond `a un mode d’authentification, ou permet des manipulations sur des comptes. Cela permet de rendre les diff´erents programmes n´ecessitant une authen- tification particuli`ere(login, su, ssh, kdm) ind´ependants de la base de donn´ees g´erant les comptes utilisateurs (passwd, LDAP, MySQL, Do- maine Windows avec Winbind).

6.5.3 Les 4 groupes de modules

Dans un fichier de configuration de PAM, nous allons retrouver les diff´erents modules r´epartis en quatre groupes (auth, account,password,session). Un module (par exemple : pam unix.so) pouvant ˆetre utilis´e dans plusieurs groupes.

Le groupe ”auth” sert `a l’authentification, il ´etablit en g´en´eral la corres- pondance entre l’utilisateur et le mot de passe.

30

Le groupe ”account” sert `a la v´erification du compte utilisateur. Est-ce que le mot de passe est encore valide ? Cet utilisateur a-t-il le droit d’acc´eder au service demand´e ? Le groupe ”password” permet par exemple d’autoriser le changement de mot de passe. Le groupe ”session” est utilis´e apr`es l’authentification pour ouvrir la ses- sion, monter les r´epertoires personnels, activer sa boˆıte mail, etc.

6.5.4 Les indicateurs de contrˆole de PAM

Lors d’une demande d’op´eration, d’authentification, de v´erification, chaque module retourne un r´esultat avec un indicateur de contrˆole et en fonction de celui-ci, PAM sait ce qu’il doit faire.

Il existe plusieurs indicateurs de contrˆole :

L’indicateur ”required” : Si le r´esultat du test ´echoue, les autres modules sont quand mˆeme analys´es avant de prendre une d´ecision finale. L’indicateur ”sufficient” : Si le r´esultat est positif, le r´esultat global sera positif mˆeme si les modules pr´ec´edents de type « required » ont ´echou´e. L’indicateur ”requisite” : Si le r´esultat du test ´echoue, l’analyse est inter- rompue et l’utilisateur est imm´ediatement averti de l’´echec. L’indicateur ”optional” : Dans tous les cas, que le r´esultat soit positif ou n´egatif, cela n’aura aucune importance dans l’authentification globale sauf si ce module est le seul test´e.

6.5.5 Configuration du fichier /etc/pam.d/login

Nous allons modifier le fichier /etc/pam.d/login pour prendre en compte l’authentification avec Winbind. Nous allons ´egalement ajouter dans ce fi- chier et dans le fichier /etc/pam.d/gdm le module pam mkhomedir.so qui permet de cr´eer le r´epertoire home de l’utilisateur automatiquement `a sa premi`ere connexion :

auth sufficient pam winbind.so auth required pam securetty.so auth required pam stack.so service=system-auth auth required pam nologin.so account sufficient pam winbind.so account required pam stack.so service=system-auth password required pam stack.so service=system-auth session required pam mkhomedir.so skel=/etc/skel/ umask=0022 session required pam stack.so service=system-auth session optional pam console.so

31

Le r´epertoire /etc/skel sert `a d´efinir un profil utilisateur par d´efaut. Ce dossier contient le squelette (skel pour skeleton en anglais) d’un environ- nement par d´efaut pour tous les utilisateurs. Nous avons cr´e´e un r´epertoire ”windows” dans /etc/skel ce qui nous permettra par la suite de monter le r´epertoire windows d’un utilisateur au moment du login. Ainsi, chaque utilisateur qui s’authentifiera pour la premi`ere fois cr´era son r´epertoire home Linux avec le r´epertoire windows.

6.5.6 Configuration du fichier /etc/pam.d/system-auth

Nous faisons ici la mˆeme chose pour le module pam winbind, et le mo- dule pam mkhomedir.so.

auth sufficient pam winbind.so auth required /lib/security/pam env.so auth optional /lib/security/pam mount.so use first pass auth sufficient /lib/security/pam unix.so likeauth nullok use first pass auth required /lib/security/pam deny.so

account sufficient pam winbind.so account required /lib/security/pam unix.so

password required /lib/security/pam cracklib.so retry=3 type= password required /lib/security/pam smbpass.so nullok use authtok try first pass password sufficient /lib/security/pam unix.so nullok use authtok md5 shadow password required /lib/security/pam deny.so

session required pam mkhomedir.so umask=0022 skel=/etc/skel session required /lib/security/pam limits.so session required /lib/security/pam unix.so session optional /lib/security/pam mount.so use first pass

6.5.7 Configuration du fichier /etc/security/pam mount.conf

Le fichier pam mount.conf permet de monter des volumes lorsque l’uti- lisateur va s’authentifier. Nous allons ici monter le profil windows de l’utilisateur dans le r´epertoire Windows, ainsi qu’un r´epertoire commun `a tous les utilisateurs.

Pour cela, il faut modifier le fichier ”pam mount.conf” en rajoutant `a la fin du fichier les volumes `a monter :

32

volume * cifs 192.168.0.2 ltsp/=$ /home/UM2/&/windows

username=&,uid=&,guid=&,file mod=0777,dir mod=0777,workgroup=UM2,rw

- -

volume * local - /home/UM2/&/windows/& /home/UM2/&/windows

bind - -

volume * cifs 192.168.0.2 commun /home/UM2/&/commun uid=&,guid=&,file mod=0777,dir mod=0777,workgroup=UM2,rw

- -

IMPORTANT : Il est important de noter que pour se connecter `a un partage windows 2003, il faut utiliser le protocole CIFS 1 .

6.6 Gestion des mots de passe des utilisateurs

Nous avons utilis´e l’annuaire Active Directory comme seule base de donn´ees pour les utilisateurs. Cela veut dire qu’un utilisateur du domaine ”UM2.local” pourra se connecter indiff´eremment sous une session Linux ou sous une session Windows. Le mot de passe d’un compte utilisateur est le mˆeme pour les deux environnements.

6.6.1 Changement d’un mot de passe

Lorsqu’un utilisateur veut changer son mot de passe, il faut qu’il change le mot de passe stock´e dans l’annuaire Active Directory. Nous allons voir comment l’utilisateur peut changer de mot de passe sous ces deux environ- nements.

Dans un environnement Windows

Sous Windows, l’utilisateur n’a rien de plus `a faire qu’un simple CTRL + ALT + SUP. Il pourra cliquer sur le bouton ”Changer de mot de passe”. Une fenˆetre s’ouvrira alors lui demandant de sp´ecifier son ancien mot de passe, ainsi que son nouveau. Nous avons dˆu lever les restrictions au niveau des strat´egies de s´ecurit´e qui sont mises par d´efaut. En effet, les mots de passe devaient contenir des ca- ract`eres sp´eciaux, ainsi qu’une longueur pr´ecise. Nous n’avions pas besoin, dans le cadre de ce projet, d’une telle strat´egie.

Lorsqu’un utilisateur modifie son mot de passe, celui-ci est donc modifi´e

1 CIFS : Common Internet File System. C’est la derni`ere ´evolution de SMB, plus ex- tensible.

33

directement dans l’Active Directory. Nous allons voir que sous Linux, c’est un peu plus d´elicat.

Dans un environnement Linux

Lorsqu’un utilisateur s’authentifie dans une session Linux, Winbind se charge de v´erifier l’identit´e de l’utilisateur avec les donn´ees qu’il a r´ecup´er´ees de l’Active Directory. Winbind ne fait que ”mapper” les utilisateurs d’un Active Directory et les importe en quelque sorte dans son environ- nement. Lorsqu’un utilisateur veut modifier son mot de passe, il effectue g´en´eralement la commande ”passwd”. Cette commande est valable dans la mesure o`u le compte qui s’est authentifi´e est un compte UNIX. Ici, le compte utilisateur provient d’un Active Directory. Il va donc falloir chan- ger le mot de passe directement au niveau de l’Active Directory.

Pour cela, nous avons cr´e´e un script qui autorise la modification d’un mot de passe pour un utilisateur sous une session UNIX, sans rebasculer sous une session TSE. Ce script nomm´e ”changepass” est stock´e dans le r´epertoire /usr/bin

# !/bin/bash smbpasswd -r 192.168.0.2

Le script utilise le programme smbpasswd pour aller modifier le mot de passe contenu dans l’Active Directory `a l’adresse 192.168.0.2. Lorsqu’un utilisateur d´esire changer son mot de passe, il lui suffit donc de taper chan- gepass. Son ancien mot de passe lui sera demand´e, et il pourra en saisir un nouveau. La prise en compte de la modification est imm´ediate.

34

Chapitre 7

Supervision du r´eseau SNMP

Nous avons d´ecid´e de mettre en place un syst`eme de supervision du r´eseau. Pour cela nous avons utilis´e le logiciel Cacti. Cacti est une solution de mod´elisation graphique compl`ete des r´eseaux, bas´ee sur la puissance de stockage de donn´ees et de g´en´eration de courbes de RRDTool 1 .

Cacti fournit une publication rapide, un syst`eme de template avanc´e, des m´ethodes multiples d’acquisition de donn´ees, et des dispositifs de gestion d’utilisateurs ext´erieurs. Tout ceci est int´egr´e dans une interface intuitive et facile d’emploi adapt´ee `a toute installation du LAN personnel jusqu’aux r´eseaux complexes avec des centaines de syst`emes.

7.1 Installation de Cacti

Avant d’installer Cacti, il faut s’assurer d’avoir install´e au pr´ealable les services Apache (pour le serveur HTTP), et la base de donn´ees MySQL. En effet Cacti se pr´esente sous la forme d’un site Internet et sa base de donn´ees RDD n´ecessite l’installation du service mySQL Cacti s’installe ensuite facilement sous la Fedora Core 5.

yum install cacti

yum install net-snmp-utils

7.2 Configuration de Cacti

La configuration du service Cacti est simple. Il faut cependant configu- rer le service Apache, et la base de donn´ees MySQL avant de pouvoir se

1 RRDtool est un outil libre de gestion de base de donn´ees RRD. Cet outil a ´et´e cr´e´e pour superviser des donn´ees serveur, telles que la bande passante, la temp´erature d’un processeur.

35

servir de Cacti. Lors de l’installation nous avons ´et´e confront´es `a un probl`eme inattendu. En effet, le service SELinux qui est activ´e par d´efaut dans la fedora SE- Linux, pour Security-Enhanced Linux, est un LSM (Linux security module), qui permet de d´efinir une politique d’acc`es MAC (mandatory access control) aux ´el´ements d’un syst`eme bas´e sur Linux. Ceci a eu pour effet de bloquer les flux HTTP et autres en provenance d’Apache. La confi- guration complexe de ce service ne nous a pas sembl´e cruciale au projet, nous avons donc simplement d´esactiv´e ce service.

7.2.1 Configuration du serveur MySQL

Pour faire fonctionner Cacti, nous avons besoin de configurer certains param`etres dans la base MySQL.

/usr/bin/mysql -p -u root

mysql> create database cactidb ;

mysql> grant all on cactidb.* to root ;

mysql> grant all on cactidb.* to root@localhost ;

mysql> grant all on cactidb.* to cactiuser ;

mysql> grant all on cactidb.* to cactiuser@localhost ;

mysql> set password for cactiuser@localhost=password(’cacti’) ;

mysql> exit ;

On autorise de cette fa¸con l’utilisateur ”cactiuser” `a int´eragir avec la base cactidb (ajout/suppression/modification), et on lui d´efinit un mot de passe pour se connecter `a la base de donn´ees.

7.2.2 Configuration du fichier /usr/share/cacti

Il faut maintenant ´editer le fichier de configuration pour l’adapter `a notre installation. Voici les lignes importantes `a modifier :

Fichier : /usr/share/cacti/include/config.php

$database type = ”mysql” ; $database default = ”cactidb” ; $database hostname = ”localhost” ; $database username = ”cactiuser” ; $database password = ”cacti” ; $database port = ”3306” ;

Ensuite, nous allons donner les droits suffisants `a Cacti pour g´en´erer ses graphiques et ses logs. Dans le r´epertoire de Cacti :

chown -R cactiuser rra/ log/

36

7.2.3 Programmation de la r´ecup´eration des statistiques :

Crontab

Nous allons utiliser Crontab 2 pour aller r´ecup´erer, toutes les cinq mi- nutes, les donn´ees sur les ´equipements que nous voulons superviser. Pour cela, nous allons ajouter la ligne suivante au fichier /etc/crontab :

*/5 * * * * cactiuser php /usr/share/cacti/poller.php > /dev/null

2>&1

Lors de la premi`ere connection, il faut utiliser le compte admin/admin.

7.2.4 Administration et supervision des serveurs

Nous allons pouvoir nous connecter au service Cacti :

http ://ltsp.um2.local/cacti/

connecter au service Cacti : http ://ltsp.um2.local/cacti/ Fig. 7.1 – Administration de Cacti 2 Crontab est

Fig. 7.1 – Administration de Cacti

2 Crontab est un programme Unix qui permet d’´editer la table de configuration du programme cron et donc de lancer des tˆaches `a horaires fixes.

37

Supervision du serveur Windows

Supervision du serveur Windows Fig. 7.2 – Statistiques sur l’interface eth0 Fig. 7.3 – Statistiques de

Fig. 7.2 – Statistiques sur l’interface eth0

du serveur Windows Fig. 7.2 – Statistiques sur l’interface eth0 Fig. 7.3 – Statistiques de ping

Fig. 7.3 – Statistiques de ping du serveur

38

Supervision du serveur Linux

Supervision du serveur Linux Fig. 7.4 – Statistiques sur la charge du serveur Fig. 7.5 –

Fig. 7.4 – Statistiques sur la charge du serveur

du serveur Linux Fig. 7.4 – Statistiques sur la charge du serveur Fig. 7.5 – Statistiques

Fig. 7.5 – Statistiques sur l’interface eth0

39

Fig. 7.6 – Statistiques sur l’interface eth1 40

Fig. 7.6 – Statistiques sur l’interface eth1

40

Chapitre 8

Installation d’un PROXY

Nous avons mis en place un serveur PROXY dans le but d’acc´el´erer les consultations des sites web et de contrˆoler l’acc`es `a Internet.

8.1 Pr´esentation du service Squid

Squid est un Proxy capable d’utiliser les protocoles FTP, HTTP, Go- pher, et HTTPS. Il permet de mettre en cache des pages web les plus fr´equemment utilis´ees et ainsi de diminuer le temps de chargement de ces pages.

Squidguard est un outil permettant de filtrer les sites en se servant des URLs, c’est une surcouche de Squid qui lui ne g`ere que le cache. SquidGuard utilise, pour le filtrage, des URLs regroup´ees en listes blanches ou en listes noires :

– Une liste noire est une liste de sites interdits. Lorsque le navigateur d’un poste informatique essaie de se connecter `a l’un de ces sites, le proxy se charge de regarder si le site figure dans la fameuse liste noire et, si c’est le cas, il va renvoyer un message d’erreur au navigateur .

– Une liste blanche est une liste qui fonctionne sur un mod`ele inverse, c’est-`a-dire que l’on va autoriser un certain nombre d’adresses pr´ealablement valid´ees et dont on est sˆur qu’elles ne pr´esentent pas de risques.

Evidemment chaque type de liste a ses avantages et ses inconv´enients : la liste noire permet d’avoir acc`es `a tous les sites qui ne sont pas interdits, ce qui veut dire qu’on a quand mˆeme potentiellement acc`es `a une grande vari´et´e de sites et que, dans la mesure o`u la liste noire est g´er´ee par des humains, on va laisser passer des sites que la machine pourrait consid´erer comme am-

41

bigus. Il est donc imp´eratif de mettre `a jour ces listes fr´equemment puisque des URLs se cr´eent chaque jour.

Le sch´ema suivant permet de voir plus pr´ecisement comment va fonc- tionner le serveur PROXY.

pr´ecisement comment va fonc- tionner le serveur PROXY . Fig. 8.1 – Serveur proxy 8.2 Configuration

Fig. 8.1 – Serveur proxy

8.2 Configuration du service Squid

L’installation du service Squid est int´egr´ee dans la distribution Fedora Core 5 (K12LTSP) que nous avons utilis´ee. Cependant, l’installation n’au- rait pas ´et´e plus compliqu´ee :

yum install squid

Nous avons tout d’abord initialis´e le r´epertoire de cache (celui dans lequel les pages des sites web les plus consult´es seront stock´ees). Il faut taper dans une console :

squid -z

Nous allons maintenant nous interesser au fichier /etc/squid/squid.conf :

42

#port d’´ecoute du service http port 3128 hierarchy stoplist cgi-bin ? acl QUERY urlpath regex cgi-bin ? redirect program /usr/sbin/squidGuard -c /etc/squid/squidguard.conf auth param basic children 5 auth param basic realm Squid proxy-caching web server auth param basic credentialsttl 2 hours auth param basic casesensitive off #Suggested default :

refresh pattern ˆ ftp : 1440 20% 10080 refresh pattern ˆgopher : 1440 0% 1440 refresh pattern . 0 20% 4320 #Recommended minimum configuration :

acl all src 0.0.0.0/0.0.0.0 acl manager proto cache object acl localhost src 127.0.0.1/255.255.255.255 acl to localhost dst 127.0.0.0/8 acl SSL ports port 443 563 acl Safe ports port 80 # http acl Safe ports port 21 # ftp acl Safe ports port 443 563 # https, snews acl Safe ports port 70 # gopher acl Safe ports port 210 # wais acl Safe ports port 1025-65535 # unregistered ports acl Safe ports port 280 # http-mgmt acl Safe ports port 488 # gss-http acl Safe ports port 591 # filemaker acl Safe ports port 777 # multiling http acl CONNECT method CONNECT no cache deny QUERY http access allow manager localhost http access deny manager

# Deny requests to unknown ports

http access deny !Safe ports

# Deny CONNECT to other than SSL ports

http access deny CONNECT !SSL ports #On definit le r´eseau authoris´e `a utiliser le service SQUID

acl our networks src 192.168.0.0/24 http access allow our networks

# And finally deny all other access to this proxy

http access allow localhost #On refuse tout le reste

43

http access deny all

Avec ce fichier de configuration, on d´efinit que le service PROXY sera disponible sur le port 3128 pour tout le r´eseau 192.168.0.0/24. Seul le poste ’localhost’ pourra administrer la configuration du serveur. Un certain nombre de ports correspondant `a des services sont d´eclar´es comme ’safe’. Toute connection vers d’autres ports (services) ne sera pas autoris´ee.

8.3 Configuration de SquidGuard

Le filtrage du contenu et la restriction d’acc´es se configurent au travers du fichier /etc/squid/squidGuard.conf. Il est possible d’y d´eclarer des p´eriodes pendant lesquelles l’acc´es est autoris´e, mais c’est ´egalement l`a que les listes blanches et noires sont pr´ecis´ees.

Fichier /etc/squid/squidGuard.conf :

dbhome /var/squidGuard/blacklists logdir /var/log/squidGuard

# TIME RULES :

# abbrev for weekdays :

# s = sun, m = mon, t =tue, w = wed, h = thu, f = fri, a = sat

#les horaires autoris´ees pour l’utilisation du proxy time horaires {

weekly a 07 :30 - 13 :30

weekly mtwhf 07 :30 - 21 :30

}

#

SOURCE ADDRESSES :

src lansource { ip 192.168.0.0/24

iplist lansource/lan

}

#

DESTINATION CLASSES :

#les Groupes de destination qui filtre vos clients dest local-ok{ domainlist local-ok/domains urllist local-ok/urls

44

}

dest local-block{ log local-block domainlist local-block/domains urllist local-block/urls

}

dest porn{ log porn domainlist porn/domains urllist porn/urls

}

dest warez{ log warez domainlist warez/domains urllist warez/urls

}

rewrite google {

s@(google.com/search.*q=.*)@\1&safe=active@i

s@(google.com/images.*q=.*)@\1&safe=active@i

s@(google.com/groups.*q=.*)@\1&safe=active@i

s@(google.com/news.*q=.*)@\1&safe=active@i

#

log google

}

#

ACLs

#les ! Devant les groupes veulent dire « tous se qui n’est pas »

acl {

lansource within horaires

{

rewrite google pass local-ok !porn !warez all

}

default

{

pass none

redirect

http ://ltsp.um2.local/cgi-bin/squidGuard.cgi ?clientaddr=%a&clientname=%n&client

}

}

Les fichiers pr´ecis´es par les diff´erentes cat´egories sont des bases de donn´ees contenant les URLs et/ou adresses IP de sites contenant des contenus ill´egaux, ou non d´esir´es sur notre r´eseau. Par exemple, pour le genre ’hacking’ le fichier ’domain’ contient des donn´ees

45

du genre :

63.71.76.111

66.28.56.113

astalavista.box.sk

neworder.box.sk

warez.com

Les contraintes de r´e´ecriture (rewrite google) permettent de modifier les adresses tap´ees par l’utilisateur dans son navigateur. Ces contraintes per- mettent par exemple de forcer l’activation du mode recherche SafeSearch propos´e par le moteur de recherche Google et qui filtre les r´esultats ayant un contenu illicite. Nous d´efinissons aussi des ACL 1 qui sont en fait des r`egles de filtrage constitu´ees entre autres de listes blanches et de listes noires. L’ACL lan- source, par exemple, n’autorise l’acc`es `a Internet que pendant les horaires pr´ed´efinis (Section lansource within horaires dans le script ci-dessus). Dans cette ACL nous pr´ecisons quels sont les groupes de sites que nous au- torisons. Ici, les sites pornographiques et les sites de Warez seront interdits. Tout le reste sera autoris´e :

pass local-ok !porn !warez all

1 Acc`es Lists ou listes d’acc´es

46

Conclusion

Le r´esultat obtenu par toute cette mise en oeuvre est surprenant. En effet lors de nos diff´erents tests, nous avons pu constater la r´eactivit´e des syst`emes distants et leur utilisation compl`etement transparente. Cela s’explique de part les conditions de mise en oeuvre. Il serait int´eressant de pouvoir tester cette impl´ementation dans des conditions r´eelles, sur un r´eseau ´etendu et utilis´e pour d’autres applications, ainsi qu’avec de nombreux clients LSTP. Cela permettrait de savoir si une telle solution est viable pour une applica- tion industrielle, et pas seulement dans le cadre d’un TER.

47