OptionRX1 :

module Configuration de serveurs

Année 2012-2013 Alain AUBERT/Gérard JACQUET

1

Organisation du module « Configuration de Serveurs »

Missions :

Vous êtes fraîchement embauché dans une entreprise spécialisée dans la mise en oeuvre de systèmes informatiques. Votre première mission (non rémunérée !) consiste à installer un ensemble de services sur des serveurs UNIX et Windows. L'équipe projet est constituée de 3 personnes au maximum encadrée par 2 e-responsables (Alain AUBERT et Gérard JACQUET) qui seront là pour vous aider, mais aussi pour évaluer votre travail. Vous aurez aussi à réaliser un travail plus spécifique pour montrer votre aptitude à l'innovation !

Les services à installer seront en particulier :- Console à distance et transfert de fichiers (Telnet et ftp sous UNIX)- Serveur DNS (sous UNIX et Windows)- Serveur LDAP (sous UNIX)- Serveur de fichiers et de compte (NFS et NIS sous UNIX)- Serveur de fichiers et de compte ( NetBIOS sous Windows)- Serveur de fichiers en multi-environnement (Samba sous UNIX)- Serveur de messagerie (SMTP/POP/IMAP sous UNIX)- Serveur WEB (HTTP sous UNIX)

Votre premier jour de mission sera consacré à l'organisation du travail du groupe et à la planification de votre réalisation. La mise en place de tous les services devra être réalisée sur le reste de la période. De plus, l'environnement de développement n'étant pas sécurisé, vous devrez être capable de reconstituer la configuration complète de vos serveurs à partir de fichiers (scripts, configuration) que vous sauvegarderez sur un dispositif adéquat (attention, il n'y a. pas d'antivirus sur les machines, il faut donc vérifier vos clefs USB et autres périphériques avant).

Modalités de contrôle (susceptible de variations) :

Durée CoefficientExamen de cours sous forme de QCM+ 1 H 0,5Dossier 0,5Examen de TP 1H30 1

Répartition sur les jours :

Jours 1 2 3 4 5 6 7 8 9 10 11 12 13Merc

18 Avril

Vendr. 20

Avril

Lundi 23

Avril

Mardi 24

Avril

Merc.25

Avril

Vend.27

Avril

Mercr.02 Mai

Vendr.04

Mai

Merc09 Mai

Vend.11 Mai

Lundi 14

Mai

Mardi 15

Mai

Merc.16

Mai

Total

CM/TD 3 3 0 4,5 1,5 0 3 1,5 3 1,5 0 7,5 1,5 30TP 3 3 3 3 0 0 0 0 3 1,5 1,5 18

Exam

Hetud 3 3 3 7,5 4,5 3 3 1,5 3 1,5 3 9 3 48Hcren 3 3 6 10,5 7,5 6 3 1,5 3 1,5 6 10,5 4,5 66Hserv

2

Travaux Pratiques

Les travaux pratiques du module d'option Réseaux1 sont organisés de la manière suivante :- Les deux premiers TP sont obligatoirement le TP N°1 et le TP N°2 pour tous les groupes.- Ensuite, il y a rotation volontaire. Le sens de rotation pour le reste des TP est laissé au libre choix des groupes, avec la condition que chacun ait fait tous les TP à la fin de l'option.

Hormis pour le premier TP, les étudiants peuvent se répartir le travail comme il le désire (dans les limites de capacité de la salle) par exemple :

- Partage du groupe pour un travail sur plusieurs TPs à la fois- Association temporaire avec un autre élève d'un autre binôme...

Lors du premier jour de l'option, il sera demandé aux étudiants de planifier globalement leur travail et donc de le faire aussi pour les TP. C'est cette planification qui permettra de déterminer qui peut venir travailler en salle de TP et quand. Un élément important d'évaluation sera le respect minimum de ce planning et surtout que le temps étudiant soit au minimum celui prévu par le module c'est à dire 48H/étudiant auquel s'ajoute 20% de travail personnel. Chaque groupe garde le même poste : 3 PC sont à votre disposition.

Liste des TP :

TP01 Serveur DNS sous UNIX 2ème jourTP02 Serveur LDAP sous UNIX 3ème jourTP03 Serveur de fichiers : Windows 2003 server En rotation libreTP04 Serveur de fichiers : UNIX/NFS En rotation libreTP05 Serveur Apache En rotation libreTP06 Serveur Samba En rotation libreTP07 Serveur de Mail En rotation libre

A l'issu de chaque séance, il est conseillé que les étudiants gèrent un compte-rendu de ce qu'ils ont fait en TP soit personnel, soit de groupe. Ce compte-rendu ne sera pas corrigé par les enseignants. Toute question relative à la compréhension des TP devra donc être posée à l'enseignant durant les séances de TP. Il est important pour les étudiants de rédiger ces compte-rendus en fonction de la destination prévue (préparation à l'examen de TP), et inscrivant donc toutes les remarques et commentaires nécessaires à la bonne réalisation des TP et non pas une inscription du type « ça marche... ».

Aucun document papier ne sera autorisé à l'examen, l'aide sur les différents équipements sera active (PC...), des fichiers d'exemple sont aussi fournis sur les machines. Les étudiants devront donc être capables de retrouver les informations manquantes et non pas suivre une démarche préétablie correspondant à celle du TP.

Pour permettre un travail fructueux à tous les sujets de TP, il correspondra des séances de cours et de TD pendant lesquelles les étudiants pourront soit préparer le TP suivant soit tenter de le terminer et de bien en comprendre les résultats. Un accès aux machines de la salle de TP est prévu même en TD ou en cours. La phase de travail des cours est un aspect important pour passer la phase de mise en oeuvre en ayant une compréhension globale des services et d'envisager une généralisation des connaissances (vous ne travaillerez pas forcément sur le même serveur ou sur le même Système d'Exploitation).

3

Polycopié

Technologie Serveurs et

Protocoles

Gérard JACQUET

Version 2013

4

Table des matières

Chapitre 1 : Introduction.........................................................................................91.1 Positionnement de ce cours....................................................................................................91.2 Approche et contenu de ce cours............................................................................................9

Chapitre 2 : Interactions Client/Serveur...............................................................112.1 Objectifs de ce chapitre........................................................................................................112.2 Définitions...........................................................................................................................112.3 Classifications des serveurs (et des services)........................................................................192.4 Lien Serveur - Système d’exploitation..................................................................................262.5 Questions concernant ce chapitre.........................................................................................28

Chapitre 3 : Technologie Serveurs.........................................................................313.1 Introduction.........................................................................................................................313.2 Packaging des serveurs........................................................................................................323.3 Packaging des éléments de stockage de masse.....................................................................343.4 Regroupement de plusieurs serveurs sur une même machine physique (virtualisation).......35

Chapitre 4 : Mise en œuvre d’une infrastructure informatique (Création,

modification)...........................................................................................................394.1 Objectif de ce chapitre..........................................................................................................394.2 Objectifs d’un projet d’infrastructure...................................................................................394.3 Caractéristiques d’un projet d’infrastructure.........................................................................404.4 Différentes phases de la conception et de la mise en oeuvre.................................................414.5 Organisation des différents serveurs.....................................................................................434.6 Les paramètres de dimensionnement des serveurs................................................................444.7 La méthodologie de dimensionnement des serveurs.............................................................45

Chapitre 5 : Résolution de noms (DNS).................................................................475.1 Objectifs de la résolution de noms et historique....................................................................475.2 Définitions...........................................................................................................................485.3 Fonctionnement....................................................................................................................535.4 Mise en œuvre : ...................................................................................................................585.5 Interaction DNS/DHCP........................................................................................................615.6 Service WINS (client Windows)...........................................................................................62

Chapitre 6 : Gestion centralisée et annuaires........................................................676.1 Introduction.........................................................................................................................676.2 Annuaire LDAP...................................................................................................................696.3 OpenLDAP sous Linux Debian............................................................................................74

Chapitre 7 : Serveurs Windows.............................................................................817.1 Introduction.........................................................................................................................817.2 Active Directory..................................................................................................................847.3 Relations Clients-Serveur....................................................................................................897.4 Utilisateurs..........................................................................................................................907.5 Ressources..........................................................................................................................987.6 Les Stratégies....................................................................................................................1007.7 Les outils d'administration.................................................................................................103

Chapitre 8 : Serveurs UNIX/Linux......................................................................115

5

8.1 Introduction.......................................................................................................................1158.2 Structure du système d'exploitation UNIX..........................................................................1168.3 Compte d'utilisateurs.........................................................................................................1188.4 Ressources........................................................................................................................1248.5 Administration...................................................................................................................131

Phase 5 : Création de répertoires supplémentaires.............................................136

Phase 6 : Gestion centralisée des comptes ..........................................................136

Chapitre 9 : Protocoles couches intermédiaires..................................................1399.1 Introduction.......................................................................................................................1399.2 Couche NetBIOS sur 802.2...............................................................................................1429.3 NetBIOS sur TCP/IP.........................................................................................................1439.4 Couche Application : CIFS/SMB.......................................................................................1499.5 Couches hautes sous UNIX : RPC......................................................................................1519.6 Couche présentation : XDR...............................................................................................1589.7 NFS...................................................................................................................................1609.8 NIS....................................................................................................................................162

Chapitre 10 : Interopérabilité..............................................................................16510.1 Introduction......................................................................................................................16510.2 Principes et types d'interopérabilité..................................................................................16510.3 Samba..............................................................................................................................16810.4 Windows Services for UNIX............................................................................................170

Chapitre 11 : Connexions à distance....................................................................17711.1 Introduction.....................................................................................................................17711.2 Telnet...............................................................................................................................17911.3 Shell distant UNIX : rlogin, rsh.......................................................................................18211.4 SSH.................................................................................................................................18311.5 X11.................................................................................................................................18311.6 VNC................................................................................................................................18411.7 RDP................................................................................................................................184

Chapitre 12 : Transfert de fichiers.......................................................................18512.1 Introduction.....................................................................................................................18512.2 FTP : File Transfer Protocol - RFC 959...........................................................................18512.3 TFTP : Trivial File Transfer Protocol...............................................................................191

Chapitre 13 : Messagerie électronique.................................................................19313.1 Introduction.....................................................................................................................19313.2 SMTP..............................................................................................................................19613.3 POP.................................................................................................................................19913.4 IMAP..............................................................................................................................20013.5 Format de messages RFC822..........................................................................................20213.6 MIME..............................................................................................................................20413.7 Exim4..............................................................................................................................205

Chapitre 14 : Serveur HTTP................................................................................21114.1 Introduction.....................................................................................................................21114.2 Principe du protocole HTTP............................................................................................21514.3 Format du protocole HTTP...............................................................................................216

6

14.4 Cookies............................................................................................................................21914.5 Serveur mandataire, proxy, cache....................................................................................22014.6 MIME..............................................................................................................................22314.7 WEB interactif................................................................................................................22314.8 APACHE.........................................................................................................................22814.9 Performances....................................................................................................................234

7 8

Chapitre 1 : Introduction

1.1 Positionnement de ce cours.

Ce cours sera centré sur les couches intermédiaires de gestion (en partie pouvant être qualifiées de middleware) : couches session et présentation ainsi que sur la couche application et les applications directement associées. Il ne concernera donc que des communication au niveau des machines d'extrémités. Il sera fait abstraction des supports de communication. Seule une connaissance des mécanismes d'adressage couches réseau et application seront nécessaires.

1.2 Approche et contenu de ce cours

En théorie, l'approche d'apprentissage dans ce cours sera faite via des vues successives de plus en plus détaillées comme présentées dans le schéma ci-dessous, chaque chapitre sera terminé par le détail de la mise en oeuvre des services présentés en général sous UNIX :

Ce document sera constitué de 14 chapitres :

Le chapitre 2 balayera rapidement toutes les catégories de serveurs mettant l'accent uniquement sur les services rendus, il présentera aussi les fondamentaux de l'interaction entre ces serveurs donnant ainsi une introduction à l'aspect architecture de serveurs.

Le chapitre 3 présentera une introduction à la méthodologie de conception et d’implémentation d’un système informatique d’entreprises. Plusieurs points seront abordés : méthodologie générale, étude des éléments de choix et des contraintes techniques. Une illustration de ces concepts sera faite lors d'un travail personnel sous forme d'étude de cas. Il sera suivi d'une brève description des mises en oeuvre physiques dans le chapitre 4.

9

Taxinomiesimplifiée

Principe defonctionnement

Mise en oeuvreet protocoles

Dans le chapitre 5 sera présenté les services permettant de relier les informations nécessaires à l'envoi de données devant transiter entre couches (principalement les problèmes de résolution de noms ou adresses) : avec les protocoles DNS.

Le chapitre 6 fournira une introduction aux services d'annuaire, il sera centré sur LDAP, élément maintenant fondamental dans la constitution des réseaux d'entreprise.

Les chapitres 7 sera consacré à la mise en oeuvre de systèmes informatiques basés sur la technologie Windows. Les principes et la mise en oeuvre pratique en terme de serveurs de compte et de fichiers seront abordés

Le chapitre 8 sera consacrés aux systèmes basés sur les technologies UNIX

Le chapitre 9 étant plutôt consacré à l'étude des protocoles mis en oeuvre (NetBIOS, CIFS/SMB) permettant de comprendre en détail le fonctionnement de ces architectures et leurs limites.De même sous UNIX

Ensuite un chapitre donnera des éléments sur le fonctionnement en multi-environnement (UNIX/Windows) en particulier il présentera le fonctionnement de Samba.

Les 4 chapitres suivants présenteront les applications de base du fonctionnement en réseaux en terme de principe et de protocoles : Console à distance, échange de fichiers, messagerie ainsi qu'une introduction aux protocoles support du Web.

A la fin de chaque chapitre, vous trouverez des activités permettant de mobiliser les connaissances acquises lors de la lecture du chapitre. En particulier, vous retrouverez les énoncés des travaux pratiques.

10

Chapitre 2 : Interactions

Client/Serveur

2.1 Objectifs de ce chapitre.

Nous allons aborder, dans ce chapitre, différentes notions nécessaires à la compréhension du fonctionnement général d'une architecture informatique basée sur des interactions clients/serveurs. Nous définirons les termes de serveur et de client, ainsi que la relation client/serveur en donnant des exemples simples. Ensuite sera abordée les concepts d'architecture Client/Serveur.Enfin les différents types de serveurs seront présentés en insistant sur leur fonction principale et les caractéristiques générales de mise en oeuvre. Au terme de ce chapitre, le lecteur devrait connaître les différents éléments d'une architecture informatique et aura eu un aperçu du vocabulaire que l'on peut rencontrer dans le domaine.

2.2 Définitions

2.2.1 Client, Serveur, Relation Client/serveur

D'un point de vue informatique, un serveur est une machine (ordinateur) qui propose un service. Ce service, dans le cas général, sera proposé à toute machine pouvant accéder via un réseau informatique à la machine serveur.

Serveur : ordinateur qui propose un service

Par symétrie, un client est une machine qui utilise un service mis à disposition par une autre machine.

Client : ordinateur qui utilise un service

Ces définitions simples nécessitent toutefois de préciser ce qu'est un service du point de vue informatique.Un service est la mise à disposition par une machine de ressources locales pour d'autres ordinateurs qui peuvent y accéder par un réseau.

Services : ressources mises à disposition par un ordinateur

Plusieurs remarques sont nécessaires à ce niveau.La première concerne les ressources mise à disposition. Celles-ci ne peuvent-être que des ressources possédées par la machine serveur (ce qui est une évidence). Les ressources potentiellement mises à disposition sont de 4 ordres :

- Espace de stockage (fichiers sur un disque dur ou sur un autre périphérique de masse)- Temps de calcul (temps UC) + utilisation mémoire centrale (l'un étant difficilement concevable sans l'autre)

11

- Liaisons à des périphériques ou à des interfaces locales (Imprimantes, accès distant…)- Applications spécifiques (bases de données, pages WEB…)

Dans ce dernier cas (le plus fréquent maintenant), le service est plus complexe et va consommer les différentes autres catégories de ressources (disque, UC, périphériques).

La deuxième remarque concerne la distinction que l'on peut faire entre les fonctions d'une machine et la machine elle-même. En fait, la relation Client/Serveur est une relation entre fonctions et non entre machines. En d'autres termes cela veut dire que plusieurs serveurs (en tant que fonctions) peuvent être hébergés sur la même machine. Par exemple, un serveur WEB peut aussi être serveur de messagerie, s'il possède les ressources suffisantes.De même, le client et le serveur peuvent être sur la même machine; Un exemple habituel est le fonctionnement de l'interface graphique sur une machine UNIX autonome : le client X (programme qui envoie les commandes graphiques pour affichage) et le serveur X (programme qui va gérer l'affichage sur l'écran à partir des commandes reçues) sont sur la même machine. Cet exemple peut être d'ailleurs vu comme un paradoxe lorsque la machine qui affiche n'est pas la même que celle qui envoie les commandes graphiques : le serveur est alors la machine locale (celle qui affiche pour l'utilisateur) et le client la machine distante (qui fait les traitements).Enfin, un serveur pour une application peut-être client pour une autre ce qui va conduire à définir des architectures plus complexes comme nous le verrons plus loin.

Dans le cas d'un ensemble de machines en réseau, les interactions Client/Serveur peuvent être vues de manière différente suivant l'endroit où l'on se place.

Relation Client/Serveur (Vision côté serveur) :On a un multiplexage de l’accès au serveur. Plusieurs clients ont accès à un seul serveur, le serveur est spécialisé dans un service particulier.

Relation Client/Serveur (vision côté client) :Dans le cas d'une machine multi-tâches, il peut y avoir des accès simultanés à plusieurs serveurs pour un client unique. Chaque serveur est toujours spécialisé dans un service mais le client a besoin

12

Client

Client

Client

Serveur

Client

de plusieurs services pour mener à bien la tâche en cours (par exemple : messagerie avec affichage de pages WEB intégrées).

Relation Client/Serveur (vision globale) :En fait dans un système informatique complet, plusieurs clients et plusieurs serveurs cohabitent et travaillent ensemble. On obtient alors une architecture plus complexe où chaque client pourra accéder à sa demande à chaque serveur :

On imagine facilement la complexité d'un tel système s'il fallait gérer chaque accès de manière individuelle pour un ensemble de 100 machines et d'une dizaine de serveurs.Pour être utilisable, l'informatique partagée va devoir être basée sur 2 aspects :

- la nécessité d’un réseau de communication pour assurer physiquement les échanges- la nécessité de protocoles gérant les échanges Client/Serveur pour contrôler logiquement ces échanges.

Dans ce dernier cas, chaque fonction spécifique nécessite la définition d'un protocole adapté. Cela conduit forcément à une convergence des protocoles applicatifs sur un même support lors d'une mise en oeuvre par réseaux informatiques. Le point de convergence des protocoles applicatifs est

13

Client

Serveur

Serveur

Serveur

Client

Serveur

Serveur

Serveur

Client

Client

Client

généralement la couche transport TCP/IP (surtout s'il y a communication entre sous-réseaux) ou la couche liaison (Ethernet) si on reste sur un même réseau local de type industriel.

Comme nous l'avions évoqué précédemment, la relation Client/Serveur peut être plus complexe avec des architectures où un serveur peut devenir client d’un autre serveur pour répondre à un client : le serveur est spécialisé dans un service mais il a besoin pour le mettre en œuvre d’un autre service :

On parle alors d'architecture à étages (tier en anglais), ou d'architectures N-tier. Ces architectures peuvent paraître plus complexes avec l'utilisation de plusieurs protocoles (un par relation entre machines), mais elles conduisent aussi à une mise en oeuvre plus simple permettant des modifications plus aisées, car chaque fonction peut être traitée séparément.

14

Client Client Client Client

ServeurServeur

Switch

ClientServeur

Client+

Serveur2

1 3

4

Une architecture fréquemment rencontrée est une architecture à 3 étages (3-tier) où les fonctions de base : IHM (Interface Homme-Machine), Traitement et stockage (base de données) sont séparées sur 3 serveurs. De ce fait, on peut changer l'interface homme-machine (fréquent sur les sites WEB par exemple) sans changer le reste de l'application. De même, la base de données peut-être complètement refondue pour pouvoir répondre à d'autres applications sans que le service initial ne soit affecté de manière visible. Un point important de ces architectures concerne la sécurité : si le réseau est constitué correctement, un client ne pourra pas directement réaliser de requêtes SQL sur le serveur de base de données. La représentation habituelle pour une application basée sur le protocole HTTP est la suivante :

Client : Navigateur

Serveur WEB + PHP

ServeurBase de donnéesSQ

L

HTTP

Plusieurs remarques peuvent être faite :- cette architecture à 3 niveaux ne possèdent que 2 serveurs, la fonction d'affichage est le rôle du client (navigateur). Cette approche n'est pas générale, car c'est bien le serveur (WEB+PHP) qui génère les ordres graphiques (HTML) le client n'est là que pour suivre directement les ordres. Quoi qu'il en soit le client a un rôle de gestion d'interface homme-machine, mais un 4ème niveau celui de la mise en forme des données pourrait être rajouté à cette architecture. Elle serait plus évidente si l'application était basée sur un autre protocole qu'HTTP.- La structure client/serveur WEB est un contre exemple parfait de l'architecture client/serveur X (ou l'inverse !) : en effet dans un relation client/serveur X11, c'est le serveur qui affiche et le client

15

Client

Serveur+Client

Serveur

Switch

Serveur+Client

qui génère les ordres alors que dans une structure WEB c'est l'inverse, l'informatique s'éloigne quelquefois (souvent ?) de la pure logique !

Lors de la mise en oeuvre de cette architectures à 3 étages dans un réseau de type LAN des problèmes de sécurité peuvent apparaître :

Client : Navigateur

Serveur WEB + PHP

ServeurBase de données

SQL

Switch HTTP et SQL

HTTP

En effet, le client peut accéder directement par une autre application au serveur de base de données, il n'y a pas d'impossibilité physique. Il faut alors prévoir d'introduire des contraintes au niveau des équipements intermédiaires (VLAN...) si l'on veut empêcher cet accès.Une autre évolution, liée à la sécurité, concerne l'authentification du client, cette dernière peut-être gérer par un serveur spécifique (LDAP...) et constitue alors un niveau supplémentaire.

2.2.2 Durée de l’échange, connexion

Lors d'échanges entre client et serveur les données échangées peuvent être importantes en taille. Il n'est pas rare que des pages WEB contenant des images dépassent les 100 kO où qu'un fichier a transférer dépasse le Mo. Le bon fonctionnement de tels échanges nécessite une permanence dans le temps de la relation client/serveur, c'est à dire un fonctionnement en mode connecté. De même pour des raisons de sécurité, on peut aussi désirer une permanence à plus long terme (jusqu'à fermeture du navigateur ou déconnexion volontaire de l'utilisateur).Suivant les caractéristiques de l’application, la gestion de la connexion peut se faire sur des couches différentes :Transport (TCP : connexion standard)Session (session utilisateur)ou au niveau de l’application (cookies…)

2.2.3 Middleware

Le middleware (quelquefois traduit en français sous le terme Intergiciel) est un ensemble de protocoles, logiciels permettant de réaliser les relations applications clientes / serveurs.

D’un point de vue des communications le middleware se situe au niveau des couches intermédiaires : Session, Présentation, ApplicationMais il peut représenter un ensemble plus complet : API (Application Programming Interface) d'outils permettant cette échange en permettant le développement d’applications qui doivent s’interfacer avec un type de serveur donné. Puisqu'il est situé au-dessus de la couche transport, mais en dessous d'une application, il a un lien direct avec le Système d’exploitation. Toutefois ce terme

16

n'a pas une définition très précise comme peuvent l'avoir les fonctions des couches basses. En particulier, son usage a évolué en fonction du temps et des catégories d'applications qu'il doit supporter.

Il existe différents catégories de middleware relativement à la technologie mise en oeuvre : - Echange de messages via une File d’attente

il nécessite un formatage propriétaire des messages, du code spécifique côté client et serveur, mais la mise en œuvre est simple et fiable.

- Appel de procédures distantes (RPC : Remote Procedure Call)L'appel de fonctions distantes se fait comme dans un programme standard, il est alors

nécessaire de définir une interface des procédures standardisée (IDL : interface definition language) : concernant les noms et les paramètres.

- Objets distribués (CORBA, DCOM...)Il y a proposition de services par des objets distribués sur un réseau avec les mêmes "avantages" que la programmation objet relativement à la programmation procédurale.

Exemple : couche RPC sous UNIX :

Fonctionnement :Appel identique à une fonction avec des paramètresAppel distant bloque le thread jusqu’au retour de la réponse (ou time out)La machine serveur exécute réellement la fonction

Structures des couches intermédiaires :

Exemple 1 : Partage de fichiers sous Windows (avec l'usage de TCP/IP)

17

Programme client

Client

Callrpc()

Execute request

Serveur

Call service

Service execute

Return reply

Request completes

Suite du programme

Exemple 2 : Partage de Fichiers sous UNIX

Exemple 3 : Autres cas sous UNIX

Très souvent l’application descend jusqu’à la couche transport quand il y a utilisation directe de l’API socket. Sous Windows, c’est souvent le cas si l’application vient du monde UNIX.

18

Couche « Session »

SMB/CIFSCouche Application/Présentation

NetBIOS

NbT

TCP

IP

Ethernet

Ethernet

Application

Couche d'interface

Couche Transport

Couche « Session »

NFS (Network File System)Couche Application

XDR (eXchange Data Representation)

RPC (Remote Procedure Call)

TCP

IP

Ethernet

Ethernet

Application

Couche Présentation

Couche Transport

Remarque : l'application est souvent découpée en fonctions liées aux couches OSI, cela n’apparaît pas dans les PDU.

2.3 Classifications des serveurs (et des services)

2.3.1 Différents types de serveurs

Serveurs d’infrastructure

Serveurs proposant des services nécessaires au fonctionnement de l’infrastructure de communicationExemples : serveurs DNS, DHCP, WINS, LDAP, contrôleur de domaine

Serveurs de ressources

Serveurs proposant des services liés à l’usage direct d’une de ses ressources par le client pour le même usageExemples : serveurs de fichiers, d’impression

Serveurs d’applications

Serveurs proposant l’exécution d’une application particulière à distanceExemples : serveurs de terminaux, serveur Telnet

Serveurs de communication

Serveurs proposant un partage de ses capacités de communications vers l’extérieurExemples : serveurs d’accès distants (VPN)

19

FTPCouche Application...

TCP

IP

Ethernet

Ethernet

Application

Couche Transport

Remarque : ne pas mélanger avec un serveur d’infrastructure, un serveur de communication est plus proche d’un routeur

Serveurs spécifiques

Serveurs multimédia par fluxServeurs de base de donnéesService d’entrepôt de données mais avec une représentation permettant des tri et choix

Serveurs de groupware

Services utilisant des informations formatées à destination d’un utilisateur humainExemples : mail, gestion de documents…

Serveurs d’applications WEB

Serveurs de fichiers dans sa version statique simpleEvolution vers un partage des traitements (sur le client et sur le serveur)Evolution vers l’usage en tant qu’interface normalisée pour diverses applicationsClient à tout faire (pas de mise à jour du poste client)Evolution vers des interactions plus complexes

2.3.2 Serveurs d'infrastructures

Serveurs DHCPUtilité : attribution d’une adresse IP à un poste sans adresse fixe

Demande non ciblée (de type BroadCast : couche MAC et réseau) :Plusieurs serveurs possibles (redondance), il faut donc définir un protocole (protocole DHCP), au dessus de UDP. Les serveurs attribuent une adresse au poste via un bail (durée limitée), il doit donc redemander une adresse périodiquement.Comme les trames BroadCast sont non routées, il est nécessaire de définir un serveur relais si les serveurs DHCP sont sur un autre sous-réseau.

Le serveur DHCP relais va donc rediriger la demande en interceptant les requêtes DHCP puis les envoyer vers un ou plusieurs serveurs DHCP connu par le serveur relais avec une adresse fixe donc routable. Le chemin de retour repasse par le serveur relais ou est direct pour un renouvellement car alors les trames ont des adresses IP unicast.

20

ServeurDHCP

Client

ServeurDHCP

DHCP

Serveurs DNSUtilité : Résolution nom littéral vers adresse IP

Le protocole DNS est basée sur UDP ou TCP. Il met en oeuvre une recherche arborescente (par zone) en travaillant sur une base de données répartie. Chaque domaine possède un serveur DNS de zone locale qui définit la correspondance entre les noms des machines locales et leur adresse IP. Les demandes remontent vers un serveur racine puis sont renvoyées vers le serveur de zone locale qui donne l'information recherchée.

Serveurs d’annuaire LDAPUtilité : Services d’authentification

21

Client

Serveur DNSzone N-2

ServeurDNS localClient

Serveur DNSzone N-1

Zone locale :entreprise ou service

ServeurDHCP

Client

ServeurDHCPrelais

DHCP

1

2

4

5

3

Ce service permet entre autre une authentification centralisée, lorsque des clients veulent accéder à différents services (serveurs). Le protocole LDAP permet les communications entre serveurs. Sur les serveurs, les applications concernées par cette authentification doivent posséder un module LDAP pour aller interroger le serveur LDAP. C'est une architecture à plusieurs niveaux.

2.3.3 Serveurs de ressources

Serveurs de fichiersUtilité : partage de fichiers et centralisation du stockage.

C'est un service complexe car il est souvent transparent pour l’utilisateur, il est donc intégré dans le système d’exploitation. Les protocoles mis en oeuvre sont donc des protocoles spécifiques au SE (on retrouve ici la notion de Middleware).

Pour Windows, ce service est basé sur CIF(SMB)/NetBIOS.Pour UNIX, il est construit à partir des RPC et de NFS/XDR

Serveurs d’impressionUtilité : partage d'imprimantes et gestion centralisée des quotas

22

ServeurLDAP

Client

Serveurquelconque

LDAP

Serveur

Client

C'est aussi un service complexe car les périphériques sont considérés comme des fichiers dans les systèmes d'exploitation. Les services proposés sont par exemple : Spooler (désynchronisation de l'envoi et de l'impression), contrôle de volume (taille), contrôle horaire...

2.3.4 Serveurs d'applications

Serveurs de terminauxUtilité : travail à distance sur une autre machine

Dans ce cas, non seulement les données sont à distance, mais le code exécuté aussi. Le client n'est en fait qu'un terminal de contrôle et de visualisation.Console texte déportée : TelnetEnvironnement graphique déporté : console à distance Windows, XWindows sous UNIXLes problème de sécurité doivent être pris en compte : protocoles cryptés, accès restreint pour certains comptes.Le domaine des serveurs d'applications est un secteur en plein développement depuis quelques années, où l'externalisation des ressources informatiques se développent rapidement dans les entreprises (serveurs CITRIX, virtualisation...) sont des technologies de plus en plus présentes..

2.3.5 Serveurs de communication : serveurs d’accès distant

Utilité : partage et contrôle d'un accès longue distance (Internet)

23

Serveur

Client

Serveur

Client

Applicationsspécifiques

Les services sont comparables à ceux d'un routeur mais c'est une approche différente. Ce service englobe d'autres fonctionnalités : authentification, cacheEn général, ils ont moins de puissance qu'un routeur en terme de routage brut.

2.3.6 Serveurs de groupWare

Serveurs de MailUtilité : envoi, réception, stockage de messages

Même si le service global, met en oeuvre un échange final de type Client/Client, des services intermédiaires sont utilisés. Les serveurs fournissent donc les fonctions : Stockage temporaire, Aiguillage (DNS), Renvoie...Le service de messagerie est basé sur des protocoles asymétriques (l'envoi et la lecture des messages ne se fait pas avec les mêmes protocoles :

Envoi : SMTPRéception : POP, IMAP

Serveurs de base de données

24

Client

ServeurAccès distant

Internet

Protocoleshaut-débits :ADSL, ISDN

ServeurMAIL

Client

ServeurSMTP

Client

SMTPSMTP

POP/IMAP

Sauvegardemessages

Stockage de données, plus Possibilités de tri, recherche...Langage SQL,... Protocole encapsulant les requêtes et réponses

2.3.7 Autres.

Transfert de fichiers

Ne pas mélanger avec serveurs de fichiers, ici les fichiers sont physiquement transférés (donc il en existe 2 copies).Ce sont des protocoles plus simples qui permettent une compatibilité inter-plateforme : FTP ; TFTPet qui sont surtout utilisés à plus longue distance.

Serveurs WEB

25

Serveur de basede données

Client

SQL

Serveur

Client

FTP

Initialement les serveurs WEB étaient uniquement des serveurs de pages HTML statiques, leur fonction correspondait à un simple transfert de fichiers HTML. Maintenant, afin de permettre une personnalisation des pages affichées, les serveurs WEB peuvent envoyer des pages HTML crées dynamiquement (Calculs sur le serveur) ou contenant des scripts (fonctions) encapsulées (calculs sur le client). On s'oriente de plus en plus vers des architectures plus complexes, où de nombreux services sont apportés s'appuyant sur le protocole HTTP et les fonctionnalités des clients (navigateurs). En fait, les protocoles applicatifs précédents (mail, transfert de fichiers...) sont remplacés par le développement d'interfaces WEB, où chaque lien ou contrôle permet de mettre en oeuvre une fonction, la complexité est reportée sur le serveur, au bénéfice d'un client générique (exemple : WEBMail versus client de messagerie).

2.4 Lien Serveur - Système d’exploitation

2.4.1 Généralités

Les fonctionnalités serveur sont toujours supportés par un système d’exploitation. En effet, un serveur utilise des ressources gérées par le SE : disque, mémoire, UC, périphériques.Pour cela le SE met aussi à disposition des ressources logicielles : threads, sémaphores, descripteurs, priorités…, ainsi que des outils de surveillance, de statistiques...

L'intégration des fonctionnalités serveur au sein d'un SE peut se faire suivant différentes approches en fonction des caractéristiques initiales des SE. Actuellement, tous les SE serveur sont basés sur des SE standard : UNIX/Linux, Windows

2.4.2 Classes de Systèmes d’exploitation serveurs:

Windows : Evolution NT -> 2000 -> 2003 -> 2008, avec une approche basée sur des services intégrés.

UNIX :UNIX, LinuxLe système d'exploitation standard possède un serveur de fichiers natif (NFS), les autres services sont ajoutés comme des applications supplémentaires, plusieurs solutions peuvent alors être choisies.

26

Serveur HTML

Client

HTTP

2.4.3 Applications serveurs de windows 2003

Serveurs DNS, DHCP, WINSContrôleur de domaine (Active directory…)Serveurs de fichiers, d’impressionServeurs d’applications (IIS, ASP, NET)Serveurs de messagerie (Exchange Server 2003)Serveurs multimedia par fluxServeurs de terminauxServeurs d’accès distants (VPN)

2.4.4 Applications serveurs de UNIX/Linux

Serveurs de fichiers natifs (NFS)Gestion des comptes natifs (NIS)Serveurs DNS, DHCP, WINSServeurs d’applications : Apache...Serveurs de messagerie (sendmail,...)Serveurs de terminaux (protocole X11)Serveurs d’accès distantsServeur SAMBA (emulation windows), contrôleur de domaine

2.4.5 Part de marché

Pour les serveurs, le renouvellement est moins rapide que pour les postes clients (10 ans). Le choix est fonction du type ou de la taille des entreprises. Windows s’est positionné, depuis Windows Serveur 2003, sur le marché des gros réseaux.Windows 2000, 2003, 2008 : 50%UNIX/Linux : 50% (avec une prépondérance de Linux relativement aux UNIX propriétaires (Solaris...)Il existe aussi une offre importante de fabricants sur des systèmes Linux adaptés avec ajout de services supplémentaires (Novell...).

27

2.5 Questions concernant ce chapitre.

Les éléments de réponse sont en partie seulement dans le polycopié, l'usage de documents complémentaires est conseillé (livres, Internet, RFC...). De plus, les réponses ne sont pas uniques et donc aucune correction ne pourra être fournie...!

Question 1 : Donner pour chaque ressource un ou plusieurs exemples de serveurs l'utilisant :

- Espace de stockage- Temps UC (+ mémoire centrale)- Liaisons à des périphériques (Imprimantes, accès distant…)

Question 2 :Imaginer une architecture Client/Serveur 4 tier.Dessiner un schéma de principe Attribuer des fonctions cohérentes à chaque étageDessiner la mise en oeuvre réelle

Question 3 :Comment est mis en place la permanence dans le temps de la relation client-serveur :Au niveau de quelles couches OSI ?A partir de quels éléments ?

Question 4 :Dessiner les interactions qu'il peut y avoir entre les différents éléments d'un ordinateur en relation client/serveur :

- Noyau du SE- Périphériques- Drivers- Applications- Middleware- Logiciel de développement : API- Autres... (nécessaires pour reliés les précédents)

Question 5 :Donner des exemples de serveurs d'infrastructure

- Noms des Services- Fonctions principales

Question 6 :Donner des exemples de serveurs de ressources

- Noms des Services- Fonctions principales

28

Question 7 :Un Serveur d’applications c'est quoi ?Exemples (aller voir sur le WEB)

Question 8 :A quoi sert un serveur d’accès distant ?Donner un schéma de fonctionnement

Question 9 :Donner le parcours d'un mail envoyé par un utilisateur de la machine de gauche vers un utilisateur de celle de droite.Donner le parcours du même mail lu par un utilisateur de la machine de droite

Question 10 :Donner la liste des systèmes d'exploitation serveur connus ainsi que les différentes versionsSi vous aviez à choisir un système serveur lequel prendriez-vous ? Pourquoi, avantages/inconvénients

29

ServeurMAIL

Client

ServeurSMTP

Client

SMTPSMTP

POP/IMAP

Sauvegardemessages

30

Chapitre 3 : Technologie Serveurs

3.1 Introduction.

A côté de la connaissance des protocoles et des services en réseaux, un aspect important conditionne la mise en oeuvre pratique d'un système d'information : c'est la connaissance technologique des solutions proposées, celles-ci évoluant de manière très rapide, il est toujours difficile de les présenter sous une forme synthétique et de départager ce qui ne sera que des solutions fugitives d'avec des évolutions technologiques durables. La tendance actuelle (qui ne correspond qu'à un retour à des choix technologiques du début de l'informatique) est vers un retour à la centralisation des moyens informatiques (matériels et logiciels). Cette évolution est principalement conditionnée par l'augmentation de la complexité des systèmes d'information qui nécessite une gestion de plus en plus précise, et donc qui revient aux mains de services informatiques centraux et échappe de plus en plus à l'utilisateur, voire même à l'entreprise (développement de l'infogérance).

Deux aspects principaux peuvent être considérés :- les aspects matériels- les aspects logiciels

Nous verrons successivement ces 2 aspects dans ce chapitre, tout en gardant à l'esprit que l'un et l'autre sont liés.

En ce qui concerne l'aspect matériel, les évolutions vont aller dans plusieurs sens :- améliorer les performances- réduire le coût- améliorer la fiabilité.

Nous verrons, les évolutions en ce qui concerne le packaging des systèmes et la répartition des ressources de stockage.

Pour l'aspect logiciel, nous pourrons considérer :- l'amélioration de la fiabilité- un meilleur usage du matériel- une optimisation de la mise en oeuvre et de la maintenance

31

3.2 Packaging des serveurs.

L'augmentation continuelle du nombre de services intégrés dans un système d'information, et donc du nombre de serveurs a conduit à rechercher des solutions pour réduire la taille globale de l'infrastructure des serveurs. Partant de boîtiers desktop (adaptés à la pose de l'écran au dessus) ou tour les serveurs actuels ont migré vers des formats plus faciles à intégrer (rack...).

3.2.1 Serveurs en rack

Les serveurs en rack, souvent de format 19 pouces (en épaisseur multiple de 1,75 pouces : 1U), permettent de mettre plusieurs serveurs dans une seule armoire et de les regrouper avec d'autres catégories d'équipements tels les commutateurs. Ces serveurs, hérités des anciens ordinateurs au format industriel (en rack eux aussi), même s'ils n'en n'ont pas les protections contre les agressions extérieures, sont plus compacts et mieux protégés dans des armoires. Un certains nombre de fonctions annexes peuvent être gérées de manière collective (ventilation supplémentaire, onduleurs, clavier/écran via un commutateur...). Quoi qu'il en soit, chaque serveur possède toutes les fonctionnalités habituelles d'un ordinateur (connectiques pour les périphériques, disque dur interne...).

(Merci DELL Computer)

3.2.2 Serveurs Lame (Blade server)

Une évolution naturelle de cette intégration dans une armoire a été de partager un certain nombre de fonctions peu utilisées dans un serveur (clavier/écran/souris) soit utilisées intensivement mais de manière intermittente (carte réseau, disque dur...), soit facilement partageables (alimentation, ventilation…).Ceci a conduit à la réalisation de serveurs dont certains composants habituels dans un ordinateur ne sont plus intégrés mais mutualisés entre plusieurs serveurs : on les nomme serveurs "Lame". Ce ne sont plus alors des serveurs en boîtiers "rackable" mais tout simplement des cartes électroniques qui vont se connecter à une baie adaptée (spécifique à un constructeur). Sur ces cartes électroniques, les éléments dominants sont les processeurs et la mémoire centrale, une interface spécifique permettant d’accéder via le fond de panier aux périphériques partagés.

32

(1) Interconnection (switch Ethernet, Fiber channel…)(2) Blade Server (HP Proliant)(3) Power Supply

(Merci HP)

Les principaux avantages des serveurs lame sont : • le gain de place (30% plus petit qu’un serveur en rack),• un coût normalement inférieur, à condition de rassembler un nombre suffisant de serveurs

( 4 minimum) pour que le coût de l’armoire contenant l’alimentation, les périphériques, la ventilation soit compenser par l’économie sur les cartes serveurs (qui sont alors simplifiées),

• une moindre consommation (par suppression des périphériques inutilisés qui consommaient tout de même de l’énergie dans les serveurs standard), cet aspect étant en partie annulé par le fait que la densité de serveurs augmentant, il est nécessaire de prévoir une ventilation plus efficace

33

Les principaux constructeurs sont HP, IBM, DELL mais les autres constructeurs se sont aussi lancés sur ce créneau de marché en plein développement.

3.3 Packaging des éléments de stockage de masse

La mutualisation de certains éléments périphériques, s’il ne pose pas de problème pour les périphériques lents (clavier, souris…) conduit à envisager des solutions différentes pour ce qui concerne le stockage de masse (disque dur) où de nombreux accès quasi-simultanés peuvent avoir lieu.

L’architecture habituel de stockage sur un ordinateur est de type DAS (Direct Attached Storage), c’est à dire que le disque dur (ou les disques) est directement relié au bus périphérique avec des normes d’échanges de type ATA/IDE ou SCSI, ce deuxième type se retrouvant plus particulièrement sur les serveurs en raison de sa meilleure fiabilité. Quoi qu’il en soit, ce type d’architecture est assez mal adapté à la mutualisation de cette ressource car les bus parallèles associés ne permettent pas un multiplexage aisé. Des évolutions ont donc été nécessaires.

3.3.1 Serveur NAS (Network Attached Storage).

Un serveur NAS est une machine uniquement dédiée au stockage de données, les communications entre cette machine et les machines clientes se font sur un support réseau standard (si possible avec un bon débit, exemple : Gbit/s Ethernet). L’accès concurrent s’en trouve alors grandement facilité, car les normes réseaux le prévoient en général.

Les avantages principaux de ce type de solutions et la réduction du coût de stockage, une sûreté de fonctionnement plus facile à maîtriser, une facile de gestion des espaces de stockage.Un système NAS peut-être considéré comme un ordinateur orienté stockage, il fonctionne en général sous un système d’exploitation dérivé de systèmes d’exploitation standard (Windows, UNIX). Dans ces machines, la partie stockage est particulièrement soignée, en général basée sur des

34

disques Raid et des interfaces disques très performantes, la simplification du reste du système permet toutefois d’obtenir des bons rapports qualité/prix.

La liaison entre le serveur NAS et les serveurs qui l’utilisent, se fait via le réseau à l’aide de protocoles standard bien connus (NFS, SMB/CIFS..).

3.3.2 Stockage SAN (Storage Area Network)

Un ensemble de stockage SAN va lui aussi fournir des ressources de stockage à un ensemble de serveurs mais les échanges se feront à un niveau plus bas proche de celui des interfaces disques pour les systèmes DAS. Des protocoles supportés par les couches basses réseaux vont permettre des accès efficaces au système de stockage. On retrouve des protocoles comme Fiber Channel, iSCSI (le protocole SCSI sur TCP/IP), ou Fiber channel sur Ethernet. Comme l’accès se fait à plus bas niveau, les données stockées doivent avoir un format propre, ce qui ne permet pas de mixer l’accès pour des systèmes différents (Windows, UNIX…), le réseau de stockage est alors découpé en unités logique pour chaque type d’accès. L’intérêt du regroupement étant alors de pouvoir gérer, la redondance et les sauvegardes de manière unique. Cette solution se retrouve en particulier dans les systèmes basés sur des serveurs Lame où les serveurs communiquent via le fond de panier avec des unités de stockage.

3.4 Regroupement de plusieurs serveurs sur une même machine physique (virtualisation)

Dans le début de ce chapitre nous avons vu comment la technologie pouvait permettre de rationaliser la taille et certaines fonctions des serveurs, une autre possibilité est de faire cohabiter plusieurs serveurs sur la même machine physique.

Ceci ne pose aucun problème sur les machines actuelles qui ont toutes des systèmes d’exploitation multi-tâches. En effet, rien n’empêche de lancer simultanément un serveur DHCP, un serveur DNS et même un serveur de fichiers sur la même machine. Une des conditions de bon fonctionnement étant que les ressources demandées à la machine ne soient pas disproportionnées, mais il n’y a aucun problème en marche normal pour répondre à des demandes DHCP (au maximum quelques unes par secondes) ainsi qu’à requêtes DNS et en même temps de fournir un espace de stockage pour un certain nombre de clients.

Toutefois ce mode de fonctionnement pose des problème de fiabilité. En effet, supposons une machine cliente, un peu déréglée, qui va demander 500 renouvellements d’adresses par seconde et voici l’ensemble des services qui s’écroule…

35

La gestion multi-tâche peut en partie compenser ce problème, mais l’expérience montre qu’un programme ou service en difficulté sur une machine va gravement perturber le fonctionnement de toute la machine.

L’idée alors est de cloisonner de manière plus stricte les différents services proposer par la machine serveur. La solution mis en œuvre actuellement est de virtualiser chaque service dans une machine virtuelle spécifique mais hébergée physiquement par une seule machine.Un logiciel ou un système d’exploitation complet va alors servir de socle au fonctionnement global, chaque service étant alors fourni par une pseudo-machine dont les ressources sont fortement contraintes par une spécification initiale.

Plusieurs catégories de mises en œuvre peuvent être envisagées (merci Wikipedia pour les images) :

Une simple isolation de l’espace de travail :

Chaque service utilise les ressources du système d’exploitation mais avec un environnement de travail isolé. Cela permet entre autre de donner certains droits sans remettre en cause la stabilité de fonctionnement du système global. Certains antivirus imposent aux applications externes de fonctionner avec ce schéma là (SandBox).

Une virtualisation du serveur (ou plus une émulation) :

36

En ce qui concerne l’aspect serveur, l’émulation n’apporte pas de réelles performances, seule la vraie virtualisation peut-être intéressante. On a alors un accès direct (mais contrôlé !) de toutes les machines à la mémoire et à l’unité centrale et un accès via un pseudo fichier réservé dans le système d’exploitation hôte pour les accès disque. Les accès aux périphériques d’entrée-sortie se font via des canaux qui viennent s’insérer entre l’OS invité et l’OS hôte.

On retrouve dans cette catégorie des produits VMWare, Microsoft (Virtual PC) et Oracle (VirtualBox).Dans une architecture virtualisée, chaque serveur virtuel se retrouve isolé, seul l’OS hôte accède à toutes les ressources puisqu’il voit les ressources disques comme des fichiers et qu’il peut modifier les modes de fonctionnement des périphériques directement. De ce fait, il semble déconseillé de l’utiliser lui aussi pour héberger des services, il est donc sous utilisé.

3.4.1 Les Hyperviseurs

Afin de ne pas consacrer trop de ressources pour l’OS hôte on peut le réduire uniquement à son rôle on parle alors d’Hyperviseur.

L’OS hôte ne va alors fournir que le support d’interface avec le matériel pour les OS invités, ainsi que les outils permettant de gérer la supervision de l’hypervision ! C’est forcément plus efficace.

On retrouve des solutions comme Xen, VMWare, et aussi un Hyperviseur Microsoft sur les serveurs Windows Server 2008 (ou 2003 avec la mise à jour 2005) : HyperV.

Souvent la virtualisation est mise en œuvre sur des serveurs qui vont apporter des services applicatifs complets à des clients léger (comme des solutions Citrix). Cette évolution vers la centralisation du traitement sur des postes spécifiques est importante actuellement et représente un retour aux architectures informatiques d’avant les postes personnels (PC).

37 38

Chapitre 4 : Mise en œuvre d’une

infrastructure informatique

(Création, modification)

4.1 Objectif de ce chapitre.

Ce chapitre présentera une introduction à la méthodologie de conception et d’implémentation d’un système informatique d’entreprises. Plusieurs points seront abordés :- Méthodologie générale- Etude des éléments de choix et des contraintes techniques

4.2 Objectifs d’un projet d’infrastructure

Ce paragraphe développe une approche projet du point de vue des besoins, c’est à dire une vision client.

A l’heure actuelle, un des points névralgiques d’une entreprise est son système informatique. La définition de la création ou de l’évolution d’un tel système doit aussi être vue sous un aspect global et non pas seulement technique.D’un point de vue hiérarchique, on peut décomposer les objectifs d’un projet d’infrastructure en plusieurs niveau.

Objectifs généraux

Objectifs de hautniveau

Objectifs de niveauintermédiaire

Objectifs de niveauintermédiaire

Objectifs de niveauintermédiaire

Entreprise

Sites/services

Objectifs de basniveau

Objectifstechniques

Objectifs de basniveau

Objectifstechniques

Objectifs de basniveau

Objectifstechniques

Les objectifs généraux sont des objectifs de gestion, de production,… au sein de l’entreprise donc complètement indépendants des contraintes informatiques. Par exemple, la mise en œuvre d’une gestion centralisée de toute l’activité de l’entreprise va faire appel à un ERP (Entreprise resource

39

planning) progiciel de gestion intégrée, solution informatique mais uniquement définie par des besoins liés à l’activité de l’entreprise (comptabilité, RH, production, commerciale…). Cette mise en œuvre d’un ERP va certainement modifier profondément la structure informatique de l’entreprise et donc conduire à la définition d’un projet d’infrastructure informatique.

Les objectifs de haut niveau concernent aussi globalement l’entreprise : ils correspondent à des choix globaux en cohérence avec un mode de fonctionnement et des besoins déterminés.Par exemple : un taux de disponibilité pour une entreprise fonctionnant 24H sur 24H, des niveaux d’intercommunicabilité pour une entreprise multi-sites, une sécurisation des communications pour une entreprise ayant des contraintes de confidentialité fortes…

En descendant dans l’arborescence on trouve ensuite des objectifs de niveau intermédiaire qui sont ceux relatifs à un site et/ou un service.Par exemple : un délai d’assistance technique celui étant fonction de l’éloignement du site relativement au site hébergeant un service informatique centralisé, la protection des données d’un service spécifique (Ressources humaines…), des accès aisés aux données pour les commerciaux en déplacement…

Au dernier niveau on trouve deux catégories d’objectifs : - des objectifs de bas niveau (techniques) mais concernant les utilisateurs, par exemple : utilisation de la dernière version d’Access, passage à un logiciel libre pour la messagerie- des objectifs pratiques qui sont liés à la gestion informatique et donc propre au service informatique : systèmes d’exploitation des serveurs, matériel de sauvegarde…

4.3 Caractéristiques d’un projet d’infrastructure

Ce point concerne les caractéristiques de mise en œuvre du projet, hors aspect technologique, il est le fruit d’une négociation entre le client et le concepteur/réalisateur (société de service ou service interne à l’entreprise). Il est commun à tous types de projets.

On y trouve :- La définition des délais et phasage

Phasage de l’opération globalePhasage de chaque élément

- La définition des équipes de conception et déploiement (et aussi de maintenance)Implication de la sous-traitanceRecherche de personnels temporairesPrise en compte du travail quotidien des personnels internes (temps libéré pour le projet)

- La définition de la portée du projetPartie de l’infrastructureTout l’existant (client et serveur…)Différentes applications

- La définition du budgetAchat de matériel/logicielFacturation des sous-traitants…

Cette partie va servir de base économique au contrat, le concepteur/réalisateur doit évaluer le coût global du projet (étude, mise en œuvre, formation) avant d’en faire une étude technique détaillée. Dans le cadre de très gros projet avec appel d’offres, l’évaluation du coût global et de

40

chaque partie peut-être sous-traitée à une entreprise spécialisée qui va proposer des solutions adaptées au besoin pouvant correspondre à un budget prévisionnel déterminé.

4.4 Différentes phases de la conception et de la mise en oeuvre

Nous allons maintenant détailler l’aspect méthodologique de la mise en œuvre d’un projet d’infrastructure informatique. Ce point concerne l’équipe projet agissant en terme de sous-traitant (interne ou externe) vis à vis de la direction et des autres services de l’entreprise.

On peut décomposer la conception et la mise en œuvre en 6 phases principales.

Phase de découverte

Phase de conception

Phase de planification

Phase de prototypage

Phase pilote

Phased’implémentation

Phase de découverteC’est l’évaluation de l’existant qui n’existe pas forcément dans une entreprise qui a vu évoluer son système d’information de jour en jour, elle récapitule :

• L’architecture globale du réseau• Les équipements réseau• Les équipements serveur• Les équipements client• Les applications• Les besoins des utilisateurs déjà satisfaits

C’est une phase assez simple si l’entreprise possède moins de 200 postes avec un ou deux sites et du matériel standard et identique.C’est une phase complexe dans le cas d’une grande entreprise avec de nombreux sites et des équipements hétérogènes et spécifiques.

Le résultat de cette phase est compilé dans plusieurs documents :• Inventaire des équipements et machines,

41

• Diagrammes de réseaux : emplacement de chaque équipement…, • Documents de configuration (correctifs, service pack,…) : un logiciel d’inventaire peut être

utilisé pour cette partie.

Phase de conceptionC’est la partie technique clef du projet. On va y retrouver la définition des choix techniques généraux et spécifiques du nouveau projet :

• Architecture globale• Choix des technologies• Nombre de serveurs• Position géographique

Elle aboutit à un certain nombre de documents de conception qui vont déterminer pour chaque sous-partie : Objectifs ; Contexte ; Approche ; Etat final ; Budget estimé

Phase de planificationCette phase ne concerne que la planification de la mise en œuvre, elle est donc contrainte par le document de phasage complet du projet. Elle définit dans un document de migration les étapes pour parvenir au système final.C’est une phase importante car même pendant la mise en œuvre du projet, le fonctionnement de l’entreprise ne doit pas être perturbé (ou au minimum) par les évolutions du système informatique.De la même manière que dans le plan global du projet, on peut utiliser des outils tels que les diagrammes de Gantt.

Phase de prototypageElle permet la création en laboratoire d’un ensemble regroupant tous les éléments essentiels du système (isolé du système de production) pour faire des tests et des réglages. Si la conception a été correcte, elle ne doit conduire qu’à des modifications mineures des choix technologiques. Elle est souvent effectuée dans les SSII par des ingénieurs débutants.

Phase piloteCette phase va permettre la mise en œuvre en production sur un sous-ensemble réduit d’utilisateurs des solutions retenues pour la nouvelle infrastructure informatique.Elle concerne par exemple dans un premier temps, 5 à 10 utilisateurs pilotes, puis 10% des utilisateurs.

Phase d’implémentationC’est la phase finale de la mise en œuvre (mais non celle du projet). Elle va conformément au document de planification conduire au déploiement total de la solution informatique. Elle inclut en général la formation des utilisateurs et les dernières modifications suite aux retours éventuels des utilisateurs.

Ensuite le projet rentre dans sa phase d’exploitation avec la mise en œuvre d’un support permanent pour pallier les défauts constatés durant l’usage régulier de l’infrastructure informatique. Un support efficace et réfléchi dès le début du projet est une condition nécessaire au bon fonctionnement du système informatique. Ce support peut être assuré par l’équipe de développement (ce qui permet de gérer au mieux des charges de travail différentes suivant les phases du projet) soit par un service spécifique, les informations techniques doivent alors transiter d’une équipe à une autre.

42

Le déroulement présenté ci-dessus n’est qu’un exemple de démarche, chaque entreprise peut l’adapter. Des méthodologies spécifiques sont aussi imposées par certains constructeurs (Microsoft) pour que l’entreprise, qui réalise le projet, puisse être certifiée pour l’implantation de projets faisant appel aux technologies de ces constructeurs.

4.5 Organisation des différents serveurs

Après avoir vu l’aspect gestion de projet, nous allons maintenant nous concentrer sur la partie technique de la conception et plus particulièrement sur le choix des serveurs et leur organisation. Plusieurs aspects sont à considérer, tout d’abord concernant les machines serveurs :

- L’organisation logiqueElle va être la conclusion de l’étude concernant le mode de fonctionnement désiré pour l’infrastructure du système informatique en conformité avec les différentes catégories d’objectifs définies dans la demande initiale. Elle concerne :

L’organisation en domainesLe découpage des utilisateurs et des groupesLes différents droits d’accès aux ressources…

- L’organisation des servicesElle va définir en particulier les différentes catégories de serveurs qu’il sera nécessaire de mettre en place pour constituer l’infrastructure informatique. On peut dresser une liste (non exhaustive) des différents serveurs que l’on peut rencontrer :

Serveurs d’infrastructure : DNS, DHCP, LDAP…, contrôleur de domaine, authentificationServeurs de ressources : fichiers, impressionServeurs d’accès distant, Serveurs mandataires (proxy, cache)Serveurs d’applications : terminal server, CITRIX...Serveurs ftp, http, mail…Serveurs de base de donnéesServeurs d’installation des clientsServeurs de ressources tierces (liés à d'autres services et non directement accessibles)Serveurs de sauvegarde

- L’organisation physiqueElle va traduire sous forme physique la mise en œuvre des différents services sur les différentes machines serveur :Chapitre1 : Le regroupement de différentes fonctions sur le même serveur,Chapitre2 : La localisation physique des services et leur duplication éventuelle…

Le bon fonctionnement de cette architecture de serveurs doit aussi s’appuyer sur une organisation des communications adaptée qui va imposer des choix sur les infrastructures de communication concernant les couches basses (jusqu’à Transport) :

- Liens réseaux et charge de ces liens- Equipement réseaux (routeurs, commutateurs…)

Un dernier aspect à considérer est tous ce qui est lié au bon fonctionnement face à des contraintes extérieures. Cela concerne la fiabilité ou sûreté de fonctionnement (défaillances des équipements et influence de l’environnement extérieur : bruit, parasites) et la sécurité (tentative d’accès aux données ou perturbation du bon fonctionnement par des personnes extérieures –ou intérieures- à l’entreprise). Cela va conduire à définir deux catégories d'architecture :

43

- une architecture liée à la sûreté de fonctionnement (redondance) - une architecture de sécurité pour faire face à des intrusions ou à des actions interdites

On pourrait compléter ces deux aspects par une architecture de surveillance permettant de manière active d’analyser les problèmes et de faire évoluer les deux précédentes.

4.6 Les paramètres de dimensionnement des serveurs

Si les choix précédents peuvent être fait préalablement à toute mise en œuvre de l’infrastructure, il n’en est pas de même pour le dimensionnement des machines et dans une moindre mesure des équipements de communications.

Concernant les machines serveurs, 4 ressources principales sont à considérer :• Stockage disques• Mémoire centrale• CPU• Connexion réseaux

Il est difficile de réaliser des prévisions précises de l’usage de ces ressources surtout pour l’utilisation de l’unité centrale, ce qui affecte directement les performances des services.Pour la prévision des ressources nécessaires, on peut utiliser des modèles simplifiés et prendre en compte une bonne marge de sécurité. Un des paramètres importants est le rythme de l’évolution des besoins qui est difficilement prévisible.

Les paramètres effectifs sont :• la possibilité de fournir le service• le délai avec lequel il est fourni• la fiabilité du service

Il est en général important de déterminer le facteur limitant.

(4) Stockage disques 4 paramètres physiques principaux peuvent être définis :

• La taille,• Le délai d’accès à une information,• Le débit en continu• La sûreté de fonctionnement

Il est assez facile (relativement aux autres ressources) de modéliser les besoins de stockage en terme de taille. Il faut tout de même considérer qu’un bon usage d’un disque est limité à environ 80% de sa capacité (pour ne pas introduire trop de fragmentation), valeur indicative car elle va dépendre de l’usage du disque (données utilisateurs ou applications installées à demeure).

Le délai d’accès à une information (contrainte mécanique) sur un disque évolue beaucoup plus lentement que la capacité ou le débit. Ce paramètre va influer si le disque est utilisé pour des accès nombreux à des fichiers différents (pas de possibilité de cache), le nombre d’utilisateurs connectés à un instant donné à donc une influence forte, ainsi que la catégorie d’applications par exemple :

• serveur d’applications (fichiers demandés par une machine)• serveur WEB (fichiers demandés par un être humain).

44

Le débit est un mélange de caractéristiques mécaniques et électriques (nombre de têtes et débit du bus). Il va être surtout prépondérant pour des transferts de données de taille importante (images, vidéo…).La sûreté de fonctionnement est assurée par des unités de disques en redondance (disk RAID) :RAID0 : disque en parallèle pas d’augmentation de la fiabilité mais de la vitesseRAID1 : miroitage complet, vitesse identique, sécurité doubleRAID5 : parité répartie, permet de reconstruire le contenu d’un disque sur N si problème (3 minimum).RAID6 : même chose que RAID5 mais avec gestion de 2 problèmes sur 2 disques.

(5) Mémoire centrale 2 paramètres sont à considérer :

• La taille• La vitesse d’accès

En fait ces paramètres peuvent être multiples car l’organisation de la mémoire centrale fait souvent appel à une architecture complexe de mémoire cache (à plusieurs niveaux). Il reste que la principale différence de temps d’exécution d’une requête quelconque est conditionnée par le fait qu’elle fasse appel à la mémoire virtuelle (disque) ou non.

(6) CPU Les unités d’évaluation de la puissance d’un CPU (MIPS, Mflop) ne rendent qu’imparfaitement compte de sa puissance réelle. L’adaptation d’une unité centrale à un besoin sur une machine de type serveur ne se vérifie en général que d’une manière pratique.

(7) Connexions réseaux L’adéquation de ce paramètre à un besoin peut être plus facilement déterminé. Une bonne connaissance des protocoles liés à chaque service permet de déterminer un débit probable en ce qui concerne les échanges sur un serveur. Le type d’infrastructure réseau associée peut avoir une influence sur les résultats. Dans un réseau totalement commuté (ce qui est le cas dans une infrastructure nouvelle actuellement), le débit sur une liaison vers un serveur est uniquement à destination de ce serveur. Elle représente en général la somme de toutes les communications à destination du serveur partant de chaque client connecté à un instant donné. Ceci explique que dans la mesure du possible le lien switch-serveur doit avoir un débit plus élevé que les liens switch-client au moins pour un serveur de fichiers.

4.7 La méthodologie de dimensionnement des serveurs

Deux approches peuvent être employées pour définir a priori le dimensionnement d’un serveur :• La modélisation, c’est à dire l’établissement de relations mathématiques qui vont à partir de

données d’entrées (nombre d’utilisateurs, puissance des machines clients…) de calculer les besoins de grandeurs de dimensionnement.

• La mesure, qui consiste, dans la « mesure » du possible à évaluer les capacités d’un serveur mis en situation réelle à répondre à une certaine demande. Un des problème étant de configurer le fonctionnement du système de test afin d’approcher la situation réelle forcément inconnue.

Ces deux approches font appel à une bonne dose d’approximation, soit liée à la représentation mathématique du fonctionnement du serveur, soit à la réalité de la mise en situation avec un nombre limité de machines tests.

45

La modélisation permet facilement de modifier les paramètres de fonctionnement et ne nécessite pas un système opérationnel, mais elle est forcément très réductrice relativement à un vrai système même dans des conditions artificielles.Une approche couplée peut aussi être envisagée, ce qui permet de définir des paramètres de modélisation à partir de mesures effectuées en réel.

En pratique, les choix sont souvent effectués à partir de l’expérience des concepteurs (Exemple : pour un serveur WEB à 100 accès simultanés, il faut 1GO de mémoire, un tel processeur…). Ensuite, dans la mesure du possible, un bon facteur de sécurité est retenu surtout dans le cas où les ressources supplémentaires utilisées n’engendrent pas un coût supplémentaire important.

Lorsqu’on dispose d’un système existant, il est possible d’utiliser des outils de mesure (Performance Monitor sous Windows Server 2003 par exemple) pour évaluer les besoins d’une nouvelle architecture basée sur le même principe.

Quelques données

Prendre en compte que la durée de vie d’un serveur est, en général, plus longue que celle d’un client :

• un client : 5 ans maximum• un serveur : peut aller jusqu’à 10 ans

RAM :En dix ans la capacité de la RAM est multiplié par 100

Disque :En dix ans la capacité d’un disque est multiplié par 30En dix ans le débit est multiplié par 3En dix ans le temps d’accès est divisé par 3

Bande magnétique :Ratio actuel du coût bande magnétique/disque dur = 1/2

Disque optique :Leur fiabilité n’est pas très grande (10 ans maxi pour un stockage sur)

Réseaux :Besoins en bande passante triple tous les 3 ans (cela dépend à quel niveau du réseau).Temps d’envoi sur le réseau supérieur au temps d’accès disque (cache en mémoire sur les serveurs).Un client un peu puissant peut saturer le réseau si équilibre lien client/switch serveur/switch. Augmentation de la puissance des clients : passage d’un mode fonctionnement en alternance, en un fonctionnement en rafale

46

Chapitre 5 : Résolution de noms

(DNS)

5.1 Objectifs de la résolution de noms et historique.

L'existence de plusieurs systèmes d'adressage suivant les couches du modèle OSI conduit à mettre en oeuvre des mécanismes de résolution d'adresses, c'est à dire de correspondance entre une adresse d'une couche donnée et celle d'une autre couche. Par exemple, le mécanisme ARP permet à partir de l'adresse couche Réseau (IP en général) de retrouver l'adresse universelle sous-couche MAC pour pouvoir envoyer physiquement le paquet. De la même manière, au niveau applicatif il est d'usage d'employer des adresses littérales (istapc23.univ-st-etienne.fr, portail.univ-st-etienne.fr, ...) pour identifier les machines physiques, mais pour envoyer effectivement des données à destination de cette machine il est alors nécessaire de transformer cette adresse littérale en adresse IP avant d'utiliser une résolution vers une adresse MAC pour l'envoyer physiquement.

Remarque : dans les modèles de réseaux (OSI, IEEE) les autres couches n'ont pas d'adresses véritables. Les couches LLC et Transport possèdent un système de point d'accès (SAP ou ports) mais qui sert uniquement au multiplexage au sein d'une même machine.

Au début des années 1980, le faible nombre de machines reliées à un réseau donné permettait de gérer la relation nom littéral<->adresse IP de manière manuelle sur chaque machine, via un fichier regroupant tous les noms des machines inter-connectées. Ce fichier (hosts.txt) pouvait être renseigné sur une seule machine puis recopié sur toutes les autres via un protocole comme ftp (File Transfert Protocol). Cette gestion décentralisée ne pouvait répondre à la résolution d'adresse lorsque l'inter-connexion des réseaux fut devenue une pratique courante. Il a donc été nécessaire de mettre en place un protocole permettant cette résolution. Un mécanisme proche d'ARP ne pouvant être envisagé pour une résolution d'adresse haut-niveau (donc inter-réseaux) car il nécessite des BroadCast qui ne peuvent être routés. Le protocole DNS a donc été conçu à partir d'une architecture de serveurs associés à des domaines de gestion. Les premières spécifications ont vu le jour en 1983, la normalisation sous le nom DNS en 1987.

47

Adresse litttérale

Adresse IP

Adresse physique

Application

Couche Réseau

Couche MAC

DNS

ARP et InvARP

5.2 Définitions

5.2.1 Mécanisme de résolution d'adresses via le protocole DNS

Le système DNS (Domain Name Server) est une structure hiérarchique à plusieurs niveaux, les informations sont réparties dans des bases de données locales à chaque domaine. Pour des raisons de compatibilité, il y a une coexistence avec une résolution basée sur un fichier local à chaque machine (fichier hosts). Les principes et la mise en oeuvre du DNS ont été définis dans de nombreuses RFC (Request For Comment) dont initialement dans les RFC1034 et 1035.Le système DNS est construits autour de 4 constituants :

- un schéma de nommage- une base de données distribuées (gestion décentralisée)- un protocole de résolution (mécanisme et trames)- une mémorisation locale dans un cache pour améliorer les performances

5.2.2 Etapes de mise en oeuvre

Nous allons décrire plus en détail les différentes étapes nécessaires pour parvenir à un système de résolution d'adresses effectif, c'est à dire :

- l'organisation du nommage- la définition des autorités et des délégations- le stockage des informations locales (serveur DNS)- la résolution d’un nom (protocole) et l'orientation des demandes

a) Schéma de nommage

Vu le nombre grandissant de machines, un espace de noms à plat (à un seul niveau) aurait été rapidement impossible à gérer. Une structure hiérarchique multiple a donc été définie initialement en fonction de la position géographique des machines ou du type d'organisations auxquelles elles appartiennent.Le nom complet de chaque machine est un nom unique (FQDN : fully qualified domain name) composé de plusieurs champs séparés par des points. La racine de la structure arborescente est située à droite du nom.Exemple (fictif) : istapc123.tse.univ-st-etienne.frnom de domaine de niveau 1 : fr, ce qui correspond à une identification géographiquenom de domaine de niveau 2 : univ-st-etienne ce qui correspond à l'organisation globalenom de domaine de niveau 3 : tse, ce qui correspond au service à l'intérieur de l'organisationnom de la machine : istapc123

Concernant les extensions de premier niveau (TLD : top level domain), qui doivent être organisées au niveau international (ICANN), un double découpage a été défini initialement suivant :

- des critères géographiques (240 extensions de premier niveau: fr ; jp ; uk ; de …)- des critères de type d'organisation, d'abord utilisés aux USA (14 extensions : com ; edu ; mil ; gov ; org ; net ...)

En fait, le FDQN de l'exemple (fictif) précédent serait "istapc123.tse.univ-st-etienne.fr." (bien remarquer le point à la fin) car dans la hiérarchie il existe un niveau supérieur (niveau racine) au dessus de fr.

48

Plus récemment (année 2000) une libéralisation de ces extensions de premier niveau a eu lieu avec la création de nouvelles extensions. L'évolution actuelle étant orientée vers encore plus de choix, entre autre en introduisant la possibilité d'intégrer des caractères nationaux dans les noms de domaine, avec des problèmes de gestion, celle-ci ne pouvant plus alors être assurée de manière centralisée par l'ICANN.

L'arborescence des noms est en pratique relativement peu hiérarchisée, le 2ème niveau étant très découpé, la plupart des noms de domaines s'arrêtent au 2ème niveau ou au 3ème niveau pour de grandes organisations.

Exemple d'arborescence (fictive):

b) Gestion décentralisée : définition des autorités et des délégations

Le choix ayant été fait d'une gestion décentralisée, les règles de fonctionnement doivent être strictes pour permettre une interopérabilité complète. La base de données contenant les liaisons nom de machine-adresse IP étant distribuée entre les différentes organisations ayant un nom de domaine, celles-ci doivent avoir la responsabilité du respect de règles contraignantes.

Chaque feuille du schéma de nommage définit un domaine ou un sous-domaine par découpage du domaine de niveau supérieur.La gestion de chaque sous-domaine est déléguée à une autorité (une personne ou un groupe de personnes : identifié par un email et inscrit à l'ICANN ou dans un organisme de niveau inférieur), cette gestion comprend :

- Mise à jour de la base de données locales- Contact avec les serveurs de niveau supérieur (principalement les serveurs racines)- Attribution et nommage des sous-domaines de niveau inférieur- Vérification du bon usage des gestionnaires de niveau inférieur

D'un autre point de vue (mais cela revient quasiment au même), la structure hiérarchique définit des zones : un niveau donné est composé de zones indépendantes, les zones s’emboîtent au fur et à mesure de la montée dans l’arbre. Chaque zone possède une autorité responsable (Name Server), celle du sous-domaine de plus haut niveau dans la zone considérée. Plusieurs zones peuvent avoir la même autorité (de plus en plus d'organisations possèdent plusieurs schémas de nommage (telecom-st-etienne.fr, telecom-st-etienne.fr, istase.com...) qui peuvent être de simples alias ou des groupes de machines différentes.

49

defr

Root (InterNIC)

com …

.univ-st-etienne

.istase

Au sein de sa zone, l’autorité peut tout faire :- Déléguer l’autorité sur une partie de la zone (sous-arbre)- Modifier l’architecture complète du sous arbre dont il est responsable

Exemple (virtuel...) :istase.univ-st-etienne.frL'autorité "fr" attribue à l’Université Jean Monnet l'autorité sur le sous domaine « univ-st-etienne.fr »L'autorité "univ-st-etienne.fr" attribue un nom de sous domaine «istase» à l’ISTASELe sous-domaine "istase" gère le nommage de toutes ses machines avec : machinexxx.istase.univ-st-etienne.frL'autorité "istase" peut aussi créer des sous-domaines : « tpreseau.istase.univ-st-etienne.fr »A chaque sous-domaine créé, il y a une autorité responsable.L'AFNIC (www.afnic.fr) est l’autorité responsable de .fr

c) Base de données distribuée (serveur DNS)

La base de données complète du système DNS est construite autour d'une base de données distribuée (au sens premier du terme) dans chaque zone. Cette base de données est constitué de fichiers contenant :

- la liste de correspondance (noms-adresses IP) des machines locales au sous-domaine.- une liste des machines permettant de remonter au niveau racine de l'arbre.- une liste des machines permettant de récupérer les informations du niveau inférieur.- des correspondances vers d'autres machines en particulier pour gérer une redondance, ou définir des redirecteurs pour des zones proches.

Très souvent ses informations sont entrées de manière manuelle (ou via le DHCP si on utilise un DNS dynamique). Elles sont stockées dans un fichier (plutôt des fichiers) dans un format variable (souvent texte sous UNIX, base de données Active Directory ou texte sous Windows). Ces fichiers sont appelés fichiers de zone.Un démon (programme résident) va utiliser cette base de données lors d’une demande de résolution. Seul le format des PDU de demande et de réponse doit être normalisé.

Exemple (de principe) de fichier de zone de recherche directe (contenu dans un serveur DNS) :# Correspondance nom d ’hôte ->Adresse IP istapc23 host 161.3.51.123istapc45 host 161.3.51.145passerelle host 161.3.1.1annexe host 162.12.21.1…C’est un exemple de principe..., malheureusement la syntaxe est un peu plus compliqué...

De la même manière, on définit un fichier de zone pour une recherche inversée. Le fichier de zone de recherche directe n'est pas toujours utilisé (en particulier sous UNIX). Cela permet entre autre de gérer correctement les alias (il peut y avoir plusieurs noms pour une adresse IP unique). Exemple de fichier de zone de recherche inversée#Correspondance Adresse IP -> nom d ’hôte#Un fichier par sous-réseaunom : 51.3.161.in-addr.arpa161.3.51.23 PTR istapc123161.3.51.12 PTR istapc112

50

...

d) Mécanisme de résolution

Avant de voir en détail les mécanisme de résolution, nous allons en présenter les grandes lignes.

Lorsqu'il a besoin de déterminer une adresse IP à partir d'une adresse littérale, un poste interroge son ou ses serveurs DNS (L'adresse IP de ce serveur est forcément connue par le poste : soit configurée manuellement soit via un autre protocole tel DHCP).Si le serveur DNS ne connaît pas la réponse, il va retransmettre la demande vers un autre serveur (ayant une base de données plus larges) en général placé plus haut dans l'arborescence. Si le nouveau serveur interrogé ne connaît pas la réponse, il retransmet vers un autre serveur., etc…De ce fait, les demandes remontent d'abord l'arbre puis le redescendent pour trouver le serveur du domaine considéré qui va alors donner l'information.Ce principe général est mis en place d'une manière un peu différente (souvent on saute directement toutes les étapes de remontée), entre autre pour éviter un cheminement trop complexe.

Pour bien comprendre le mécanisme réel, il est nécessaire de définir des types de serveurs DNS :

- Serveurs de noms locauxCe sont les serveurs directement liés au sous-domaine. C'est vers eux que vont toutes les requêtes DNS des postes du sous-domaine. Ils ont en charge la résolution des adresses demandées.

- Serveurs de nom racineCe sont les serveurs liés à l’infrastructure globale d’Internet. Ils sont la clef du mécanisme DNS. Ces serveurs sont au nombre de 13 dans le monde (on peut en obtenir la liste via ftp.rs.internic.net : fichier cache.dns), ils peuvent être relayés localement par une technique de routage particulière (Anycast). Ces serveurs doivent connaître tous les serveurs de domaine de premier niveau.

- Serveurs de nom de source autoriséeIls sont aussi liés à une zone (ils peuvent être souvent aussi serveur de nom local si c'est une zone de plus bas niveau). Ce sont eux qui contiennent les véritables correspondances IP-adresse littérale. Il y en a au moins 2 (un primaire et un secondaire pour redondance).

La distinction entre serveur de noms local et serveur de source autorisée correspond à 2 fonctions complètement différentes. Un serveur de nom local est la machine qui reçoit les requêtes DNS de la part des postes locaux et va le rediriger vers des serveurs de nom d'autres domaines, le serveur de nom de source autorisée et celui qui répond aux requêtes DNS (c'est lui qui a les informations). Dans un réseau de petite taille et de dernier niveau, une seule machine peut remplir les 2 rôles. Dans une zone de niveau plus élevé, ce sont forcément 2 machines différentes, car on ne va pas mélanger les demandes venant de quelques machines raccordées à un zone de niveau élevé avec les demandes venant de l'extérieur pour déterminer les serveurs de zones de niveau inférieur.

Schématisation du mécanisme réel de résolution DNS :- Un poste interroge son serveur de noms locaux (l'adresse IP de ce serveur est configurée sur chaque poste)- Le serveur local interroge un serveur racine

51

- Le serveur racine répond au serveur local (Il donne en réponse l’adresse d’un serveur de noms de source autorisée de niveau le plus haut connu (au moins niveau 1) relatif au domaine demandé- Le serveur local interroge ce nouveau serveur- Si ce dernier a la réponse, le serveur local la renvoie au poste client. Sinon le nouveau serveur donne l’adresse d’un serveur de niveau inférieur. Le serveur local renvoie la demande au serveur de niveau inférieur...

Ce mécanisme peut être simplifié si le serveur de noms locaux possèdent des redirecteurs (serveurs ayant des réponses directes pour certains domaines). En particulier, un lien entre le serveur de noms locaux et le serveur de source autorisée locale permet d'éviter de remonter une requête locale vers le serveur racine.

e) Type de recherche

Dans la schématisation précédente on peut remarquer 2 manière de fonctionner : soit le serveur se charge de la résolution complète soit il renvoie le problème à un autre. On aboutit à 2 types de recherches différentes :

- Une recherche récursive : la machine qui demande ne voit revenir que la réponse - Une recherche itérative : la machine qui demande peut recevoir une réponse de type « va voir ailleurs »

Les recherches récursives sont souvent utilisée par le poste client demandeur, les recherches itératives souvent utilisée par les serveurs DNS en particulier lorsqu'ils communiquent avec les serveurs racine (pour éviter une surcharge de ceux-ci). Les 2 types de recherche coexistent, les mécanismes sont donc assez complexes pour pouvoir assurer une rapidité de réponse suffisante sans trop charger les différents serveurs. Le mode (itératif ou récursif) est négociée entre le demandeur et le répondeur. Il est fortement déconseillé de faire une demande récursive sur un serveur racine car cela peut être source de saturation

Un exemple :Récursive : 1/5 ; Itérative : 2 ; 3 ; 4

f) Mémorisation locale

Lors d’une résolution réussie, les serveurs DNS stockent dans une mémoire locale les correspondances, ceci est aussi valable pour le poste client.

52

ServeurDNS local

.fr

Serveur racine

1

Client

.univ-st-etienne.fr

Poste istase

2

3

4

56 : communication

Serveur autorisé

Serveur autorisé

Cette mémoire cache garde ces informations pour une durée assez longue (2 jours par exemple). En effet, les correspondances ne changent pas vite (sauf machines en DHCP…). A ce moment là, le serveur qui transmet les informations, les transmets sous réserve (source non autorisée lorsqu’elles sont issues d’un cache et non pas d’une réponse par le serveur autorisé).Ce mécanisme réduit fortement les charges sur les différents serveurs DNS (entre autre les serveurs racine). En cas de problème (changement d'adresses de certaines machines), il est toujours possible de réinitialiser le cache(par exemple ipconfig /flushdns sous Windows).

5.3 Fonctionnement

Le fonctionnement du DNS nécessite le stockage d'informations sur les serveurs (fichiers de zone) et les clients (mémoire cache) ainsi que des échanges d'informations entre ces machines (PDU DNS). Ce stockage et ces échanges sont réalisés sous la forme d'enregistrements de ressources (RR : Resource Records)

Ces RR servent aussi bien pour les fichiers de zone que pour les PDU (avec un champ supplémentaire) et en binaire.

5.3.1 Les Resource Records

Le format de principe des RR est le suivant :

Name TTL Class Type Type-specific-data

Name : nom du nœud dans la zoneTTL : time to live (pour la durée de maintient en cache)Class : protocole concerné (IN : internet protocol)Type : type de l ’enregistrement (Adresses, nom canonique…)Type-specific data : format défini par le champ class et type

Exemple de RR :istapc134 IN A 161.3.51.134 (le champ TTL est omis)

Différents type de RR (champ Type : RFC 1035 puis d'autres)A : Adresse IPv4AAA : Adresse IPv6CNAME (canonical name) : un alias pour un hôteNS (name server) : définit un serveur de nom du domainePTR (pointer) : utilisé pour la résolution inverseSOA (Start of Authority) : définit le nom de la zone et divers paramètres (e-mail contact ; different times…)HINFO (host information) : données texte relatives à un hôteMX (mail exchanger) : nom du serveur de messagerie du domaine considéréMB : mail boxMG : mail group

5.3.2 PDU DNS

Les PDU DNS sont formatées en 5 champs :- Un en-tête toujours présent (12 octets)

53

- 1 champ Question- 3 champs RR optionnels (Answer, Authority, Additional)

Elle a comme taille 512 octets maximum. Cette PDU est au dessus de la couche transport en UDP via le port 53. La PDU est codée afin de compacter certains types d'informations qui reviennent souvent. Dans la PDU, hormis l'entête, les informations sont sous forme de caractères ASCII. Chaque information est constituée de chaînes de caractères séparées par des points (exemple univ-st-etienne.fr). Le codage de chaque chaîne de caractères commence par un octet de longueur puis les codes ASCII, les points ne sont pas codés, après la dernière chaîne, un caractère nul (0x00) est ajouté pour séparer cette information de l'information suivante. Pour éviter de répéter certaines informations (par exemple le nom de domaine complet). Chaque nouvelle occurrence est remplacée par le code 0xC0 (qui n'est pas un caractère) suivi du décalage en nombre d'octets où on trouve la chaîne pour la première fois.

En-tête (Header) :

ID : identificateur unique sur 16 bits pour corréler question et réponseQR (Question/Response) : Q=0 ; R = 1Opcode (Operation Code) : standard/inverse query ; status server query (0 ; 1 ; 2) les autres valeurs sont inutilisées pour l’instantAA (Authoritative answer) : positionné si le poste répondant est un serveur ayant autorité sur le domaine (sinon l'information provient d'un cache)TC (TrunCation) : positionné si le message est trop longRD (Recursion Desired) : demande par le client d'une recherche récursive si possibleRA (Recursion Available) : recherche récursive possible (proposé par un serveur)

54

+---------------------+

| Header |

+---------------------+

| Question | the question for the name server

+---------------------+

| Answer | RRs answering the question

+---------------------+

| Authority | RRs pointing toward an authority

+---------------------+

| Additional | RRs holding additional information

+---------------------+

1 1 1 1 1 1

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ID |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

|QR| Opcode |AA|TC|RD|RA| Z | RCODE |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| QDCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ANCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| NSCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

| ARCOUNT |

+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Z : not usedRCODE (Response code) : code de retour du serveur

0 : OK1 : Format Error 2 : Server failure3 : Name Error5 : Refused

QDCOUNT : nombre d’entrées dans le champ questionANCOUNT : nombre d’entrées dans le champ réponseNSCOUNT : nombre d’entrées dans le champ pointant sur une AuthorityARCOUNT : nombre d’entrées dans le champ complémentaire

Champ Question :Le champ question est composé de 3 items :

- Qname : le nom demandé ;- Qtype : le type de demande (se réfère à la liste des types de RR) ;- Qclass : la classe de la demande (en général toujours IN : Internent protocol)

Champ Answer :Des RR répondant à la question.

Champ Authority :Des RR pointant sur d’autres NS. Permet de donner d'autres sources d'informations pour une réponse incomplète à une demande.

Champ Additional :Des RR additionnelles. Par exemple, des RR réponses à des questions probables ultérieurement. Si on demande le nom du serveur de mail (MX ?), une demande corollaire sera ensuite de connaître son adresse IP (le serveur anticipe donc cette question)

Un exemple :

PDU de demande : mail box du domaine univ-st-etienne.frChamp Question :Qname : univ-st-etienne.fr ; Qtype : MX ; Qclass : INLes autres vides

PDU de réponse :Champ Question : le même que la questionChamp Réponse (une ou plusieurs RRs) :univ-st-etienne.fr MX 10 smtp.univ-st-etienne.frChamp AuthorityChamp Additionalmail.univ-st-etienne.fr A 161.3.1.24

Traduction en hexadécimal : PDU DNS : Demande : mail box de univ-st-etienne.frHeader : 00 26 01 00 00 01 00 00 00 00 00 00

00 26 : Transaction ID : 01 : 0 : message is question

0 0 0 0 : Opcode standard Query

55

0 : not an authority for the domain 0 : not truncated 1 : recursion desired

00 : 0 : recursion not available ; 0 0 0 : Z (not used);

0 0 0 0 Reply code (no error)

Champ Question :

0F 75 6E 69 76 2D 73 74 2D 65 74 69 65 6E 6E 65 02 66 72 00 00 0F 00 01

Qname : univ-st-etienne.fr(en ASCII avec un premier octet de longueur et une fin 0x00)0F 75 6E 69 76 2D 73 74 2D 65 74 69 65 6E 6E 65 02 66 72 00les points sont remplacés par la longueur

Qtype : MX ; Qclass : IN (2 octets + 2 octets)00 0F 00 01

PDU DNS : Réponse : mail box de univ-st-etienne.frHeader : 00 26 85 80 00 01 00 02 00 04 00 08(Message de type Answer ; autorithy for the domain, recursion desired ; recursion available)(Nbre de question 1 ; Nbre de Answer : 2 ; Nbre d'Authority 4 ; Nbre d'Additional : 8)Champ Question :Qname : univ-st-etienne.fr + Qtype : MX ; Qclass : IN0F 75 6E 69 76 2D 73 74 2D 65 74 69 65 6E 6E 65 02 66 72 00 00 0F 00 01Champ Answer RRs (2) :univ-st-etienne.fr MX IN 2days 10 coise.univ-st-etienne.frC0 0C 00 0F 00 01 00 02 A3 00 00 0A 00 0A 05 63 6F 69 73 65 C0 0Cuniv-st-etienne.fr MX IN 2days 0 aix.univ-st-etienne.frC0 0C 00 0F 00 01 00 02 A3 00 00 0A 00 00 03 61 69 78 C0 0COn utilise une compression pour ne pas remettre les portions de noms déjà utilisées :

C0 + position dans la PDU (C0 0C : pour la 12 ème position)Authority RRs : 4Additional RRs : 8En général les adresses IP (A ou AAA) des machines des RR précédentes

5.3.3 Format des fichiers de zone (zone files)

Le format des fichiers de zone peut varier entre les implémentations (surtout sous windows où ils peuvent être intégrés à un annuaire). On les représentera sous le format UNIX.Généralement ils comprennent 3 catégories d’informations :

- des commentaires : démarrage par un « ; »- des directives : démarrage par un « $ »- et enfin des RRs

Les directives principales :$ORIGIN : change le domaine d’origine pour les noms relatifs$TTL : time to live par défaut (en général définie avant les RR)$INCLUDE : inclus le fichier précisé

56

Le premier RR dans le fichier est de type SOA (Start Of Authority). Elle définit le fonctionnement pas défaut et le domaine d’origine. Tous les RR doivent avoir la même classe (même protocole)

Chaque champ des RR est normalement séparé des autres par un espace ou une tabulation (certaines implémentations étaient relativement sensibles au nombre d'espaces, car des champs peuvent être omis).

Format du type SOA :

MNAME RNAME SERIAL REFRESH RETRY EXPIRE MINIMUM

MNAME : nom du serveur de domaineRNAME : adresse mail du responsable de domaineSERIAL : n° de série des donnéesREFRESH : intervalle entre 2 interrogations (polling) pour les serveurs intermédiairesRETRY : intervalle si polling infructueuxEXPIRE : durée de l’autorité sur la zoneMINIMUM : TTL minimum pour chaque entrée

Un exemple :

; ISI.EDU zone. is loaded with an origin of ISI.EDU:

; . must be coded by \.

@ IN SOA VENERA Action\.domains ( 20 ; SERIAL

7200 ; REFRESH

600 ; RETRY

3600000 ; EXPIRE

60) ; MINIMUM

NS A.ISI.EDU.

NS VENERA

NS VAXA

MX 10 VENERA

MX 20 VAXA

A A 26.3.0.103

VENERA A 10.1.0.52

A 128.9.0.32

VAXA A 10.2.0.27

A 128.9.0.33

$INCLUDE <SUBSYS>ISI-MAILBOXES.TXT

Le fichier ISI-MAILBOXES.TXT contenant les informations suivantes :

MOE MB A.ISI.EDU

LARRY MB A.ISI.EDU

CURTLEY MB A.ISI.EDU

STOOGES MG MOE

LARRY

CURTLEY

57

Quelques éléments d'interprétations :

Un caractère @ remplace le nom de zone (ici ISI.EDU) donné par le nom du fichier ou la directive $ORIGIN.Lorsque les lignes ne commencent pas à gauche (premier champ manquant), c'est celui précédent qui est utilisé.Les noms de machines non terminés (nom relatif) par un point sont complétés par le nom de la zone (exemple VENERA dans la directive MX devient VENERA.ISI.EDU. qui est le FQDN ou nom absolu)Très souvent la classe (IN) est omise à partir du deuxième enregistrement (il ne peut exister qu'une classe dans un même fichier de zone)..

Remarque : pour les enregistrements PTR seul l'adresse hôte est utilisée.

5.4 Mise en œuvre :

5.4.1 Principe

La résolution DNS est basée sur une interaction client/serveur. Côté serveur, un programme résident (démon) de nom bind ou named attend les requêtes sur un port déterminé, côté client, un resolver (solveur ?) va servir d'interface entre l’application et la fonction de résolution de nom.C’est lui qui déclenche les accès en local à la base de données (fichier hosts), il vérifie aussi que la réponse n'est pas dans la mémoire cache. Si échec, il déclenche alors une demande à destination des serveurs DNS distants.

Il peut exister différents type de serveurs de noms (DNS) :- Serveur primaire : Administration des ressources locales, autorité sur ces ressources- Serveur secondaire :il recopie sans avoir autorité- Serveur cache : pas de table locale, mais il mémorise les requêtes- Serveur forwarding : il renvoie simplement les requêtes vers d'autres serveurs et sert aussi de cache, il permet par exemple de centraliser en cache une base DNS répartie.

5.4.2 Côté serveur (Debian Linux)

Le démons gérant le DNS sous debian est directement dérivé de bind (Berkeley Internet Name Daemon) et a pour nom d'exécutable : named.Il est lancé par le script /etc/init.d/bind9 : /etc/init.d/bind9 start (stop ou restart)

Remarque : tous les fichiers situés sous /etc/init.d sont des scripts (lisibles), ils servent à lancer les différents démons. En général à chaque démon est associé un ou plusieurs fichiers de configuration situés sous /etc. Lors d'une modification du fichier de configuration, on doit en général relancer le démon (option restart) pour que les modifications soient prises en compte. Les messages d'erreurs sont centralisés dans un des fichiers log sous /var/log.

Pour le service DNS il y a 2 catégories de fichiers :- Configuration générale du démon- Ressources de la base de données DNS

58

a) Configuration générale du serveur DNS sous Debian Linux :

Le fichier gérant la configuration globale du démon named est /etc/bind/named.conf. C'est un fichier texte à la syntaxe précise.En fait, ce fichier initial ne contient que le minimum nécessaire et il contient plusieurs (au moins 2) directives $INCLUDE vers les fichiers suivants : /etc/bind/named.conf.local et /etc/bind/named.conf.options.On travaille donc sur les fichiers inclus sans modifier ce fichier principal ce qui évite les erreurs trop importantes de configuration et permet de se centrer sur les informations à modifier.

Le fichier named.conf contient des déclarations par défaut, en particulier il définit plusieurs zones par défaut :zone « . » de type hint qui indique le fichier root.servers (les serveurs racine)

zone « localhost » : elle indique le fichier master.localhost

zone inverse « 0.0.127.in-addr.arpa » (localhost.rev) elle contient la résolution inverse locale

Le fichier /etc/bind/named.conf.local contient une liste des noms des fichiers ressources créés par l'administrateur qui vont constituer la base de données DNS

Remarques :L’utilisation d’outils graphiques de configuration et la modification manuelle sont exclusives (souvent sous Linux), les modifications par un outil graphique ont souvent un effet sauvegardé soit dans les fichiers de configuration standard soit dans d'autres fichiers liés à la distribution. Pour un administrateur, il est fortement déconseillé d'utiliser cette voie de configuration.

b) Les déclarations de zone

Elles définissent les noms (chemin) des fichiers contenant les RR. Elles contiennent 3 informations, la syntaxe est la suivante :zone "nom" { : définit la zone (valeur par défaut de l’origine)type "type" : type de serveurfile "nom du fichier" : nom du fichier de zone

Exemple :zone « domain1.fr» {type master ;file « domain1 »}

Les différents types sont : master (maître) ; slave (esclave) ; hint (serveurs racine) ; forward (à rediffuser : serveur cache)

Pour un serveur DNS principal, les zones sont en général de type « master ». Les serveurs secondaires sont eux de type « slave ». La communication entre serveurs DNS pour des résolutions inter-domaines doit passer par un serveur de niveau plus élevé (ayant au moins connaissance des 2

59

domaines). Au niveau le plus élevé (zone .), ce sont les serveurs racine : leurs coordonnées sont donc accessibles par le fichier de zone associé à la zone ., ce fichier est de type « hint ».

5.4.3 Côté client (Linux Debian)

Fonctionnement général :

Le fichier /etc/nsswitch.conf détermine le fonctionnement des différentes bases de données (en particulier du DNS pour définir le choix de l'ordre dans la résolution).

Exemple de la ligne définissant le fonctionnement du DNS : hosts files dns

hosts précise quelle base de données est concernée (ici résolution des noms d'hôtes)Les entrées suivantes précises l'ordre : d’abord le fichier /etc/hosts (files) puis DNS (dns).

Le fichier /etc/host.conf lui aussi détermine l’ordre de résolution pour le DNS (a priori dans les nouvelles versions c'est le fichier nsswitch qui a précédence). Le fichier host.conf contient aussi des directives plus précises sur l'usage du fichier /etc/host.Syntaxe du fichier host.conf :order files bind nis

Fonctionnement de la résolution de nom par DNS :

Le fichier /etc/resolv.conf définit les mécanismes utilisés pour la résolution de noms DNS.Il est limité à un nombre maximum de lignes réduit.Il définit un seul domaine associé : ligne domainexemple : domain istase.univ-st-etienne.frIl peut définir plusieurs domaines de recherche : ligne search x1 x2 x3Il définit de même 3 serveurs DNS possibles maximum : lignes nameservernameserver 192.168.5.21L'ordre dans le fichier correspond à l’ordre d’interrogationLes serveurs DNS sont définis par leurs adresses IP, en effet pour lancer une requête DNS, il faut connaître l'adresse IP d'un serveur ce que l'on ne peut obtenir par DNS puisque l'on ne connaît pas l'adresse du serveur !!!

Remarque : Pour un bon focntionnement des applications, le serveur DNS doit pointer sur lui-même dans le resolv.conf (127.0.0.1).

Commandes de debug côté clientLa commande "nslookup" permet une mise en œuvre manuelle d’une interrogation quelconque, elle possède de nombreuses options.La commande "dig" possède les mêmes fonctions, elle corrigerait a priori certains problèmes de nslookup...

60

5.4.4 Côté Serveur sous Windows

Pour un serveur windows (2000, 2003, 2008) Les fichiers de zone sont contenus par défaut sous le répertoire c:\windows\system32\dns). En fait, si le DNS est intégré à l'annuaire Active Directory zone intégrée à Active Directory), les fichiers de zone ne sont pas présents dans ce répertoire. En fait, cela ne change rien pour l'administrateur car Windows fournit une interface de gestion des RR indépendante de l'endroit de stockage.Si c'est un serveur de zone principal non intégré à Active Directory, les fichiers de zones se nomment *.dns et sont des fichiers texte rw.Si c'est un serveur de zone secondaire les fichiers *.dns sont des fichiers texte en lecture seule copie des précédents.

Il existe aussi des zones stub (fichiers de définition des serveurs DNS parent)

L'accès normal à la configuration se fait par la console DNS, ce qui évite les erreurs de syntaxe.

Il existe tout de même des outils complémentaires permettant de configurer en ligne de commandes :Commande dnscmd (sur le CDROM dans outils complémentaires W2003)Commande dnslint (vérification de syntaxe)Un journal dns.log est géré, il est visualisable avec l'observateur d’évènements. Une bonne gestion du DNS est essentiel sous Windows Server car il conditionne le bon fonctionnement de nombreux services (dont la connexion des clients au serveur).

5.4.5 Côté Client sous Windows

L'ordre de résolution sous Windows est le suivant :- Cache DNS local- Fichier hosts- Requête auprès du serveur- puis tentative de résolution NetBIOS (si le nom est simple : sans .)

Des commandes en ligne existent et permettent de : - voir le cache DNS : ipconfig /displaydns- vider le cache DNS : ipconfig /flushdns ou net stop dnscache puis net start dnscache

nslookup existe aussi en ligne de commande sous Windows

5.5 Interaction DNS/DHCP

Tous ce que l'on a vu précédemment ne peut s'appliquer si l'adresse IP des machines est obtenue dynamiquement par DHCP. On ne peut alors relier de manière permanente un nom de machine avec une adresse IP unique car celle-ci peut varier. Le DNS comme nous l'avons vu est alors inopérant car on ne peut définir une entrée statique dans un fichier de zone.

La solution utilisée actuellement est une mise à jour dynamique des fichiers de zone : c'est le DNS dynamique ou DDNS. Sa mise en œuvre est assez récente (RFC2136). Elle existe dès Windows 2000 server, ainsi qu'avec la version bind9 et dhcp3 sous debian.

61

Plusieurs variantes existent pour la mise à jour dynamique, en fonction de qui possède les informations nécessaires.

Pour réaliser un DNS dynamique, 2 informations sont nécessaires pour remplir le fichier de zone :- Nom du poste- Adresse IP obtenue dynamiquement

2 cas peuvent être envisagés :- Mise à jour par le serveur DHCP vers le serveur DNS- Mise à jour par le client vers le serveur DNS

Cela impose des contraintes sur le poste faisant la mise à jour :- Il faut que le poste ait les informations nécessaires (si serveur DHCP)- Il faut que le poste ait les droits de modification sur le serveur DNS- Il faut que le poste soit capable de gérer le protocole de modification

Mise en œuvre DNS dynamique :Configurer le serveur DNS pour qu’il accepte les modifications dynamiquesConfigurer le serveur DHCP (ou le client) pour qu’il envoie les modificationsUtilisation du champ « flag » de la PDU DHCP pour définir le mode de fonctionnement

Rappel : autre lien DNS/DHCPSi le client fonctionne en DHCP, souvent il ne connaît pas son serveur DNS, cette information peut-être envoyée dans les options DHCP.

5.6 Service WINS (client Windows)

Sous Windows, en NetBIOS over TCP/IP (NbT), une autre catégorie de résolution peut être nécessaire : la résolution de nom NetBIOS vers adresse IP.C'est un mécanisme de base pour WIN NT ; WIN95 ; WIN 98. Il est moins utile pour W2000, Win XP et W2003 car il peut être remplacé par le service DNS. Il est toujours présent car utilisé pour les partages fichier/imprimante et pour peupler le voisinage réseaux. Mais il n'est plus utile pour l’ouverture de session.L'ordre de résolution (habituel...) :

- Cache NetBIOS- Requête vers serveur WINS- Diffusion générale- Fichier LMHOSTS (Lan Manager hosts)

Mais suivant leur configuration, les machines ne réagissent pas de la même manière. Il y a différents types de nœuds :B nœud : uniquement diffusion (Broadcast)B nœud avancé : idem avec LMHOSTSP nœud : serveur de nom par protocole NBNS (WINS)M nœud : diffusion puis NBNSH nœud : NBNS puis diffusion (par défaut)

Gestion du cache NetBIOSIl existe une commande permettant de gérer ce cache :

nbstat -c : affiche

62

nbstat -r : reset

fichier LMHOSTS (Lan Manager hosts)Ce fichier se situe dans le répertoire c:\system32\drivers\etc, il a la même fonction que le fichier host pour le DNS.Il peut contenir des entrées permanentes (#PRE)Syntaxe :161.3.51.10 « ISTASE-LINUX \0x1b » #PRE #DOM: ISTASE 161.3.51.212 istapc212161.3.51.1 istasegw #PRE

Requête vers un serveur WINS (Windows Internet Name Service)Ce sont des requête NBNS (NetBios Name Service). Elles ont approximativement le même format que les requêtes DNS.

Pour qu'un Serveur windows devienne serveur DNS, il est nécessaire de rajouter un composant Windows : le service WINS. Le serveur WINS est son propre client WINS.

Au niveau clientIl faut configurer le nom/adresse du serveur WINS via :

Paramètres TCP/IP avancésOnglet WINS

On peut aussi activer/ou non la recherche LmHostIl faut bien penser à valider NetBIOS sur TCP/IP

Pour un poste non WINS, les requêtes de résolution de noms sont de type Broadcast (Pas de routage). Elles peuvent toutefois être interceptée par un Proxy WINS qui utilise son cache ou qui fait la requête auprès du serveur WINS.La base de données WINS est de type Access (Compressée et non lisible directement)La conversion LmHost -> BdD permet de garder les entrées statiques. Dans un réseau de taille importante, il peut y avoir des duplications des bases de données sous 2 formes :Liaisons poussée (source qui déclenche) ou tirée (destination qui déclenche). Cela peut-être une source de trafic importante.

Exploration (Favoris Réseaux…)Un maître explorateur possède une liste de toutes les machines de son groupe de travail. Un explorateur maître de domaine les regroupe toutes. Un client peut ainsi mettre à jour rapidement son voisinage réseau sans attendre les trames de déclaration des machines sur le réseau.

63

TP Module OptRx1

N°01 : Service DNS sous UNIX

Objectifs du TP:

Installation et paramétrage sous Linux Debian du service DNS

Ressources nécessaires au TP

- Durant le TP, vous allez utiliser un PC client Windows, un PC client LINUX et un PC serveur Debian Linux à configurer avec l’adresse IP 192.168.N°poste.N°PC.

- Pour mettre en œuvre la liaison physique entre ces PC, vous utiliserez un switch.

Phase 1 : Configuration du serveur DNS

Le domaine à créer sera tseposteX.org (ou X sera votre numéro de poste), les noms des clients : clientxx.tseposteX.org et le nom du serveur : serveur.tseposteX.org

Pour cela vous modifierez le fichier de configuration du démon bind (fichier /etc/bind/named.conf.local inclus dans named.conf) pour y ajouter les chemins vers les fichiers de définition de la base de données. Visualisez préalablement le fichier named.conf pour en comprendre la syntaxe.

Ensuite vous aurez à créer ou modifier les fichiers de zone pour y intégrer les « resources records » nécessaires au bon fonctionnement du DNS : généralement le nom des fichiers de zone pour la résolution directe est le nom de la zone (exemple : istase.org) et l'adresse IP à l'envers suivie de in-addr.arpa pour la résolution inverse (exemple : 1.168.192.in-addr.arpa).

A chaque modification du DNS, redémarrez le démon : /etc/init.d/bind9. Pour vérifier s'il y a des problèmes de configuration, vous pouvez afficher la fin du fichier de

log /var/log/syslog.

1. Configurer les clients avec une adresse IP fixe.2. Configurer la résolution de nom directe. (vous devrez utiliser la commande nslookup pour tester le bon fonctionnement). 3. Configurer le poste client Windows afin qu’il utilise ce DNS. Tester vos configurations en faisant des ping de la machine cliente vers la machine serveur (et inversement) en se servant des noms. Visualiser les trames échangées entre les différentes machines.4. Faire plusieurs essais successifs, y-a-t-il toujours des trames échangées ? Pourquoi ? Visualiser le cache local (ipconfig /displaydns) et remettre à zéro si nécessaire les caches DNS (ipconfig /flushdns sous windows).5. Configurer le poste client Linux afin qu’il utilise ce DNS (modifier le fichier /etc/resolv.conf pour définir le nameserver et le domain).6. Configurer le poste serveur afin qu’il utilise son propre service de DNS (idem configuration client avec /etc/resolv.conf).7. Configurer la résolution inverse. La tester avec l'option -a de la commande ping.

Phase 2 : Configuration DNS avancée

64

1. Mettre en place un serveur cache pour les résolutions locales. Transformer votre client Linux en serveur DNS cache ou relais (sans aucun fichier de zone mais relayant les demandes).

Dans le fichier named.conf.options (sous /etc/bind), décommenter l'option forwarders en ajoutant l'adresse du poste serveur avec les fichiers de zone. Modifier pour le poste windows le serveur DNS pour le faire pointer sur le serveur cache. Faire un essai de résolution. Détailler et expliquer les échanges DNS à l’aide de l’analyseur de trames.

2. Mettre en place un serveur secondaire (serveur esclave) pour les résolutions locales. Transformer le serveur cache précédent en serveur DNS secondaire (les fichiers de zone sont recopiés du serveur primaire).

Dans les fichiers de zone concernés : changer master en slave et rajouter la directive masters avec l'adresse du serveur primaire. Faire un essai de résolution. Détailler et expliquer les échanges DNS (résolution et mise à jour du serveur secondaire) à l’aide de l’analyseur de trames.

3. Interconnecter votre serveur primaire avec les serveurs primaires des autres groupes de TP. Pour cela vous allez reconfigurer votre serveur secondaire en serveur de zone supérieure (.org) voire en serveur racine et lui donner les différentes informations nécessaires pour contacter les serveurs des autres groupes de TP.

Phase 3 : Désinstallation (Phase obligatoire)

1. Sauvegarder les configurations que vous avez modifiées. Vous devez être capable à la fin du TP de reconstruire toutes les configurations très rapidement. Pour cela vous devez sauvegarder les fichiers de configurations modifiés ainsi que créer les scripts nécessaires pour reconstruire les modifications que vous avez effectuées.

2. Les configurations initiales des machines sont reconstruites au redémarrage des machines, vous devez juste : Arrêter les 3 PC et éteindre les écrans. Attention : certains ordinateurs nécessitent que

�l’on appuie sur le bouton marche/arrêt après avoir cliqué sur Démarrer Arrêter.

65 66

Chapitre 6 : Gestion centralisée et

annuaires

6.1 Introduction.

6.1.1 Gestion centralisée et annuaire

La généralisation de l'informatique dans la gestion d'une entreprise ou d'une organisation a conduit à multiplier les bases de données nécessaires au bon fonctionnement de ces applications. Un des enjeux de la pérennité de cette évolution est de pouvoir regrouper les informations, en particulier nominatives, dans un ensemble cohérent pour ne pas stocker des informations non synchronisées ou contradictoires. Par exemple, lorsqu'une personne quitte une entreprise, elle doit être supprimée de l'annuaire téléphonique, mais aussi de la liste de gestion de la paie et ne doit pas non plus conserver des accès informatiques aux postes de l'entreprise. Toutes ces opérations liées à des bases de données doivent être faites dans un laps de temps réduit. L'objectif est alors de trouver un moyen de centraliser efficacement ces informations et de permettre la fusion de ces multiples bases de données dans un unique ensemble appelé annuaire informatique.

Par exemple, une école peut avoir besoin de :un fichier Microsoft Excel contenant la liste du personnel administratifune base Microsoft Access du personnel enseignantun fichier Microsoft Excel des numéros de téléphone des personnelsun fichier /etc/passwd des comptes Unix des utilisateursun fichier /etc/aliases (ou Sympa) de listes de Mailun fichier Samba sur le serveur UNIX des utilisateurs Windowsd'autres bases MySQL, Oracle, maps NIS,…

Un annuaire va pouvoir regrouper toutes ces informations et surtout s'interfacer avec les applications qui utilisent ces données.Par exemple, comment envoyer un mail contenant leurs nouvelles coordonnées de compte UNIX, à l'ensemble du personnel administratif sachant que l'administrateur système ne les connaît que par leur nom et prénom. Un annuaire va permettre de faire cette opération sans que l'opérateur ait à intervenir manuellement.

67

6.1.2 Concept d'annuaire

Un annuaire informatique est un service permettant d'accéder à des informations relatives à des personnes, des machines (ou d'autres ressources) de manière organisée (arborescente).L'objectif est de maintenir de façon cohérente et contrôlée une grande quantité de données.

Ce n'est pas exactement un système de gestion de base de données (SGBD) dans lequel le schéma des données stockées est défini pour résoudre un certain problème. Ce schéma est connu des applications et les objets sont généralement complexes, stockés dans différentes tables ayant des relations entre elles (base de données relationnelle). Un langage spécifique permet la lecture et mise à jour des tables (requêtes SQL, …).

Les différences principales entre un annuaire et un SGBD sont :pas de liens de dépendances entre les objets stockés dans un annuaireles objets peuvent être distribués sur plusieurs annuaires pour assurer une meilleure disponibilitéle schéma de stockage des données est standardisé pour assurer un partage des donnéesLes attributs peuvent être multi-valuésles applications de l'annuaire n'ont pas besoin de connaître la structure interne des données stockéesun annuaire est principalement consulté en lecture et optimisé pour cela

Les caractéristiques d’un annuaire sont donc :Optimisé pour la lecture : mémoire cache si modifications raresModèle distribué de stockage : ajout de données par plusieurs servicesExtension des informations stockées : nouvelles catégories d ’enregistrementFonctionnalités de recherche avancéesRéplication entre serveurs : redondance pour un service plus rapide et plus fiable, un annuaire pouvant être consulté sur une version répliquée car les modifications sont rares

6.1.3 Utilisation d'un annuaire pour l'authentification centralisée

Avec la multiplication des applications demandant une authentification (messagerie, serveurs de fichiers, site WEB...) il est devenu difficile de retenir toutes les indications de login/passwd, surtout si on prend en compte des contraintes fortes de sécurité (password long et varié). La mise en place d'un système d'authentification centralisée et unique répond à ces impératifs de confort et de sécurité.Les systèmes basés sur des annuaires LDAP sont actuellement les plus courants. Ils sont constitués d'un serveur LDAP stockant, parmi d'autres informations, toutes les indications nécessaires à l'authentification. Ce serveur LDAP est interrogé automatiquement par les applications serveur (WEB, messagerie...) auxquelles tentent d'accéder les utilisateurs. Ces applications vont communiquer par un module interne client LDAP avec le serveur LDAP.

68

6.2 Annuaire LDAP.

6.2.1 Présentation

LDAP (Lightweight Directory Access Protocol) a été initialement présenté comme un protocole à destination des postes de travail. Il a été proposé à l'IETF en 1995. Il est l'héritier de l'annuaire X500 (proposée par l'ISO), un standard conçu par les opérateurs télécom pour interconnecter leurs annuaires téléphoniques. X500 est basé sur le modèle OSI.LDAP peut être vu comme une adaptation de X500 à Internet (même modèle de schéma, …), mais simplifié dans un premier temps. Il est basé sur la pile de protocoles TCP/IP (Port TCP 389 du serveur).le standard ne concerne pas le contrôle d'accès aux données de l'annuaire, il ne définit pas non plus le moyen de stockage des données. La version actuelle est la version 3 [RFC 3377][RFC4510]. Elle définit 9 opérations fondamentales. De nombreux compléments sont aussi publiés : RFC 2251 à 2256, RFC 2829 à 2830, RFC 2849...

6.2.2 Principes

Les objectifs principaux sont de :fournir aux utilisateurs des informations fiables, facilement accessiblespermettre aux utilisateurs de mettre à jour eux-mêmes leurs informations personnellesrendre les informations accessibles de façon contrôléefaciliter le nomadisme des utilisateurséviter la redondance d'informations : un seul annuaire pour l'ensemble des servicesfaciliter la gestion (administration) des postes de travail, des équipements réseaune pas remettre en cause les applications existantes...

LDAP est d'abord un protocole permettant à un client d'interroger un serveur. Il y a donc une normalisation d’un ensemble de messages. Mais pour garantir l'interopérabilité, il n'y a pas de précision sur le stockage des données, à charge au serveur de transformer le format de stockage interne des données en directives normalisées lors de l'échange avec le client.

69

Client LDAP

Requêtes et réponses LDAP

Format interne

Serveur LDAP

Stockage des

donnéesBdD

Client Applicatif : Web, Mail...

Serveur applicatif : WEB, Mail...

+Client LDAP

Serveur LDAP

LDAPProtocole Applicatif :

HTTP, POP, IMAP...

La RFC 2251 définit 2 modèles pour LDAP : Un modèle de protocole : c'est à dire les relations client/serveurUn modèle de données qui va permettre de structurer les informations de manière identique pour les différents postes.Pour ne pas mélanger les données et les types potentiels, il existe aussi une version plus évoluée avec 4 modèles (ou même 5) :Un modèle d'information (les types de données)Un modèle de nommage (l'organisation des données)Un modèle fonctionnel (les éléments d'échange client/serveur)ainsi que deux fonctionnalités ajoutés :Un modèle de sécurité (définissant les droits d'accès aux données)Un modèle de réplication : c'est à dire la répartition de la base sur plusieurs serveurs

Dans cette deuxième version, le modèle d'information définit les structures et types des informations contenues dans l'annuaire. Cela ressemble aux déclarations de type dans un langage informatique. C'est une description générale des données applicables à plusieurs usages.

Le modèle de nommage décrit comment l'information est organisée et référencée : chaque entrée doit être définie de manière unique par un nom : DN (Distinguished Name).

Ce DN est la concaténation de RDN (Relative Distinguished Name) qui est un attribut spécifique à valeur unique à un niveau de l’arbre.Cette concaténation donne un nom complet unique de type :

DN:cn=adminposte5, ou=poste5, dc=istase2003, dc=fr

Il est constitué des RDN ou=poste5 et cn=adminposte5, la racine du nom étant dc=istase2003,dc=fr.Il est construit sous forme d’arbre (DIT : directory information tree). Une entrée d’annuaire est un nœud de l’arbre, chaque nœud possède des attributs. La forme de l'arbre est spécifique à une application, ce qui permet au client et au serveur d'interagir.

Le modèle fonctionnel correspond au protocole : c'est la liste et la syntaxe des requêtes permettant l'interrogation de la base et la mise à jour des informations. C’est le protocole LDAP.Le modèle de sécurité permet de gérer l'authentification des clients, la vérification des droit d ’accès, ceci depuis LDAPv3. Certaines fonctionnalités ne sont pas normalisées.

6.2.3 Le modèle d'information

Un annuaire est modélisé par un schéma LDAP qui va déterminer les objets utilisables dans l'annuaire. Un schéma LDAP définit une liste des classes d'objets, les types des attributs et leur syntaxe répondant aux normes de l'Object Management Group (OMG). Ils sont standardisés (IANA) : pour permettre l'interopérabilité entre logiciels et surtout l'interfaçage avec les applications clientes (Samba, …). Quoi qu'il en soit, il est possible de rajouter des schémas spécifiques pour utiliser LDAP dans des environnements non standard. Les classes d'objets modélisent des objets réels : un compte Unix (posixAccount), une organisation (o), un département (ou), un personnel (organizationPerson), une imprimante (device), …ou abstraits : l'objet père de tous les autres (top), …Une classe d'objet est définie par : un nom, un OID, des attributs obligatoires, des attributs optionnels, un type (structurel, auxiliaire ou abstrait).

70

Exemple :objectclass ( 2.5.6.6 NAME 'person' DESC 'RFC2256: a person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

Un attribut est défini lui aussi par un nom et un identifiant d’objet unique (OID), l'OID est attribué par l’IANA sous la forme d'une suite de nombres (exemple : 1.3.6.1.4.1.65234.23 décrit ISO ; org ; dod ; internet ; private ; company ; « istase » ; cours …). La définition du type de l'attribut (Attributetype) va spécifier la syntaxe de cet attribut et son utilisation via des règles de comparaison. Dans l'exemple ci-dessous : « SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} » précise que l'attribut est de type chaîne de caractères, « caseIgnoreSubstringsMatch » précise qu'il ne faut pas tenir compte de la casse des lettres et des espaces.

Exemples :attributetype ( 2.5.4.41 NAME 'name' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} )

attributetype ( 2.5.4.4 NAME ( 'sn' 'surname' ) DESC 'RFC2256: last (family) name(s) for which the entity is known by' SUP name )

attributetype ( 2.5.4.6 NAME ( 'c' 'countryName' ) DESC 'RFC2256: ISO-3166 country 2-letter code' SUP name SINGLE-VALUE )

Les noms des attributs les plus courants ont des abréviations :cn : common namedc : domain componentsn : surnameIl y a alors deux noms séparés par un espace dans la déclaration NAME.

Certains attributs sont toujours présents dans les objets : L’attribut objectClass est toujours présent car c'est lui qui donne le type de l'objet sans lequel on ne pourrait connaître les autres attributs nécessaires et autorisés.De même le pseudo attribut dn (Distinguished name) est toujours présent.

Un attribut peut-être mono ou multivalué s'il est présent plusieurs fois. Un objet peut-donc cumuler les types s'il a plusieurs objectClass.

6.2.4 Le modèle de nommage

71

L'annuaire est construit sous forme arborescente, cet arbre est décrit par le DIT (directory information tree). Chaque instanciation d'objets est placée dans cet arbre avec un certain nombre de valeurs d'attributs. Il contient les données de l'annuaire (il correspondrait à la déclaration de structures et à l'affectation des valeurs des champs dans un programme informatique).

Le DIT est décrit dans des fichiers ldif qui vont construire l'annuaire interne par traduction.

Format LDIF : LDAP Interchange format (RFC 2849) : C'est un format texte, chaque entrée est séparée par un retour à la ligne. La première ligne est le nom de l'entrée (association de l'attribut dn avec le chemin dans l'arbre), les suivantes sont aussi des associations entre attributs et valeurs, seuls les attributs définis dans le schéma peuvent être utilisés.

Exemple de DIT et sa description LDIF :

dn: dc=istase2003, dc=frobjectClass: domaindc:istase2003

dn: ou=prof, dc=istase2003, dc=frobjectclass: organizationalUnitou : prof

dn:cn=jacquet,ou=prof ,dc=istase2003, dc=frcn:jacquetgivenName : Jacquet GérardObjectClass : personObjetcClass:inetOrgPersontelephoneNumber:0477915723mail : jacquet@istase.fr DIT équivalent à l'exemplemanager:cn=dir,dc=istase,dc=fr

En fait, le nom de l'entrée dn un attribut toujours présent en première ligne, il a comme valeur la position dans l'arbre de l'instance de l'objet (différents rdn séparés par des virgules)..

Il peut y avoir plusieurs entrées dans un fichier ldif, elles doivent être construites de manière arborescente ordonnée. Par exemple, « dn:cn=adminposte5, ou=poste5, dc=istase2003, dc=fr » ne peut être créé si le « dn:ou=poste5,dc=istase,dc=fr » ne l'est pas.

6.2.5 Le modèle fonctionnel : protocole LDAP

Il définit les échanges entre client et serveur, d'un point de vue des commandes disponibles, de leurs arguments et de la syntaxe de la PDU.

LDAP définit 9 opérations de base regroupées en trois catégories :- Les commandes de connexion au service : bind, unbind, abandon (le client abandonne la requête en cours)- Les commandes de mises à jour des entrées de l'annuaire : add, delete, modify, Modify DN (rename)- Les commandes d'interrogation : recherche (search) et comparaison (compare) d'entrées

72

dc=istase2003, dc=fr

ou=prof

cn=jacquet

LDAPv3 est conçu pour être extensible sans avoir à modifier la norme. Il permet l'ajout d'opérations en plus des 9 de base (Extended Operation). Il permet aussi l'ajout de paramètres associés à une opération.

Le format de transport des données n'est pas de l'ASCII comme SMTP, HTTP, … C'est un encodage LBER : Lightweight Basic Encoding Rules. Le protocole LDAP utilise ASN1 + BER.

ASN1 (Abstract Syntax Notation One) : 1993Il est aussi utilisé par SNMP. C'est un standard de représentation formelle de message. Un compilateur permet de traduire le message pour l ’envoyer. Il comprend des types prédéfinis, une syntaxe proche de celle du langage C (C like).

Exemple :Nom ::= SEQUENCE {name PrintableString (SIZE (1..30)),address PrintableString (SIZE (1..60)),moreaddress PrintableString (SIZE (1..30)) OPTIONAL,zipcode NumericString (SIZE (5))}

BER (Basic Encoding Rules) X690 de l ’UITC'est la syntaxe de transfert qui est le résultat de la traduction d’ASN1. C'est un encodage de format TLD (type length data ou type-longueur-valeur) ou ILC (Identifier Length Content).

Chaque champ a comme longueur 1 ou plusieurs octets.

Le champ Identifier se décompose en 3 parties : la classe, la forme, et le numéro de référence.Exemple de champ Identifier : 0 1 0 0 0 0 1 10 1 Class : Application0 Forme : Primitive0 0011 : Tag Number ou Application Number : SearchRequest)

Le premier champ (Class) a 4 valeurs :00 : Universal01 : Application10 : Context Specific11 : Private

Le deuxième (Form) a seulement 2 valeurs : Primitive (0) ; Constructed (1)

Le troisième champ va dépendre de la classe, par exemple pour la classe Universal :0 0001 : Boolean ; 0 0010 : Integer ; 0 0011 : Bitstring ; 0 0100 : OctetString ; 0 0110 : OID ...

6.2.6 Le modèle de sécurité

les mécanismes de sécurité sont définis dans une couche séparée : cela permet d'utiliser des méthodes d'authentification externes.Les mécanismes de sécurité comprennent :

73

les méthodes d'authentification pour se connecter à l'annuaire (qui peut se connecter à l'annuaire et comment)les mécanismes de règles d'accès aux données (une fois connecté, à quoi peut-on accéder et avec quels droits)les mécanismes de chiffrement des transactions

6.2.7 Le modèle de réplication

Il définit les échanges de la connexion Serveur/Serveur. Le service de réplication (replication service) a beaucoup évolué avec LDAPv3 passant d'un mécanisme géré par le démon slurpd à plusieurs possibilités géré par syncrepl. Ce service de réplication consiste à recopier périodiquement le contenu d'un annuaire LDAP d'une machine sur une autre afin d'avoir une redondance nécessaire pour garantir une bonne continuité de service.Il est aussi possible de créer des liens entre différents annuaires (referral service) : cette fonction est définie dans LDAPv3.

6.2.8 Utilisation de LDAP

Les différents domaines d’application possibles des annuaires LDAP sont :Les applications système (authentification, information sur les utilisateurs...)Les applications Intranet/ExtranetLes applications InternetLes bases de données

Les applications systèmesL’annuaire utilisé pour servir aux besoins des services réseaux tels que l’authentification,le contrôle d’accès, la localisation des imprimantes ou des serveurs de fichier.Dans ce cas, il est étroitement lié au système d’exploitation.De plus en plus de fabricants se tournent vers le standard LDAP pour l’implanter dans leur système.Exemple : Windows 2000, Novell, Solaris, Linux...

Exemple : authentification avec Samba

6.3 OpenLDAP sous Linux Debian

74

Client Windows

Requêtes et réponses LDAP

Requête NetBIOS

login/mot de passe Serveur

LDAPServeur SAMBA

Serveur SAMBA avec module LDAP

Client LDAP

6.3.1 Présentation.

OpenLDAP est un serveur LDAP Opensource développé à partir de 1998. Il est distribué sous forme de code source, mais est disponible compilé par exemple sur la plupart des distributions Linux et existe aussi sous Windows. C'est un des serveurs LDAP le plus utilisé. Il propose un démon permettant de traiter les requêtes LDAP, de bibliothèques servant à gérer le protocole, ainsi que des utilitaires. La base de données associée est libre et dépend des plate-formes support et des choix du gestionnaire (Berkeley Database – Bdb - par exemple et par défaut sous Debian Linux).

6.3.2 Le serveur OpenLDAP sous Debian Linux

Un serveur LDAP a besoin de plusieurs éléments pour fonctionner :– un démon (programme résident) qui va répondre aux requêtes des clients.– Un ou des fichiers de configuration lu au démarrage du démon et qui vont paramétrer le

fonctionnement du serveur.– Des schémas LDAP qui vont servir de contrôle pour que la base LDAP respecte des

contraintes de formatage. Ces schémas sont en général stockés dans des fichiers.

OpenLDAP fonctionne sur un serveur Debian à partir du démon slapd lancé par le script /etc/init.d/slapd (/etc/init.d/slapd start).Le fichier de configuration au lancement du démon est /etc/ldap/slapd.conf. Il gère l'accès à des bases de données de type bdb par défaut. L'administrateur va ajouter aux fichiers un certain nombre d'informations, en particulier pour chaque arborescence DIT, une nouvelle base de données. Des exemples sont en général proposés dans le fichier. Ce fichier peut aussi contenir des fichiers inclus permettant de séparer certaines étapes de la configuration.Les fichiers schémas sont stockés dans le sous-répertoire /etc/ldap/schemas. Le fichier core.schema est obligatoirement utilisé, les autres sont utilisable à la demande, il faut insérer à ce moment là leur nom au bon endroit du fichier de configuration. Ces fichiers doivent être consultés chaque fois qu'un problème de syntaxe LDAP est retourné par le serveur.

Avant le lancement du serveur, on adapte le fichier de configuration pour l'application envisagée. Puis on lance le serveur en vérifiant dans les fichiers de Log que tout c'est bien passé. Après lancement initial du serveur LDAP, on procède au peuplement de la base de données via la création d'un fichier ldif (au format texte) créé par l'administrateur et exportation vers la base de données via une commande ldapadd (ou ldapmodify). La modification ou le complément de la base peut se faire ensuite à n'importe quel moment par les mêmes commandes. L'effacement se fait quant à lui par ldapdelete qui prend comme argument principal un fichier texte contenant les dn à effacer dans l'ordre inverse de leur dépendance. La vérification ou le test peut se faire par ldapsearch qui va reproduire le fonctionnement d'une fonction cliente et ainsi permettre une mise au point plus simple.

A chaque modification des fichiers de configuration, le serveur doit être relancé (/etc/init.d/slapd restart), ceci permet d'avoir un serveur fonctionnant avec les bons paramètres. Attention, de bien utiliser restart qui arrête le serveur avant de le relancer, sinon il peut y avoir plusieurs instances de serveurs LDAP fonctionnant avec des paramètres différents.

75

6.3.3 Un client simple sous Debian

Chaque application utilisant LDAP est un client LDAP. Du fait de l'interopérabilité de LDAP, le client peut être hébergé sur une machine ayant un SE différent.

Sous Debian, sa configuration se fait via un fichier de configuration commun (quelle que soit l'application) /etc/ldap/ldap.conf. Il n'est pas relié à un démon mais va être consulté à chaque lancement de commandes cliente.Le fichier de configuration contient au minimum :La définition du serveur LDAP par son URI (ou l'adresse IP du serveur en l'absence de DNS)Sa base (le début de l'arborescence)

Sous Linux, un client LDAP simple peut-être installé afin de tester le serveur. Il va permettre, via plusieurs commandes spécifiques (ldapcompare, ldapsearch...) de tester simplement le fonctionnement d'une interrogation LDAP. En fait les commandes permettant d'ajouter des informations à la base LDAP, de les supprimer sont aussi basées sur le même fichier. C'est à dire qu'au démarrage au moins, un client LDAP doit aussi être configuré sur le serveur.

6.3.4 Usage avec les applications.

L'utilisation de la base LDAP par une application serveur (Web, Mail...) va se faire suivant le même principe que l'application cliente simple. En ajoutant des modules supplémentaires à l'application serveur, celle-ci va devenir client LDAP. Par exemple, un serveur Web utilisant LDAP pour l'authentification va être client LDAP d'un serveur LDAP pouvant se situer sur la même machine ou sur une autre machine.

Il faut alors bien veiller à ce que les schémas utilisés soient ceux demandées par l'application serveur et que le DIT inclus bien les différents objets et attributs nécessaires. C'est en général la principale difficulté de mise en oeuvre de LDAP.

Le reste de la configuration concerne le serveur d'application.Par exemple, sous Apache, il faut ajouter les modules dynamiques authnz_ldap.load et ldap.load en créant des liens symboliques sous le répertoire /etc/apache2/mods-enabled vers ces fichiers contenus dans le répertoire /etc/apache2/mods-available par la commande :

ln -s /etc/apache2/mods-available/xxx /etc/apache2/mods-enable/xxx

De même il faut modifier les fichiers de configuration en y ajoutant les lignes permettant de prendre en compte le client LDAP, sous Apache il est nécessaire de rajouter au fichier de configuration du site :

<Directory /home/webdir/dir_ldap>...AuthType BasicAuthBasicProvider ldapAuthName « LDAP Directory »AuthzLDAPAuthoritative offAuthLDAPURL ldap://adresseIP/dc=istase,dc=frAuthLDAPBindDN « uid=root,ou=admin,dc=istase,dc=fr »AuthLDAPBindPassword admintestRequire valid-user

76

</Directory>

L'adresse IP le DN de login et le mot de passe doivent bien entendu correspondre à la machine serveur LDAP.

Dans certains cas, il est nécessaire de compléter le schéma LDAP avec des fichiers de schéma supplémentaires, afin de trouver dans l'annuaire les objets nécessaires au bon fonctionnement de l'application cliente. Lorsque l'application cliente interfère directement avec le système d'exploitation (authentification LDAP sous UNIX au lieu des fichiers habituels), il faut être très prudent car cela peut comprmettre le fonctionnement complet du système.

6.3.5 Réplication

Le fonctionnement de la réplication est défini dans le fichier slapd.conf que ce soit au niveau du fournisseur (provider) ou du consommateur (consumer).

Exemple de fichiers de configuration côté provider :

database bdb suffix dc=Example,dc=com rootdn dc=Example,dc=com directory /var/ldap/db index objectclass,entryCSN,entryUUID eq

overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100

Exemple de fichier de configuration côté client (consommateur) : database hdb suffix dc=Example,dc=com rootdn dc=Example,dc=com directory /var/ldap/db index objectclass,entryCSN,entryUUID eq

syncrepl rid=123 provider=ldap://provider.example.com:389 type=refreshOnly interval=01:00:00:00 searchbase="dc=example,dc=com" filter="(objectClass=organizationalPerson)" scope=sub attrs="cn,sn,ou,telephoneNumber,title,l" schemachecking=off bindmethod=simple binddn="cn=syncuser,dc=example,dc=com" credentials=secret

On peut aussi gérer 2 serveurs miroir, les 2 serveurs ayant alors un fonctionnement équilibré, une modification sur l'un sera répliquée sur l'autre et vice-versa :

77

MirrorMode node 1:

# Global section serverID 1 # database section

# syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid2.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +"

mirrormode on

MirrorMode node 2:

# Global section serverID 2 # database section

# syncrepl directive syncrepl rid=001 provider=ldap://ldap-sid1.example.com bindmethod=simple binddn="cn=mirrormode,dc=example,dc=com" credentials=mirrormode searchbase="dc=example,dc=com" schemachecking=on type=refreshAndPersist retry="60 +"

mirrormode on

78

TP Module OptRx1

TP N°02 : Authentification centralisée : annuaire LDAP

Objectifs du TP:

1. Mise en œuvre d’une infrastructure d'authentification basée sur LDAP.2. Utilisation d'OpenLDAP, un serveur OpenSource.3. L'aspect serveur d'application sera traité dans les TP les concernant.

Ressources nécessaires au TP

- Durant le TP, vous allez utiliser un PC client Windows et deux PC sous Debian Linux, l'un pour le service LDAP, l'autre comme client. (adresse IP 192.168.N°poste.N°PC)

- Pour mettre en œuvre la liaison physique entre ces 3 PC, vous utiliserez un switch.

Phase 1 : Configuration du serveur LDAP et constitution de la base de données

1. Configurer le serveur LDAP en éditant le fichier /etc/ldap/slapd.conf. Définir une nouvelle base de données pour votre usage :

database bdbsuffix « dc=istase,dc=fr »rootdn « uid=root,ou=admin,dc=istase,dc=fr »rootpw admintest

2. Lancer le service LDAP : /etc/init.d/slapd. Bien vérifier que le démon est lancé, certaines erreurs conduisent à un arrêt sans message.

3. Vérifier le port d'écoute par la commande netstat -natup |grep -e LISTEN

4. Construire la base de données. Créer un fichier LDIF sous /tmp. Dans lequel vous insérerez les définitions de base de l'arborescence et celle de l'utilisateur root appartenant à l'unité d'organisation admin :

dn:dc=istase,dc=frobjectclass: dcobjectobjectclass:organizationo: istase directory servicedc: istase

dn:ou=admin,dc=istase,dc=frobjectclass: OrganizationalUnitou: admin

dn: uid=root,ou=admin,dc=istase,dc=frObjectclass: InetOrgPersoncn: rootsn:rootuid: rootuserPassword : admintest

79

5. Toute opération sur la base de données, même à partir du serveur, passe par une interface client, vous devez donc configurer, sur le serveur LDAP, le client LDAP, en utilisant le fichier de configuration /etc/ldap/ldap.conf.

URI ldap://127.0.0.1BASE dc=istase,dc=fr

6. Lancer la traduction du fichier LDIF pour être inséré dans la base bdb.ldapadd -x -D « uid=root,ou=admin,dc=istase,dc=fr » -W -f /tmp/fichier.ldif

7. Vérifier le contenu de la base de données par la commande :ldapsearch -x « filtre » (objectclass=* pour tout).

8. Entrer les informations complémentaires dans la base concernant les utilisateurs user1, user2 et user3 en les plaçant directement sur le domaine dc=istase, dc=fr dans une classe d'objet de type « person ». Vérifier dans les fichiers de schéma les attributs obligatoires et autorisés (core.schema). Modifier les entrées pour qu'elles soient acceptées par le serveur LDAP.

9. Vérifier la bonne insertion par la commande ldapsearch.

10. Déplacer ces éléments (user1, user2 et user3) dans une unité d'organisation de nom « standarduser ». On pourra utiliser la commande :

ldapdelete -v -x -D « DN root » -w -f /tmp/basedelet.txten remplissant le fichier avec les DN à détruire dans l'ordre inverse de leur création.

11. Vérifier le contenu de la base complète. Puis vérifier le contenu de la base à partir du point dn:ou=standarduser,dc=istase,dc=fr avec l'option -b de ldapsearch.

Phase 2 : Consultation du serveur LDAP par un client générique

1. Configurer le client LDAP sous le deuxième poste linux en modifiant le fichier /etc/ldap/ldap.conf. : URI ldap://adresse IP du poste serveur

BASE dc=istase,dc=fr

2. Tester l'interrogation LDAP à partir de ce poste distant par ldapsearch -x objectclass=*. Pourquoi cela marche-t-il sans préciser l'adresse du serveur ? Visualiser les trames échangées.

3. A partir des trames capturées, analyser le format des échanges LDAP d'un point de vue global, puis dans le détail du codage binaire.

4. Tester un enregistrement avec la fonction ldapcompare -x DistingishName attribut:value.Visualiser les trames échangées.

5. Faire une opération de même type à partir d'un client Windows en utilisant le browser Softera.

Phase 3 : Réplication

1. Configurer le serveur LDAP actuel pour qu'il devienne provider, et le client Linux pour qu'il devienne un serveur esclave (consumer). Visualiser les échanges et les Log.

2. Elever le rang du deuxième serveur LDAP pour qu'il fonctionne en miroir avec le premier. Visualiser les échanges.

Phase 4 : Arrêt des machines

80

Chapitre 7 : Serveurs Windows

7.1 Introduction.

7.1.1 Rappel : constitution d'un système d’exploitation

Plusieurs éléments se retrouvent systématiquement dans tout système d'exploitation :– Le noyau qui va intégrer des fonctions de base telles que : la gestion de l’exécution du CPU

(multi-tâches, temps réel...), la gestion bas niveau des E/S (drivers), la gestion des ressources (fichiers...).

– Une interface Homme/Machine (IHM ou UI User Interface) de type texte ou plus souvent graphique

– Un interpréteur de commande– Des utilitaires en ligne de commande ou graphique permettant de surveiller et de configurer le

système

81

Outils :Compilateur

LinkerDebugger

Applications

Drivers

Matériel

Humain

Gestion desI/O

Gestion desfichiers

Bibliothèquessystèmes

InterfaceH/M

Interpréteurde

commandes

Pour que l'ordinateur soit opérationnel, ces éléments sont complétés par des applications plus ou moins associées au système d'exploitation (éditeur, traitement de texte...) ainsi que par des outils de développement (compilateur...).

7.1.2 Un système d ’exploitation « serveur »

Actuellement, tous les systèmes d'exploitation serveur sont associés à des systèmes d'exploitation client. En effet, un système d'exploitation (S.E.) est un ensemble de codes énorme évalué en terme de développement à des centaines voire des milliers d'années/homme. Il est donc normal de réutiliser pour un S.E. serveur tous les outils développés pour les S.E. commerciaux standard ce qui favorise ainsi la rentabilité et diminue le prix de revient d'un S.E. Serveur.

le temps de développement étant très long, il y a en fait très peu d'évolutions entre les versions d'un S.E. qu'il soit client ou serveur et ceci en particulier sur le noyau qui est un ensemble de codes complexes et interdépendants. Souvent ces évolutions se limitent à l'ajout de quelques fonctionnalités et à des modifications d'interfaces. Des améliorations sont apportées mais en prenant en compte l'existant et en respectant surtout dans la mesure du possible la compatibilité entre versions, ceci étant encore plus sensible pour les S.E. Windows conduisant des fois à une évolution très lente.

Concernant les S.E. serveurs, l'évolution est encore plus lente car il n'y a pas vraiment d'effet « marketing » comme pour un poste client et généralement le S.E. reste installé sur le matériel pendant toute sa durée de vie, la mise à jour étant une opération trop complexe et risquée. Il n'est pas donc rare de voir des S.E. Serveurs, tournant en entreprise, correspondant à des versions âgées d'une dizaine d'années.

Les différences entre S.E. client et serveur sont assez faibles, on les retrouve principalement au niveau des outils d'administration et des applications fournies directement avec le serveur.Sous Unix/Linux, il s'agit principalement d'une optimisation de l'exécutable permettant une vitesse d’exécution des services plus forte, des fonctionnalités de communication améliorées ainsi qu'une sûreté de fonctionnement plus importante. Les services supplémentaires (serveur de fichiers, Web, Mail...) étant livrés sous forme de paquets, ils peuvent s'ajouter à n'importe quelle version du S.E.Des implémentations spécifiques (payantes) proposent des fonctionnalités supplémentaires : gestion des droits d’accès renforcés, outils d’administration graphiques...

Concernant Windows, objet de ce chapitre, il existe de nombreuses versions de S.E. serveur qui différent par les services qui y sont associés, la base restant strictement la même.

7.1.3 Windows Server

Les versions serveurs de Windows s'insèrent dans la famille Windows de manière parallèle aux évolutions des S.E. client.

82

a) Différentes versions de Server 2003/ Server2008

Derrière l'appelation Server2003, il y a plusieurs versions possibles qui ont en commun la base d'un serveur mais qui diffèrent par les services fournis et des options différentes :– Server 2003 Standard Edition comprend les services suivants : • Network load Balancing,• Serveur messagerie intégré• Version de SQL server allégée

– Server 2003 Enterprise Edition possède en plus les technologies de Clusters– Server 2003 DataCenter Edition permet d'utiliser le Resource manager (partage du CPU…) – Server 2003 Web Edition ne propose qu'un Serveur Web plus simple

La dernière version date de février 2008 et s'appelle Server 2008. Elle propose des points d’évolution par rapport à Server2003 :– amélioration du serveur Web IIS (Internet Information Services)– intégration d'un virtualisateur (Hyper-V) : il permet de faire fonctionner plusieurs OS sur la même

machine (c'est l'équivalent de Virtual Server 2005 pour Server 2003)– des amélioration sur la sécurité– et sur la robustesse...

Sevrer 2008 a une déclinaison comparable à Server 2003 :– Server 2008 Standard Edition– Server 2008 Enterprise Edition– Server 2008 DataCenter Edition– Server 2008 Web Editionet aussi l’option Hyper-V ou non... !

b) Configuration nécessaire à Serveur 2003

• Processeur 1GHz minimum• 1 Goctets de RAM (moins si seulement serveur de fichiers)

83

Windows

1.0

Serveur

2.0 3.0 3.1

95

3.1

Windows

Windows for Workgroup

95 Mil.

XP

3.1NT 4.0 2000

3.1 4.0 2000

XP

2003 2008

Vista W7

Home

Vista W7

Pro

• 2 Goctets de disque pour le S.E. (Active Directory : 500 Mo ; Journaux : 500 Mo ; SysVol : 500 Mo)

• Espace pour les utilisateurs• Le systèmes de fichiers doit être en NTFS (FAT32 non supporté)• les communications sont basées sur TCP/IP

Le contrôle de légalité se fait par un système de licences :– Licences d’accès client (CAL) ; une par poste connecté indépendamment du nombre de serveurs– Licences d’accès serveur : nombre de connexions sur un serveur (multipliées si plusieurs

connexions à des serveurs).C'est une limitation stricte, il faut donc posséder les licences pour chaque utilisateur.

c) Différents types de services proposés par Server 2003

Serveurs d'infrastructure– Serveurs DNS, DHCP, WINS– Contrôleur de domaine (Active directory…)

Serveurs de ressources :– Serveurs de fichiers– Serveurs d’impression– Serveurs d’applications (IIS, ASP, NET)?

Serveurs GroupWare :– Serveurs de messagerie

Communication :– Serveurs multimedia par flux– Serveurs de terminaux– Serveurs d’accès distants (VPN)

Base de données

Plusieurs serveurs (services) sont en général présents sur la même machine même si cet aspect tend à se réduire avec la virtualisation.Attention, il ne faut pas mélanger les fonctions véritablement serveurs avec celles liées à l’infrastructure de fonctionnement réseaux voire avec les fonctions réseaux (routage, firewall…) qui peuvent être présentes sur la même machine

7.2 Active Directory.

7.2.1 Structure

Active Directory est basée sur une approche par objets. Il comporte différents types d'objets :– des utilisateurs– des ordinateurs– des ressources

84

– des services– mais aussi des « objets lien »– des profils– des règles de fonctionnement ou stratégies (policy)?

Cette approche était déjà présente dans les anciens serveurs novell (dans les années 1995), elle procure une maintenance plus aisée mais avec un logique plus difficile à comprendre initialement, en effet, par exemple des objets de types différents peuvent être regroupés dans un même conteneur.

Les éléments constitutifs d'Active Directory permettent de décrire une structure hiérarchique où les éléments physiques habituels (ordinateurs, utilisateurs) ne sont que la terminaison. De plus des éléments transversaux complètent cette structure (relations d'approbation, droits...).Déjà sous Windows NT Server, un certain nombre d'éléments étaient présents :Les Utilisateurs et les Ordinateurs bien entendu, mais aussi les Domaines, les Groupes (d'utilisateurs et d'ordinateurs), ainsi que les Relations d'Approbations.Les Unités d ’organisation (OU) sont apparues avec Windows 2000 Server, ainsi que, pour permettre la gestion de grands réseaux, les Sites, les Arbres de domaines, les Forêts d’arbre de domaine, ainsi que les Stratégies de Groupe (GPO). Il n'y a pas eu d'évolution fondamentale dans les versions suivantes.

7.2.2 Concepts de base

a) Les domaines

Ils sont un regroupement d'entités gérées par une même base de données (Active Directory). Cette base de données contient l'ensemble des comptes utilisateurs, des machines raccordées et permet donc une authentification unique. Les machines contenant cette base de données sont des contrôleurs de domaine.

b) Les groupes

Ce sont des sous-ensembles d’utilisateurs (au sens compte utilisateurs). Ils permettent une gestion commune des droits. On peut mélanger dans un groupe des utilisateurs et des ordinateurs. Un groupe peut contenir d’autres groupes (imbrications).

c) Les arbres

Les arbres regroupent un ensemble de domaines avec un aspect hiérarchique (ou peu comme la hiérarchie dans un système de DNS). Il existe des relations de confiance entre eux.

d) Les forêts

Ce sont des ensemble d’arbres (sans relation de nom) présents à un même niveau.

e) Les sites

Ils constituent une autre vision de l'organisation des domaines et font appel à une subdivision physique ou géographique d’un domaine. Ils sont basés sur la constitution physiques des réseaux

85

locaux et vont agir sur les contraintes de communication. Active Directory répertorie les emplacements géographiques, ce qui permet par exemple d’optimiser l’usage des liens WAN. Ils doivent être définis à la construction de la base de données.

7.2.3 Les groupes

a) Différentes catégories de groupes

Windows Server distingue 2 catégories de groupes :

Des groupes de sécurité

Ils sont utilisés pour attribuer des permissions à de grands ensembles d’utilisateursExemple : droit d’accès à un répertoire pour tous les éléments du groupe. Ils possèdent une description unique par un SID (Security ID). Ce sont ceux qui sont couramment utilisés dans Active Directory.

Des groupes de distribution

Active Directory étant un annuaire LDAP, on peut aussi y définir des caractéristiques supplémentaires liées par exemple à une messagerie. Un groupe de distribution permet d'envoyer directement un message à tous les membres du groupe de manière indépendante de l’application. Ils sont surtout utilisés dans les applications de messagerie (Exchange par exemple).

b) Différents types de groupes de sécurité

Les groupes de sécurité peuvent être distingués par leur portée. On distingue alors des groupes locaux, globaux et universels. Ils vont permettre de partager des ressources entre plusieurs domaines d'une forêt. Suivant les cas, ils vont contenir des objets de plusieurs domaines, ou à l'inverse être restreint à des objets d'un seul domaine. De même, ils vont pouvoir être utilisés soit

86

Domaine :Istase.org

Domaine :Etud.Istase.org

Domaine :Prof.Istase.org

Domaine :Tp.etude.Istase.org

Domaine :Td.etud.Istase.org

Domaine :Univ-st-etienne.fr

Domaine :Istase.univ-st....fr

Domaine :FacS.univ…

Site

uniquement à l'intérieur du domaine où ils sont définis soit dans toute la forêt. Toutes les possibilités seront couvertes par la constitution de groupes de groupes permettant ainsi un contrôle fin de l'accès aux ressources sur toute une forêt.

Les groupes locaux d’ordinateur

Ils sont présents sur chaque ordinateur (serveur ou poste de travail). Par exemple, les groupes « utilisateur avec pouvoir », « administrateurs », « opérateurs de sauvegarde »…On peut accéder à leur liste par : Poste de travail -> bouton de droite -> gérer -> utilisateur et groupes.Ces groupes n'ont aucun intérêt pour une gestion de domaine, leur portée est locale uniquement.

Les groupes locaux de domaine

Ils vont permettre de définir des droits pour une ressource appartenant au domaine. Les utilisateurs et les groupes pouvant obtenir ces droits peuvent être issus de toute la forêt.

Les groupes globaux

Ils ne contiennent que des utilisateurs du domaine mais peuvent avoir des droits sur toutes les ressources de la forêt.Insérable dans un groupe local pour les machines qui font confiance au domaine

Les groupes universels

Ce sont les plus généraux des groupes, ils peuvent contenir des utilisateurs de toute la forêt et être utilisés pour définir des droits sur n'importe quelle ressource de la forêt. Ils n'existent qu'à partir de Server 2000. Ils peuvent contenir n ’importe quel groupe de n ’importe quel domaine de la forêt

Emboîtement de groupes :

Les groupes locaux de domaine (GLD) peuvent contenir :– des utilisateurs de toute la forêt– des groupes universels– des groupes globaux de toute la forêt– des groupes locaux de son domaine

Les groupes universels (GU) peuvent contenir :– des groupes globaux d’un domaine quelconque de la forêt– des groupes universels d’un domaine quelconque de la forêt

Les Groupes globaux (GG) peuvent contenir :– des utilisateurs du domaine– des groupes globaux de son domaine

Toutes ces relations peuvent être résumées dans le schéma suivant :

87

Il convient maintenant de définir l'usage des groupes pour déterminer l’accès aux ressources :Ordre : A -> GG -> GG -> GU -> GLD -> Pavec A : Account (les utilisateurs) et P : les permissions (autorisations) sur les ressources

Les groupes globaux permettent de rassembler les utilisateurs d’un même domaineLes groupes universels permettent de rassembler des groupes globaux issus de toute la forêtEnfin, les groupes de domaines locaux permettent d’attribuer plus facilement les permissions à une ressource du domaine pour le rassemblement des groupes précédents.

Comme pour une station de travail, il existe des groupes prédéfinis sur un serveur Windows :– des groupes Administrateurs avec plusieurs niveaux• administrateur de domaine• administrateur de forêt...

– des groupes Opérateurs avec des fonctions et des droits différents :• Opérateurs de compte• Opérateurs de serveur

– des groupes Utilisateur

7.2.4 Les unités d’organisation (OU)

Ce sont des conteneurs d’objets Active Directory. On peut y mettre des utilisateurs, des groupes, des ordinateurs, d’autres OU.Si un domaine est trop grand, on peut envisager un découpage en unités d’organisation, on peut alors les considérer comme des sous-domaines. Cela permet de définir un découpage logique plus proche de celui présent au sein d’une entrepriseExemple : au sein d’un même domaine (TSEwin)Service général (1 administrateur global, des utilisateurs, des ordinateurs)Site Comptable (1 administrateur local, des utilisateurs, des ordinateurs)

88

Locaux dedomaine

Universels

Globaux

Inter-domaineMême forêt

Intra-domaine

Intra-domaine

Utilisateurs

Utilisateurs

Utilisateurs

Un utilisateur peut avoir un bureau (informatique) différent suivant le site où il travailleOn peut envisager plusieurs types de découpage suivant le modèle d'administration :

– Modèle d’administration centraliséAdministration par un seul groupe centralisé sur un site. Les serveurs stratégiques (DNS, Mail...) sont sur ce site, mais il est nécessaire d'avoir une action à distance sur les autres serveurs.– Modèle d’administration distribuéLe service informatique est réparti sur tous les sites. Les droits sont plus difficiles à définir et granulaires, mais les actions peuvent se faire sur place.– Modèle d’administration mixteCombinaison des 2 précédents avec un choix de se rapprocher plus ou moins de l’un ou de l’autre modèle.

Les unités d’organisation vont être utilisées pour attribuer plus facilement des droits et pour appliquer des configurations aux utilisateurs et machines d'une même OU (Bureau, applications accessibles...). En effet, les stratégies de groupes (GPO) s’appliquent uniquement aux OU et aux domaines. Seule exception, les stratégies de comptes ne s'appliquent qu'à l'ensemble du domaine.

Exemple : dans un modèle décentralisé, chaque site à une OU contrôlée par le service informatique local.L’usage des OU est assez controversé. Pratiquement on peut avoir un usage réduit avec une OU par domaine dans le cas d'une entreprise moyenne et une gestion informatique centralisée. L'avantage est que les OU sont moins contraignantes que les domaines : on peut les modifier facilement. A l'inverse beaucoup d’OU rendent la gestion difficile car il faut bien connaître leur contenu.

7.2.5 Usage

Il faut bien comprendre les différences entre OU et groupes car ils peuvent contenir les mêmes catégories d'objets :un utilisateur peut appartenir à plusieurs groupes, mais un utilisateur n’appartient à un niveau donné qu’à une OU car c'est un conteneur (Container) dans lequel l'objet est déposé. Active Directory ne définit qu'une fois chaque objet et celui-ci est soit déposé dans un conteneur simple (non paramétrable) soit dans une OU.Les OU contiennent ce que l’on veut contrôler alors que les groupes définissent qui contrôle car les OU sont placées sous le contrôle d’un groupe. On peut emboîter des OU (les groupes aussi), mais une OU ne peut être emboîtée à un niveau donné qu'à une autre OU alors que les groupes peuvent être imbriqués.Les groupes ne sont utilisés qu'en lien avec les attributs (droits sur) d’un objet. Les OU permettent d'agir sur les éléments qui y sont contenus via les GPO.

7.3 Relations Clients-Serveur.

7.3.1 Principe.

Plusieurs éléments vont entrer en ligne de compte dans une relation client-serveur. Principalement, on distingue :

89

– les utilisateurs (personne et machine)– les ressources fournies par le serveur

L'administration d'un serveur de type Windows Server 2003 fait appel à plusieurs aspects. Les tâches courantes sont liées à :– L'administration d’utilisateurs ou de groupes– L'administration de ressources– La surveillance de bon fonctionnement

elles sont complétées par des tâches plus exceptionnelles :– Maintenance, mise à jour– Dépannage

7.4 Utilisateurs

L'administration des utilisateurs fait appel à un certain nombre de fonctions de base qui vont se traduire par des modifications ou des ajouts d ’informations dans l’annuaire Active Directory, par exemple :– Création , modification ou suppression d'utilisateurs.– Réinitialisation de mots de passe– Gestion des profils utilisateurs– Modification des droits et des appartenances– Surveillance des usages– Détection des comptes inactifs...

90

Ordinateur Client

Script

Profil errant

Serveur

Ressources partagées

Ressources propres

User Information de connexion

Accès aux ressources

7.4.1 Les comptes d'utilisateurs.

a) Généralités

Un compte d'utilisateur désigne de manière univoque une personne via un nom d'utilisateur. Sur un système serveur comme Windows Server 2003, on associe à ce nom d'utilisateur d'autres caractéristiques qui vont être stockées conjointement dans l'annuaire :– Autres noms (Civilité, nom équivalent pour d'autres servcies, Mail...)– Appartenance à un ou plusieurs groupes d'utilisateurs– Environnement utilisateur (bureau, nom du répertoire personnel, scripts d'ouverture de session)– Heures de connexion autorisées, ...– Informations diverses : adresses, numéro de téléphone...

Le nom d'utilisateur présente ceratines contraintes : il doit être au maximum de 20 caractères sans caractères spéciaux tels que : "/ \ [] <>:;+?,*.

Il est décrit en interne par un SID unique (Security ID) de type : S-1-5-21-N1-N2-N3-RID

par exemple : S-1-5-21-123456-456789-2374847-1010

S-1-5-21 toujours présent (version inchangée)N1-N2-N3 définissent le domaine (valeur identique pour tous les utilisateurs d'un domaine)Le dernier chiffre est le RID (Relative IDentifier) : il est toujours différent pour chaque élément du domaine et n'est jamais réutilisé sur un domaine.

Ceci veut dire que si vous créez un utilisateur puis le détruisez, puis le recréez avec le même nom d'utilisateur ce deuxième utilisateur ne sera pas le même en interne et ne pourra donc pas accéder aux ressources du précédents. Les ressources appartenant à un utilisateur détruit sont donc inaccessibles sauf éventuellement par l'administrateur qui doit alors changer les droits et surtout l'appartenance d'une ressource pour les rendre à nouveau accessible.

b) Contexte de compte

Il existe deux contextes de comptes d'utilisateur :– Contexte serveur : ce sont des comptes globaux gérés au niveau du domaine, ils sont donc

hébergés sur un serveur.– Contexte local : pour des machines windows clientes il existe des comptes d'utilisateur pour la

machine(en particulier l'administrateur local)

Attention : il existe aussi des comptes locaux sur un serveur (en particulier aussi l'administrateur), qui vont permettre de se connecter directement sur le serveur pour la gestion principalement.

Au moment de la connection, l'invite de login permet de choisir entre le contexte local et le contexte serveur (menu déroulant machine/domaine). De manière limitative, il n'est possible de se connecter directement qu'à un seul domaine sous Windows.

Contexte local : Ce sont les comptes d'utilisateur locaux sur une machine particulière. Les noms utilisés n'ont aucune correspondance sur une autre machine.

91

Ils sont stockés dans une base de données SAM (Security Accounts Manager) dans \windows\system32\config\SAM (c'est un des fichiers de la ruche : on le retrouve donc dans la base de registres).Cette base contient au minimum des utilisateurs prédéfinis :– L'administrateur (administrator ou administrateur) qui le premier compte créé à l'installation de

l'ordinateur– Un compte invité (guest ou invite) qui a des droits réduits (il peut être désactivé pour plus de

sécurité, ce qui est le défaut)

Sur un serveur, la gestion des comptes locaux est différente de celle des comptes de domaine concernant la stratégie de sécurité : en effet il n'est pas souhaitable, par exemple, de verrouiller le compte administrateur pour un nombre de tentatives de connection infructueuses trop important car cela bloquerait le serveur...

Contexte serveur (en fait comptes de domaine) :

Les comptes de domaine sont valides sur tout le domaine et les sous-domaines Windows. Ils regroupent en particulier tous les utilisateurs du domaine (qui peuvent donc se connecter sur toutes les machines du domaine).Il est stocké dans le fichier NTDS.DIT sous windows\NTDS. Il contient une base de données de tpye Access, qui va servir de base d'information pour le service d'annuaire Active Directory, le protocole LDAP étant utilisé pour la communication de ces informations entre machines.En fait c'est une base de données beaucoup plus large contenant : les serveurs, les stations de travail, les ressources, les paramètres des applications, les stratégies…Cette base de données est répliquée vers tous les contrôleurs de domaines du domaine concerné.

Il existe sur un serveur de domaine des comptes prédéfinis en plus grand nombre que les comptes locaux : il y a bien entendu l'administrateur du domaine mais aussi un certain nombre d'autres comptes de type administration (administrateur de comptes, d'arbre...). Concernant les comptes administrateurs, il peut être prudent de ne pas imposer des restrictions sur le nombre d'essais du mot de passe avant verrouillage comme pour le compte administrateur local pour éviter tut risuqe de blocage. A l'inverse, l'accès aux comptes administrateurs à distance doit être restreint.

Il est aussi préférable de désactivé le compte invité (guest), car une connexion locale sur un poste du domaine peut permettre ensuite l'accès aux ressources via le compte invité.D ’autres utilisateurs (et groupes) sont créés automatiquement en fonction des besoins (administrateur du domaine, de l ’entreprise…), ils sont placés dans le container "user" par défaut.

c) Création d’un utilisateur

Il existe plusieurs possibilités pour créer de nouveaux utilisateurs :– via l'interface graphique et la console utilisateurs et ordinateurs Active Directory.– commande « dsadd user » : ele permet une automatisation de la création des comptes via des

fichiers de script. Sa syntaxe est assez complexe, elle utilise un format LDIF : CN=user, OU=tpreseau, DC=istase,DC=fr pour décrire les objets.

Que ce soit par l'une ou l'autre des manières, un certain nombres d'informations sont nécessaires pour créer correctement un nouvel utilisateur :– au minimum un nom et le nom d’ouverture de session

92

– puis le mot de passe

Ensuite on peut préciser les propriétés du compte via de nombreux onglets, ces informations seront aussi stockées dans l'annuaire Active Directory :– Adresses mail, web, postale, téléphones, commentaires…– Titre du poste de travail, nom des responsables...– Profil (poste avant W2000) sinon stratégies de groupes– Membre de : appartenance aux divers groupes...

L’utilisateur ainsi créé est placé par défaut dans le conteneur "User". Comme ce n’est pas une OU il est nécessaire de déplacer l'utilisateur si on veut le contrôler plus fnement.

d) Définition d'un mot de passe

La sécurité étant un élément essentiel au bon fonctionnement d'un domaine, la méthode pour définir les mots de passe est importante.

Lors de la création d'un compte un mot de passe initial temporaire y est affecté. Il faut donc cocher la case : « l'utilisateur doit changer de mot de passe à la 1ère connexion » sauf pour les comptes partagés ou l'invité s'il est activé, car la personne qui se connecte en invité ne doit pas changer le mot de passe. De fait, pour ces comptes, il faut aussi cocher la case : "l’utilisateur ne peut pas changer le mot de passe". Enfin pour éviter que des mots de passe trop ancien subsiste avec une plus grande chance d'être découvert, il ne faut pas cocher le mot de passe n'expire jamais sauf toujours pour les comptes partagés car l'utilisateur n'a pas le droit de le modifier.

Les caractéristiques d'un mot de passe utilisateur sont définies dans la stratégie de compte (globale), ou via une GPO appliquée à une OU. Ces caractéristiques sont par exemple :– Taille minimale/maximale(8 caractères minimum recommandé)– nombre de mots de passe antérieurs interdit avant réutilisation (10 recommandé) – Lettres et chiffres ; Majuscule/minuscule– Proximité avec le nom de compte– le délai d'expiration du mot de passe– le nombre de tentatives erronées avant désactivation du compte– la durée de désactivation du compte (perpétuelle recommandé)

La règle par défaut est contraignante mais plus sure. Elle conduit à préférer les mots de passe ayant subi au moins deux transformations : insertion de un ou plusieurs caractères, de mot au sein de mot,remplacement de caractères, permutations.

De plus des règles de fonctionnement vont permettre de détecter des tentatives d'intrusion : les tentatives de connexion infructueuses sont signalées dans l'observateur d'événements. Concernant le blocage d'un compte, il y a réinitialisation du décompte automatique après une connexion réussie au compte.

7.4.2 Les profils.

93

a) Principes généraux

Les profils (ou profil utilisateur) sont un ensemble d'informations associées à un utilisateur ou à un groupe d'utilisateurs. Ils ont pour but principal la personnalisation de l'environnement de travail. C'est un des point les plus délicats de la gestion d'un domaine, les utilisateurs devant travailler dans de bonnes conditions.

Le profil contient en particulier :– la définition de l'environnement graphique,– le contenu du menu démarrer, ainsi que plusieurs autres répertoires de base– la partie utilisateur de la base de registre

Il existe deux types de profils :– les profils locaux stockés sur la machine– les profils itinérants stockés sur le serveur et recopié sur la machine.

Un profil utilisateur comprend plusieurs fichiers et répertoires.En particulier le fichier NTUSER.DAT qui va contenir les informations servant à remplir la partie utilisateur de la base de registres lors du démarrage (HKEY_CURRENT_USER). Ce fichier est stratégique pour le bon fonctionnement du compte utilisateur sur l'ordinateur. Il existe aussi un fichier ntuser.ini qui va contrôler la manière dont le profil est sauvegardé ainsi qu'un fichier ntuser.dat.log (historique des modifications) mais qui n'est pas accessible par l'utilisateur. Des applications peuvent rajoutées d'autres fichiers sous ce répertoire, mais habituellement un ou plusieurs répertoires sont prévus pour cet effet (local Settings ; Application Data).D'autres répertoires existent aussi et vont permettre de sauvegarder la configuration du bureau ou vont contenir des informations pour certaines applications (Internet Explorer...). Des répertoires temporaires permettent aussi aux applications de sauvegarder des informations durant la connexion courante (des plantages peuvent remplir artificiellement ces répertoires). Le répertoire "Mes Documents" est normalement prévu pour stocker les fichiers utilisateurs (le défaut sur la plupart des logiciels Microsoft et autres). Son usage est à déconseiller car il peut entraîner des délais importants lors de l'usage en réseaux s'il est sauvegardé sur le serveur et poser des problèmes de sauvegarde si la partition système est endommagée. Il est de bonne politique de placer les données Utilisateurs dans une partition indépendante ou de les mettre sur un partage réseaux sur le serveur dans le cas d'un usage en domaine. De même, le répertoire Bureau contient les raccourcis et fichiers déposés sur le bureau, il est donc déconseillé de placer sur le bureau des fichiers car ils sont transférer, en usage domaine, à chaque connexion et déconnexion se qui provoque des délais importants à ces phases de fonctionnement et surcharge le serveur.

b) Profil local

Le profil local est stocké sur la machine cliente dans le répertoire c:\Documents and Settings\nom de l'utilisateur. Il existe pour tous les utilisateurs locaux. Un profil local peut aussi exister pour les utilisateurs du domaine suivant la configuration.Lors de la connexion en local, des données contenues dans le profil "All Users" viennent se rajouter aux informations contenues dans le profil local utilisateur.

Enfin lors d'une première connexion, ou si un problème d'accès au profil se pose, il existe un profil utilisateur nommé "Default User" pour permettre un fonctionnement simplifié.

94

c) Profil itinérant

Ils sont stockés sur le serveur de domaine dans un répertoire partagé. Il faut préciser dans la configuration des utilisateurs sous Active Directory un chemin d'accès réseau permettant d'y accéder. La structure d'un profil itinérant est la même que celle d'un profil local.

Lors de la connexion le profil itinérant est recopié sur la machine cliente dans le répertoire associé aux profils locaux. Cette copie du profil est conservée en local (sauf indication contraire dans la configuration), elle permet en cas de problème de connexion au serveur de conserver une copie pour une utilisation ultérieure. En fait, il y a un choix du profil retenu lors d'une connexion : si les deux existent : le plus récent (comparaison de la date de NTUser.dat) est conservé. Comme le profil itinérant est mis à jour par recopie du profil local lors de chaque déconnexion, ils doivent être synchronisés si l'utilisateur reste sur la même machine. Dans le cas d'un usage nommade (même au sein d'un même établissement), il ya des mises à jour qui sont faites et les connexion/déconnexion sont plus longues surtout en fonction de la taille du profil…

Pour accélerer cette recopie, certains répertoires ne sont pas recopiés, c'est le rôle du fichier ntuser.ini qui va définir les répertoires à prendre en compte et ceux à ne pas recopier.

Si un profil itinérant est défini, lors de la première connexion de l'utilisateur sur le domaine un profil est créé avec le profil courant de la machine (Default User), le répertoire utilisateur est créé sur le serveur. Il est donc assez important de bien choisir sa machine lors de la première connexion (celle où un profil par défaut est bien construit). A chaque modification, ce profil est sauvegardé sur la machine et sur le serveur. Ensuite, lors d'une connexion sur une nouvelle machine, il y a recopie du profil itinérant en local sur la machine et l'environnement résultant et ce profil en addition du profil "All User" de la machine en local. C'est pour cela que même en fonctionnement de profil itinérant les configurations peuvent varier.

Pour des raisons de sécurité et de bon fonctionnement, il peut être nécessaire de figer l'environnement de travail des utilisateurs. Ceci est relativment simple avec les profils itinérants, il suffit alors de renommer NTUser.dat en NTUser.man (de mandatory). Le seul fait de changer cette extension va faire que le profil itinérant sera en lecture seul : l'utilisateur peut changer ses paramètres lors d'une session, mais ils ne seront pas conservés pour la session suivante.

7.4.3 Les scripts.

a) Les fichiers de commande Windows

Même si Windows n'est pas un SE orienté ligne de commandes, l'usage des scripts y est possible et même incontournable pour un certain nombre d'opération d'administration.

Sous Windows, initialement les fichiers scripts sont des fichiers de commande (type *.bat). Il vont permettre d'exécuter une suite de programmes via un langage de commande. Ces programmes ne doivent pas avoir d'interfaces graphiques (ils doivent fonctionner en mode console). Toutes les commandes natives du shell DOS/Windows sont utilisables. Certaines se sont rajoutées ensuite. Sur un serveur des commandes supplémentaires sont aussi disponibles pour gérer la base Active Directory (dsadd...) et un certain nombre d'autres services (DNS...).Des variables peuvent être utilisées, ce sont des variables d’environnement. Elles sont entourées par le caractère %.Exemples : %username%, %Homedrive%, %Homepath%, …

95

Hormis le langage de commande de base, d'autres langages sont possibles (sans restriction si il existe un interpréteur) : par exemple PERL, Python, Jscript.

b) Configuration des services (commande net)

Tout un ensemble de commandes vont permettre de gérer des services réseaux. Elles existent depuis les premières versions. Ce sont les commandes "net xxx ". Elles vont permettre entre autre de gérer le fonctionnement de NetBIOS.

Commandes sur un clientNet name : définition d ’un aliasnet print : impression d ’un fichiernet send : envoi d ’un messagenet use : montage d ’un disque réseaunet config : affiche la configurationnet statistics : affiche les statistiquesnet time : synchronise un ordinateurnet view : fournit la liste des serveurs et des ressourcesnet helpmsg : affiche l ’aide sur les messages (erreurs, alertes)?net help : aide en ligne (aussi : net [cmde] /help)?

Gestion sur un serveurNet user : gère les utilisateursnet group : gère les groupesnet localgroup : gère les groupes locauxnet account : gestion base de données utilisateurnet computer : gestion base de données domainenet file : referme les fichiers ou liste les fichiers ouvertsnet session : gère les sessions sur un serveurnet share : gestion des partages

Commande de gestion des servicesNet start : démarre un service réseauNet stop : arrête un service réseauNet pause : arrête temporairement un service réseaunet continue : redémarre un service réseau

Par exemple :Montage d'un partage disk\répertoire du serveur sur le disque logique n:

(net use n: \\serveur\\disk\repert)Envoi d'un message aux utilisateurs :

net send utilisateur message

c) Scripts utilisateurs

Ces commandes vont en particulier permettre de réaliser des opérations par exemple lors du démarrage du PC. On les retrouve dans les script de Login.L'exécution a lieu dans une fenêtre de commande (cmd.exe) fugitive, on la voit apparaître lorsqu'une commande du script est bloquante (demande de mot de passe...)

96

Windows server utilise les scripts a plusieurs moments de la connexion/deconnexion :– Scripts de connexion (pour l'utilisateur), – Scripts de déconnexion (pour l'utilisateur) ,– Scripts d’arrêt (pour la machine),– Scripts de démarrage (pour la machine).

On peut définir un script d’ouverture de session de plusieurs manière :Dans les informations de profil du compteDans les stratégies de groupes (GPO)

L'exécution est soit synchrone (bloquant) soit asynchrone (non bloquant), ce réglage se fait dans la base de registres. Normalement, l'exécution du script de connexion se fait dans une fenêtre de commande visible mais elle peut être cachée. Attention : les scripts peuvent être bloquants ou longset même nécessiter une intervention utilisateur si il y a une authentification demandée. Le test avant usage doit donc être méticuleux et se faire avec les mêmes droits que l'utilisateur potentiel.

En environnement domaine, les scripts de connexion sont recherchés par les clients dans un partage NETLOGON défini sur le serveur par défaut dans Windows\SYSVOL\sysvol\domain_name\script. En effet comme l'utilisateur ne peut avoir défini de directive de montage avant de lancer le script qui les contient, il doit donc y avoir au moins un répertoire partagé qui est un nom prédifini permettant d'accéder aux scripts de démarrage, c'est le rôle de NETLOGON présent depuis les premières versions de Windows Server. Toutefois une option existe dans les versions les plus récentes permettant de définir un montage utilisateur directement dans un onglet de la configuration utilisateur.

Un même script peut être défini pour plusieurs utilisateurs. De fait, le partage NETLOGON ne peut avoir de protection en lecture, il est donc lisible par tous même avant connection au serveur. Les fichiers scripts qu'il héberge ne doivent pas contenir des directives portant atteinte à la sécurité (exemple : mot de pas dans une directive net use...).

d) Scripts de gestion

Ils vont permettre à l'administrateur d'automatiser un certains nombre de procédures répétitives et fastidieuses, par exempe :– Création de nombreux utilisateurs– Création de répertoire utilisateurs– Modification des caractéristiques d’un ensemble d’utilisateurs

Des scripts d'automatisation des tâches plus complexes peuvent se faire à partir de plusieurs langages spécifiques : en langage Perl, il est possible d’utiliser des fichiers texte en entrée qui vont permettre de paramétrer les actions (mot de passe tiré au sort...).

Windows Server met à disposition des commandes supplémentaires pour la gestion d'Active Directory :– Création d'utilisateur : commande dsadd user– Modification des caractéristiques d’un ensemble d’utilisateurs : commande dsmod user– Utilisation possible de l’annuaire Active Directory par des requêtes : dsquery puis utilisation du

résultat dans un pipe...

97

7.4.4 Les comptes d'ordinateurs

Sous Active Directory, il existe aussi des objets ordinateur. Ceux-ci vont permettre de les placer dans des unités d'organisation afin d'en contrôler le fonctionnement.

Ces comptes d'ordinateurs du domaine peuvent être créés de plusieurs manières :– 1ère approche (Sur le contrôleur du domaine)Création d'un compte pour le nouvel ordinateur par utilisation du gestionnaire de serveurCliquer sur Ordinateur puis Ajouter au domaine– 2ème approche : sur le poste que l'on veut connecter au domainePossibilité de créer un compte d'ordinateur à distance via l'onglet : nom d ’ordinateur dans Propriétés Système puis modifier puis nom de domaine. Il y a ensuite création automatique à la 1ère connexion (il faut toutefois une authentification utilisateur avec des droits appropriés sur le serveur : c'est à dire administrateur de comptes).

7.5 Ressources

7.5.1 Généralités

Un des objectifs d'un serveur est de fournir des ressources partagées aux postes du domaine. Les ressources habituelles sont des répertoires ou disques, c'est à dire un espace de stockage ou l'accès à des informations stockées, des imprimantes.D'autres ressources sont possibles : services, registres, GPO...

La mise à disposition de ressources s'effectue en plusieurs étapes :– Côté serveur : partage de ressourcesDéfinition d'un partage (clic droit sur le répertoire puis partage)attention il faut décocher l’onglet partage simple dans l’explorateur pour pouvoir contrôler le partage d'une ressource.– Côté Serveur : définir des autorisations d ’accès (liste de contrôles d'accès : ACL)Cela va permettre de d'autoriser ou refuser les différents accès (lecture, écriture...) aux ressources par les utilisateurs ou les groupes.– Côté Client : montage de la ressourceLe client s’attribue la ressource qui apparaît comme un disque logique (une lettre suivie de:) par une commande net use ou par l'explorateur de fichiers, ou comme une imprimante partagée.

Sur Windows Server, il existe aussi une console de gestion des ressources appelable par une MMC (Microsoft Management Console) via un composant logiciel enfichable.

7.5.2 Les permissions d'accès

a) Principe

Leur objectif est d'autoriser ou d'interdire l'accès de certaines machines et/ou utilisateurs à diverses ressources d'autres machines (les serveurs).

98

Elles vont permettre de gérer le niveau d'accès maximal à un fichier ou à un répertoire local ou au contenu d'un partage.

Initialement, les permissions sous Windows étaient assez limitées (lecture, écriture, accès total). Avec les listes de contrôle d'accès (ACL : Access Control List), cet aspect est devenu beaucoup plus détaillé. Les ACL sont devenus l'outil de base pour gérer l'accès des utilisateurs aux ressources (fichiers, répertoires, périphériques).

Les ACL vont permettre de définir des permissions (autorisation ou refus) pour des utilisateurs et des groupes. De base, il y a 6 groupes d'accès possibles :– aucun accès– lecture– lecture et exécution– écriture– modifier (=lire, écrire, exécuter, supprimer)– contrôle total (=modifier + droit de changer les permissions)

En fait il y a 13 autorisations spécifiques

Les groupes d'accès correspondent à des droits représentés par une lettre :Contrôle total : RWXDPOModifier : RWXPLire : RXAutorisation spéciale : définition manuelle des droits d'accès (c'est à dire accès aux 13 items spécifiques).

En cas de conflit de permissions, ce sont les permissions les plus restrictives qui s'appliquent.Pour chaque item on peut définir : autoriser ou refuser, ce qui va encore compliquer les droits d'accès résultants.L'accès à un fichier est indépendant de l'accès à un répertoire. Un utilisateur peut accéder à un fichier même si le répertoire ou l'un des répertoires du chemin d'accès lui est interdit.

Attention à l'imbrication des droits d'accès, car les autorisations ou les refus peuvent venir de l'utilisateur mais aussi des groupes auxquels il appartient.Exemple : l'utilisateur toto ne dispose pas a priori des droits pour accéder au fichier boot.ini. Mais s’il est membre du groupe Administrateur, il peut modifier ses droits d'accès et ainsi passer outreRemarque : lorsqu'on spécifie des droits d'accès pour un répertoire, on a 2 jeux de droits : un pour le répertoire et un pour les fichiers qui seront ajoutés à ce répertoireil peut y avoir héritage des droits pour les sous-répertoires et les fichiers contenus dans un répertoire (case à cocher pour choisir l’option).

Dans un environnement complet avec des utilisateurs et des groupes divers, la définition des droits résultants devient rapidement difficile à évaluer. Il existe un outil permettant d'obtenir les droits résultants calculés par Windows.

b) Mise en oeuvre

Une boîte de dialogue permet de régler ces droits pour chaque utilisateur ou groupe ajoutés (bouton de droite puis sécurité) avec un choix initial :– Autorisations spéciales– lecture

99

– lecture et exécution– écriture– modifier (=lire, écrire, exécuter, supprimer)– contrôle total (=modifier + droit de changer les permissions)

Principes de base de mise en œuvre.Une ACL fiable repose sur des groupes d'utilisateur solides et cohérents. Il faut donc planifier la constitution des groupes pour qu'ils soient logiques et associés à des besoins réels.Les accès doivent être distribués avec parcimonie, si possible à partir de l'item de taille la plus petite. Éviter d'ajouter tout un groupe à une ACL pour satisfaire les besoins d'un seul utilisateur.Attention aux cases « Refuser » qui conduisent souvent à une perte d'accès aux ressources. Par exemple, refuser contrôle total à « Utilisateurs », fait qu'il n'y a quasiment plus d ’accès à la ressource (car l’utilisateur administrateur peut aussi être utilisateur) !

7.5.3 Les droits ou privilèges.

Une autre approche coexiste avec les ACL, ce sont les privilèges :Droits spécifiques attribués à des groupes (ou utilisateurs)Exemple : droit de sauvegarde pour les opérateurs de sauvegarde (c'est à dire droit de lecture sur toutes les ressources à sauvegarder).

Les droits sont définis avec l’outil paramètres de sécurité du poste (gestion de la sécurité locale) ou du contrôleur de domaine (Stratégies locales->Attribuer des droits utilisateurs).

Les privilèges passent outre les ACL, sinon les opérations de maintenance sont impossibles.

Quelques exemples de droit :– Accéder à cet ordinateur depuis le réseau– Ajouter des ordinateurs au domaine– Sauvegarder des fichiers et des répertoires– Restaurer des fichiers et des répertoires– Modifier l'heure système– Gérer le journal d'audit et de sécurité– Arrêter le système– Prendre possession de fichiers ou d'objets

7.6 Les Stratégies

7.6.1 Principe

Elles sont un complément aux autorisations et aux droits en particulier pour les ressources particulières et pour le fonctionnement global du poste de travail.

Windows server fournit des outils supplémentaires pour contrôler le fonctionnement des postes au sein d’un domaine Active Directory. Le cœur de la gestion d'un poste de travail étant la base de registres, il est alors nécessaire de réaliser des actions sur la base de registres au moment de la

100

connexion par exemple, les stratégies vont le permettre et donc étendre le champ d'action du serveur sur les postes de travail.

7.6.2 Historique.

Cette approche existe depuis les versions NT Server sous la forme de Stratégies systèmes (avant W2000 server). Elles pouvaient être appliquées aux utilisateurs et ordinateurs et influencer le fonctionnement des applications. Leur gestion se faisait par un utilitaire PolEdit, les stratégies système étaient enregistrées dans un fichier NTConfig.pol. Elles permettaient de sauvegarder et d'imposer des configurations dans la base de registres lors d ’une connexion.Elles se sont transformée en Stratégies de groupes (GPO : Group Policy Object) à partir de Windows Server 2000, elles s'appliquent à certains objets Active Directory (unité d'organisation, domaine). Elles rassemblent aussi les configurations utilisateurs (script…)Les objectifs est de définir les actions que chaque utilisateur est autorisé à effectuer sur une machine donnée, c'est une notion assez proche du profil (car lié à l'aspect du bureau) mais plus efficace au niveau de la sécurité

7.6.3 Les GPO.

Les GPO (Group Policy Object) sont des objets Active Directory rassemblant les droits, les règles de fonctionnement et les paramètres applicables aux ordinateurs ou aux utilisateurs d'un domaine Windows Server. Les GPO permettent une gestion plus fine des autorisations.Elles regroupent un ensemble de paramètres très complet.

Elles sont associables à seulement certains objets Active Directory :– Site– Domaine– Unités d’organisation

Ces objets peuvent contenir les objets sur lesquels elles sont applicables : ordinateurs, utilisateurs...Contrairement à ce que pourrait laisser penser leur nom, elles ne sont pas associables à des groupes mais elles peuvent s'appliquer aussi à des groupes à condtion qu'ils soient inclus dans des unités d'organisation.

Les GPO étant des objets Active Directory, on peut et doit définir des autorisations sur les Objets GPO : Création, destruction, lecture/application. Leur accès en modification doit être limité aux administrateurs car elles ont une incidence directe sur la sécurité dans le domaine.

La gestion des GPO s'effectue par un outil graphique de gestion : la GPMC (Group Policy Management Console). A l'ouverture apparaît un choix sur les éléments à contrôler.

101

Au premier niveau, deux choix existent :– ordinateur, les paramètres ne s'appliqueront qu'aux ordinateurs placés sous l'objet où est appliqué

la GPO.– utilisateur, les paramètres ne s'appliqueront qu'aux utilisateurs et groupes placés sous l'objet où est

appliqué la GPO.

Le 2ème niveau est identique pour les 2 items de 1er niveau :– Paramètres de logiciel (installation de logiciels)– Paramètres Windows (scripts + sécurité)– Modèle d ’administration

Quoi qu'il en soit les items présents sous ces onglets de 2ème niveaux sont différentes : si cela concerne l'ordinateur les paramètres vont être liés au comportement des applications et des ressources. Si cela concerne les utilisateurs : les paramètres interviendront sur le bureau, les différents menus...

Par défaut, très peu de paramètres sont configurés, lorsqu'ils sont configurés, ils peuvent prendre 2 états : Activé ou Désactivé. L'état Désactivé n'est pas équivalent à Non configuré, car dans le premier cas la Gpo applique l'état Désactivé, dans le deuxième elle laisse le choix de l'étatà un autre niveau de fonctionnement (autre GPO, paramètres locaux).

102

Un bon paramétrage de GPO est difficile à mettre en place. En effet, il y a une telle abondance de possibilités que le choix est souvent difficile et les résultats aléatoires.Par exemple, il est recommandé de se méfier de paramètres qui paraissent intéressants mais qui ne le sont pas : empêcher de lancer RegEdt32 utile si l'on veut empécher l'utilisateur de modifier la base de registres n'empêche en fait que de lancer une application qui a ce nom là et donc ne verrouille pas grand chose, il est toujours possible via une copie renommée d'exécuter des applications Windows non autorisées.

7.7 Les outils d'administration

Windows Server propose un certain nombre de services afin de faciliter la gestion du serveur– Sauvegarde et restauration de fichiers (backup)?– Observateur d'événements serveur (Audit)?– Surveillance du réseau, analyseur de performances– Administrateur d'accès distant– etc....

7.7.1 Les sauvegardes.

C'est une des responsabilités principales de l'administrateur système : il doit assurer que les utilisateurs ne perdent pas leurs données.Il faut définir une stratégie de sauvegarde : le temps investi pour mettre en oeuvre une bonne stratégie de sauvegarde n'est jamais du temps perdu, car il faut répondre à de nombreuses questions pour assurer le servcie auprès des utilisateurs :– Quels fichiers doivent être traités ?

Tous, mais pas forcément tous à la même fréquence ....– Où ces fichiers se trouvent ils ?

Déterminer les ordinateurs les plus importants à sauvegarder– Qui est chargé de sauvegarder tel fichier ?

Par exemple, Administrateur réseau : le serveur, utilisateur :disques locaux– Quelles sont les ressources mises en oeuvre ?

Lecteur de bande, CDRom, ...– Où, Quand et dans quelles conditions ont lieu les sauvegardes ?

Idéalement depuis le poste de l'administrateur en dehors des heures ouvrables– Quelle est la fréquence des sauvegardes?

Tous les jours pour les fichiers importants, sinon 1 fois par semaine (par exemple). Il faut garder à l'esprit que l'objectif est de faire perdre le minimum de temps à l'entreprise. De fait, lors de la perte de données, la sauvegarde n'a un intérêt que si le temps cumulé de sauvegarde et de restitution des données perdues est inférieur au temps passé à les créer. L'opération de sauvegrade est souvent automatisée, mais celle de reconstruction est toujours une opération délicate et qui prend du temps.

Concernant les fichiers et répertoires plusieurs opérations sont possibles :– Sauvegardes complètes

Tous les fichiers sont copiés et marqués sauvegardés– Sauvegarde par duplication

Tous les fichiers sont copiés

103

– Sauvegarde différentielleTous les fichiers modifiés depuis la dernière sauvegarde complète sont copiés et marqués sauvegardés

– Sauvegarde incrémentielleIdem précédent sauf sauvegarde précédente de type quelconque

– Sauvegarde quotidienne : Tous les fichiers de la journée

Initialement les opérations de sauvegarde requieraient un lecteur de bande. Sous Windows Server la stratégie de sauvegarde a complètement changée depuis Windows Server 2008. Elle était basée avant sur NTBackup associé avec un lecteur de bande. Suite à la disparition progressive de ce type de périphérique, il n'est plus géré dans les nouvelles versions : les sauvegardes s'effectuent maintenant sur des disques ou via des CD/DVD. L'accès aléatoire pour ce genre de périphérique permet une restauration plus facile que sur une bande où seul un accès séquentiel était possible. Les outils de sauvegarde sont accessibles seulement aux membres des groupes Administrateurs et Opérateurs de sauvegarde.

Plusiuers éléments font que les outils de sauvegarde fournis avec Windows Serverv ne sont pas suffisants pour une grande entreprise, il faut alors utiliser de préférence des utilitaires du commerce plus approfondis.En particulier, il est insuffisant de ne sauvegarder que les fichiers, il faut aussi conserver les autorisations voire d'autres informations.Par défaut, les fichiers sont restaurés dans leurs répertoires d'origine. Si on ne restaure pas l'ACL, alors c'est l'utilisateur qui restaure le fichier qui en devient propriétaire, et l'ACL par défaut du répertoire est appliquée.

7.7.2 L'observateur d'événements.

C'est le premier outil à connaître pour identifier les différents problèmes de fonctionnement d'un serveur. Il va répertorier les problèmes de lancement de services, les tentatives de connexion frauduleuses.

C'est un outils totalement paramétrables, sur chaque objet Windows 2003 on peut définir des actions à auditer. Hors de son usage par défaut, il est d'une très grande complexité. Il faut en particulier faire un compromis entre le nombre d’évènements que l'on surveille et une surveillance efficace. Les messages de surveillance sont destinés à un opérateur qui doit pouvoir les explorer sans trop prendre de temps.

L'audit de sécurité est une facette de l'observateur d'événements :Selection de Journal->SécuritéConfiguration des événements reportés dans l ’audit de sécuritéStratégies>Audit (gestionnaire des utilisateurs) Les évènements "auditables" sont :– Ouverture et fermeture de sessions– Accès à certains fichiers ou objets– Gestion des utilisateurs et groupes– Modifications des stratégies de sécurité– Redémarrage / arrêt du système

104

Remarque : il est aussi possible de filtrer les événements par date, par source, par utilisateur

105

7.7.3 L'évaluation des performances.

Un autre outil va permettre de suivre les performances du serveur : l'analyseur de performances. Il propose :– des graphes de compteurs d'accès (Différents compteurs : temps processeur, temps utilisateur...)– des journaux de performances– des alertes de baisse de performances

Cet outil va permettre de surveiller le système en permanence et de pouvoir donner des indications lors de baisse de performances. Les informations sont par défaut assez sommaire.

106

Il propose certaines fonctionnalités intéressantes, par exemple :– l'enregistrement des performances dans un journal, ce qui permet de faire des recoupements

d'informations entre baisse de performances et différents événements.– La définition d'alerte (Alerte sur différentes valeurs de compteurs) : par exemple sur le temps

CPU utilisé

Quoi qu'il en soit, en fonctionnement normal, les performances sont directement liées aux ressources mise en jeux (taille de la mémoire centrale, puissance du processeur...). Cet outil est surtout utile lors de problèmes de fonctionnement liés à une application trop gourmande par exemple (Antivirus inadapté à la puissance de la machine...).

7.7.4 Le service planning

Son objectif est de planifier le lancement de tâches répétitives.Exemple : sauvegarde journalière des différents fichiers journal

Commande at Syntaxe : at [\\hote] heure [quand] commande

Exemple :at \\istase 16:00 /every:vendredi SumEvent.bat

Cette commande a été remplacée par schtasks sous Windows Server 2003 :

schtasks /paramètre [arguments]

Liste de paramètres de premier niveau:

107

/Create Crée une nouvelle tâche planifiée. /Delete Supprime les tâches planifiées. /Query Affiche toutes les tâches planifiées. /Change Modifie les propriétés d'une tâche planifiée. /Run Exécute la tâche planifiée immédiatement. /End Arrête la tâche planifiée actuellement en cours d'exécution. /? Affiche cet écran d'aide.

Des arguments supplémentaires sons ensuite ajoutés suivant la fonction demandée :

/S système Spécifie le système à distance sur lequel seconnecter. /U nom_utilisateur Spécifie le contexte de l'utilisateur sous lequel la commande doit s'exécuter. /P mot_passe Spécifie le mot de passe pour un utilisateur donné. /TN nom_tâche Identifie la tâche planifiée à exécuter. /? Affiche cet écran d'aide.

Exemple : SCHTASKS /Run /S servertest /U admintest /P admintest /TN "Sauvegarde Incrémentale"

7.7.5 Gestion des contrôleurs de domaine

En environnement de taille importante, il est nécessaire de faire cohabiter plusieurs serveurs et contrôleur de domaine. Il va être en particulier nécessaire de synchroniser les contrôleurs de domaine entre eux pour que les informations Active Directory contenu dans le contrôleur principal puissent être partagées vers les serveurs contrôleur de domaine secondaires : on parle alors de synchronisation des contrôleurs secondaires.La synchronisation est faite par défaut lors de l'ajout d'un nouveau contrôleur

Outil graphique : Gestionnaire de serveurOption Ordinateur, Synchroniser avec le contrôleur principal

Promouvoir des ordinateurs aux rôles de contrôleur de domaineCommande ordinateur, promouvoir au rôle de PDC

Rétrograder le PDC en contrôleur secondairesuppression du compte d'ordinateur, réinstallation de NT,…

Attention les fonctionnalités dépendent des niveaux du domaine : natif, mixte...

7.7.6 Gestion des serveurs de fichiers

Toutes les fonctions liées aux serveurs de fichiers sont regroupés sur une console d'administration. On y retrouve les 4 fonctions principales :– la gestion physique et logique des unités de stockage (Administration des disques et des volumes)– la gestion globale des ressources de type fichiers (Gestion de ressources du serveur)– la gestion des partages (Gestion des dossiers partagés)– la gestion du système de fichiers distribué (DFS)

108

L'administration des disques et volumes permet de définir de nouvelles partitions, de gérer leurs tailles et de leur affecter une lettre de lecteur (par exemple x:).Il peut y avoir deux types de partition :Partition principale : partition qui accueille un système d'exploitationPartition étendue : partition dédiée aux donnéesSur un disque formaté avec Windows, il peut y avoir un maximum de 4 partitions.

Si il y a plusieurs partition principal, une seule est active.Sur une partition étendue, vous pouvez créer plusieurs unités logiques qui vont apparaître comme des disques différents (lettres différentes).

Le gestionnaire de ressource va permettre de contrôler les quotas d'occupation du disque (taille maximale adminssible pour un utilisateur) et de gérer du filtrage (fichiers interdits de stockage).

Le gestionnaire des dossiers partagés lui va concerner les définitions des paratges et le suivi des postes les utilisant.

109

7.7.7 NTFS

NTFS (New Technology File System) est le système de fichiers standard sous Windows. A l'inverse de son prédécesseur (système FAT), il permet de définir un propriétaire pour les fichiers ainsi que des autorisations d'accès complexes. Il a une capacité théorique de stockage très importante (Plusieurs To).

Il permet la journalisation : toutes les opérations réalisées sur le système sont stockées dans un fichier journal. Ceci permet "théoriquement" de reconstruire le système dans la dernière bonne configuration connue après un plantage.

Il met en place une écriture différée des données : écriture directe dans un cache mémoire vive, écriture en temps masqué sur le disque dur.

La description d'un fichier sous NTFS comporte :– son nom en UNIcode– des dates (création, dernier accès, dernière modification)– des attributs DOS (lecture seule, archive, caché, système) pour compatibilité– des autorisations de sécurité (ACL)

Cela permet un contrôle d'accès discrétionnaire : permet de spécifier des notions de contrôles d'accès au niveau répertoire et fichiers.

NTFS peut être activé avec une compression automatique des données ainsi qu'avec un cryptage.

7.7.8 La sécurité sous Windows Server

110

Le premier niveau essentiel de sécurité est le contrôle d'accès aux comptes avec droits : mots de passe fiables. La stratégie par défaut de Windows Server concernant les mots de passe peut paraître contraignante mais elle est sure.Il peut être intéressant d'utiliser un compte Administrateur différent de celui par défaut pour le rendre moins repérable, car il faut connaître le couple login/mot de passe et non pas seulement le mot de passe.

Utiliser avec parcimonie le groupe Tout le monde car il regroupe à la fois des utilisateurs authentifiés (password) et aussi des utilisateurs non authentifiés. Une bonne pratique est de ne jamais l'utiliserdans des ACL et de le remplacez par le groupe "Utilisateurs authentifiés".

Tous les objets Active Directory étant controlable par des ACL, il peut être intéressant de protéger des clés du registre par des ACL.

Verrouiller certains accès réseau : La configuration avancée de TCP/IP permet d'interdire des accès protocole par protocole : il faut mettre en œuvre le Firewall et le paramétrer correctement.

Il faut aussi utiliser correctement l’observateur d ’évènements et régler les évènements à auditer.

111

TP OptionRX1

N°03 : Configuration de Windows 2003 Server en contrôleur de domaine et serveur de fichiers

Objectifs du TP:

Installation et paramétrage d’un serveur de fichiers sous Windows Server 2003

Ressources nécessaires au TP

– Deux PC client sous windows XP et un troisième connecté en mode console à distance sur un serveur Windows 2003. Liaison physique entre les PC et le serveur par un switch.

– 2 serveurs sont disponibles : l'adresse du serveur ISTASE2003TP1 est 10.20.1.10, l’adresse du serveur ISTASE2003TP2 est 10.20.2.10.

– Le nom de login est adminposteX. (X étant le numéro du poste de travail)

Attention vous avez des droits d’administration sur un serveur qui est utilisé par plusieurs

groupes...

Phase 1 : Configuration réseau des PC client et serveur6. Configurer les adresses IP sur les 3 machines. Vérifier le bon fonctionnement par un ping.7. Connectez-vous sur le poste Server 2003 par une machine XP en bureau à distance.

Phase 2 : Configuration du serveur DNS1. Lancer la console de gestion DNS (démarrer -> outils d’administration -> DNS).2. Créer un fichier de zone pour le domaine ISTASE2003TPx.fr contenant les relations pour

les 2 machines plus le serveur :Nom des clients : clientxx.ISTASE2003TPx.frNom du serveur : serveur.ISTASE2003TPx.fr

3. Configurer la résolution de nom ainsi que la résolution inverse (console DNS). Pour vérifier s'il y a des problèmes de configuration, vous pouvez utiliser l'observateur d'évènements.

4. Configurer le serveur et le poste client Windows afin qu’il utilise ce DNS.5. Tester vos configurations via des ping de la machine cliente Windows vers l’autre machine

cliente en se servant des noms littéraux.6. Visualiser le cache DNS de votre machine (ipconfig /displaydns)7. Visualiser les trames échangées entre la machine et le serveur DNS lors de la résolution.8. Utiliser la commande nslookup pour tester les résolutions directe et inverse mises en place.9. Activer les enregistrements dans le journal de log à partir de la console DNS. Mettre en

œuvre quelques résolutions puis consulter le journal avec l’observateur d’évènements.

Phase 3 : Configuration des utilisateurs

1. En utilisant la console de gestion des utilisateurs (menu Utilisateur et Ordinateur Active Directory), visualiser les différents éléments de la structure active directory. Retrouver les groupes, les Unités d’organisation et les utilisateurs. Vous travaillerez uniquement dans l’OU (Organization Unit) relative à votre poste (Tpreseau->postex).

2. Avec la console, créer un compte utilisateur ayant pour nom celui d'une des personnes du groupe. Placer le sous l’OU vous étant attribuée.

3. Faire la même opération en ligne de commande (commande dsadd) pour les autres personnes du groupe. Automatiser en créant un fichier *.bat regroupant ces commandes.

112

4. Modifier et compléter les caractéristiques des utilisateurs pour peupler l’annuaire Active Directory. Soit par bouton de droite et onglet propriétés, soit en ligne de commande (commande dsmod).

5. Sur les ordinateurs clients, connectez-vous en vous raccordant au domaine Windows 2003 adéquat (Poste de travail->Propriétés->nom de l’ordinateur). Visualisez les modifications dans la base de données Active Directory sous l’onglet Computer. Déplacer ces ordinateurs pour les mettre dans votre OU.

Phase 3 : Mettre en œuvre l’accès au fichier par partage

1. Ajouter un répertoire spécifique à chaque utilisateur dans l’arborescence F :\posteX. Attribuer lui le nom de l’utilisateur, donner les droits d’accès à cet utilisateur sur ce répertoire. Pour lui permettre de l’utiliser à distance partager le répertoire F:\posteX. Vérifier le bon usage en montant un disque réseau sur le client.

2. Définir des autorisations différentes pour les différents répertoires utilisateurs relativement aux autres utilisateurs (Lecture, Ecriture…). Vérifier le bon fonctionnement. Finalement, attribuer les droits de lecture seuls pour les utilisateurs non propriétaire du compte.

3. Ajouter un répertoire partagé accessible à tous les utilisateurs. A qui appartiennent les fichiers déposés ?

4. Définir des quotas sur chaque répertoire (console mmc_quota à lancer en ligne de commande).

Phase 4 : Création d’unités d’organisation et de groupes1. Créer des nouvelles unités d’organisation, aux noms des étudiants, contenue dans l’unité

posteX. Donner le contrôle de gestion de chaque OU respectivement à l’utilisateur de même nom. Quels droits effectifs a cet utilisateur sur l’OU ? Positionner dans chaque OU, 2 utilisateurs (user1, user2…), y mettre aussi un ordinateur client.

2. Créer une troisième OU (Ounomdesdeuxétudiants), et donner le contrôle sur cette OU au groupe constitué par les 2 étudiants initiaux. Déplacer les 2 étudiants dans cette OU.

Phase 5 : Définition des profils, des scripts de connexion et contrôle des propriétés1. Créer un script permettant de connecter un lecteur réseau. Tester en appelant ce script.2. Pour un utilisateur, définir un profil itinérant et le script de connexion (en utilisant celui créé

précédemment) par l’onglet adéquat. Le script doit être placé dans le partage netlogon du serveur et le profil dans un autre répertoire partagé.

3. Connecter-vous avec le nom du premier utilisateur, vérifier qu’un profil a été créé sur le serveur à l’endroit déterminé.

4. Modifier l’aspect du bureau, vérifier que cette modification a été sauvée en vous connectant avec l’autre utilisateur ayant le profil en commun.

5. Sur le serveur, modifier l’extension du fichier ntuser.dat en ntuser.man (profil obligatoire), reconnecter-vous, faite une modification sur le bureau. Puis déconnectez-vous et reconnectez-vous et vérifier que le profil est resté comme à l’initial.

6. Sur le client, visualiser le fichier c:\windows\debug\usermode\userenv.log pour voir les différentes étapes de la connexion.

7. Pour le groupe d’utilisateurs, définir un script de connexion supplémentaire (en en créant un deuxième avec un autre montage) par une GPO associée à la troisième OU.

8. Créer une nouvelle GPO pour chaque unité d’organisation créée précédemment. Peut-on en créer pour les utilisateurs ?

9. Configurer différemment les paramètres d’Internet Explorer sur les différents comptes et les différentes machines de votre domaine grâce aux GPO.

Phase 6 : Arrêt : Déconnecter vous du serveur puis arrêter les PC et éteindre les écrans.

113 114

Chapitre 8 : Serveurs

UNIX/Linux

8.1 Introduction.

8.1.1 UNIX/Linux : historique

UNIX est un système d'exploitation fonctionnant sur divers processeurs : Sun Sparc, DEC Alpha, PowerPC IBM …et aussi sur PC et compatibles Intel (Linux et FreeBSD)Il est entièrement multitâche préemptif et multi-utilisateurs.

Partant d'un base de développement commune dans les année 1970, il est apparu deux familles initiales d'UNIX : une libre d'origine universitaire BSD (Berkeley Software Distribution) avec diffusion des sourcesune dépendant d'ATT : System V

Quoi qu'il en soit au fur et à mesure des versions des parties de code ont été échangées, conduisant à des systèmes proches mais pas tout à fait compatibles.

Dans les années 1990, en parallèle avec des versions propriétaires (AIX d'IBM, HPUX de HP, Solaris de SUN), des versions libres ont été développées : GNULinux, repartant d'une base de codes différentes, et des versions basées sur BCD : NetBSD, OpenBSD et FreeBSD pour une architecture PC.

8.1.2 GNU/Linux

Les distributions Linux sont exemptes de droits d'utilisation. Le code source est livré et « recompilable ». Il est donc complètement indépendant vis à vis des éditeurs de logiciel.

Différentes distributions sont proposées : Red Hat, Caldera, Debian, Suse, Ubuntu... avec plus ou moins de variantes. Elles se distinguent sur la méthode de distribution (les paquets) et sur les utilitaires d'installation.Les distributions sont toutes basées sur le même noyau Linux dont la version est repérée par une suite de 3 nombres : X.YY.ZZExemple : 2.0.34

115

Elles proposent un certain nombre d'applications, en particulier plusieurs environnements graphiques (gnome et kde) permettant un usage identique à Windows.

Le type de distribution libre conduit à un inconvénient pour l'utilisateur : aucun service après vente n'est disponible, quoi qu'il en soit la communauté Linux sur Internet est très active et il est des fois plus rapide d'obtenir une solution à son problème qu'avec un vrai SAV. Dans les versions plus anciennes, la prise en charge de certains périphériques récents n'était pas possibles, cette partie étant souvent laissée au bon soin du fabricant de périphériques, ceci est beaucoup moins sensible actuellement.

Des entreprises proposent des versions payantes car elles y inclus des services supplémentaires dont l'aide à l'installation ou des fonctionnalités propres dans la gestion. C'était le cas de Novell qui est passé d'un système d'exploitation serveur propriétaire à une implémentation de Linux Suse. De même dans le domaine des stations de travail,

8.1.3 BSD

Dans le même ordre d'idée, la branche universitaire d'UNIX a continué d'exister via des projets de même type que Linux. Si Linux est plutôt sur le segment (mais pas exclusivement) des postes de travail, les dérivées de BSD se positionnent plutôt dans le domaine des serveurs avec une fiabilité importante. FreeBSD, OpenBSD, NetBSD sont les 3 distributions qui tiennent une plus grande part de marché. Des versions commerciales dérivées existent aussi : Apple propose sur ses ordinateurs un système commercial dérivé de UNIX BSD : Mac OS X.

8.1.4 Caractéristiques

Contrairement à Windows, UNIX est naturellement un SE serveur dès ses versions initiales. Il possède depuis de nombreuses années un accès réseau natif basé sur TCP/IP, une gestion des utilisateurs cohérente, des mécanismes de partage de ressources fiables.

Il a servi de base sous une version propriétaire à des serveurs de type MainFrame constructeur (exemples : AIX d’IBM, HPUX, Solaris). Il reste une référence dans ce domaine.Il est très répandu sous une version libre pour de plus petits serveurs et même sur de plus grosses machines depuis quelques années. Linux représente plus de 25% de part de marché (part évaluée avec, bien entendu, les versions payantes). Pour mémoire Windows Server est autour de 50%, mais tout cela en valeur. Il est plus difficile d'avoir une estimation en nombre sur des distributions libres !

8.2 Structure du système d'exploitation UNIX

8.2.1 Structure du système de fichiers UNIX

Sa structure logique est basée sur plusieurs partitions d'un disque. Il comprend au minimum 2 partitions :une partition principale montée sur le répertoire racine (/)contenant tous le système de fichiers.Une partition de swap (mémoire virtuelle) : non directement accessible par l’utilisateur

116

La taille de la partition de mémoire virtuelle doit être au minimum supérieure à la taille de la mémoire physique (deux fois est plus confortable).Couramment il y a plusieurs partitions supplémentaires, ce qui permet d'isoler les données utilisateurs du système, ce qui est souhaitable lors d'une ré-installation du système. Ces partitions apparaissent toutes dans l'arborescence complète. Elles sont montées sur le système de fichiers / à des points de montage définis, par exemple :– Les répertoires utilisateurs sont montés sous /home– les fichiers du SE et des applications sous /usr – Les fichiers variables du système d'exploitation sous /var …

Le choix de ce découpage se fait au moment de l'installation, il peut être modifié à la demande en faisant des montages différents mais au prix d'un gaspillage de ressources, ce qui n'est pas souhaitable.L'arborescence complète comprend à partir de / : répertoire racine/home : répertoires utilisateurs

/usr : fichiers permettant l’exécution du SE et de certaines applications/var : fichiers de tailles variables/tmp : fichiers temporaires/etc : fichiers de configuration/export : fichiers exportés pour les serveurs/dev : fichiers de périphériques, utilitaires/bin : lien sur /usr/bin

Il y a ensuite des découpages de 2ème niveau. Pour le répertoire /usr on trouve :/usr/bin : commandes basiques/usr/etc : commandes de maintenances/usr/lib : librairies et diverses fonctions/usr/local : logiciels installés en local/usr/share : logiciels indépendants de la machine cible/usr/kvm : logiciels dépendants de la machine cibleet bien d’autres suivant les SE

Concernant le répertoire utilisateur /home, on retrouve tous les répertoires utilisateur en 2ème niveau :Exemples : /home/jacquet ; /home/aubert... quoi qu'il en soit ce choix n'est qu'une convention la position des répertoires utilisateur est totalement configurable.

Il faut bien prévoir une place suffisante en cas de partition, car la modification de taille d'une partition n'est pas disponible sur toutes les implémentations et n'est pas compatible d'un système à un autre. Un taux de remplissage maximum de 80% est à prévoir.

8.2.2 Contrôle du fonctionnement du SE et des applications.

Sous UNIX, beaucoup de commandes de configuration sont en fait des scripts. Ces commande sont donc modifiables et peuvent différer suivant les distributions, c'est même une des principales différences apparentes au moment du fonctionnement entre les distributions.Les fichiers de configuration sous UNIX sont donc des fichiers texte éditables associés aux applications. Leur syntaxe est précise et des fois complexe, voire pointilleuse. Il y a de nombreux fichiers de configuration, souvent plusieurs par application.

117

Hormis le chargement initial du noyau, tout le démarrage du système est aussi basé sur des fichiers script de démarrage, de fait toutes les procédures de démarrage sont paramétrables.Du fait de la modification de fichiers de script pour la configuration, il est souhaitable pour bien maîtriser les changements de ne les effectuer que d'une seule manière et manuellement. La mise en œuvre de modification via l'interface graphique, si elle peut se comprendre pour un système de type poste de travail n'est pas à envisager pour un serveur, car les modifications par des menus ne peuvent être maîtrisées par l'administrateur. C'est l'une des différences principales entre la gestion d'un système Windows Server et celui d'UNIX. Pour l'un la facilité, pour l'autre la maîtrise...à chacun de choisir.

8.3 Compte d'utilisateurs.

8.3.1 Utilisateurs et groupes

PrincipeIl y a 2 catégories d’utilisateurs :– des utilisateurs locaux de la machine– des utilisateurs « réseaux » (par un service spécifique : NIS ou autre)

En local, il y a de nombreux utilisateurs et groupes prédéfinis :– root (c’est l’administrateur)– guest (invité) : souvent sans droit et mot de passe– groupe et utilisateurs nobody (créé pour des raisons de sécurité)– A cela s'ajoute des utilisateurs et des groupes spécifiques pour les applications, qui ont le même

usage que nobody, ils permettent de faire fonctionner certaines applications sans avoir les droits de root (ftp, gdm, bind …)

Fichier de gestion des comptes utilisateursLes utilisateurs locaux sont stockés dans /etc/passwd.C'est un fichier texte avec les droits d'écriture pour root, et de lecture tout le monde.Une entrée du fichier se présente sous la forme :Username:Password:ID_User:ID_Group:Information:User_Directory:Shell

Chaque utilisateur est repéré par un ID uniqueChaque utilisateur appartient à un groupe au minimumUn répertoire est associé à l’utilisateur (on y va par la commande cd ~)On peut choisir l’interpréteur de commande utilisé par défaut (Shell), car UNIX propose plusieurs interpréteurs de commande (csh, Borne shell, ksh...).

Le mot de passe est crypté dans le fichier /etc/passwd. Mais le problème est que /etc/passwd est accessible en lecture, ce qui est nécessaire pour connaître les utilisateurs. La découverte du mot de passe est ainsi possible par cryptage et comparaison (force brute mais hors ligne donc indétectable). Cela est d'autant facilité que la fonction de cryptage est fournie par le Système d ’Exploitation.

Les implémentations plus récentes utilisent un fichier /etc/shadow qui ne contient que les mots de passe et qui donne une correspondance ligne à ligne avec le fichier /etc/passwd.

118

Chaque utilisateur a une entrée dans chaque fichier, mais le fichier /etc/shadow n'est lisible que par root.

Fichier de gestion des groupes d'utilisateursChaque utilisateur est membre d'un groupe au moins. L'intérêt étant de définir des droits d'accès commun pour un ensemble d'utilisateurs. Les informations sur les groupes sont stockées dans /etc/group sous le format suivant :

GroupName:Special_Field:ID_Group : Usernames of possible membersExemple d'entrée du fichier /etc/groupEtud : :21:betty,baba,noel,quentin,sandra

Chaque groupe a un ID unique. Un utilisateur peut être présent dans plusieurs groupes. Son groupe initial est celui défini dans /etc/passwd, mais il peut en changer et prendre un de ceux auxquels il est associé dans le fichier /etc/group par la commande newgrp.

Méthodes de gestion des utilisateurs et des groupes.

Même si le résultat final se trouve dans les 3 fichiers précédents, il existe différentes méthodes pour la gestion des utilisateurs et des groupes :– Edition des fichiers,– utilisation de commandes,– utilisation de scripts,– des applications avec l'interface graphique

L'édition manuelle des fichiers concernés, même si elle a été la méthode habituelle dans les premières versions est à proscrire car trop risquée et surtout difficilement compatible avec le fichier /etc/shadow.

En mode graphique le gestionnaire des utilisateurs permet cette gestion mais attention aux modifications automatiques des fichiers, il y a risque de perte des modifications antérieures, et souvent incompatibilité avec une autre méthode de modification.

La méthode conseillée est l'utilisation des différentes commandes :useradd : commande création d’utilisateursuserdel : commande suppression d'utilisateursgroupadd : commande création de groupesgroupdel : commande suppression de groupes

Il existe de nombreuses options permettant de configurer tous les paramètres. Lors de la création de plusieurs utilisateurs, il y a la possibilité de scripts spécifiques fait par l’administrateur à partir des commandes précédentes.

Les scripts adduser, deluser, addgroup, delgroup sont aussi une autre possibilité, mais ils sont spécifiques Linux et donc moins portables.

8.3.2 Profils

119

Fidèle à la philosophie UNIX, les profils utilisateurs sont des fichiers script au format texte. Ces fichiers sont stockés dans le répertoire utilisateur, il débute par un point (visible si seulement on utilise l'option a dans ls -la). Des fichiers de configuration sont nécessaires pour chaque shell et pour certaines applications.Exemple de fichiers définissant le profil :.Xdefaults, .bashrc, .kde, .kderc, .screenrc, .cshrc et une liste de fichiers dépendant des applications utilisées (gestionnaire de fenêtres utilisé...).

A la création on peut recopier un profil par défaut stocké dans /etc/skel (Linux debian). Ce qui permet d'avoir un profil utilisable dès la création.

Remarques : Fichiers script

Les scripts doivent avoir les droits d’exécution x, sinon il faut le lancer avec le shell. Par exemple un script cshell se lance par csh cmd si cmd est le nom du fichier script.

La variable d'environnement PATH contient le chemin de recherche des exécutables. Si le chemin « . » n’est pas présent, l’exécution dans le répertoire local ne se fait pas, il faut alors taper ./cmd.

Pour modifier la variable d'environnement PATH on utilise la commande set : set path= ....La modification des variables d'environnement est locale au processus (celui qui gère la console). Pour la rendre disponible depuis n'importe quelle fenêtre de commande : export path

8.3.3 NIS

a) Introduction

NIS (Network Information System) est un annuaire répliqué. NIS a été introduit par SUN en 1985 (Yellow Pages (yp) à l'origine). Ce n'est pas un standard de l'Internet mais il a été largement utilisé et le reste encore en environnement 100% UNIX.

L'objectif est de réduire le temps d'administration d'un parc de machines. NIS fournit des informations à l'ensemble des machines connectées, il est à comparer à un domaine Windows basé aussi sur un annuaire.L'usage minimum est de simplifier la gestion des comptes, des mots de passe. Il suffit de créer un nouvel utilisateur sur le serveur NIS pour que chaque machine client NIS ait accès aux informations de login de cet utilisateur et puisse se connecter sur les machines raccordées au domaine. Le fonctionnement est basé sur un échange physique via le réseau du contenu des tables. Par exemple, les informations des utilisateurs définis sur le serveur (dans le fichier /etc/passwd) vont être automatiquement recopiées sur chaque machine client NIS et venir compléter le fichier /etc/passwd local lors de l'exécution.

Les informations susceptibles d'être distribuées via NIS sont entre autre :– les noms de logins, mots de passe et répertoire d'ouverture de session (/etc/passwd)– les renseignements de groupes d'utilisateurs (/etc/groups)– les alias réseaux (/etc/hosts)– et en fait toutes informations contenus dans les fichiers de configuration d'UNIX ayant un intérêt

en réseau

120

NIS est une base de données distribuée qui permet le partage d'informations système. Son architecture est basée sur un découpage en domaines. Les clients sont rattachés à un domaine NIS via un ou plusieurs serveurs NIS.

Domaine NISUn domaine NIS est constitué : – d'un serveur NIS maître qui maintient les tables NIS (maps NIS : informations contenues dans la

base). NIS gère une base de données (format DBM) contenant les informations nécessaires (login, password…).

– En option : un ou plusieurs serveurs NIS esclaves qui permettent de décharger le serveur principal et procurent une meilleure résistance aux pannes et permet la maintenance en ligne. Le maître réplique ses informations vers les serveurs esclaves.

– Des clients NIS qui peuvent interroger les serveurs maîtres ou esclaves. Les clients NIS se connectent à la base de données pour récupérer les informations nécessaires (ypbind).

Il y a échange des données en clair.

Protocole NIS : NIS est basé sur des protocoles de couche haute : protocole de couches « session », et « présentation ».la couche session est réalisée avec les RPC (SUN-RPC) : Remote Procedure Call

Un démon est nécessaire au fonctionnement des RPC : rpc.portmap Le rôle de ce démon (daemon) est de scruter les ports logiques de la machine et rediriger les paquets TCP/IP vers les bons servicesc'est à dire des démons utilisés par les services de couche supérieure (NIS, NFS…).

Remarque : les serveurs standard basés sur les RPC sont lancés par inetd (démon généralement lancé via un script au démarrage), il faut veiller à ce que portmap soit lancé avant inetd.

Mise en œuvre : Il a 2 aspects à considérer :– Coté serveur : il faut définir un domaine NSI, construire les bases de données dbm (makedbm ou

make), puis lancer le démon ypserv (serveur NIS).– Coté client : au démarrage (avant authentification), il faut lancer la connexion sur le serveur NIS

(ypbind) du domaine. Dès que ybbind fonctionne, la machine devient un client NIS. Il y a récupération des bases de données et authentification.

Préalablement, il faut que les machines soient dans le même domaine (commande domainname ou nisdomainname). Ensuite, Il faut alors que le serveur réponde, sinon la machine cliente est en attente jusqu'à un timeout relativement long, puis login sur des utilisateurs locaux.

b) Configuration détaillée du serveur

1ère étape : Attribution d’un nom de domaineL'attribution d’un nom de domaine se fait par commande « nisdomainname » ou ypdomainnameCette étape doit se faire en premier car les tables seront stockées dans le répertoire :

/var/yp/« nom de domaine »

2ème étape : Construction des bases de données NIS locales

121

La création des bases de données NIS (ou maps NIS) revient à faire une traduction de fichiers locaux ayant vocation à être exportés vers des fichiers au format base de données de type dbm, fichier à fichier.Le choix des fichiers que l'on souhaite "publier" via NIS, se fait par modification d'un fichier de type Makefile. Il faut ajouter les entrées appropriées dans /var/yp/Makefile.La construction des tables NIS se fait par lancement de la commande make (ou makedbm) dans le répertoir /var/yp (il utilise alors le fichier Makefile précédent qui est dans le répertoire courant).Les bases sont construites sous /var/yp/nom_de_domain, on y retrouve chaque fichier traduit dans un format différent. Il est utile de bien vérifier que cette traduction a eu lieu en listant ce répertoire.

Concernant certains fichiers dont /etc/passwd et /etc/group, des contraintes sont définies dans le Makefile et qui vont permettre de n'exporter que certains utilisateurs. On définit un UID et un GID minimum pour que les entrées puissent être publiés (ce qui évite que les comptes systèmes dont root soient exportés).

3ème étape : Configuration du serveur NIS2 fichiers sont nécessaires à sa configuration :– /var/yp/securenets (adresse des domaines vers lesquels NIS est autorisé)– /etc/ypserv.conf (configuration de base du démon ypserv, liaison à un DNS)

4ème étape : Lancement du serveur NISEn premier lieu, assurez-vous que le portmapper tourne (rpcinfo -p), puis lancez le serveur par la commande : ypserv.On peut lancer le serveur nis pour un domaine différent de celui du serveur par la commande :

ypserv -d

La commande rpcinfo - u localhost ypserv devrait alors répondre :program 100004 version 2 ready and waiting

Vous pouvez aussi vérifier les potentiels messages d’erreur dans les fichiers log (/var/log/daemon.log ou /var/log/syslog).

c) Lancement de NIS au démarrage du serveur

Les bases étant construites, si l'on veut lancer le serveur NIS au démarrage, il est nécessaire de modifier les fichiers de démarrage pour cela. Sur un serveur Linux de type Debian, il faut créer ou modifier un lien dans le répertoire de démarrage du niveau concerné (par exemple : /etc/rc2.d pour un niveau 2), les liens commençant par Sxx (où xx est un nombre) font démarrer des services dans l'ordre des xx. Les liens débutant par Kxx arrêtent des services dans l'ordre inverse. Ces liens (symboliques) doivent pointer vers des fichiers script qui sont habituellement dans le répertoire « /etc/init.d ». On peut alors paramétrer le fichier concernant nis (/etc/init.d/nis) pour contrôler le démarrage du serveur.

d) Script d'initialisation lors d’un premier usage

Un utilitaire (script) nommé « ypinit » permet de s'affranchir des premières étapes. Et de simplifier la gestion des serveurs esclaves.Sur le serveur maître, lancer : /usr/lib/yp/ypinit -mLe script va demander des informations pour la configuration (serveur esclave…) puis construire les bases de données.

122

Sur un serveur esclave, lancer /usr/lib/yp/ypinit -s masterhost, il y a alors recopie automatique des bases exportées par le serveur maître sur le serveur esclave par ypxfr.

e) Configuration et lancement du client

Le lancement du client se fait par la commande /usr/sbin/ypbind qui va lancer le démon de même nom.Le fichier de configuration de ypbind se nomme yp.confDans ce fichier, on trouve le nom du serveur NIS :

ypserver monServeurNis ou ypserver 161.3.51.86

Il est impératif de tester manuellement le bon fonctionnement de ypbind avant de raccorder la machine au domaine au démarrage.On peut faire une vérification a posteriori du lancement via la commande ps -aux (liste des processus). On peut aussi vérifier que tout s'est bien passé, en scrutant les ports rpc mappés (via rpcinfo -p localhost), on trouve au minimum deux ports mappés pour ypbind :100007 2 tcp 705 ypbind100007 2 udp 708 ypbindSignification : numéro du programme, version, protocole, port

Des utilitaires vont permettre de teste le fonctionnement :– ypwhich : donne l’identification du serveur NIS– ypcat : affiche une table publiée du serveur– ypmatch : vérifie manuellement qu’une clef est conforme– yppasswd : modification d’une clef mot de passe sur le serveur à partir du client

Ces autres programmes (ypcat,ypwhich, ...) se trouvent dans /usr/bin.

Remarque : pour que ypbind fonctionne il faut que le répertoire /var/yp existe sur le client.

f) Configuration de l’authentification via NIS

Pour que l'authentification se fasse via les tables NIS il faut ajouter la ligne :+: : : : : : : au fichier /etc/passwd des machines clientes

Cela revient à ajouter temporairement le fichier exporté /etc/passwd à celui en local.

Cela peut se faire de manière plus précise, par exemple, utilisation des logins NIS pour jack, le groupe etud, pas de login autorisé pour l'utilisateur guest via NIS :+jack:::::::+@etud:::::::-guest

On peut vérifier le bon fonctionnement de l'authentification, en effet, dès que ybbind fonctionne, la machine est client NIS du domaine. Comme l'utilisateur est déjà logué, il faut utiliser un nouveua login par la commande « su » qui va mettre en place une vérification sur /etc/passwd local puis une vérification sur les maps publiées du serveur NIS du domaine.

123

g) Exécution du client au démarrage de la machine

De la même manière que le serveur, il faut lancer le programme ypbind (daemon) au démarrage de Linux. La méthode habituelle est la même que pour le serveur, il faut modifier le fichier de démarrage dans le répertoire adapté : /etc/init.d/nis et le positionner en client. Il faut faire attention à ce que tout fonctionne bien car lorsque NIS est démarré, le timeout à la connexion est très long si le serveur ne répond pas, d'où la quasi obligation d'avoir un serveur esclave.

h) Configuration de la résolution de nom via NIS

On peut utiliser les fichiers /etc/hosts du serveur pour la résolution de nom du client. Il faut ajouter nis dans la ligne host du fichier /etc/host.confExemple hosts : files nis dns

i) Défauts des NIS

Il n'y a pas d'authentification des clients NIS : il suffit de connaître le nom de domaine pour interroger le serveur et connaître le contenu de ses maps. On peut toutefois contrôler un peu la sécurité par les fichiers de configuration du serveur. La sécurité minimum implique de ne pas publier /etc/shadow car il y a transmission du fichier. Il ne faut mettre dans /etc/shadow que les utilisateurs locaux.Les maps sont transmises en totalité même en cas de faible modification de leurs contenus, ce fonctionnement n'est pas adapté aux WAN car le trafic pourrait être important.NIS est petit à petit remplacé par LDAP, cependant, les NIS sont encore largement utilisés dans les domaines anciennement installés.

8.4 Ressources.

8.4.1 . Principes généraux.

a) Système de fichiers

Sous UNIX, la description des ressources se fait suivant une approche unifiée : toutes les ressources sont vues extérieurement comme des fichiers.

Elles sont rassemblées dans un système de fichiers global de type arborescent. Il existe 4 types d’objets dans l’arborescence du système de fichiers UNIX :Les fichiers ordinairesLes répertoiresLes liensLes fichiers spéciaux ou fichiers de périphériques

Du fait de cette approche unifiée, un certain nombre de commandes permettent de gérer ces objets de manière unique : ls (« listage »), rm (destruction), cp (copie), … Mais il faut faire attention à l’usage de ces commandes et à leur résultat (effacer un périphérique de type disque peut avoir certaines conséquences...).

124

Les 2 premiers types sont courants, il est toutefois nécessaire de rentrer un peu plus dans le détail des 2 derniers.

b) Les liens

Ce sont des pointeurs vers d'autres fichiers (un peu comme les raccourcis Windows). Toutefois il existe, sous UNIX, 2 types de liens :Lien physique : fichier est effectivement effacé lorsque tous ses liens sont effacés. Tous les liens ont mêmes propriétés que le fichier initialLien symbolique (c'est plutôt ceux-ci qui sont équivalents à un raccourci Windows). Dans ce cas, le lien peut subsister même si le fichier est effacé. Ils sont très utilisés pour les scripts de démarrage et pour les bibliothèques, car ils permettent de gérer des versions différentes sans changement des scripts (par exemple gcc -compilateur C/C++- est un lien vers gcc-4.23 une version de ce compilateur)

Création d'un lien

Lien physique : ln mainfile.txt tempfile.txtLien symbolique : ln -s monfichier monlien

c) Les fichiers de périphériques

Ce sont des fichiers spéciaux de 2 types :type b : pour périphériques en mode « bloc » Exemples : disques, cdrom...Type c : pour périphérique en mode « character » clavier, liaisons série...

En général ils sont contenus dans le répertoire /dev (devices). Ces fichiers permettent d'accéder directement aux périphériques, dans ce cas l'usage en est délicat. En fait, ils sont plutôt destinés à être montés sur un point du système de fichier, ce qui en est l'usage normal.

La commande mount permet de réaliser ce montage.mount -t ext2 /dev/hda3 /mnt

Répertoire /dev/dev/console : écran/dev/fd : lecteurs de disquettes (/dev/fd0 pour a:)?/dev/hd : disques dur IDE /dev/hda1 : 1ère partition sur le premier disque maître/dev/sd : disque dur SCSI/dev/cdrom : cdrom !/dev/tty : terminaux/dev/ttyS : ports série (/dev/ttyS0 : COM1)?

Ils peuvent correspondre à des périphériques physiques ou logiquesPar exemple les partitions logiques du disque physique sd0 vont être : sd0a ; sd0b ; sd0c ;

On peut utiliser directement (mais avec beaucoup de précaution) ces périphériques. L'usage habituel est de les monter à un nœud du système de fichiers.

125

d) Commande ls

La visualisation du contenu du système de fichiers se fait avec la commande ls :en général avec des options : ls -laChaque entrée est affichée avec une présentation uniforme que ce soit un fichier, un répertoire ou un lien :-rw-r--r-- 1 jacquet prof 1283 feb 31 25:63 chap6.txt

1ère lettre : d (directory), l (link), - fichier, b/c (fichier spéciaux)9 lettres suivantes : permissions rwx (lecture, écriture, exécution) pour user,group,all othersle nombre de liens physiques existantsle nom du propriétaire ; le groupe ; la taille ; la date ; le nom de l'élément

D'autres attributs peuvent se rajouter : bits SetGID/SetUID, sticky bit (dont nous verrons le sens plus tard) ils sont visualisés à la place du bit d'exécution (s = s+x ; S = s mais pas x).

8.4.2 Autorisations.

a) Les autorisations de base

Les droits ou autorisations sur un objet Linux sont assez simples. Il y a 3 niveaux d'autorisations avec 3 possibilités.Les trois niveaux d'autorisation sont :– propriétaire (o) pour owner– groupe (g)– tous les autres (a) all others (attention c'est bien tous les autres, ces permissions ne s'appliquent

donc pas aux deux précédents.

Pour chaque niveau, il y a trois spécifications : r (read), w (write), x(execute)

Ces spécifications ont un sens seulement pour les fichiers. Pour les répertoires, les permissions deviennent :– r : autorisation de listing du répertoire (commande ls)– w : autorisation de créer un fichier dans le répertoire, de l'effacer ou d'en modifier son nom : en

fait tous ce qui modifie l'aspect du répertoire lors d'un ls.– x : autorisation d'ouvrir ce répertoire (commande cd).

Si l'utilisateur a un droit w sur un fichier, il peut le modifier mais pour l'effacer il faut qu'il ait les droits w sur le répertoire.

Exemple : (obtenu par la commande ls) drwx rwx rwx name1

-rwx --- --- name2

name1 : répertoire accessible en listing/modification/ouverture à tout le monde (owner+group+all others)name2 : fichier accessible en lecture/écriture/exécution à son seul propriétaire

b) Les attributs supplémentaires

Des attributs supplémentaires existent :

126

Les bits SetGID/SetUID : (lettre s ou S)Ces attributs s'appliquent aux programmes exécutables (binaires, a priori pas aux scripts). Quand il est positionné, il permet l'exécution du programme avec un niveau de droit de l'ID user (SetUID) ou group (SetGID). En effet, il est parfois nécessaire de donner des droits temporaires plus élevés à un utilisateur pour réaliser une opération particulière (un exemple courant est le programme de montage /bin/mount : chaque utilisateur peut monter ses propres systèmes de fichiers mais l'opération de montage intervient directement au niveau du système d'exploitation).Ces bits sont positionnés en interne dans le champ des permissions d'un élément (9 bits sont utilisés pour les autorisations), 3 autres vont être utilisés par ces nouveaux attributs.

Sur un répertoire le bit SetGID indique que les fichiers (ou répertoires) créés auront une appartenance au groupe du répertoire et non au créateur.

Enfin un dernier attribut existe : le sticky bit ou bit collant (lettre T ou t) qui vient remplacer les droits d'exécution des autres utilisateurs avec la même règle. Il va servir à contrôler l'effacement des fichiers dans un répertoire. Si le répertoire possède cet attribut, les fichiers contenus à l'intérieur ne peuvent être effacés (sauf par le propriétaire), mais ils peuvent être modifiés suivant les droits donnés par les spécifications w. Il permet de gérer l'effacement ou la modification d'un fichier de manière différente. Lorsque ce bit s'applique à un fichier, il permet dans les anciennes versions de laisser ce programme résidant en mémoire (les méthodes de gestion de la mémoire actuelles ne le nécessitent plus).

c) La modification des droits d’accès

Elle est réalisable par le propriétaire (ou par root) via la commande chmod :Exemple :chmod a+x fichier (exécution pour tout le monde)syntaxe : chmod ([a] [g] [u] ) ([+] [-]) ([r][w][x]) filename

Usuellement, on utilise aussi une notation octale (pour faire plus pro !)

On traduit les droits d'accès en octal en considérant : r=4, w=2, x=1Exemples : -rwxrwxrw- : 0776 ; -rwx --- --- : 0700

Utilisation : chmod 777 fichier (changement des droits d'accès pour tous)

d) La modification du propriétaire ou du groupe

Elle s'exécute par la commande chown et seulement pour root (a priori l'utilisateur n'a plus le droit de le faire pour ses fichiers (ce qui lui permettait de s'affranchir des quotas!) :Exemple :chown nouveau_propriétaire fichier : chown jacquet file.txt

De même pour la modification du groupe et la commande chgrp, celle-ci pouvant se faire aussi par le propriétaire (s’il appartient au nouveau groupe) ou root.chgrp new_group fichier : chgrp group1 file.txt

Le propriétaire n’est pas forcément membre initial du groupe du fichier.

127

8.4.3 Construction du système de fichiers.

Le système de fichiers d'un serveur sous UNIX est en général constitué de plusieurs partitions, ou de plusieurs disques, voire réparti sur plusieurs machines. Afin de constituer l'entité unique qui est le système de fichiers on va réalise une opération commune sous UNIX : le montage des ressources.

En fait, pour pouvoir être utilisée sous UNIX, une ressource, telle que une partition de disque, un CDRom, une disquette, doit être raccordée sur la structure unique du système de fichiers. Cette opération s'appelle un montage. C'est une de différence avec le fonctionnement de Windows où toute nouvelle ressource sera associée à un nouveau lecteur (lettre avec:).

Une fois montée, la ressource ne se distingue pas du reste du système de fichiers, ce qui permet d'avoir une gestion plus uniforme des ressources.

La commande pour réaliser ce montage est :mount options périphérique « point de montage »

Options :-t : type de montage (ext2, msdos, vfat, iso9660…)?-w : monte la ressource avec autorisation rw-r : monte la ressource avec autorisation lecture seule

Les fichiers déjà existants sous le point de montage seront masqués.

Exemple :mount -t ext3 /dev/sd0b /mnt/test

Montage d'une partition /dev/sd0b au format ext3 au point de montage /mnt/test.De nombreuses options existent, il faut regarder l'aide (commande man mount) pour connaître celles utilisées sur le système concerné.

De la même manière que le montage, il faut libérer les ressources (les démonter) lorsque l'on ne les utilise plus. Cela permet entre autre de fermer correctement tous les fichiers ouverts et de terminer les transactions si il y en a en cours. Par exemple, on ne peut extraire (proprement) un CDROM ou une disquette que si elle est démontée (cela est équivalent à retirer le périphérique de Windows pour une clef USB). Il arrive même que des fois sur certaines stations de travail, il n’y ait pas de boutons mécaniques d’extraction, seul le démontage éjecte le périphérique.

Usage :umount unité | pointMontage

umount -a : démonte tous les systèmes de fichiersumount -f fstype : démonte tous les systèmes du type spécifié (msdos, ntfs,hpfs, nfs, ....)

umount /dev/sd0b ou umount /mnt/test a le même effet pour l'exemple précédent.

Pour faciliter les montages courants, on les regroupe dans un fichier : le fichier fstab.

128

fstab contient les montages prédéfinis avant le démarrage, il peut être utilisé directement au démarrage avec un mount -a qui exécute tous les montages spécifiés dans /etc/fstab. Cela est fait en général au démarrage via un script.

Ce fichier peut être aussi utilisé pour ne pas avoir à taper toutes les options : si l'entrée sd0b reliée à /mnt/test est dans ce fichier avec les bonnes options, il suffit de taper mount /mnt/test pour que le reste soit fait automatiquement.

Le fichier mtab contient les montages actuellement réalisés. A chaque opération manuelle mount/umount modifie le fichier mtab. Ceci permet d'avoir une vue instantanée des ressources associées. Entre autre, avant l’arrêt d'une machine un script démonte tous les montages présents dans mtab, d'où l'obligation d'arrêter une machine sous UNIX de manière correcte (commande shutdown -h now par exemple).

8.4.4 NFS

a) Principe

Si l'on veut utiliser des ressources reliées par réseau, il faut utiliser un service spécifique : NFS (Network File System).Son objectif est de monter un système de fichiers à distance sur un réseau TCP/IP. L'intérêt étant de bénéficier de disques durs d'autres machines comme si ils étaient locaux. D'un point de vue de l'utilisateur, l'accès à une ressource distante est transparent. Le mécanisme de montage se fait de la même manière que pour une ressource locale. Quoi qu'il en soit il faut qu'un service soit présent sur le serveur pour mettre en place cette relation clients/serveur.

L'usage de NFS va nécessiter d'intervenir au niveau du serveur et du client. Sur le serveur, il faut que le serveur possédant la ressource l'autorise à être monté par un système distant (cela s'appelle exportation). Il faut aussi que le service NFS server soit activé. Au niveau du client, il faut que le service NFS client soit activé et que celui-ci monte la ressource.

b) Opérations sur le serveur NFS

Etape 1 : autorisations d'exportationLes autorisations d'exportation se font sur le serveur via le fichier /etc/exports. Il contient des lignes qui vont définir les portions de son système de fichiers qui peuvent être exportées. Par exemple la ligne :

/home istapc85.univ-st-etienne.fr (rw) va permettre l'exportation en lecture écriture de /home au bénéfice de la machine istapc85

D'autres options sont possibles : ro (read only), de la même manière que pour la commande mount, il faut taper l'aide (man exports) pour connaître toutes ces options.

Etape 2 : lancement du service

Il faut que plusieurs démons soient lancés (portmap et en général nfsd)

129

Pour être sur du bon lancement, on utilise un fichier script (exemple /etc/init.d/nfs-kernel-server sous Linux) en fait un certain nombre de services sont lancés et on peut retrouver sur certains systèmes tout un ensemble de démons :rpc.statd : surveillance du trafic et gestion des erreurs NFSrquotad : gestion des quotas utilisateursmountd : gestion du montagenfs : interface utilisateurnlockmgr : gestion des verrous NFS (lockd) qui empêche l’ouverture simultanée en écriture

Ces démons sont visibles par la commande ps aux.

Le démon NFS est contrôlé par plusieurs fichiers de configuration dont :/etc/hosts.allow : machines autorisées à se connecter via nfs/etc/hosts.deny : machines interdites de connexionLe défaut est l'autorisation, c'est pour cela qu'une sécurité minimum consiste à remplir ces fichiers.

c) Opération sur le client

Etape 1 : lancement du serviceCertains démons doivent aussi fonctionner sur le client (le portmapper et nfsd aussi). Le lancement se fait aussi par un script (/etc/init.d/nfs-common). On peut visualiser les démons lancés avec la commande ps aux.

Etape 2 : montage de la ressource

On peut utiliser un montage manuel avec l'option -t : mount -t nfs istapc86:/home /mnt

Ou aussi mettre une entrée dans le fichier /etc/fstab pour un montage automatique :istapc86:/home /home nfs timeo=20

syntaxe : nomHote:/fichier/système/cheminLa valeur timeo=n spécifie un timeout (ms) pour l'accès aux fichiers distants, elle est fondamentale pour ne pas bloquer trop longtemps le client si le serveur ne répond pas.

d) Gestion des droits d’accès aux ressources partagées (exportées) :

La gestion des droits d'accès aux éléments contenus dans la ressource peut être assez complexe, c'est pour cela qu'il est bon de préciser ce point là. Il y a trois niveaux de contrôle : au niveau de NFS, au niveau du partage et au niveau des droits individuels sur l'élément. La complexité vient de l'interaction entre ces 3 aspects lorsqu'ils sont tous utilisés.

1er niveau : les fichiers /etc/hosts.allow et hosts.deny vont permettre un contrôle global sur les postes ayant droit.

2ème niveau : comme nous l'avons vu précédemment le contrôle de l'exportation se fait via le fichier /etc/exports. Beaucoup d'éléments peuvent être contrôlés. En particulier, les machines ayant une autorisation pour un partage donné, mais aussi les utilisateurs. Par exemple :Pour les sous-réseaux (n° IP ou nom DNS)/var/mail 192.168.3.0/24(ro)Pour les groupes de postes@group1 : défini dans /etc/netgroup

130

Pour les postes :/tmp istapc32(rw)Il existe des options permettant de limiter à certains utilisateurs pour un poste (avec le UID et le GID)

3ème niveau : il concerne la gestion des droits d’accès aux éléments dans la ressources partagées :En particulier chaque fichier ou répertoire a des autorisations. Elles sont données principalement pour le propriétaire et le groupe. Il faut donc déterminer un UID et un GID lors d'un échange NFS. Cela ne pose pas de problème de réalisation car NFS transmet l'UID et le GID du demandeur, mais ceux-ci sont comparés avec l'UID et le GID de l'élément qui ne proviennent pas de la même machine. Pour une gestion stricte, il faudrait qu’il y ait correspondance des UID et des GID entre les machines (ce qui est le cas en fonctionnement NIS), quoi qu'il en soit la sécurité est limité à la connaissance de ces 2 identifiants. En lecture, le problème n'est pas crucial, mais lors d'une écriture, le fichier va appartenir à un utilisateur local du serveur qui lui doit correspondre à celui distant. Quelquefois l'UID nobody est utilisé si il n'y a pas correspondance. De même, il y a un problème si l'utilisateur distant est root, car il est forcément différent de celui du serveur pour des raisons de sécurité. Un paramètre (root-squash) permet de contrôler les accès par un utilisateur root distant.

e) Cohabitation avec le DNS

Dans la version 4 de NFS, si le client DNS est activé, il y a une requête PTR pour trouver le domaine du client. S'il n'existe pas de serveur DNS, NFS bloque pendant un temps supérieur au timeout, un message d'erreur est alors généré (la demande ne peut être acceptée).

8.5 Administration

Plusieurs éléments de gestion sont spécifiques à un serveur.

8.5.1 Sauvegarde des données

Il existe un utilitaire (tar : tape archiver) simple, fiable, disponible sur tous les systèmes Unix. Il permet de créer un fichier archive (équivalent d'un zip mais sans compression) contenant une partie de l'arborescence. Il était adapté à la sauvegarde sur bandes, mais il est parfaitement utilisable autrement.

tar option destination sourceOptions principales de tar :c : crée une archivex : extrait une archivef fichier : crée ou lit une archive de nom fichierZ : compacte ou décompacte l'archivet : crée un index des fichiers de l'archive et l'affiche sur stdout

Exemple :tar cvf /dev/fd0 /home : sauvegarde de home sur une disquette

131

8.5.2 Réseau.

La configuration réseau du réseau est un élément essentiel du bon fonctionnement d'un serveur sous UNIX.Le fonctionnement de TCP/IP est commandé par un ensemble de fichiers de configurations situé dans /etc/etc/hosts : associe nomMachines et adressesIP/etc/networks : associe les noms de domaines à des classes d'adresse IP/etc/network/interfaces : configure et active les interfaces EthernetUn daemon démarre ensuite les services réseaux bas niveau : /etc/inetd ou équivalent

a) Commande ifconfig

La commande ifconfig va permettre de configurer une interface individuelle. Le premier usage est l'attribution d'une adresse IP à une interface.ifconfig interface adresse_IP netmask masque Exemple :ifconfig eth0 161.3.51.81 netmask 255.255.255.0

On peut aussi afficher l'état de l'interface (Nb de packets émis, reçus, adresses...) en tapant :ifcongih interface (ifconfig eth0 ou ifconfig -a pour toutes les interfaces)

En général, si il y a plusieurs cartes réseau sur un serveur, la 1ère carte réseau porte le nom eth0 (sous Debian), mais ce n'est pas toujours la même suivant la configuration (IRQ…) et les caractéristiques. Le choix est fait à l'installation.

On peut activer ou désactiver une interface par la commande ifconfig interface up/down.

b) Fichier /etc/network/interfaces

Ce fichier contient les informations nécessaires pour la configuration du réseau lors du démarrage du PCIl contient pour chaque interface utilisée :– Son adresse IP (ou la configuration auto en DHCP)– Le masque– L'adresse IP de la passerelle– D'autres informations sur le fonctionnement du réseau

Des fichiers scripts sont aussi présents dans le même répertoire pour gérer les cartes réseaux

Attention, il y a risque d'interférence entre les configurations lorsque la configuration par menu graphique du réseau est utilisée en alternance avec les commandes en ligne.

c) Fichier /etc/hosts

Correspondance entre nom de machines et adresses IPExemple127.0.0.1 localhost

132

161.3.51.81 istapc81.univ-st-etienne.frEn complément du DNS (ou NIS…) si le service est lancé

Fichier /etc/networksCorrespondance entre nom de domaines et adresses IPExemplelocalnet 127.0.0.0univ-st-etienne.fr -c1 161.3.51 (-c1 : identifie le 1er sous réseau de classe C

d) Programme route

Il permet de définir les routes pour parvenir à certains réseaux. Pour une machine avec une carte réseau unique, il n'y a à définir qu'une passerelle par défaut :

route add default gw adresseIP_passerelle

Sinon cette commande peut-être utilisée d'une manière générale :– Suppression d'une route : route del– Ajout d'une route : route add– Affichage des routes : route

Exemple :Table de routage IP (vue en telnet sur un poste windows !)

e) Programme netstat

Sans argument : affichage des connexions réseau actives-i : affiche les statistiques pour toutes les interfaces du réseau-c : affiche l'état du réseau mis à jour toutes les secondesExemple de résultat de netstat -i

8.5.3 Surveillance

133

La surveillance du bon fonctionnement du serveur se fait via un ensemble de fichiers au format texte qui sont situés dans le répertoire /var/log.Les plus intéressants sont syslog, kern.log pour les processus généraux du système. Mais en fait se rajoute à tous cela les fichiers spécifiques à chaque serveur d'application dans des fichiers à part ou même des sous-répertoires supplémentaires style samba ou apache.

134

TP OptionRX1

N°04 : Configuration d’un Serveur de fichiers UNIX

Objectifs du TP:Installation et paramétrage d’un serveur de comptes et de fichiers sous Linux Debian.

Ressources nécessaires au TP

- Durant le TP, vous allez utiliser un PC client Linux et un PC serveur Debian Linux à configurer avec l’adresse IP 10.20.N°poste.N°PC. Ils seront reliés par un switch. Le 3ème PC pourra servir pour l’analyse de trames ou comme 2ème client.

Phase 1 : Configuration réseau des PC client et serveur sous UNIX1. Configurer les adresses IP sur les 3 PC, mettre en œuvre la liaison physique entre ces PC.2. Vérifier le bon fonctionnement par un ping.

Phase 2 : Configuration du PC serveur sous Linux Debian1. Visualiser les fichiers /etc/group et /etc/passwd pour vérifier leur état initial (Aucun ID

supérieur ou égal à 200).2. Créer un groupe de nom tpuser avec un GID = 2000 (commande groupadd). Vérifier la

bonne réalisation de cette commande.3. Créer un répertoire utilisateur (tpuser1) sous le répertoire /home/tpreseau qui doit être

initialement vide (commande mkdir).4. Créer un compte utilisateur (ID tpuser1 = 2001) : utiliser la commande useradd, positionner

cet utilisateur dans le groupe tpuser. (Attention le script adduser fait le même genre d’opérations mais n’est pas présent sur tous les UNIX). Visualiser le fichier /etc/passwd pour en voir l’évolution. Le répertoire de démarrage doit correspondre à celui créé.

5. Copier les fichiers stockés (profils) dans /etc/skel dans le répertoire utilisateur.6. Ajouter un mot de passe (tpuser1) au compte tpuser1 par la commande « passwd tpuser1 »

(attention ne pas changer le mot de passe de l’utilisateur root). Où ce mot de passe est-il stocké ? Voir le fichier /etc/shadow.

7. Connecter-vous en tant qu’utilisateur tpuser1 (su tpuser1). Visualiser les fichiers présents sur votre répertoire personnel (more …). Editer ces fichiers, que se passe-t-il ? Pourquoi ?

8. Essayer d’autoriser l’accès à l’un d’eux en changeant le propriétaire et le groupe (commandes chown, chgrp). Que se passe-t-il ?

9. Reconnecter vous sur le terminal en root (su root), faire les modifications précédentes.10. Modifier les droits d’écriture (en les donnant à tous le monde) sur un autre fichier

appartenant à Root par la commande chmod. Vérifier en vous reconnectant en tpuser1.11. Combien de shell avez-vous lancé, déconnectez-vous de ces scripts par la commande exit.12. Réaliser un fichier script (fichier texte), reprenant toutes les commandes afin de faire les

mêmes opérations sur les deux autres utilisateurs (tpuser2, tpuser3). Vérifier le bon fonctionnement du script en l’exécutant. Mettre le script sous /home/tpreseau.

13. Reconnecter vous en tpuser1 par l’interface graphique.

Phase 3 : Configuration du PC client sous Linux 1. Créer les mêmes répertoires et comptes que sur le serveur (utiliser un fichier script).

Phase 4 : Mettre en œuvre l’accès au fichier par partage

1. Vérifier par la commande rpcinfo – p, les services rpc disponibles sur la machine serveur et client.

135

2. Lancer les services nfs et portmap sur les machines s’ils ne le sont pas (/etc/init.d/nfs-kernel-server). Avant cela créer un fichier /etc/exports contenant une ligne de commentaires (début par #).

3. Refaire la commande rpcinfo. Visualiser aussi les ressources exportées par le serveur showmount –e Ipserveur. Y en a-t-il ?

4. Autoriser l’exportation du système de fichier /home/tpuser1 (modification du fichier /etc/exports). Redémarrer les services nfs pour prendre en compte la modification du fichier. Vérifier la bonne exécution avec la commande showmount à partir du client.

5. Monter cette arborescence sur le client au point de montage /mnt/remote : commande (mount –t nfs répertoire_distant répertoire_local) Pour le répertoire distant il faut préciser la machine : 192.168.1.34:/home….

6. Essayer de modifier les fichiers du serveur à partir du client, vérifier les évolutions de part et d’autre en créant de nouveaux sous-répertoires. Supprimer ce montage.

7. Pour mettre en place un vrai service de compte partagé pour un utilisateur, réaliser le montage de /home/tpuser1 sur le même répertoire client. Comment cela est-il vu du côté utilisateur. Faire la même chose pour les autres comptes. Quelle stratégie aurait été plus simple à mettre en œuvre ?

8. Pour rendre permanent ce montage sur le client, modifier le fichier fstab en conséquence. Démonter les montages actuels puis faire mount all (pour simuler un redémarrage de la machine client).

9. En modifiant les paramètres de montage dans le fichier /etc/exports déterminer comment est gérée l’authentification.

10. A l’aide de Wireshark, regarder les protocoles mis en oeuvre lors des échanges.

Phase 5 : Création de répertoires supplémentaires

1. Créer un répertoire accessible à tous les utilisateurs sous /home/tpreseau/partage2. Créer un répertoire accessible au groupe tpuser uniquement sous /home/tpreseau/tpuser.

Phase 6 : Gestion centralisée des comptes

Afin de non seulement partager les ressources disques mais aussi de gérer de manière centralisée les utilisateurs, nous allons utiliser un service rpc appelé NIS (ou yp yellow page)

1. Définir un nom de domaine pour le serveur (domainname istase.net) (fichier /etc/defaultdomain).

2. Construire les tables nis via un make dans le répertoire /val/yp.3. Visualiser le contenu du fichier Makefile, quelles tables ont été construites ?.4. Paramétrer les différents fichiers pour le serveur (définir les caractéristiques du serveur via

les fichiers /etc/ypserv.conf et ypserv.securenets). Il y a peu de modifications.5. Lancer manuellement le démon nis par la commande ypserv.6. Vérifier que le service nis est lancé par la présence des démons nécessaires.7. Lancer le client après l'avoir configuré. Vérifier le lancement.8. Tester le service nis, le serveur doit bien répondre et les tables peuvent être lues, en utilisant

les utilitaires ypwhich, ypcat, ypmatch.9. Supprimer les utilisateurs sur la machine client. Editer les fichiers :

/etc/passwd : ajouter la ligne suivante à la fin : + : : : : : :/etc/group : ajouter la ligne suivante à la fin + : : :/etc/shadow (si utilisé) : ajouter la ligne + : : : : : : : :

(Attention ne jamais supprimer la ligne de l’utilisateur root ni les lignes des utilisateurs

prédéfinis)10. Tester une connexion sur le client via un su user, user étant un utilisateur nis défini sur le

serveur.

136

11. Comment faut-il faire pour que l'authentification nis se fasse au démarrage ? Connectez-vous sur le PC client avec un compte défini sur le serveur.

12. Reconstruire les tables par la commande /usr/lib/yp/ypinit –m. Vérifier préalablement la présence d’un fichier /etc/network.

13. Lancer le serveur par le script global (/etc/init.d/nis). Que se passe-t-il ?14. Vérifier que le service nis répond bien et que les tables peuvent être lues.

Phase 7 : Désinstallation (Phase obligatoire)

1. Sauvegarder les configurations que vous avez modifiées. Vous devez être capable à la fin du TP de reconstruire toutes les configurations très rapidement. Pour cela vous devez sauvegarder les fichiers de configurations modifiés ainsi que créer les scripts nécessaires pour reconstruire les modifications que vous avez effectuées.

Les configurations initiales des machines sont reconstruites au redémarrage pour ne pas

perturber les autres groupes vous devez : Arrêter les 3 PC et éteindre les écrans .

137 138

Chapitre 9 : Protocoles couches

intermédiaires

9.1 Introduction.

9.1.1 Principe

a) modèle en couche

Le modèle en couche permet une approche simplificatrice du fonctionnement d'un réseau, quoi qu'il en soit, rares sont les implémentations pratiques qui respectent vraiment le modèle ISO avec ses 7 couches.

Les couches basses (Couche physique->couche transport) respectent en général beaucoup mieux ce modèle, car elles sont liées directement à la transmission des données et doivent donc avoir une interopérabilité sans faille pour pouvoir rassembler des réseaux différents.

Les couches intermédiaires et hautes (Couches Session/Présentation/Application), liées aux applications, ont beaucoup plus de latitudes. Suivant les cas, elles peuvent ne permettre que de faire communiquer ensemble des machines parfaitement compatibles ou assurer une interopérabilité complète mais pour des applications simplifiées.

On trouve 2 catégories d'implémentations :

Les premières sont liées à des protocoles simples style ftp ou telnet, où les couches intermédiaires n'ont pas d'utilité. La totalité des fonctions du protocole se retrouve dans la couche application qui est dans un format ASCII.

Du coup ces protocoles simples ont une interopérabilité quasi totale quels que soient la machine et son système d'exploitation à

139

Couche Application

Couche Présentation

Couche Session

Couche Transport

Couche Réseau

Couche Liaison

Couche Physique

Application

FTPCouche Application...

TCP

IP

Ethernet

Ethernet

Application

Couche Transport

condition qu'ils soient basées sur TCP/IP, ce qui est le cas pour tous les échanges réseaux locaux actuellement.

La deuxième catégories d'implémentations concerne des protocoles complexes où le modèle possède beaucoup plus de couches, il se rapproche du modèle complet de l'OSI même si les fonctions de chaque couche ne coïncident pas avec celle du modèle OSI. Elles sont souvent associées au partage de fichiers et d'imprimantes.

b) Fonctionnalités des couches intermédiaires

Les couches intermédiaires et hautes (Session/Présentation/Application) vont réaliser la gestion de l’interface avec l'application. Elles sont constituées de protocoles (PDU : Protocol Data Unit), mais aussi des fonctions associées (SDU : Service Data Unit). Dans le cas des couches plus élevées, ces SDU ont une importance fondamentale car toutes les fonctionnalités sont réalisées par les machines qui communiquent (donc aux 2 bouts car on est au dessus de la couche transport) et sont donc faites logiciellement.

Les PDU sont complexes est souvent de format binaire. Elles ne sont pas forcément normalisées, mais peuvent être propriétaires (exemple de NetBIOS). Certaines sont décrites dans des RFC (NBT), d'autres sont seulement fournies par le constructeur (NIS).

Les SDU, ensemble de fonctions assurant l’interface, sont regroupées dans des bibliothèques de fonctions exécutées sur un ordinateur. Elles sont souvent liées à un système d’exploitation et associées à des services particuliers. Elles se présentent sous forme d’API.

Ces caractéristiques font que de nombreux problèmes d’interopérabilité apparaissent lorsqu'il s'agit de faire fonctionner ensemble des applications de ce type provenant de constructeurs différents.Exemples : partage de ressources (disque/imprimante...)

9.1.2 Structures des couches intermédiaires Windows

Le partage de fichiers sous Windows est basé sur une couche d'interface : NetBIOS (Couche « Session ») et une couche de services : SMB ou CIFS (Couche « Application/Présentation »). Si SMB/CIFS est resté quasiment constant au cours du temps, la couche d'interface a beaucoup évoluée en fonction des couches inférieures, pour en arriver à NBT (NetBIOS over TCP/IP) au dessus d'une couche Transport TCP.

140

NetBIOS a existé directement sur une sous-couche MAC ou LLC pour des réseaux locaux, mais aussi au-dessus de IPX/SPX. Plusieurs encapsulations peuvent exister en même temps sur une même machine (surtout serveur), mais actuellement seule NBT doit être utilisé sur des réseaux de machines récentes.

9.1.3 Couches intermédiaires sous UNIX

De la même manière que sous Windows, sous UNIX, le partage de fichiers est mis en place en utilisant la plupart des couches du modèle en couche. Seules les couches hautes diffèrent dans un réseau TCP/IP. C'est à dire les couches Session/Présentation/Application. Sous UNIX, un mécanisme particulier les RPC (Remote Procedure Call) permet de rendre transparent le fait que le fichier ne se situe pas sur la machine où il est utilisé. Le format des PDU est complexe et de type binaire.

Partage Fichiers sous UNIX :

141

Ethernet/xxx

Ethernet/xxx

LLC (802.2)

NetBIOS

SMB/xxx

xxx

xxx

Application

Ethernet

IPX

SPX

NetBIOS

SMB/xxx

xxx

Application

Ethernet Ph

Ethernet

IP

TCP

NetBIOS

SMB/xxx

xxx

Application

Ethernet Ph

IBM

NetBIOS

xxx

xxx

Réseau IBM

IBM

9.2 Couche NetBIOS sur 802.2.

9.2.1 Principe

Netbios sur 802.2 (sur sous-couche LLC) a été utilisé sur les serveurs anciens (avant 199x). Il se compose de 4 protocoles associés (avec 4 format de trames) :– Name Management Protocol– User Datagram Protocol– Diagnostic and Monitoring Protocol– Session Management ProtocolIl est la base des autres implémentations, même si les trames ont changées, le principe des protocoles est resté.

9.2.2 Name Management Protocol

C'est la publication des nouveaux noms NetBIOS :Noms NetBIOS : 15+1 caractères = adresseNom individuel (plusieurs pour une machine : aliases)Nom de groupe (équivalent au workgroup sous windows)

Principe :Diffusion d'un broadcast pour diffuser un nouveau nom. S'il n'y a pas de réponse de conflit, la machine peut se l'attribuer et les serveurs peuvent l'ajouter au voisinage.4 trames : ADD_GROUP_NAME_QUERY ; ADD_NAME_QUERY

142

Couche « Session »

NFS (Network File System)Couche Application

XDR (eXchange Data Representation)

RPC (Remote Procedure Call)

TCP

IP

Ethernet

Ethernet

Application

Couche Présentation

Couche Transport

ADD_NAME_RESPONSE : si il existe ; NAME_IN_CONFLICT si il y a un autre problème

Une commande : net name [nom [/add || /delete]] va permettre de faire cette opération manuellement.

9.2.3 User Datagram Protocol

Envoi de trames en mode non fiable (à ne pas mélanger avec UDP de la pile TCP/IP).En général il est utilisé seul, sans protocole de couches supérieures.2 trames :DATAGRAM : Point à PointDATAGRAM BROADCAST : Broadcast

9.2.4 NetBIOS Diagnostic and Monitoring Protocol

Utilisé pour obtenir des informations d’état sur les postes locaux ou distants4 trames :STATUS QUERYSTATUS RESPONSETERMINATE TRACETERMINATE LOCAL & REMOTE TRACE

9.2.5 NetBIOS Session Management Protocol

Ces trames permettent la gestion d’un échange en mode connexion2 trames de découverte :NAME_QUERY ; NAME_RECOGNISED (équivalent du DNS)4 trames de gestion de session :SESSION_INITIALIZE ; SESSION_CONFIRM (démarrage)SESSION_END ; SESSION_ALIVE (fin et maintien)6 trames de transport de données :DATA_FIRST_MIDDLE ; DATA_ONLY_LAST (envoi de données)DATA_ACK ; NO_RECEIVE (vérification)RECEIVE_OUT-STANDING ; RECEIVE_CONTINUE (gestion)

9.3 NetBIOS sur TCP/IP

9.3.1 Principe.

Netbios sur TCP/IP a été défini par les RFC1001 (principes) et RFC1002 (format des trames). Il est donc public, ce qui a été une nouveauté venant de Microsoft. De fait, la généralisation des échanges via TCP/IP concernant les échanges inter-réseaux a rendu obligatoire, la mise en oeuvre de NetBIOS sur un protocole pouvant être routé sur tout l'Internet. Certains y ont même vu un abandon progressif des protocoles propriétaire Windows, mais depuis la publication des RFC, il reste toujours le standard, en association avec SMB/CIFS (pour les couches supérieures), de la communication pour le partage des ressources sous Windows.

143

TCP/IP prenant en charge l'essentiel de la communication en mode connecté, NetBIOS s'est considérablement simplifié.Il ne comprend plus que 3 services et protocoles associés (avec 3 format de trames) :– Name Service (Name Service Packets )– Datagram Service (Datagram Service Packets)– Session Service (Session Service Packets)

En comparaison avec NetBIOS sur 802.2 : les trames ont changées mais le principe des protocoles est resté (moins le 4ème service : monitoring and diagnostic).Le service le plus complexe est le Name Service car il doit prendre en charge tous les problèmes de compatibilité, les 2 autres s'appuyant largement sur TCP/IP sont plus simples.

9.3.2 Name Service (NetBIOS Name Service).

a) Principe

C'est la déclaration des noms pour une communication. Pour des raisons de compatibilité, les anciens noms NetBIOS ont été conservés, mais s'y rajoute des noms compatibles DNS. Ce deuxième aspect est de plus en plus présent surtout avec les dernières versions de Windows Server où un serveur DNS est intégré, et sert de base à de nombreuses fonctions d'Active Directory. Il va permettre de réaliser des communications à l'échelle de l'Internet.

Il y a plusieurs service (SDU) : Add Name ; Add Group Name ; Delete Name qui vont permettre de déclarer des noms de machines, et de découvrir celles avec qui communiquer. Ces services s'appuient sur des échanges d'informations (PDU).

144

Couche « Session »

SMB/CIFSCouche Application/Présentation

NetBIOS

NbT

TCP

IP

Ethernet

Ethernet

Application

Couche d'interface

Couche Transport

b) Nom NetBIOS

Initialement, les noms NetBIOS étaient codés sur 16 octets. 15 octets servent au nom, le dernier étant le type de service. Pour des raisons de compatibilité avec le système DNS, une représentation dérivée est utilisée pour la représentation des noms dans les paquets NBT. Elle permet d'utiliser encore une représentation interne de type NetBIOS 16 octets mais d'avoir un échange compatible DNS. Ce changement de représentation se fait à 2 niveaux :1er niveau : traduction des noms NetBIOS en pseudo noms de machine+domaine2ème niveau : traduction au format DNS

Name Format 1er niveau : On découpe chaque octet en 2 octets et on ajoute le caractère 'A' (0x41) à chaque demi octet. Ceci permet d'avoir un nom avec uniquement des codes ASCII compatible DNS.Si le nom NetBIOS est trop court, il est complété par des espaces, le résultat de cette traduction est donc toujours un nom de 32 caractères ASCII avec des caractères compris entre 'A' et 'P'.

Exemple FRED (rfc 1001) devient :EGFCEFEECACACACACACACACACACACACA

Puis on complète par le NetBIOS Scope, c'est à dire le pseudo nom de domaine. Si celui-ci est telecom.com, le nom complet devient :

EGFCEFEECACACACACACACACACACACACA.telecom.com

Name Format 2ème niveau : C'est le même genre de traduction que pour le DNS. C'est à dire un octet de longueur qui remplace le '.' puis la valeur en ASCII. On peut aussi ne pas répéter les chaînes de caractères déjà utilisées et les remplacer par un code spécifique.

c) Mécanisme du Name Service

Le mécanisme du Name Service est un mécanisme assez complexe car il prend en charge plusieurs types de machines entre autre pour des raisons de compatibilité.

Concernant l'attribution et la résolution de noms, il y a 3 catégories de machines :– Des B Nodes (BroadCast Nodes) ils mettent en oeuvre la résolution de noms par des BroadCast,

ils ne peuvent donc communiquer que sur un sous-réseau.– Des P Nodes (Point to Point nodes) qui font cette opération par une demande auprès d’un serveur

NBNS et NBDD– Des M Nodes (Mixed Nodes) : ils utilisent les 2 techniques, ce qui leur permet de communiquer

avec des B nodes sur le sous-réseau et avec des P nodes ailleurs.

Serveur NBNS (NetBIOS name server) ou Serveur WINS (Windows Internet Name Server) qui est l'implémentation Microsoft de NBNS.Serveur NBDD (NetBIOS datagram distribution)Permet de passer des datagrammes sur Internet (~passerelle)Une machine va réclamer un nomsi le nom existe la machine répond

4 opérations peuvent être présentes :– Name registration : Each WINS client is configured with the IPv4 address of a WINS server.

When a WINS client starts, it registers its NetBIOS names and their corresponding IPv4 addresses

145

with its WINS server. The WINS server stores the client’s NetBIOS name-to-IPv4 address mappings in its database.

– Name renewal : All NetBIOS names are registered on a temporary basis so that if the original owner stops using a name, a different host can use it later. At defined intervals, the WINS client renews the registration for its NetBIOS names with the WINS server.

– Name resolution : A WINS client can obtain the IPv4 addresses for NetBIOS names by querying the WINS server.

– Name release : When a NetBIOS application no longer needs a NetBIOS name, such as when a NetBIOS-based service is shut down, the WINS client sends a message to the WINS server to release the name.

d) Name Service Packet

Format des trames du Name Service Protocol est compatible avec celui du DNS.

Name Registration Request (2 champs) :1 champ question avec le nom demandé1 champ Additional avec le même nom et un TTL

Positive Name Registration Response (1 champ) :1 champ réponse : avec le nom demandéLe flag est à 0x0 (c’est OK)?

Negative Name Registration Response (1 champ) :1 champ réponse : avec le nom demandéLe champ Flag avec le code de refus :0x01 : Format Error ; … ; 0x06 : Active Error (le nom est déjà utilisé) …

146

Answer Ressource Record

Question Entries

AR Count

Qd Count

NS Count

An Count

Transaction ID Flag RcodeOpcode

0 8 164 21 28

Additionnal Ressource Record

Authority Ressource Record

9.3.3 Datagram Service.

C'est un service non fiable, unicast ou Broadcast. Il comprend 4 primitives de service (SDU) :– Send Datagram,– Send BroadCast Datagram,– Receive Datagram,– Receive BroadCast Datagram

Datagram Service Packet

Valeur du champ Type :0x10 - DIRECT_UNIQUE DATAGRAM

0x11 - DIRECT_GROUP DATAGRAM 0x12 - BROADCAST DATAGRAM 0x13 - DATAGRAM ERROR 0x14 - DATAGRAM QUERY REQUEST 0x15 - DATAGRAM POSITIVE QUERY RESPONSE 0x16 - DATAGRAM NEGATIVE QUERY RESPONSE

Champ Flag :

Symbol Description

M MORE flag, If set then more NetBIOS datagram fragments follow.

F FIRST packet flag, If set then this is first (and possibly only) fragment of NetBIOS datagram

SNT Source End-Node type: 00 = B node 01 = P node 10 = M node

147

Data

Datagram Length (opt)

Source IP

Source Port

Datagram IDFlag

0 8 164 21 28

Type

0 0 0 0 MFSNT

B0 B1 B2 B3 B4 B5 B6 B7

11 = NBDD RESERVED 0-3 Reserved, must be zero (0)

Les champs Source IP et Source Port existent toujours, les autres sont optionnels et vont dépendre du type de datagramme.

9.3.4 Session Service.

C'est un service fiable en mode connecté au niveau session.

Il y a gestion d’une session avec 3 phases :– Etablissement de la session– Maintien de la session– Arrêt de la session

Les SDU du service fiable (Session Service) :Call, Listen, Hang Up, Send, Receive, Session status

Les échanges de PDU :

Ouverture en 2 temps : TCP puis NetBIOSLa première est toujours acceptéeLa deuxième démarre par une PDU : session requestPDU de maintien :Session Keep Alive : envoi périodique si le poste est configuré

Session Service Packet :Ouverture d’une connexion TCP (port 139)Ouverture d’une session NetBIOS

NBT : séquence d'ouverture de session

148

LengthFlag

0 8 164 21 28

Type

Trailer (Packet dependant)

9.4 Couche Application : CIFS/SMB

9.4.1 Principe général.

Le protocole de couche application sous Windows est SMB (Server Message Blocks), renommé plus tard CIFS (Common Internet File System).

Il permet le partage de fichiers en mode Client/serveurIl assure une compatibilité avec les différentes versions de Windows

Il existe une gestion de la sécurité (authentification) et un cryptage des informations sensibles

SMB/CIFS utilise le rassemblement des commandes ANDX batching, c'est à dire que plusieurs commandes peuvent être passées par la même trame.

Il y a verrouillage des fichiers distants lors de l’utilisation.

C'est un échange de type Client/Serveur simple :Une question -> une réponse

149

Ouverture Session

Client ServeurSYN (IP+Port=139)

SYN/ACK

ACK

Session Request Packet

Positive Session Response Packet

Session message Packet

Session Message Packet

Plusieurs question peuvent être en cours (MID)Multiplex ID : permet au client d’identifier les réponses provenant du serveur.

Le dialogue est basé sur des commandes simples mais nombreuses :Plus de 100 commandes– SMBmkdir : 0x00 : Create Directory– SMBOpen : 0x02 : Open a file– SMBunlink : 0x06 : Delete file– SMBsends : 0xd0 : Send message...

9.4.2 Protocole.

SMB Packet

Signification des champs :– Tree ID : Défini la ressource concernée (disk, printer…)– Process ID : identifie le process qui accède à la ressource ce qui évite l’accès concurrent– User ID : obtenu au moment de la connexion, le serveur donne un ID en début de session

(login+passwd). Il définit les droits d’accès.– Multiplex ID : identifie les requètes– Word Count + Parameter words : command specific data– Byte Count + Buffer : buffer de bytes

Exemple d'échange SMB : ouverture session

150

Parameter Words

Pad or Security signature (12 bytes)

Multiplex ID

Tree ID

User ID

Process ID

0xFF

0 8 16 24

Buffer

S M B

Command Error Class 0x00 Error Code

Error Code (continued) Flag2Flag

WordCount

ByteCount

9.5 Couches hautes sous UNIX : RPC

9.5.1 Principe

Les RPC Remote Procedure Calls (RFC 1831) sont une extension de la notion d’appel de procédures locales. Les RPC fournissent une API pour que le programmeur ne voit pas de différence entre l'utilisation d'une procédure locale ou distante.L’accès aux services en local se fait par des appels à des fonctions systèmesL’accès Client/Serveur se fera par des RPCIndépendant de la couche transport

API au dessus de l ’API socket (couche transport)Créées et définies par Sun Microsystem

– Fonctionnement– Appel identique à une fonction avec des paramètres– Appel distant bloque le thread jusqu’au retour de la réponse (ou time out)

151

Ouverture SessionClient Serveur

Demande Session NetBIOSOuverture

SessionNetBIOS

Positive Acknowledgement

SMB_COM_NEGOCIATE

SMB_COM_NEGOCIATENegociate

CIFSDialect

SMB_COM_SESSION_SETUP_ANDXUser Login

-> UIDSMB_COM_SESSION_SETUP_ANDX

SMB_COM_TREE_CONNECT_ANDXConnect toRessource

-> TIDSMB_COM_TREE_CONNECT_ANDX

– La machine serveur exécute réellement la fonction

Mise en œuvreun programme est en attente en permanence côté serveur : Daemon (démon)A la réception d’une demande, il exécute, puis il renvoie le résultat

Le démon gère plusieurs fonctions (procédures)Il doit identifier la demande : Information dans la PDU

Informations nécessaires à la mise en œuvre (Informations qui doivent transiter dans la PDU) :– Identifier la procédure que le serveur doit exécuter– Vérifier les droits d’accès du client aux fonctionnalités du serveur

152

Client

Demande

Serveur

Réponse

Démon

Clientprogram

Client Serveur

Callrpc()

Executerequest Call

service

Serviceexecute

Programcontinues

ReturnReply

Requestcompletes

– Définir le format des données d’entrée à envoyer– Définir le format des données de retour

Identification de la procédure distante à exécuterUne procédure distante est définie par :– un numéro de programme (~ choix du démon)– un numéro de version (gestion de plusieurs versions simultanément : compatibilité)– un numéro de procédure (chaque procédure a un numéro)

Numéro de programme0x00000000 à 0x1FFFFFFF : définie par Sun0x20000000 à 0x3FFFFFFF : définie par l’utilisateur0x40000000 à 0x5FFFFFFF : numéros attribués dynamiquement0x60000000 à 0xFFFFFFFF : RéservésExemples0x100003 et version 3 : NFS services ; 0x100000 version 2 portmap

Numéro de procédure (dans l’ordre de création)Procédure 0 (pour NFS) est la procédure NULL : test de l’accès au serviceProcédure 1 (pour NFS) : GETATTR, recherche de paramètresProcédure 3 (pour NFS) : LOOKUPProcédure 6 (pour NFS) : READ, lecture contenu de fichier

Authentification :– La méthodologie d’authentification et d’autorisation est définie indépendamment du protocole– zone de données réservée pour cela

L'échange des données se fait dans un format XDR (décrit ensuite) : RFC 1832 dans la zone dépendante de la procédure appelée.

9.5.2 La PDU

Echange sur 2 phase PDU Call - PDU Reply

153

Format de la PDU de demande call

PDU de réponse (reply avec acceptation)

154

Program

Version

Procédure

Type

RPC version

Transaction ID

0 8 164 19 24

Credential ….

Verifier ….

Ethernet

Ethernet

IP

TCP

RPC

XDR

NFS

Application

Ethernet

Ethernet

IP

TCP

RPC

XDR

NFS

Application

Call

Reply

Exemple d’un échange RPC

Envoi d ’une PDU de demande : type 0 (Call)Retour d ’une PDU de réponse : type 1 (Reply)

2 états pour la réponseAcceptéRejeté

Si accepté, 2 étatsExécutéNon exécuté

Exemple de PDU RPC (call) :Remote Procedure Call, Type:Call XID:0x822df084XID: 0x822df084 (2184048772)Message Type: Call (0)RPC Version: 2Program: NFS (100003) / Program Version: 3Procedure: CREATE (8)Credentials

Flavor: AUTH_UNIX (1) / Length: 32 / Stamp: 0x00000bb4Machine Name: istapc82 (length: 8 ; contents: istapc82)UID: 0 / GID: 0Auxiliary GIDs (GID: 0)

VerifierFlavor: AUTH_NULL (0) / Length: 0

Exemple d'une PDU RPC reply :Remote Procedure Call, Type: Reply XID:0x822df084

155

Program

Version

Procédure

Type

RPC version

Transaction ID

0 8 164 19 24

Reply state

Verifier ….

Accept state

XID: 0x822df084 (2184048772)Message Type: Reply (1)Program: NFS (100003)Program Version: 3Procedure: CREATE (8)Reply State: accepted (0)Verifier

Flavor: AUTH_NULL (0)Length: 0

Accept State: RPC executed successfully (0)

9.5.3 Implémentation

La création de programme basés sur les RPC se fait via la fourniture d’une API de haut niveau (au dessus des sockets). Puis on utilise un compilateur spécifique pour créer le programme.

Fonctions utilitaires fournies côté serveur– Enregistrement des procédures– Conversion des formats de données

Fonctions utilitaires fournies côté client– Appel des procédures { call_rpc() }– Conversion des formats de données

Publication et découvertePublication : faire connaître ce que propose le serveurDécouverte : déterminer ce que propose le serveur

Résolution d’adresses + numéro de ports

Service lookup (RFC 1823)portmapper (version 2)rpcbind (version 3 et 4)Ecoute sur le port 111 (UDP et TCP)Redirection du client sur le port du programme

Commande rpcinfo -p : affiche les services rpc disponibles (port…)

156

Déclaration

Attente sur Port 111

Demande de connexion

Connexion sur le port applicatif

157

Client Serveur

PortmapperPort 111

Program

Déclaration

Client Serveur

PortmapperPort 111

ProgramPort xxxx

Client Serveur

PortmapperPort 111

ProgramPort xxxx

(Port xxxx)

Client Serveur

PortmapperPort 111

ProgramPort xxxx

Il existe plusieurs implémentations :– RPC ONC : Sun– RPC DCE : Open Group (gratuit)– Version Windows– XML RPC ; SOAP …

9.6 Couche présentation : XDR.

9.6.1 Principe.

XDR (External Data Representation) est un protocole de présentation des données en un format portable. Il est dans un format proche du Langage C.Il existe d'autres possibilités : XML...

Aucun échange ne correspond à ce protocole (pas de zone dans la PDU). En effet, la couche présentation n’a pas besoin de paramètres dans ce cas, il suffit que le format de représentation soit le même aux deux bouts.

9.6.2 Mise en oeuvre.

Exemple de description de la PDU RPC sous XDR :

158

Ethernet

Ethernet

IP

TCP

RPC

XDR

NFS

Application

Ethernet

Ethernet

IP

TCP

RPC

XDR

NFS

Application

Si c'est une PDU de demande (case CALL valide) :

Si c'est une PDU de réponse (case REPLY valide)

Il y a encore 2 cas :Réponse d'acceptation :

159

struct call_body {

unsigned int rpcvers; /* must be equal to two*/

unsigned int prog;

unsigned int vers;

unsigned int proc;

opaque_auth cred;

opaque_auth verf;

/* procedure specific parameters start here */

};

union reply_body switch (reply_stat stat)

{

case MSG_ACCEPTED:

accepted_reply areply;

case MSG_DENIED:

rejected_reply rreply;

} reply;

struct rpc_msg {

unsigned int xid;

union switch (msg_type mtype) {

case CALL:

call_body cbody;

case REPLY:

reply_body rbody;

} body;

};

C'est principalement une représentation des structures de données :types simples

4 octets mini : intbool -> enum {0, 1} -> intdouble : 8 octets ; quadruple : 16 octets…

structure, union …opaque : chaîne d ’octets quelconquestring : chaîne de caractères

L'API fournit des procédures de conversion :xdr_int() : conversion représentation xdr vers intxdr_bytes()…

9.7 NFS

GénéralitésNetwork File System version 3 (rfc 1813) Network File System version 4 (rfc 3010, rfc 3530)Généralisation de la notion de systèmes de fichiers pour des ressources en réseauMontage de systèmes de fichiers distantsMise à disposition de ressources (exportation côté serveur)Utilisation locale (montage côté client)Communication via des descripteurs (fichier/répertoire)stocké côté client (serveur sans état)résultats des requêtes, contenus des répertoires, file handle, noms et attributs des fichiers, valeur du temps.

160

struct accepted_reply {

opaque_auth verf;

union switch (accept_stat stat) {

case SUCCESS:

opaque results[0];

/*

* procedure-specific results start here

*/

case PROG_MISMATCH:

struct {

unsigned int low;

unsigned int high;

} mismatch_info;

default:

9.7.1 Principe général.

Ce service est mise en œuvre par plusieurs démons : nfsd, mountd (rpc.nfsd ; rpc.mountd)Il ya plusieurs fichiers de configuration dont /etc/exports : systèmes de fichiers exportable

Des commandes sont aussi fournis :/usr/etc/exportfs (gestion du fichier d’exportation)statistiques : nfsstatmontage : mount -t nfs server001:/home/expt /mnt/essaishowmount -e server001

La sécurité est gérée par RPC

Liste des fonctions NFS et leurs attributsvoid NFSPROC3_NULL(void) = 0;GETATTR3res NFSPROC3_GETATTR(GETATTR3args) = 1;SETATTR3res NFSPROC3_SETATTR(SETATTR3args) = 2;LOOKUP3res NFSPROC3_LOOKUP(LOOKUP3args) = 3;ACCESS3res NFSPROC3_ACCESS(ACCESS3args) = 4;READLINK3res NFSPROC3_READLINK(READLINK3args) = 5;READ3res NFSPROC3_READ(READ3args) = 6;WRITE3res NFSPROC3_WRITE(WRITE3args) = 7;CREATE3res NFSPROC3_CREATE(CREATE3args) = 8;MKDIR3res NFSPROC3_MKDIR(MKDIR3args) = 9;SYMLINK3res NFSPROC3_SYMLINK(SYMLINK3args) = 10;MKNOD3res NFSPROC3_MKNOD(MKNOD3args) = 11;REMOVE3res NFSPROC3_REMOVE(REMOVE3args) = 12;RMDIR3res NFSPROC3_RMDIR(RMDIR3args) = 13;RENAME3res NFSPROC3_RENAME(RENAME3args) = 14;LINK3res NFSPROC3_LINK(LINK3args) = 15;READDIR3res NFSPROC3_READDIR(READDIR3args) = 16;READDIRPLUS3res NFSPROC3_READDIRPLUS(READDIRPLUS3args) = 17;FSSTAT3res NFSPROC3_FSSTAT(FSSTAT3args) = 18;FSINFO3res NFSPROC3_FSINFO(FSINFO3args) = 19;PATHCONF3res NFSPROC3_PATHCONF(PATHCONF3args) = 20;COMMIT3res NFSPROC3_COMMIT(COMMIT3args) = 21;

Type et contenu des paramètres dans la RFC (description au format XDR)

Exemple de description format XDR, Procedure 7: WRITE - Write to fileDéclaration fonction et arguments d'entrée

WRITE3res NFSPROC3_WRITE(WRITE3args) = 7;enum stable_how {UNSTABLE = 0,DATA_SYNC = 1,FILE_SYNC = 2};struct WRITE3args { nfs_fh3 file; offset3 offset; count3 count; stable_how stable; opaque data<>; };

161

Déclaration arguments de sortiestruct WRITE3resok { struct WRITE3resfail { wcc_data file_wcc; wcc_data file_wcc; count3 count; }; stable_how committed; writeverf3 verf; };

union WRITE3res switch (nfsstat3 status) { case NFS3_OK : WRITE3resok resok; default : WRITE3resfail resfail; };

9.8 NIS

NIS est lui aussi basé sur les RPC suivant le même principe que NFS. NIS étant un produit SUN Microsystem, il n'y a pas de description dans les RFC. Quoi qu'il en soit le code source se trouve dans toutes les distributions Linux par exemple.

162

TP n°3 suite : Etude des protocoles réseaux NetBIOS

Ce TP vient en complément de celui sur le serveur Windows, afin de bien comprendre les mécanismes des échanges.

Phase 1 : Questions concernant la déclaration des noms NetBIOS :

Etude du protocole NBNS et du lien avec le DNS

1) Par la commande net name, créer un nouvel alias (votre nom) pour votre machine. Visualiser les trames envoyées par votre machine. - Qu'en déduisez–vous sur les protocoles actifs sur votre PC ?- Sous quelle forme sont envoyés les paquets (type d'adresses en dessous de NetBIOS) ?- Décrivez les différents systèmes de nommage (adressage) de NetBIOS.- Analyser le contenu des autres champs des trames NetBIOS.

2) Tenter de créer un nouvel alias, mais d'un nom déjà utilisé par la deuxième machine de votre binôme. Décrivez les trames échangées, et les champs NetBIOS.

3) Refaire la même manipulation avec un alias correspondant au serveur Windows. Pourquoi y a t’il une différence ?

4) Détruire les alias créés. Cela génère-t-il des trames sur le réseau ? Si oui lesquelles ?

Phase 2 : Questions concernant NetBIOS sur TCP/IP (NbT) :Etude du protocole Session Service Protocol

a) Par le voisinage réseau, aller sur le serveur, accéder à votre répertoire personnel et ouvrir un fichier texte. Déterminer les différentes trames échangées pour effectuer cette opération. Vous pourrez séparer l'analyse en plusieurs acquisitions pour bien mettre en évidence le séquencement de ces trames (si il y a authentification –car pas de connexion antérieure- les mots de passe ne circulent pas en clair).

b) Analyser le champ NetBIOS de ces trames ? Où sont mises en œuvre les différentes fonctions des trames NetBIOS précédentes ?

c) Peut-on reconstituer la session complète en partant de la connection TCP ? Si non, déconnecter-vous et reconnecter-vous puis capturer les trames avant toute action sur le voisinage réseau.

Phase 3 : Questions concernant SMB/CIFS (avec NetBIOS sur TCP/IP) :

a) En utilisant la capture du a) précédent, faire la même analyse sur la partie SMB de ces trames. Détermination des différents types de trames. Séquencement de l'échange. Analyse du contenu des champs. Repérer en particulier les trames associées (question-réponse) par les différents ID.

b) Par la commande "net use", associer le répertoire applint du serveur ist-bessat à un disque réseau m: sur votre client. Dans ce cas aussi analyser les échanges SMB. Y a-t-il de nouveaux types de trames ? Si oui analyser les.

c) Supprimer l'association. Trames SMB échangées ?

163

d) En réutilisant la capture du c) précédent, analyser l’échange relatif à l’authentification du point de vue de la couche SMB.

e) Analyser de même les trames SMB échangées pour :- la création d’un répertoire- le déplacement dans un sous-répertoire- la destruction d’un répertoire- la création d’un fichier- la lecture d’un fichier- la destruction d’un ficher- la copie d’un fichier

Pour tous ces échanges, seule la partie SMB/CIFS sera à considérer, il sera surtout important de mettre l’accent sur les catégories de trames utilisées pour chaque fonction ainsi que sur leurs paramètres spécifiques. L’analyse des champs récurrents ne sera pas nécessaire puisque vous l’aurez faite à la question a).

164

Chapitre 10 : Interopérabilité

10.1 Introduction.

L'interopérabilité est la capacité à faire fonctionner ensemble des machines (des applications…) hétérogènes, c'est à dire présentant des caractéristiques différentes sur un ou plusieurs aspects.En premier lieu, cela peut être des machines fonctionnant sous des systèmes d'exploitation différents : UNIX et Windows par exemple. Mais cela peut aussi se limiter à faire fonctionner ensemble des applications différentes (client HTTP avec un serveur FTP...), ou de constructeurs différents (bases de données Oracle avec MySQL...). Dans le cadre de ce chapitre, c'est plutôt l'interopérabilité entre les systèmes d'exploitation client et serveur qui va nous intéresser et principalement l'interaction Windows et UNIX.Les différences peuvent se situer à plusieurs niveaux :- En terme de communicationProtocoles réseaux différents (NetBIOS/SMB versus RPC/NFS...)Systèmes d'adressage et mécanismes de résolution d’adresses différents- En terme de ressourcesOrganisation des systèmes de fichiers : autorisations sur les fichiers, gestion des partages...- En terme de représentation des informationsCodage des informations (CR ou CR+LF pour la séparation des lignes) ; big ou little endian sur des machines ayant des processeurs différents.

10.2 Principes et types d'interopérabilité.

L'interopérabilité peut se situer à plusieurs niveaux, elle peut concerner un simple accès réciproque à des données avec nécessité de prise en charge des différences de format jusqu'à une intégration plus poussée avec des accès transparents entre systèmes, elle peut aussi se limiter à des outils de conversion permettant de récupérer des informations d'un système pour les intégrer dans un autre.Actuellement, le support d'échange privilégié entre différents systèmes est le réseau, c'est donc à ce niveau que les problèmes d'interopérabilité devront être traités, même si les échanges de type média amovibles pourraient être aussi concernés, en général ceux-ci sont correctement traités depuis assez longtemps et ne concerne pas vraiment un cours sur les réseaux.

Comme nous l'avons vu précédemment, une interopérabilité réussie nécessite de résoudre plusieurs problèmes : protocoles réseaux, format des ressources à partager, authentification et droits basés sur des données utilisateurs différentes.

Un premier niveau consiste à relier les différents systèmes via des applications normalisées basées sur des couches réseaux compatibles (actuellement la couche transport TCP/UDP constitue le socle commun de tous les systèmes de communication réseaux basés sur des ordinateurs conventionnels).

165

Les exemples les plus courants de ce type d'interopérabilité sont l'usage des applications Telnet (ou leur équivalent sécurisé) ainsi que de FTP. L'usage de telles applications permet de résoudre les problèmes liés aux échanges de données sur n'importe quel type de systèmes mais ne prennent pas en compte la conversion des différents formats des ressources et nécessite en général une double authentification (à la connexion initiale sur le système hôte et au lancement de l'application Telnet/FTP sur le système cible). De plus l'usage des ressources du serveur nécessite une copie locale sur le client : ce qui est inconcevable dans le cas d'une véritable utilisation partagée des ressources. C'est pourquoi, des outils poussant l'intégration plus avant ont été développés, ils ne peuvent être que spécifiques à des catégories de machines et de systèmes d'exploitation bien définies. En général soit l'adaptation est faite au niveau du client soit au niveau du serveur, l'autre machine fonctionnant sans aucune modification ou ajout.

Cette adaptation se fait en plusieurs étapes, au niveau des protocoles d'échanges couches hautes qui vont permettre une exploitation intégrée des ressources ainsi qu'au niveau de l'exportation des ressources initialement reliée à un type d'échange vers un autre type d'échange.

En pratique, il est nécessaire tout d'abord que la machine basée sur un système d'exploitation A puisse proposer des ressources sous un format compatible avec le système d'exploitation B et qu'elle puisse aussi les formater suivant un protocole d'échange compatible avec le système d'exploitation B.

Lorsque l'adaptation est faite au niveau du client, elle doit être présente sur tous les clients ce qui nécessite plus de modification au niveau du parc de machines. Quoiqu'il en soit la modification du client est assez souvent plus simple car les fonctionnalités peuvent être réduites et ne viennent pas interférer avec le fonctionnement global du serveur. C'était en général la solution retenue il y a quelques années (client NFS pour PC : PCNFS).

166

Pile TCP/IP

Pile TCP/IP

Application Cliente

Application Serveur

Machine A(Syst. Exploitation A)

Machine B(Syst. Exploitation B)

Si l'adaptation est faite au niveau du serveur, elle ne doit être faite qu'une fois, mais avec beaucoup plus d'attention car le bon fonctionnement du serveur conditionne le fonctionnement de l'infrastructure complète.

Actuellement, la gestion du parc de machines clientes étant de plus en plus normalisée c'est cette solution qui est retenue car elle conduit à une gestion plus centralisée. On retrouve dans ce cadre des solutions comme Samba (Serveur UNIX, Client Windows).

167

Pile TCP/IP

Pile TCP/IP

Application Cliente

Application Serveur

Machine A(Syst. Exploitation A)

Machine B(Syst. Exploitation B)

Couches hautes S.E. B

Couches hautes

Adaptation S.E. A - S.E. B

Pile TCP/IP

Pile TCP/IP

Application Cliente

Application Serveur

Machine A(Syst. Exploitation A)

Machine B(Syst. Exploitation B)

Couches hautes S.E. A

Couches hautes

Adaptation S.E. A - S.E. B

En fait, une machine cliente ou serveur possédant, pour un constructeur donné, des systèmes d'exploitation assez semblables, les 2 solutions peuvent être mises en place avec les mêmes technologies, c'est le cas par exemple de Windows Server for UNIX pour Microsoft.

10.3 Samba

10.3.1 Objectif et rôle de Samba.

L'objectif principal de Samba et de mettre à disposition des ressources d'un système sous Linux pour des clients fonctionnant sous Windows 95, NT, XP. Samba peut avoir pour rôle de partager uniquement un système de fichiers pour des machines clientes Windows, ou encore une imprimante. Mais il peut aussi remplacer en grande partie un contrôleur de domaine Windows Serveur afin de gérer une infrastructure complète de machines clientes Windows.Toutefois, il est basé sur une approche DOS de la gestion des machines Windows en particulier relativement aux droits sur les ressources. Un module supplémentaire permet d'étendre cette gestion des droits de manière plus fine que celle habituellement utilisée sous UNIX en ajoutant une gestion des ACL Windows.D'un autre point de vue, Samba peut-être utilisé pour permettre à une machine Linux de se connecter en tant que client sur une machine Windows fournissant une ressource.

10.3.2 Constitution de Samba

L'implémentation actuelle est basée sur 2 démons : smbd (Server Message Block Daemon) et nmbd (NetBIOS Name Server Daemon !).

Le démon nmbd gère l'aspect réseau couche haute, c'est à dire les protocoles NetBIOS over TCP/IP, concernant la déclaration des machines et la résolution des noms.

Le démon smbd gère l'ensemble de la conversion des ressources du format UNIX vers un format compatible avec des partages Windows, ainsi que l'authentification et les autorisations. Il intégre aussi une gestion minimum de domaines Windows

10.3.3 Configuration de Samba

Le fonctionnement de Samba est principalement défini par un fichier de configuration nommé smb.conf.

Ce fichier comporte plusieurs sections dont une principale : [global], et des sections permettant de définir des ressources exportées [homes], [printers]...

[global] : permet de définir le fonctionnement général du serveur Samba, définition du nom de domaine, du mode de fonctionnement du serveur, des ordinateurs (@IP) accrédités pour accéder au système, ...

168

[homes] : permet de spécifier des répertoires personnels pour chaque utilisateur d'une connexion via le serveur Samba[printers] : configuration du partage d'imprimante

les autres sections permettent de définir les propriétés des partages supplémentaires.

a) Partie globale du fichier de configuration :

Cette partie contient le nom du serveur (netbiosname), de son domaine ou groupe de travail (workgroup), et les rôles qu'il assure (local master, domain master...).

Un exemple est donné ci-dessous :

[global] workgroup = ISTASE server string = istapc83 password server = 192.168.1.83 local master = No domain master = No encrypt passwords = true netbios name = ISTAPC83 name resolve order = host bcast wins server = 192.168.1.45 NIS homedir = No

b) Partie liée à un partage

Cette partie permet de définir la ressource partagée (système de fichiers UNIX, imprimante) via la directive "path", le type d'accès à la ressource (writable, readable...), le nom du partage vu en exportation...

Un exemple est donné ci-dessous :

[appli_partage]path = /home/export/applicomment = applications partagéeswritable= no

c) Gestion des utilisateurs pouvant utiliser Samba

Afin de contrôler l'accès aux ressources UNIX, il est nécessaire de définir des utilisateurs qui puissent être associés d'un côté aux machines Windows, de l'autre aux ressources UNIX. Ceci est fait en deux étapes :- création d'utilisateurs locaux sur la machine UNIX (adduser, useradd...) ce qui va permettre de définir des droits relativement aux ressources- création d'une base de données utilisateurs Windows sur la machine UNIX. Cette base ne devra contenir que des utilisateurs déjà définis sous UNIX pour pouvoir y associer des droits locaux.

169

La création de la 2ème catégories d'utilisateurs ne peut se faire qu'avec une commande spécifique : smbpasswd qui va créer et peupler un fichier smbpasswd (choix discutable !).Suivant par qui est utilisé cette commande, elle n'a pas le même mode de fonctionnement. Si elle est lancé par un utilisateur standard, elle lui sert seulement à modifier son mot de passe. Si le super-utilisateur lance cette commande, il va pouvoir ajouter ou supprimer des utilisateurs directement dans le fichier smbpasswd. L'utilisateur doit déjà exister dans le fichier /etc/passwd pour pouvoir être ajouté dans smbpasswd, ceci pour les raisons exposées préalablement.

d) Droits sur les ressources.

Un des points qui illustre parfaitement les difficultés de mise en oeuvre d'une interopérabilité en multi-environnement est la différence de gestion des droits sous Windows et sous UNIX.En effet, les droits de base sous UNIX sont liée à 3 critères (lecture, écriture, exécution) et ceci pour 3 entités (propriétaire, groupe, les autres) alors que sous Windows les droits sont de 2 catégories, les droits simples (issus du DOS) : lecture seule, archive, fichier caché et les droits liés aux ACL (access list) qui sont très détaillés.

10.3.4 Mise en oeuvre pratique de Samba

Le démarrage manuel de samba peut s'effectuer par le script (/etc/init.d/samba) sous DebianComme tous les scripts du répertoire /etc/init.d, il peut prendre plusieurs options :- start : premier démarrage- stop : arrêt manuel- restart : arrêt et redémarrage

Remarque : sur un serveur de prodction, généralement on lance samba au démarrage du système Linux, par exemple en mettant un lien commençant par la lettre S dans un répertoire /etc/rcxxx.d vers le script /etc/init.d/samba (où xxx représente le niveau de démarrage en général rc2.d).

Le fichier de configuration est relu automatiquement à une périodicité donnée. Pour éviter les problèmes lors d'un changement dans un fichier de configuration, on travaille sur un fichier temporaire dont on peut tester la syntaxe par la commande :

testparm smbtmp.conf [hostname/hostip](le paramètre facultatif hostname, hostip demande à testparm de vérifier si la machine spécifiée peut accéder correctement aux services indiqués).

10.4 Windows Services for UNIX

Depuis quelques années (1999), Microsoft propose aussi des services réseaux permettant de relier un environnement de machines UNIX avec des serveurs Windows : Windows Services for UNIX (SFU). Au fur et à mesure des versions, plusieurs évolutions ont eu lieu :- Prise en charge de NFS plus complète en lien avec Active Directory- Environnement complet d'applications et de scripts (technologie Interix)- Internationalisation

170

Windows SFU fonctionne sous les plateformes (Windows 2000 Pro et Server, Windows XP, et Windows Server 2003/2008), il a surtout été testé côté UNIX sur des plate-formes propriétaires (Solaris, HPUX, AIX) qui constituent sa part de marché potentielle. Plusieurs niveaux d'inter-opérabilité peuvent être envisagés :- une simple utilisation réciproque des ressources UNIX/Windows (à l'image de Samba)- l'utilisation d'outils Windows Server (MMC) pour gérer les ressources partagées- une gestion commune des comptes utilisateur- une intégration plus complète au niveau du portage des applications et des modes de fonctionnement.

Utilisation réciproques des ressources

Ce service peut se décomposer en 4 outils différents :

- Client for NFS : qui va permettre à des postes clients ou serveurs Windows d'accéder à des ressources UNIX sous NFS.- Server for NFS : qui va, à l'inverse, permettre à des clients NFS d'accéder à des ressources sous Windows, mais via NFS (c'est en quelque sorte l'inverse de Samba)- Gateway for NFS : qui va permettre, à un serveur Windows, de servir de passerelle entre une infrastructure Windows et une infrastructure UNIX sans ajouter de logiciel sur les ordinateurs Windows.- Server for PCNFS : qui va permettre à Windows d'émuler un serveur PCNFSD gérant entre autre l'authentification.

Outils Windows Server pour gérer les ressources :

En fait, ce service inclut des outils assez standard :- Client et serveur Telnet (versions différentes de ceux déjà existants depuis Windows 2000)- Console MMC de gestion des services Windows SFU- Outil de script PERL pour automatiser les tâches de gestion et d'administration

Simplification de la gestion des comptes.

Ce service permet de faire cohabiter de différentes manières un contrôleur de domaine Windows avec une architecture basée sur NIS :- Utilitaire de migration de NIS vers Active Directory (outil qui paraît assez logique commercialement parlant pour Microsoft).- NIS Server : permet d'émuler un Serveur NIS à partir d'un contrôleur de domaine Windows en intégrant les domaines NIS à Active Directory.- Gestion commune de l'authentification entre les 2 systèmes (mise en correspondance des noms d'utilisateurs et synchronisation des mots de passe).

Intégration d'applications

Afin de pas perdre les connaissances et les développements mis en oeuvre sous UNIX, Windows SFU propose un sous-système intégré (Interix) et un kit de développement pour porter directement les scripts (Shell, Perl...) et les applications (après recompilation) écrites dans des langages de programmation standard (C, C++, Fortran...).

171 172

TP OptionRX1

N°06 : Configuration de serveurs Samba

Objectifs du TP:Installation et paramétrage sous Linux Debian d’un serveur Samba

Ressources nécessaires au TP

1. 2 PC clients Windows et un PC serveur Debian Linux (adresse IP 10.20.N°poste.N°PC).2. Mise en œuvre de la liaison physique entre ces PC par un switch.

Partie 1 : Partage de fichiers simple (UNIX-Windows) via Samba

Phase 1 : Configuration des PC1. Configurer les propriétés réseau des PC client pour permettre la connexion au

serveur Samba. Cocher le client pour réseau Microsoft 2. Configurer l’adresse IP, le masque, le nom de l’ordinateur : PCx (x numéro du PC).3. On commencera par définir un groupe de travail : tpreseau

Phase 2 : Configuration du PC serveur sous Linux Debian pour un partage non sécurisé

1. Toute la mise en œuvre de samba repose sur le fichier /etc/samba/smb.conf que vous éditerez.

Ce fichier décrit les ressources que l'on désire partager, ainsi que les permissions/restrictions qui leur sont associées. Le fichier smb.conf se découpe selon des rubriques (chacune référencé par une ligne contenant le nom de la section entre crochets) comprenant chacune un ensemble de lignes de paramètres du type attribut = valeur. Une ligne commençant par un # est une ligne de commentaire. Il existe 3 sections initiales:

- La section [global] qui définit des paramètres généraux sur le serveur- La section [homes] qui définit le partage d'un répertoire personnel- La section [printers] qui définit les imprimantes partagées par le serveur

Il est possible d'ajouter ses propres sections

La modification du fichier smb.conf se fera uniquement par ajout de lignes sans supprimer ou modifier les lignes commentées.

1. Modifier ou ajouter (s'ils n'existent pas) les champs suivants dans la section [global] :

workgroup = tpreseau (association au groupe de travail tpreseau)guest account = nobody (définition du nom d’utilisateur invité)security=share (niveau de sécurité le plus faible)

1. Ajouter une section définissant un nouveau partage :

[partage_libre] (nom visible du partage)path=/home/partage (répertoire UNIX à partager)comment = repertoire partage (commentaire affiché par l’explorateur)guest only = yes (accès par un compte public uniquement)guest ok = yes (accès sans mot de passe autorisé)

Ne pas oublier de créer le répertoire /home/partage et d’y mettre un fichier texte à l’intérieur pour tester le partage.

173

1. Tester la syntaxe du fichier /etc/samba/smb.conf grâce à l'utilitaire testparm et éventuellement déceler des fautes de saisie (testparm /etc/samba/smb.conf).

2. Lancer le service par le script /etc/init.d/samba start. Que donne la commande ps ?3. Pouvez-vous accéder au répertoire partagé sur le serveur à partir d’un PC client (voisinage

réseau) ? Editer le fichier déposé dans le répertoire, pouvez-vous le sauvegarder ?4. Rendre le partage accessible en écriture :

Ajouter la ligne suivante dans la section définissant le partagewriteable = yes (autorisation d’écriture pour samba)

Est-ce suffisant pour permettre l’écriture sur la ressource ?

1. Modifier les propriétés UNIX du répertoire et des fichiers pour permettre la modification.Tester la sauvegarde du fichier modifié.

1. Outils de suivi du fonctionnement de Samba :- Visualisez le contenu des différents fichiers journaux sous le répertoire

/var/log/samba. Il en existe un pour chaque deamon et un par connexion NetBIOS.- Sur le serveur, lancez la commande smbstatus pour visualiser les connexions

actives.Important: pour la suite du TP, observer au fur et à mesure du travail, le suivi des

connexions des clients Windows, avec les indications du nom de l'utilisateur, de la

machine cliente et de son numéro IP, la date et l'heure. Vous pouvez aussi suivre les

échanges de trames entre les machines pour bien comprendre le fonctionnement

Phase 3 : Configuration du PC serveur sous Linux Debian pour un partage sécurisé

2. Modifier le niveau de sécurité de votre serveur Samba en modifiant le champ suivant dans la section [global] :

security=user (niveau de sécurité par authentification utilisateur)

Pour l’utilisation de samba, il est nécessaire de créer des comptes pour les utilisateurs sur le serveur. Cette procédure est effectuée en 2 étapes, création des comptes UNIX, puis création des comptes Samba (en général on effectue une simple synchronisation des comptes entre les 2 systèmes)

3. Création de comptes utilisateurs UNIXCréer le groupe tpsamba et l’utilisateur tptest. Utiliser les commandes groupadd et

useradd (avec paramètres pour tenir compte du groupe).

4. Ensuite définir les mots de passe pour samba par la commande : smbpasswd –a <nom utilisateur>

5. Définir un nouveau partage (partage_sec) avec un accès limité à l’utilisateur précédent avec une authentification :

[partage_sec] (nom visible du partage)path=/home/partage2 (répertoire UNIX à partager)comment = repertoire partage securise (commentaire affiché par l’explorateur)valid users = tptest (autorise seulement l’utilisateur tptest)

6. Comment se fait l’accès sur la ressource de la phase 2 (partage_libre) ?7. Créer un autre utilisateur tptest2 ainsi qu’un partage (partage_sec2) associé à celui-ci,

vérifier les droits d’accès respectifs des utilisateurs sur les divers répertoires.

Partie 2 : Emulation d’un contrôleur de domaine Windows via Samba

174

Phase 1 : Configuration du contrôleur principal de domaine PDC

Un contrôleur principal de domaine (PDC) est un service chargé du contrôle de l'authentification des requêtes de connexion sur un réseau (comme d'habitude par nom de connexion (login) et mot de passe (password)). Samba peut assurer ce service partiellement en émulant les fonctionnalités d'un serveur Windows. Il permet entre autre de mettre en place des scripts de connexion (logon scripts).

1. Modifier la section [global] du fichier /etc/samba/smb.conf afin de valider Samba en contrôleur principal de domaine :

[global]

domain logons = Yes

# ce serveur est le controleur du domaine

domain master = True

# explorateur maitre de domaine

local master =yes

2. Création du partage [netlogon]Ce partage est destiné à recevoir les fichiers de configurations nécessaires au moment

de la connexion (scripts…). Il se situera dans le répertoire /home/samba/netlogon.

[netlogon]

comment = Service de connexion réseau

# répertoire où les scripts seront placés

path = /home/samba/netlogon

guest ok = yes

browseable = no

writeable = no

share modes = no

Phase 2 : Raccorder les machines Windows au contrôleur principal de domaine PDC

(8) Ajouter la machine sur le contrôleur de domaine 2.1 Créez un compte root pour samba avec le même mot de passe qu’UNIX. 2.2 Rajoutez un compte UNIX pour la machine cliente avec la commande:

useradd –d /dev/null MACHINE$ 2.3 Ajouter la machine cliente dans la base samba

smbpasswd -a -m MACHINE$

2.4 Puis définir le mot de passe qui correspond au nom de la machine clientesmbpasswb MACHINE$ (le mot de passe sera MACHINE)

(9) Paramétrer le client Windows Poste de travail / Propriétés

Onglet nom de l'ordinateur /Modifier

Membre du Domaine ……………

Login: root passwd: admintest

Et bien sûr ... redémarrer !

(10)Résultats et tests

Vous devez constater que la boîte d'invite à la connexion est modifiée : le 3ème champ Domaine y est ajouté. Se connecter en tant qu’utilisateur tptest. Observations : bureau, voisinage réseau ?

175

Phase 3 : Création du répertoire personnel de chaque utilisateur (répertoire home)1. Créer un nouvel utilisateur : tptest1.2. Créer un répertoire personnel pour chaque utilisateur sous /home/samba.

La section [homes] du fichier smb.conf permet de définir l'accès au répertoire personnel de chaque utilisateur.

1. Modifiez ce fichier afin que chaque utilisateur du système ait accès à son répertoire home et qu’il soit le seul à pouvoir lire et écrire des fichiers.

writeable yesvalid users = %U

1. Connectez-vous au serveur à partir du PC client. Avez-vous accès à votre répertoire ?Sinon :

logon drive = U:

Phase 4 : Mise en œuvre des scripts de connexion et des profils de chaque utilisateur

� Créer un répertoire public [appli] accessible en lecture pour seulement tptest et tptest1.

read list = tptest,tptest1

� Définir un script de connexion dans lequel vous montez un deuxième disque réseau en F : pour le partage public [appli].

# pour fixer le nom des scripts de connexion

logon script = script.bat

� Définir un sous-répertoire utilisateur (./logon) où seront stockés les profils utilisateurs.logon home = \\%L\home\samba\%U\logon

Phase 6 : Désinstallation (Phase obligatoire)

1. Sauvegarder les configurations que vous avez modifiées. Vous devez être capable à la fin du TP de reconstruire toutes les configurations très rapidement. Pour cela vous devez sauvegarder les fichiers de configurations modifiés ainsi que créer les scripts nécessaires pour reconstruire les modifications que vous avez effectuées.

2. Les configurations initiales des machines sont reconstruites au redémarrage des

machines donc pour ne pas perturber les autres groupes vous devez : Arrêter les

3 PC et éteindre les écrans. Attention : certains ordinateurs nécessitent que l’on

appuie sur le bouton marche/arrêt après avoir cliqué sur Démarrer���� Arrêter

176

Chapitre 11 : Connexions à

distance

11.1 Introduction.

Même si le travail sur une machine en local est encore de loin le modèle le plus répandu et le plus efficace en terme d'échange réseau, il peut être intéressant dans de nombreux cas de pouvoir travailler sur une machine distante à partir d'une interface locale. Cette interface peut-être de type texte pour les protocoles les plus simples ou de type graphique pour les plus évolués. On parle d'une manière générale de « connexion à distance ». Cela conduit à déporter la plupart des fonctions, hormis l'interface Homme-machine (IHM), sur la machine distante. Cela peut être vu comme une dématérialisation de l'informatique et ressembler au « cloud computing » d'un point de vue technique.

La mise en œuvre de cette technologie nécessite 3 éléments :– Une application locale qui récupère les informations des périphériques d'entrée (souris, clavier) et

qui affiche dans une fenêtre spécifique les résultats provenant de la machine distante.– Un protocole de communication permettant d 'échanger, entre la machine locale et la machine

distante, les informations nécessaires.– Une application distante qui transmet les informations reçues de la machine locale et les envoie

vers le programme exécuté et qui récupère les résultats affichés et les renvoie vers la machine locale.

177

Schéma de principe d'une connexion à distance

Les fonctionnalités peuvent évoluer, du plus simple, où il y a seulement exécution déportée de commandes tapées au clavier en local, au plus compliqué où une interaction graphique complète (souris, clavier, affichage graphique) est mise en œuvre. Les environnements d'exploitation locaux et distants peuvent être hétérogènes (Windows, UNIX...) surtout si les commandes sont des commandes texte. Des mécanismes de sécurité sont en général ajoutés pour contrôler la prise en main de la machine distante : authentification, droit d'accès de type access list, cryptage.

Les applications de connexion à distance peuvent être classées en fonction de leur protocole de communication et de leur possibilités, on peut citer :– telnet : application de base interopérable, en standard sur de nombreux environnements– rlogin : service de connexion à distance spécifique UNIX– rsh : lancement de programme à distance– ssh : connexion à distance sécurisée– X11 : connexion à distance graphique pour les postes UNIX– VNC : protocole plus récent multi-plateforme de connexion à distance graphique.– RDP : console à distance Windows et Service terminal serveur.

Toutes ont en commun un contrôle interactif du poste distant par l'IHM du poste local, mais avec des degrés d'intégration différents. Le poste distant doit être considéré comme un serveur, le poste local comme le client.

Le principe de mise en œuvre repose sur les 3 points vus précédemment :– Un protocole de communication qui va transporter les informations (éléments d'interaction et

affichage) entre le client et le serveur. Ce protocole sera plus ou moins compliqué suivant les informations qui transitent (texte ou graphique).

– Une interface côté client qui peut être seulement un programme spécifique avec un accès réseau.– Un démon côté serveur qui doit être capable de rediriger le flux d'information provenant du client

vers une application en local (de même pour le flux de retour). Ce démon doit avoir une interaction avec le système d'exploitation car il envoie directement des informations à une tâche (celle qui est exécutée à distance) sur le serveur.

178

IHM (clavier, souris, écran)

Application de transfert

Programme exécuté

Application de transfert (démon)

Protocole

Client Serveur

11.2 Telnet.

11.2.1 Principe

Telnet (TELecommunication NETwork protocol) est un des premiers standard de l'Internet. Les RFC (RFC854 et RFC855) qui le décrivent datent de 1983. Il est basé sur un échange en mode connecté sur TCP via le port 23 côté serveur. C'est un protocole orienté caractère : c'est à dire que chaque caractère tapé sur le client va déclencher un échange de trames sur le réseau. C'est la condition pour avoir une interactivité complète. Il y a une authentification du client sur le shell distant mais par défaut le mot de passe circule en clair : ce n'est pas un protocole sécurisé.L'usage habituel est d'un terminal local vers une application distante avec une interface texte. On peut aussi l'utiliser de terminal à terminal ou d'application à application mais c'est très rare.

Le client telnet va avoir à gérer 4 phases dans le cadre d'une session :– Une phase de connexion au niveau TCP (3 trames échangées : SYN ; SYN+ACK ; ACK).– Une phase de négociation des options Telnet qui va permettre au client et au serveur d'utiliser les

mêmes paramètres.– Une phase d'échange où chaque caractère tapé au clavier est envoyé sur le réseau à destination du

serveur. Durant cette phase des caractères de contrôles peuvent aussi être envoyés.– Une phase de déconnexion au niveau TCP (4 trames échangées : END ; ACK ; END ; ACK).

Le tri entre les caractères venant de la console et ceux de contrôle est fait par une interface NVT (Network Virtual Terminal) qui va assurer l'interopérabilité entre machines de systèmes d'exploitation différents.

11.2.2 Le protocole Telnet

Telnet étant un protocole orienté caractère, il utilise naturellement le codage ASCII pour transmettre les caractères tapés au clavier. La PDU telnet se limite donc souvent à un seul caractère. Pour des raisons de compatibilité entre systèmes différents, les caractères de contrôle (codes ASCII entre 0x00 et 0x1F) sont interprétés par l'interface NVT et convertis de manière identique quel que soit le système d'exploitation. Pour ne pas les confondre avec des caractères standard, la plupart sont codés sur 2 octets le premier étant le code 0xFF.

179

IHM (clavier, écran)

Terminal NVT

Programme exécuté (avec interface

console)

Application NVT (démon)

Telnet Protocol

Client Serveur

a) Format NVT

La communication se fait via un terminal réseau virtuel : NVT : Network Virtual TerminalKeyboard + Printer (bi-directionnel)NVT définit une transmission homogène, les PDU sont identiques quelle que soit la machine

Prise en compte de l'hétérogénéitémécanisme de négociation d'options à la connexion

exemple : codage des caractères ASCII sur 7 ou 8 bitstelnet d'une machine Windows vers une machine Unix --> tous les caractères ASCII étendus n'ont pas la même signification

Les caractères ASCII standard (7 bits) sont transmis tels quels (de 0x20 à 0x7F)

Les premiers codes ASCII (0x00 à 0x1F) peuvent être interprétés :^C : caractère d’arrêt est transmis sous la forme :0x255 0x254 (IAC IP)

Gestion de la touche Enter (CR : carriage return)^M : retour à la ligne sous Windows (CR-LF)^M : retour en début de ligne sous UNIXOn transmet : 0x0A 0x0D (CR-LF)

NVT : commandes spécialesCodes des commandes (1er octet IAC : 0xFF)2ème octets :

0xF9 : (GA : Go ahead)0xF8 : (EL : Erase Line)0xF7 : (EC : Erase Character)0xF6 : (AYT : Are You There)0xF5 : (AO : Abort Output)0xF4 : (IP : Interrupt Process)0xF3 : (BRK : Break)0xF2 : (DM : Data Mark)0xF1 : (NOP : No Operation)

Signification des commandes spéciales :

NVT : commandes spéciales :GA (Go ahead)Envoyé si le terminal local est bloqué en attente de réponseUtilisation Serveur vers ClientExemple : fin d ’une réponse longue avec plusieurs CR-LF

IP (Interrupt Process)Fonctionnalité permettant d ’interrompre un processus utilisateur

AO (Abort Output)

180

Effacement de la fin d ’une transmission sans arrêter le processus

AYT (Are You There)Fonctionnalité permettant de savoir que le poste distant est encore actif

EC (Erase Character)Effacement du dernier caractère entré

EL (Erase Line)Effacement de la ligne courante

DM (Data Mark)Définit la fin de données hors bande dans une trame TCP avec le flag urgent positionnéExemple : IP DM

BRK : (Break)Touche Break or ATTN appuyé (hors code ASCII)?

NOP : (No Operation)

b) Négociation des options (RFC 855)

La négociation des options se fait aussi par des commandes spéciales :

Codes des commandes (1er octet IAC : 0xFF)2ème octets :

0xF0 : (SE : End of Subnegociation)0xFA : (SB : Beginning of Subnegociation)0xFB : (WILL : demande ou confirmation d’utilisation locale d ’une option)0xFC : (WON’T : refus d’utilisation locale d ’une option)0xFD : (DO : demande ou autorisation d ’utilisation distante d ’une option)0xFE : (DON’T : refus ou demande d ’arrêt d ’utilisation distante d ’une option)

3ème octet : code de l’option

Séquencement d'une demande d'utilisation d'option acceptée :– IAC WILL ABC (demande utilisation option « ABC »)– IAC DO ABC (acceptation utilisation option « ABC »)– IAC SB ABC parameters IAC SE (configuration option)

Séquencement d'une demande d'utilisation d'option refusée :– IAC WILL ABC (demande utilisation option « ABC »)– IAC DON ’T ABC (refus utilisation option « ABC »)

Différence DON ’T <-> WON ’TDemande d’utiliser une option (WILL ; DO ou DON ’T)Demande que le poste distant utilise une option (DO ; WILL ou WON ’T)

NVT : Exemples d’options

Echo : local ou distant (RFC 857)

181

IAC WILL ECHO (0xFF 0xFB 0x01)

Taille de terminalIAC WILL window size

Transmission sur 8 bits (RFC 856)IAC WILL transmit binary (0xFF 0xFB 0x00)

Interprétation des 8 bits sauf si IAC : 0x255 transmis par IAC IAC

Suppression du Go ahead (RFC 858)

Gestion de l ’envoi des états(RFC 859)

11.2.3 Exemple de fonctionnement Telnet

Un client Telnet simple est disponible sur tout les systèmes d'exploitation. Les commandes Telnet disponibles sur le client sont en général très réduites. Elles se limitent à la mise en oeuvre de la connexion et aux choix des options. Par exemple sous Windows le client telnet (lancé par telnet en ligne de commande) propose l'écran suivant :

Liste de commandes réduiteCommandes de connexion

open « nom du poste distant » : ouverture sessionclose : fermeture sessionquit : sortie du mode commande (fermeture application)?

Configurationset /unset : positionne et annule les optionsdisplay : affiche les paramètres de fonctionnement

11.3 Shell distant UNIX : rlogin, rsh.

182

UNIX étant une système d'exploitation orienté réseaux, des protocoles de connexion à distance ont été présents dès l'origine. Hormis Telnet, d'autres protocoles un peu plus complexes sont disponibles.

11.3.1 rlogin.

Rlogin (Remote Login) est présent principalement pour les systèmes de type BSD. Il propose les mêmes services que Telnet mais avec une procédure d'accès

11.3.2 rsh.

Rsh (Remote shell) permet de lancer une commande isolée sur une machine distante.

11.4 SSH

SSH (Secure Shell) propose lui aussi les mêmes services que telnet et rsh réunis mais dans un environnement sécurisé.

11.4.1 Principe général.

SSH encapsule les segments envoyés au niveau transport en y rajoutant plusieurs couches supplémentaires.

11.4.2 Mise en oeuvre.

SSH encapsule les segments envoyés au niveau transport en y rajoutant plusieurs couches supplémentaires.

11.5 X11

X11 est le protocole historique permettant de partager des fenêtres graphiques entre plusieurs machines. Implémenté sous UNIX à l'origine en lien avec l'interface graphique basé sur un relation client/serveur, il a existé des implémentations sous Windows en tant que client graphique de machines UNIX.

183

11.5.1 Principe général.

X11 est un protocole basé sur des échanges de directives graphiques. Il est donc assez contraignant d'un point de vue compatibilité.

11.6 VNC

VNC (Virtual Network Computing) est un protocole plus récent et multi-plateforme permettant d'échanger des informations graphiques.

11.6.1 Principe général.

VNC est un protocole basé sur FRB

11.7 RDP

RDP (Remote Desktop Protocol) est le protocole utilisé par Microsoft pour toutes les applications d'échange graphique. Il est basé sur des protocoles multimédia.

11.7.1 Principe général.

RDP est un protocole basé sur les recommandations ITU T.share

184

Chapitre 12 : Transfert de fichiers

12.1 Introduction.

Un transfert de fichier consiste en la copie intégrale d'un fichier d'un système de fichiers vers un autre en environnement potentiellement hétérogène. Le fichier est transféré tel quel en binaire, ou en ASCII avec adaptation au format local.Le protocole de transfert de fichiers le plus courant est FTP (File Transfer Protocol), il existe aussi un protocole allégé : TFTP (Trivial File Transfer Protocol), utilisé entre équipements moins évolués qu'un ordinateur (switch, routeur, imprimante...). Il existe d'autres possibilités soit uniquement dans le monde UNIX (rcp, scp), soit des protocoles dérivés de FTP : SFTP par exemple.

Lors d'un transfert de fichiers, il peut être nécessaire de prendre en compte l'hétérogénéité des systèmes de fichiers d'un OS à un autre et ceci à plusieurs niveaux :– dans la façon de représenter les noms de fichier (longueur,caractère espace,…)– dans la description des droits d'accès au fichier (lecture, écriture, exécution, propriétaire, …)– et enfin dans la représentation des données contenues dans le fichier (saut de ligne…)

FTP , par exemple, permet de choisir entre 2 modes :– le mode ascii : transfert au format NVT avec conversion au format local (TYPE A)– le mode binary: transfert sans conversion (TYPE I)

Le transfert de fichier est en général une interaction de type client/serveur. Le client (initiateur de la connexion) interagit avec l'utilisateur, le système de fichier local et les protocoles réseau. Le serveur (héberge les fichiers distants) interagit avec les protocoles réseau et le système de fichier distant.Il est important de ne pas confondre ces protocoles avec les protocoles d'accès aux ressources distantes (NFS, SMB...) qui eux permettent une utilisation directe des fichiers d'un poste à un autre (partage de fichiers). Dans le cas des protocoles de transfert de fichiers, il y a recopie en local du fichier, ce qui permet un protocole beaucoup plus simple.

12.2 FTP : File Transfer Protocol - RFC 959.

12.2.1 Principe

C'est le standard sur TCP/IP pour le transfert de fichiers. Il fonctionne en mode avec connexion (TCP) sur le port 21 côté serveur.

185

Il y a un contrôle d'accès au serveur distant par un couple login et mot de passe. Quoi qu'il en soit, le nom d’utilisateur et le mot de passe circule, par défaut, en clair sur le réseau.

FTP met en œuvre le transfert de fichiers via l'utilisation de 2 connexions TCP en parallèle : une Connexion de contrôle (ftp) et une connexion de données (ftp-data).

FTP : Connexions contrôle et données

Connexion de contrôle (ftp) : Elle concerne l'échange des commandes et des réponses entre le client et le serveur. C'est ce que l'on appelle un “contrôle hors-bande” (sur le port 21 côté serveur).Cette connexion est Full duplex, fiable et initiée par le client. Elle est basée sur le protocole Telnet.

Connexion de données (ftp-data) : elle concerne l'envoi de fichier ou celui de données relatives aux fichiers (liste de fichiers/répertoires. Elle est temporaire, full-duplex, avec un besoin de débit et une fiabilité plus réduite. La connexion est fermée dès que le caractère EOF est reçu.Elle est initiée par défaut par le serveur (ouverture active (connect()) du serveur vers le client (depuis le port 20 vers un port proposé par le client).

186

Serveur

Client

Interfaceutilisateur

Interfaceprotocole Client

rlogin

Interfaceprotocole serveur

Connexion deContrôle

Système defichiers

Commandesclient

Interfacesystème de

fichiers client

Interfacesystème de

fichiers serveur

Connexion dedonnées

Système defichiers

Active transfer :La connexion ftp-data est initiée par le serveurProblème de firewall ou de PAT : impossibilité de créer la connexion à partir du serveur même s'il connaît le numéro de port du client.Passive transfer : La connexion ftp-data est initiée par le clientintégré dans les navigateurs, paramétrable sur certains clientsFonctionnement : le client envoie la commande PASV au lieu de PORT sur le port 21 (RFC 1579 : Firewall-Friendly FTP) ce qui revient à demander au serveur de faire une attente sur le port 20.

Les options définies dans la RFC donne 72 façons d’échanger les données :2 types principaux de transfert– ASCII NVT : avec interprétation des codes spéciaux d’un type de machine à l’autre, moins rapide,

compatible, fichiers texte ou équivalents– Binaire : fichier tels quels, plus rapide, pas de compatibilité si formats différents, fichiers de

données bruts

12.2.2 FTP : connexion de contrôle (détail)

Il ne faut pas mélanger les requêtes ou commandes du protocole avec les commandes de l’application d’interface cliente.

Les commandes du client vont déclencher un échange de requêtes et réponses sur la connexion de contrôle en ASCII NVT. Les requêtes du protocole sont au format ASCII : texte littéral interpétable (list…)Les réponses du protocole sont au format ASCII : nombre de 3 chiffres

FTP : commandes clientesCommandes clientes (si interface texte)Pour bien comprendre les échanges, il faut connaître les commandes qui les déclenchentSouvent les applications graphiques ont une fenêtre texte pour suivre les commandes échangées

Le serveur FTP maintient un « état » : répertoires courants local et distant, usernameCommandes UNIX-like : utilisation des commandes cd, ls…En local et à distance

Quelques commandes clientesget : téléchargement d’un fichierput : envoi d’un fichierexit : arrêt de la connexionascii / binary : choix du type de transfertls : liste le répertoire distantcd : change de répertoire distantlcd : change de répertoire localuser : connexion sur un serveurpwd : répertoire distantrmdir : destruction du répertoire distant

187

Les requêtes ou commandes du protocoleA ne pas mélanger avec les commandes de l’application d’interfaceEn ASCII NVTSous-ensemble de TelnetIAC+IP : interrupt process ; IAC DM : mode urgentCommandes d’options (WILL, WONT, DO, DONT)30 commandes spécifiques FTP environ3 ou 4 caractères ASCII avec des arguments optionnels

exemple : USER jacquetexemple : STOR filename (envoi d’un fichier)

Liste des requêtes du protocole :USER username : nom d’utilisateur pour l’authentificationPASS mot de passe : authentification sur le serveurQUIT : fin de la connexion sur le serveurPORT p1, p2,p3,p4,p5,p6 : ouverture d’une connexion-datap1, p2,p3,p4 : adresse du client IP : p5,p6 : port sur le clientLIST liste de fichiers : liste des fichiers ou répertoiresRETR filename : récupère un fichier (provient de get)?STOR filename : envoi un fichier (provient de put)?ABOR : termine la commande précédente et le transfert

188

TYPE type : choix du type de transfert A ou IA : ASCII ; I : binaire

Liste des réponses du protocole :Nombre de 3 digits : xyz suivi d’un message optionnel en clair (pour un utilisateur humain)?1yz : réponse préliminaire positive, mais autre envoi2yz : réponse complète positive (nouvelle commande attendue)?3yz : réponse intermédiaire positive, attente autre commande4yz : réponse complète négative transitoire : réessayer5yz : réponse complète négative permanente : ne pas réessayer« y » a aussi une significationx0z : erreur de syntaxex3z : authentification

12.2.3 FTP : Connexions contrôle et données

Scénario d'une connexionftp serveur.univ-st-etienne.fr

(le client FTP se connecte sur le port 21 du serveur)SYNC port 21 ; ACK+SYNC ; ACK<- 220 : server ready

(Identification)-> USER jacquet + 0x0D 0x0A<- 331 password required-> PASS *******+0x0D 0x0A<- 331 login OK(retour au prompt : une commande doit être envoyée)get file.txt

(Demande création d ’une connexion ftp-data : port 4012)-> PORT 161, 3,51, 25, 40,12 (serveur va créer une connexion ftp-data depuis port 20)SYNC 4012 ; ACK+SYNC ; ACK<- 200 Port command OKAY(récupération du fichier)-> RETR file.txt<- 150 opening ASCII DATA<- envoi de données sur le port 4012<- 226 Transfert complete(Connexion ftp-data close dès que le transfert est terminé)Etc...

189

12.2.4 Sécurité sous FTP

Authentification :Le client doit avoir un compte et un mot de passe sur la machine serveur

On peut aussi limiter les accès à certains utilisateursexemple : interdiction du ftp de l’utilisateur rootSinon ftp anonymous

Autorisation d’accés :Contrôle fin possible au niveau de chaque utilisateur

Mise en œuvre avec des fichiers de configurationpar exemple :/etc/ftpusers/etc/proftpd...

190

12.3 TFTP : Trivial File Transfer Protocol.

12.3.1 Présentation.

Le protocole de transfert de fichiers TFTP est défini dans la RFC 1350. C'est un protocole léger : facilement implantable dans des systèmes sans disque (en ROM). On peut alors l'utiliser au boot pour récupérer un fichier de configuration ou un système d'exploitation plus complet (terminaux X, imprimantes réseau, routeurs Cisco…). Il sert par exemple pour les opérations de maintenance sur les équipements Cisco (sauvegarde et rechargement de la configuration, chargement de l'IOS).Il fonctionne au-dessus du protocole de trasport UDP sur le port 69.

Les différences entre TFTP et FTP sont les suivantes :TFTP ne liste pas les répertoires distantsTFTP ne nécessite pas de mot de passe pour récupérer ou déposer des fichiersLe protocole est complètement différent (TFTP protocole binaire, FTP protocole ASCII)

12.3.2 Protocole TFTP.

Il est constitué de 5 types de messages seulement :– Demande de lecture– Demande d’écriture– Données– ACK (Acknowledge : acquittement)– Erreurs

La fiabilité est assurée par un acquittement positif avec timer de retransmission sur l'émetteur et le récepteur. Les messages DATA font 512 octets maximum. Ils sont numérotés et sont aussitôt acquittés par un ACK.On ne peut faire qu'un seul tftp à la fois : il n'y a pas d’identification du transfert.

.Format des messages TFTP :

Demande de lecture (code op. : 1) ; Demande d ’écriture (code op. : 2)

Données :

191

1 octetn octets 1 octetn octetsCode op. : 2 octets

Demande delecture/écriture

Nom du fichier 0x00 Mode 0x00

2 octets 512 octets maxiCode op. : 2 octets

DonnéesCode op. : 3

Numéro de bloc Octets de données

ACK :

Erreurs :

12.3.3 Mise en œuvre

Suite des opérations :– demande de lecture (ou écriture)– Echange de blocs de 512 octets avec confirmation à chaque bloc– Echange du dernier bloc (<512 octets), confirmation

Si erreur arrêt de l’échange ou retransmission du paquet si pas de confirmation

Sécurité : pas d'authentification, les accès sur le serveur sont limités à des zones du disque.Sous Linux les répertoires accessibles sont passés en arguments du démon tftpd (/tftpboot par défaut)

192

2 octetsCode op. : 2 octets

ACKcode op. : 4

Numéro de bloc

2 octets 1 octetn octetsCode op. : 2 octets

Erreur code op. : 5

Code d’erreur Message d’erreur 0x00

Chapitre 13 : Messagerie

électronique

13.1 Introduction.

Le fonctionnement d'une messagerie électronique est plus complexe qu'une simple relation client-serveur. En fait, c'est plutôt d'une relation client-client qu'il faut parler car l'émetteur et le destinataire d'un message électronique sont des utilisateurs. Entre ces deux clients plusieurs serveurs vont s'intercaler pour permettre l'échange du message électronique.

Plusieurs fonctions de base doivent donc se retrouver dans un système de messagerie :– La composition d’un message via un Editeur (présent dans le client)– Le transfert du poste source vers le poste destination (faisant intervenir clients et serveurs)– Le suivi et la gestion des problèmes de transmission (au niveau des serveurs)– La conversion des formats de message (client et serveur)– Mise à disposition (lecture différée sur un serveur)– Mise en page (Affichage sur le client)– Renvoi (Possibilité d’acquittement par le client)

A ces fonctions s'ajoutent maintenant des fonctions liées à la sécurité : anti-spam, anti-virus...

Un trajet complet d'un message se fait en plusieurs étapes :

193

Schéma de principe d'une transmission de message électronique

Il y a 2 entités pour réaliser ces fonctions :– Mail User Agent (UA ou MUA) qui est l'interface utilisateur d’envoi et de réception– Mail Transfer Agent (MTA) qui gère les communications et le stockage

Associé à ces deux entités, il existe plusieurs protocoles :– SMTP : UA -> MTA ; MTA<-> MTA – POP : MTA -> UA– IMAP : MTA -> UA– RFC 822 : UA <-> UA (échange virtuel, couche présentation)– MIME : UA <-> UA (échange virtuel, couche présentation)

Plusieurs cas peuvent se rencontrer.

13.1.1 Transfert simple : ordinateur vers ordinateur

UA + MTA sur la même machine Pas de protocole entre UA et MTASMTP entre les 2 MTAUtilisation la plus ancienne : mise en oeuvre par telnet sur la machine de messagerie ou plus rarement un compte de messagerie par machine.

194

ServeurClient

User Agent

Mail TransferAgent

Mail TransferAgent

RFC 822 ouMIME

Mail en attented’envoi

Utilisateur

SMTP

Mail en attentede lecture

User AgentUtilisateur

Message rédigé par l'utilisateur1

Serveur d'envoi de messages

Lecture du message par l'utilisateur2

Serveur de réception de

messages

Protocole

Protocole Protocole

Serveurs de transmission de messages

ProtocoleServeurs de transmission de messages

13.1.2 Transfert : passage par un serveur générique

Le MUA est sur la machine utilisateur et le MTA sur le serveur de messagerie SMTP.Il y a partage NFS de /var/spool/mail (répertoire de travail du MTA) du serveur pour la lecture par le MUA (En environnement 100% UNIX). Mais la gestion est délicate (partage).

13.1.3 Transfert bidirectionnel :

Transfert UA -> MTA : SMTPLecture des messages : MTA -> UA : POP ou IMAP

13.1.4 Transfert entre domaine

MTA (serveur) relais : SMTPRésolution d’adresses avec DNS (Entrée MX des fichiers de zone)

195

NFS NFSSMTP

Serveur

Client

User Agent

Mail TransferAgent

Mail TransferAgent

RFC 822 ouMIME

Mail en attente

Utilisateur

SMTP

Mail en attente

User AgentUtilisateur

SMTP

Client

Serveur

POP IMAP

ServeurClient

User Agent

Mail TransferAgent

Mail TransferAgent

RFC 822 ouMIME

Mail en attented’envoi

Utilisateur

SMTP

Mail en attentede lecture

User AgentUtilisateur

13.1.5 Historique

Les premiers usages de la messagerie électronique ont été sur le réseau Arpanet en 1982, des RFC ont été déposée pour décrire les protocoles, initialement :RFC 821 (transmission)RFC 822 (format de message)

Une normalisation de messagerie a été aussi faite par le CCITT en 1984 sous la référence X400.Basée sur unMessage Handling System, X.400 se rapproche de MOTIS (OSI). Elle est difficile à implémenter et a eu un développement faible. Le format de messagerie issu de la RFC822 reste largement plus utilisée.Des améliorations ont été apportées face aux limitations de SMTP, principalement :– MIME, pour étendre les capacités de codage– ESMTP, pour améliorer le transport

Le principe de mise en œuvre repose sur les 3 points vus précédemment :– Un protocole de communication qui va transporter les informations (éléments d'interaction et

affichage) entre le client et le serveur. Ce protocole sera plus ou moins compliqué suivant les informations qui transitent (texte ou graphique).

– Une interface côté client qui peut être seulement un programme spécifique avec un accès réseau.– Un démon côté serveur qui doit être capable de rediriger le flux d'information provenant du client

vers une application en local (de même pour le flux de retour). Ce démon doit avoir une interaction avec le système d'exploitation car il envoie directement des informations à une tâche (celle qui est exécutée à distance) sur le serveur.

13.2 SMTP.

13.2.1 Principe

SMTP (Simple Mail Transfer Protocol) est issu de la RFC 821. C'est un protocole orienté texte (ASCII) : les échange client/serveur sont donc facilement lisibles et non cryptés.

196

SMTP SMTP

POP IMAP

ServeurClient

User Agent

Mail TransferAgent

Mail TransferAgent

RFC 822 ouMIME

Mail en attented’envoi

Utilisateur

Mail en attentede lecture

User AgentUtilisateur

MTArelais

Il n'y a pas d'authentification (n'importe qui peut usurper l'identité d'une autre personne pour envoyer un message), d'où les spams. Plus récemment, des limitations ont été mise en place au sein d'un domaine, en lien avec le nom de la machine et le DNS par exemple. Il utilise le port 25 sur TCP.

L'échange Client-> serveur est basé sur des commandes de 4 lettres suivies d'informations supplémentaires. Le retour Serveur -> Client est basé lui sur un code de 3 chiffres + commentaires (le tout en ASCII).

13.2.2 Le protocole SMTP

Dans le sens Client-> serveur, il y a 5 Commandes SMTP essentielles :– HELO : identification du client (nom « fully qualified »)– MAIL (from:) : expéditeur du message– RCPT (to:) : destinataires (plusieurs lignes RCPT sont possibles)– DATA : début du message envoyé par le client (Fin du message : par <CR> <LF> . <CR> <LF>),

c'est le point tout seul qui est important !– QUIT : termine l’échange du courrier

Il existe d'autres commandes :RSET : annule la transaction ;VRFY : vérifie adresse sans envoyer de messageNOOP : test réponse serveur ;EXPN : vérifie adressesHELP : … ;TURN : inversion du sens SMTP

Les informations échangées sont au format NVT.

Exemple d'échange SMTP pour l'envoi d'un message (S pour serveur, C pour client) :

Connexion TCP port 25S: 220 Marvel comics sendmail SMTP readyC: HELO comics.dcS: 250 hello, nice to meet you comics.dcC: MAIL FROM: Batman@gotham.dc.comS: 250 OK C: RCPT TO: Superman@metropolis.dc.comS: 550 No such user here C: RCPT TO: Spiderman@marvel.comS: 250 OK C: DATA S: 354 Start mail input; end with . C: Blah blah blah... C: ...etc. etc. etc. C: .S: 250 Mail acceptedC: ...etc. etc. etc. C: .S: 250 Mail accepted

197

C: QUIT221 comics.dc delivering mailfermeture connexion TCP

Exceptionnellement, c'est un des seuls protocoles où le serveur envoie d'abord une réponse avant toute demande du client une fois la connexion sur le port 25 acceptée.Les codes de retour ont une signification bien définie (en fait les commentaires ne sont là que pour l'interface homme-machine) :– Codes en 2xx : opération réussie– Codes en 3xx : opération à continuer– Codes en 5xx : opération avec erreur

Limitations

Le codage des informations est sur 7 bits, ce qui limite les caractères utilisables.Le nom d'utilisateur (celui qui est devant le @) est limité à 64 caractères, le nom de domaine (derrière le @) est lui aussi limité à 64 caractères.Le nombre de destinataires (le nombre de ligne RCPT avant un DATA) doit être inférieur à 100.Les lignes doivent être inférieures à 1000 caractères et la taille des messages inférieure à 64Ko.

De plus, au niveau fonctionnement des Timeouts différents peuvent générer des terminaisons incohérentes. Il peut y avoir des Mailstorm (bouclages) dans le cas où l'adresse de l'émetteur sert pour créer des listes.

Retour d'erreurs

Les retour d'erreurs peuvent se faire via des messages électroniques envoyés du serveur de réception vers le MUA émetteur :

Utilisateur inconnu au sein d'un domaine connu (ou unknown local part)This is the Postfix program at host stroph.univ-st.fr.I'm sorry to have to inform you that the message returnedbelow could not be delivered to one or more destinations.<essai.essai@iut-gtr.univ-mrs.fr>: unknown user: "essai.essai »

Domaine inconnu (A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed:bourboule@aussi-cela.frunrouteable mail domain "aussi-cela.fr"

13.2.3 ESMTP

C'est une extension de SMTP plus récente (RFC 1651). Elle définit un cadre permettant de spécifier de nouvelles extensions à SMTP. Les messages commencent alors par EHLO au lieu de HELO.Il y a par exemple :– Extension : DSN (Delivery Status Notification)– paramètres supplémentaires à MAIL et RCPT– Codages : BODY=8BITMIME ou BODY=7BIT

198

– paramètres supplémentaires à MAIL et RCPT

Il est prévu une récupération de messages en attenteETRN (extraction de courrier sur un relais MX par exemple)

13.3 POP

13.3.1 Principe.

POP (Post Office Protocol) est un protocole de retrait de message entre UA et MTA. Il fonctionne sur TCP via le port 110.Les messages sont retirés du serveur et chargés dans des répertoires locaux. C'est à l'utilisateur de prévoir une sauvegarde des messages en local.L’utilisateur peut choisir de laisser une copie du message sur le serveur.Le serveur a besoin d’un espace disque suffisant pour enregistrer les messages le temps qu’ils soient retirés.Tout est rapatrié sur la machine locale. Ceci pose un problème si le débit de connexion est faible et qu'il y a beaucoup de messages de taille importante.

L'authentification est prévue dans le protocole (en clair).

13.3.2 Protocole.

Il est lui aussi basé sur des commandes sur 4 caractères pour le dialogue client vers serveur.

Commandes en ASCII :– USER : envoi du nom de login– PASS : envoi du mot de passe– STAT : nombre de mail à lire– UIDL : chargement– LIST xx : détermination du message– RETR xx : chargement du message n°:xx

Réponses en ASCII :+OK hello there+OK password required+OK logged in

13.3.3 Lien SMTP-POP

Pour que les messages reçus pas SMTP sur le serveur Mail final puissent être lus par le client MUA, il faut qu'il existe un lien entre SMTP et POP. Cela se fait sur le serveur SMTP/POP à l'aide de répertoires utilisés de manière conjointes par les 2 serveurs. Ces répertoires sont les « MailDirHome » de chaque utilisateur de messagerie enregistré. Ces répertoires peuvent être intégrés dans les répertoires utilisateurs (/home/utilisateur) ou dans une arborescence indépendante

199

(/var/mail). La première solution permettant une gestion de l'espace disque utilisateur plus simple, la seconde permettant d'isoler sur un serveur la partie messagerie du reste des services.Pour assurer une bonne synchronisation entre la réception des messages et leur lecture, des répertoires temporaires peuvent être utilisés. Il y a en général trois ou quatre répertoires associés à chaque utilisateur : ./sent (messages envoyés) ; ./tmp (stockage temporaire) ; ./new (messages reçus) : ./trash (messages supprimés mais pas détruits). Chaque message correspond à un fichier dans un de ces répertoires.

13.4 IMAP

13.4.1 Principe général.

Le protocole IMAP (Internet Message Access Protocol) date de 1986. C'est aussi un protocole de retrait de messages entre UA et MTA. Il travaille sur le port 143 en TCP.Par défaut, l'utilisateur consulte les messages, mais ne les charge pas en local, il ne récupère que les en-têtes, ce qui est beaucoup plus rapide. Le message n'est chargé entièrement que lorsque l'utilisateur veut l'afficher à l'écran. L'inconvénient associé à cet avantage, est que l'on ne peut lire un message en entier en mode déconnecté que s'il a déjà été lu. De plus l'occupation disque sur le serveur est plus importante, car les messages y restent. Mais ce dernier problème n'en est plus vraiment un pour l'instant, car la taille des messages est faible relativement à l'espace disque potentiellement attribué à un utilisateur. Toutefois, depuis quelques années une évolution de la taille des messages électroniques (de plus en plus complexes et incluant de plus en plus d'images) pourrait remettre en question cet aspect.

Un serveur IMAP utilise lui aussi l'arborescence permettant de faire le lien entre SMTP et le protocole de retrait de message. Mais à la différence d'un serveur POP, le serveur IMAP est un « vrai » serveur de fichiers où l'on peut créer de nouveaux répertoires et déplacer les messages dans des répertoires pour organiser sa messagerie.De plus, il y a un enregistrement structuré des messages. On peut organiser les « boîtes » avec plusieurs types d’utilisateurs et des modérateurs : – Ceux qui peuvent lire, écrire et effacer les messages– Ceux qui peuvent lire et écrire les messages– Ceux qui peuvent seulement lire les messages

Cela présente plusieurs avantages entre autre pour partager des messages : l’utilisateur peut s’abonner à des « boîtes », selon ses droits.Exemple : sympa2TR@univ.fr est un boîte que tous les utilisateurs peuvent lire (un ou plusieurs modérateurs peuvent effacer).Un message est envoyé à sympa2TR@univ.fr, c’est une invitation à un examen de réseaux avec un plan attaché (taille : 452Ko). Il y a 54 personnes dans la liste « sympa2TR ».Avec POP il est envoyé à tous les membres de la liste. Le serveur doit donc enregistrer plus de 25 Mo de données (54 fois la même chose).Avec IMAP, Le message est déposé dans la « boîte 2TR» (452Ko).

200

13.4.2 Mise en oeuvre.

Le protocole IMAP (RFC 3501 pour la version 4) est basé sur des principes proches de POP. Ce sont aussi des échanges client/serveur en mode ASCII qui sont réalisés avec des commandes littéralement visibles et des réponses elles aussi de type ASCII.

Les commandes sont plus nombreuses : NOOP ; LOGOUT ; STARTTLS ; AUTHENTICATE ; LOGINen mode connecté :SELECT ; EXAMINE ; CREATE ; DELETE ; RENAME ; SUBSCRIBE ; UNSUBSCRIBE ; LIST LSUB ; STATUS ; APPENDmais aussi :CHECK ; CLOSE ; EXPUNGE ; SEARCH ; FETCH ; STORE ; COPY ; UID

Les réponses sont en général de type : OK ; NO ; BAD ; PREAUTH ; BYE

Plusieurs commandes peuvent être envoyées avant réponse, ce qui implique une numérotation des échanges : un numéro d'ordre est donc inséré avant les commandes et rappelé au niveau de la réponse. Cela complique d'autant la conception des clients et serveurs IMAP, car une simple machine d'état ne suffit plus à gérer les échanges.

Exemple d'échange (modification de noms de répertoire MailBox) : C: A682 LIST "" *

S: * LIST () "/" blurdybloop S: * LIST (\Noselect) "/" foo S: * LIST () "/" foo/bar S: A682 OK LIST completed C: A683 RENAME blurdybloop sarasoop S: A683 OK RENAME completed C: A684 RENAME foo zowie S: A684 OK RENAME Completed C: A685 LIST "" * S: * LIST () "/" sarasoop S: * LIST (\Noselect) "/" zowie S: * LIST () "/" zowie/bar S: A685 OK LIST completed

C: Z432 LIST "" * S: * LIST () "." INBOX S: * LIST () "." INBOX.bar S: Z432 OK LIST completed C: Z433 RENAME INBOX old-mail S: Z433 OK RENAME completed C: Z434 LIST "" * S: * LIST () "." INBOX S: * LIST () "." INBOX.bar S: * LIST () "." old-mail S: Z434 OK LIST completed

201

13.5 Format de messages RFC822

13.5.1 Généralités

Les informations envoyées par SMTP sont juste suffisantes pour permettre l'envoi, l'acheminement et la réception des messages. Mais aucune information supplémentaire ne peut être transmise hormis dans le corps du message. Si l'on veut que ces informations supplémentaires (transmises dans le corps de message SMTP) soient utilisées par les intermédiaires et les destinataires il faut définir un format de messages pour le corps d'un courrier électronique, c'est l'objectif de la RFC822 et du format qui y est décrit. En terme de modèle en couches, cette couche peut être vue comme une couche présentation donc ajoutée avant SMTP, POP ou IMAP (couche de niveau session).

Un message est donc composé de plusieurs parties :Message = Enveloppe + Entête + Corps

L'enveloppe contient les commandes nécessaires aux MTA (SMTP ou POP ou IMAP)L'entête est une liste de champs (utilisés par les UA), c'est ce qui est défini dans la RFC 822.Le corps est le texte du message.

L'en-tête et le corps sont séparés par une ligne blanche.Les messages sont transmis et stockés à ce format. Ils sont codés en caractères ASCII 7 bits.

Concernant l'entête, la syntaxe de chaque champ est définie par :<nom du champ> : <valeur du champ>

13.5.2 En-tête

Exemples de champsTo: Destinataire(s) principal(aux)CC: Destinataire(s) de copieBCC: Destinataire de copie muette !From: Personne qui a créé le messageSender: Personne qui a effectivement envoyé le messageReceived: Lignes ajoutées par chaque MTA le long du transfertReturn-Path:chemin de retour(@expéditeur)?Date : Date & heure du transfertReply-To: @email de dest de réponseMessage-Id: Numéro de référence unique du messageIn-Reply-To: Id du message auquel se rapporte la réponseKeywords: Mots clésSubject: objet du messageX- : champs spécifiques utilisateurs ou UA

Certains champs peuvent reprendre des informations contenues dans la couche inférieure.

Exemple (entête + corps) :

Message-Id: <12345@mail.istase.org>X-Mailer: mulot version c+

202

X-blague: ceci est une blagueDate: Thu, 5 Dec 2011 09:14:32 +0000To: etudiant@mail.bvra.netFrom: jacquet@mail.istase.org Subject: présence en cours

Corps du message, bla bla

13.5.3 Caractère non ASCII dans l'en-tête

L'utilisation obligatoire de caractères ASCII 7 bits dans l'en-tête pose des problèmes, en particulier pour les messages non anglophones.

Une modification de l'en-tête a donc été proposée (RFC 1522 puis remplacée) pour permettre l'envoi de caractères non-ASCII.Le format est le suivant (il ne doit pas correspondre à une suite de caractères 7 bits que l'on peut trouver normalement dans un message) :

=? Charset ? Encoding ? Encoded-text ?=avec :charset : spécification du jeu de caractèresEncoding : méthode d'encodageEncoded-text : le texte codé (forcément assez court car on est dans l'en-tête).

Charset : jeux de caractères spécifiques à un pays (ou un clavier...)2 valeurs : us-ascii ou iso-8859-X (X = un digit) ex. : iso-8859-1

Encoding : méthode d’encodage (Q ou B) qui va transformer un code ASCII étendu en code 7 bits ou inférieur.

Q : quoted-printable pour transmettre les codes > 0x7FSyntaxe : = XY avec XY 2 digits hexadécimauxExemple : é : =E9 ; <space> : = 20 ...

B : codage en base 643 octets de texte (ASCII 8 bits) sont convertis en 4 mots sur 6 bits.encapsulés dans des octets pour la transmission. Si le texte est non multiple de 3, il y a bourrage avec le signe "=".

Exemple (QDHp : codage en base 64 en utilisant les caractères ASCII) :

A1é (ASCII étendu) -> 0x40 0x31 0xe9 (base 16) -> 0100 0000 0011 0001 1110 1001 (base 16 traduit base 2) -> 010000 000011 000111 101001 (base 2 regroupé base 64) -> 01010001 01000100 01001000 01101010 (base 64 complétée à 8 bits en additionnant 0x41) ->0x51 0x44 0x48 0x6A (octets codés hexa sont envoyés)(la valeur 0 donne le code ASCII de A… ; la valeur 26 : a … ; la valeur 63 : / ou _)

203

13.6 MIME

13.6.1 Principe

Le codage de la RFC 1522 ne s'appliquant qu'à l'en-tête, il a été proposé une extension concernant les caractères non ASCII pour le corps du message, puis aussi pour d'autres types d'objets (images, sons...). Ces extensions sont regroupées dans une nouvelle définition de format : le format MIME (Multipurpose Internet Mail Extension). Il est décrit initialement dans les RFC 1521, 1523 et de nombreuses autres (maintenant dans les RFC 2045 à 2049), puisque c'est un format extensible ou de nouveaux types peuvent être définis.

Cette extension sous son format général ne concerne que le corps du message et est donc plus large que celle pour l’en-tête, qui est inclus dans le format MIME aussi.

Ce nouveau format représente une évolution importante pour la messagerie permettant non seulement d'utiliser des caractères non ASCII standard mais d'insérer du contenu multimedia dans les messages. Il est basé sur une structure de corps multiples.

Ce fomat devant s'insérer dans un système de messagerie existant, il a du être défini en minimisant les modifications pour ne pas perturber le fonctionnement des MTA. Il se limite donc à l'ajout de nouveaux champs à l’en-tête RFC 822, le contenu du message étant alors traduit en fonction de ces champs. Il n'y a donc pas de modifications au niveau SMTP, POP ou IMAP.

5 nouveaux champs ont donc été ajoutés à l'en-tête :MIME-Version : Identifie la version MIME (toujours 1.0)Content-Type : Nature du messageContent Description : Texte décrivant le contenu du messageContent-Id : Identificateur UniqueContent-Transfer-Encoding : Encodage utilisé pour le transfert

Exemple :MIME-Version: 1.0Content-Type: multipart/alternative;Content-Description: ceci est un codage MIME

13.6.2 Content-Type

La définition du contenu du message se fait en types et sous-types :Content-Type: <type>/<sous-type>

On trouve les couples suivants :Text/Plain : texte non formatéText/Richtext : texte incluant des commandes simples de formatage (gras, souligné...)Image/Gif : image fixe au format gifImage/Jpeg : idem jpegAudio/Basic : son audibleVideo/Mpeg : vidéo au format MpegApplication/Octet-stream : Flux d’octets brutsApplication/Postscript :Document imprimable au format PostScriptMessage/Rfc822 : Message Standard Rfc822Message/Partial : Message transféré séparément en plusieurs blocs

204

Message/External-body : le message lui-même doit être recherché sur l ’internet

Des types particuliers sont aussi possibles, ce sont les types multipart où le message contient plusieurs codages :Multipart/Mixed: Parties indépendantes dans l’ordre spécifiéMultipart/Alternative: Le même message en plusieurs formatsMultipart/Parallel : Les parties doivent être lues simultanémentDigest: Chaque partie est un message RFC 822 complet.

Pour les types multipart, on définit des séparateurs :– Début par : --texte_identificateur– Changement de partie : --texte_identificateur– Fin du multipart : --texte_identificateur--

Déclaration de l’identificateur de parties :Content-Type: multipart/related; boundary="----=_NextPart_8310"

Les parties peuvent être emboîtées les unes dans les autres. Elles peuvent avoir des types différents.

Exemple : This is a multi-part message in MIME format.

Content-Type: multipart/related;boundary="----=_NextPart_001_0025_01C4F4.13BF8310"------=_NextPart_001_0025_01C4F4.13BF8310Content-Type: multipart/alternative;boundary="----=_NextPart_002_0026_01C4F4.13BF8310"------=_NextPart_002_0026_01C4F4.13BF8310Content-Type: text/plain; charset="iso-8859-1"Content-Transfer-Encoding: quoted-printablececi est un message en texte ------=_NextPart_002_0026_01C4F4.13BF8310

13.6.3 Content-Transfert-Encoding

On retrouve les choix possibles pour l'en-tête (les trois premiers) plus d'autres :– 7 bit : NVT– Quoted-Printable– Base 64 – 8bit: ASCII 8 Bits (déconseillé car incompatible RFC821), les MTA RFC821 convertiront le texte– Binary : sans formatage (déconseillé : idem précédent)

13.7 Exim4

13.7.1 Principe général.

Exim4 : MTA (SMTP) sous Linux

205

Les Fichiers de configuration sont sous /etc/exim4

La configuration d'un serveur de messagerie est complexe. Il y a plusieurs possibilités :– Fichiers découpés dans plusieurs répertoires– Un seul fichier (taille importante)

Un utilitaire : update-exim4.conf convertit ces fichiers en un seul fichier /var/lib/exim4/config.autogenerated

Linux Debian fournit un fichier supplémentaire qui contient les modifications les plus courantesupdate.exim4.conf.conf

Usage du MTA sous LinuxIl doit être lié à un DNS (enregistrements MX)Un compte mail doit correspondre à un utilisateur

On doit définir (sous Debian) :Une adresse de base : univ-st-etienne.fr

dc_other_hostname='noms mail séparés par des ;'Une interface et un port d'écoute

dc_local_interfaces='adresse IP d'écoute sur le port 25'Un répertoire de sauvegarde des mails

dc_localdelivery='maildir_home'

13.7.2 MDA (Mail Delivery Agent)

Un MDA va gérer les messages sur le serveur destination il va communiquer avec le MUA par les protocoles POP, IMAP.Sous Linux debian, il y a plusieurs paquets possiblesPOP : courier_popIMAP : courier_imapIls sont basés sur des modules complémentaires :courier_base, Authlib, authlib_userdb

Le MUA est sur le client : Thunderbird, Outlook, Eudora...

206

TP Module OptRx1

N°07 : Serveurs de messagerie (SMTP, POP,IMAP)

Objectifs du TP:Dans ce TP nous utiliserons Exim4 comme MTA (serveur SMTP par défaut de Debian). Sa

configuration est basée sur une double structure de fichiers (soit découpée, soit fichier unique) ainsi qu'un fichier (update_exim4.conf.conf) permettant sous Debian de réaliser des modifications simples.

Pour ce qui concerne le relecture des mail, deux types de protocoles seront utilisés(POP et IMAP) et donc deux types de MDA (courier_pop et courier_imap).

Enfin, deux clients de messagerie seront utilisés (ThunderBird et OutlookExpress ®) Ressources nécessaires au TP

o un PC client Windows et deux PC serveur Debian Linux (S1 et S2)o Pour mettre en œuvre la liaison physique entre ces 3 PC, vous utiliserez un

switch.

Le serveur S1 sera le MTA pour le domaine istase.fr (mail de type user@<nomS1>.istase.fr ou user@istase.fr ou user@smtp.istase.fr), S2 sera le MTA pour le domaine telecom.com. Les 2 MUA seront modélisés par la même machine (le client sous Windows) mais avec des comptes de messagerie adaptés (2 comptes de messagerie user1 et user2 sur Outlook Express et 2 comptes user3 et user4 sur Thunderbird).

Phase 1 : Configuration du serveur S1 en MTA Exim4 local

1. Sur chaque serveur Linux créer 2 utilisateurs (user1 et user2 sur S1 et user3 et user 4 sur S2) avec le script adduser.

2. Configurer exim4 (on utilisera uniquement le fichier de paramètres présent sous le répertoire /etc/exim4 : update-exim4.conf.conf ), changer les lignes :

dc_other_hostname='noms mail de la machines séparés par des ;'dc_local_interfaces='adresse IP d'écoute sur le port 25' (vide si toutes)dc_use_split_config='true' (pour utiliser si besoin les fichiers séparés)dc_localdelivery='maildir_home' (permet de créer un répertoire Maildir sous

/home/userx)3. Lancer la construction automatique du fichier de configuration d'exim4 à l’aide la commande :

update-exim4.conf. Puis lancer le démon /etc/init.d/exim4. Vous pouvez vérifier la syntaxe du fichier de configuration : exim4 -bV.

4. Lancer Outlook Express sur le PC client et créer un compte de messagerie user1 avec comme adresse mail user1@istase.fr. Mettre comme serveur sortant et entrant l'adresse IP du serveur S1.

5. Envoyer un mail à user2@istase.fr. Vérifier la bonne arrivée du mail en allant voir dans le répertoire /home/user2/Maildir.

6. Regarder la bonne exécution dans les fichiers de log (mainlog), s'il y a problème regarder aussi rejectlog.

7. Visualiser un échange complet à l'aide de Wireshark. Décrire le protocole d'envoi de messages.8. Faite un envoi similaire en utilisant le nom de la machine (on prendra smtp.istase.fr). Modifier

le fichier de configuration pour que seul ce nom là soit accepté. Visualiser les messages d'erreur.9. Remettre dans l'état antérieur.

207

Phase 2 : Configuration du serveur S2 en MTA Exim4 local et de S1 en MTA relayChapitre1 : Configurer le serveur S2 de la même manière que le serveur S1 en adaptant les indications de configurations à son domaine. Chapitre2 : Configurer le serveur S1 pour qu'il puisse aussi servir de relais à des messages à destination de S2 : dc_eximconfig_configtype='internet'

dc_relay_domain='*' (autorisation pour tous les domaines)

Chapitre3 : A partir du PC client (client de messagerie Outlook Express, compte user1), envoyer un mail à destination du compte user3@smtp.telecom.com Que se passe-t-il ? Visualiser le message dans le fichier de log. Vérifier le bien fondé par nslookup.Chapitre4 : Rajouter un fichier de zone sur S1 (db.telecom.com) pour permettre l'envoi vers S2. Vous mettrez à l'intérieur un seul enregistrement A reliant la machine smtp.telecom.com à son adresse IP (vous pourrez copier le fichier local en en changeant le nom puis rajouter dans ce nouveau fichier l'enregistrement adéquat). Bien penser aussi à rajouter la déclaration de cette zone dans le fichier named.conf.local et de modifier le fichier resolv.conv du poste S1 pour qu’il boucle sur lui-même pour les résolutions DNS.Chapitre5 : Quelles adresses mail sont actives parmi : user3@smtp.telecom.com et user3@telecom.com. Pourquoi ?Chapitre6 : Rajouter un enregistrement MX pour permettre la deuxième syntaxe.

Phase 3 : Lecture des mails par le protocole POP(1) Configurer sur le PC client, le client de messagerie Thunderbird pour qu'il récupère les mails de

l’utilisateur user3 par le protocole pop3. Vous devez récupérer les mails envoyés lors de la phase2

(2) Capturer et visualiser à l’aide d’Ethereal les paquets lors de la récupération des mails. Pour cela n'hésitez pas à renvoyer des mails à user3 à partir de user1.

(3) Les mails lus sont-ils conservés sur le serveur ? Modifier le client de messagerie pour le permettre.

Phase 4 : Lecture des mails par le protocole IMAP

1. Configurer le client Thunderbird pour qu'il récupère les mails de l’utilisateur user4 par le protocole imap4.

2. Capturer et visualiser à l’aide d’Ethereal les paquets lors de la récupération des mails. Pour cela n'hésitez pas à renvoyer des mails à user4 à partir de user1.

3. Les mails lus sont-ils conservés sur le serveur ?4. Créer via le MUA un sous-répertoire « urgent » dans l’arborescence des messages.

Comment cela est-il traduit sur le serveur imap ?

Phase 5 : Finalisation de l'infrastructure de messagerieDans cette phase, vous devez pouvoir envoyer des mails de n'importe quels utilisateurs vers

n'importe quels utilisateurs1. Configurer le serveur S2 en MTA relay2. S1 jouant aussi lors de la phase 2 de serveur DNS, ajouter la zone db.istase.fr3. Configurer les clients de messagerie de la manière suivante:

- Compte user1 sur Outlook Express (serveur sortant smtp, serveur entrant pop)- Compte user2 sur Outlook Express (serveur sortant smtp, serveur entrant imap)- Compte user3 sur Thunderbird (serveur sortant smtp, serveur entrant pop)- Compte user4 sur Thunderbird (serveur sortant smtp, serveur entrant imap)

4. Tester vos configurations par l'envoi de mails.

208

Phase 7 : Désinstallation (Phase obligatoire)

1. Sauvegarder les configurations que vous avez modifiées. Vous devez être capable à la fin du TP de reconstruire toutes les configurations très rapidement. Pour cela vous devez sauvegarder les fichiers de configurations modifiés ainsi que créer les scripts nécessaires pour reconstruire les modifications que vous avez effectuées.

2. Les configurations initiales des machines sont reconstruites au redémarrage des machines donc pour ne pas perturber les autres groupes vous devez juste arrêter les

3 PC et éteindre les écrans.

209 210

Chapitre 14 : Serveur HTTP

14.1 Introduction.

14.1.1 World Wide Web

Le Web peut être considéré comme une architecture pour accéder à des documents (de tous ordres hyperdocuments) liés entre eux et situés sur des machines distantes mais reliées par Internet.

Cette architecture est basée sur 3 éléments :• la localisation --> URL• le protocole --> HTTP• le langage --> HTML

Ce sont ses caractéristiques particulières qui en ont fait ce qu'il est actuellement :• Une interfaces graphiques très conviviale, avec de multiples formats possibles (le langage

HTML et ses successeurs permettent une description aisée)• Une très grande quantité d'informations partagées sur le réseau, ces informations sont reliées

entre elle par des liens (c'est le domaine de la localisation)• Une grande diversité des informations

Une page Web contient des “objets” :• du code HTML de base : initialement du texte avec un format de mise en forme• des images et autres objets multimédia• et surtout des liens vers d’autres pages désignés par une adresse (URL)?

Pour ce qui concerne ce cours, nous allons surtout nous intéresser aux protocoles (HTTP...) et aux problématiques de mise en œuvre.

14.1.2 Relation Client/serveur

Le protocole HTTP est un protocole Client/Serveur. Le client HTTP (navigateur ou browser) dialogue avec un serveur HTTP (serveur Web) selon le protocole HTTP.

Le client (navigateur ou browser) réalise l'interface homme-machine permettant à l'utilisateur de visualiser les pages Web et d'interagir en suivant des liens par simple click. Le document possède

211

une dimension supplémentaire (relativement aux documents standard) via les liens (notion d'hypertexte), il permet la consultation d'une information répartie.

Le serveur reçoit la demande, vérifie les autorisations et transmet l'information. Dans sa version initiale, le serveur réalise des actions simples (lecture sur disque d'un fichier HTML puis envoi). Le client, quant à lui doit réaliser toute la mise en forme en prenant en compte tous les formats supportés. Cela peut mettre en œuvre des actions complexes (affichage graphique...), l'architecture des clients actuels est souvent basés sur une base commune et des modules qui se rajoutent (plug-in…).

Schéma de principe d'une connexion HTTP

Le nom de client léger web n'est pas forcément dans ce cas bien adapté.

14.1.3 Historique

Créé au début des années 1990, HTTP est un protocole récent. Il a été conçu sur des bases simples avec des interactions réduites. C'est un protocole basé texte (les PDU sont codées ASCII est donc directement lisibles par un utilisateur). Il est basé sur des requêtes (sens client vers serveur) ou « méthodes » et des réponses (sens serveur vers client) suivant un principe semblable aux autres protocoles orienté texte (ftp, POP, SMTP...).

La version d'origine (HTTP 0.9) possédait une seule méthode : GET. Aucun en-tête n'était ajouté à la requête. Ce protocole est basé sur le port 80 en TCP. Dans cette version initiale : une requête égale une connexion TCP.

Le protocole HTTP a été amélioré en plusieurs étapes :

HTTP 1.0 : Il a permis l'introduction des en-têtes qui permettent l'échange de "méta" informations, ainsi que de nouvelles possibilités : utilisation de caches, méthodes d'authentification, …

HTTP 1.1 :Dans cette version, les connexions sont dans un mode persistant par défaut. Ce mode permet de réduire le trafic TCP car il n'y a qu'une connexion/déconnexion par chargement d'une page entière,

212

IHM (clavier, souris, écran)

Gestion des requêtes HTTP

Interface avec les ressources

disque

Ecoute et traduction des requêtes HTTP

(démon)Protocole HTTP

Client Serveur

même si elle est constituée de plusieurs fichiers sur le serveur, ce qui est la règle dans les pages actuelles.Elle a aussi permis l'introduction des serveurs virtuels (gestion de plusieurs sites par le même serveur) : la directive Host dans la requête est nécessaire pour retrouver le bon serveur.

La gestion généralisée de cache a permis une amélioration des performances. Les pages qui sont le plus souvent demandées sont conservées dans un cache, ce qui soulage le réseau et procure un accès plus rapide. Ce cache peut être situé localement ou au niveau d'un serveur relais (proxy).

14.1.4 Adressage des documents

Avant de cibler sur le protocole HTTP, il est nécessaire de bien préciser la syntaxe de description des positions des ressources. Chaque page est repérée par une adresse URL (Uniform Resource Locator). Cette adresse sert à retrouver le document parmi toutes les pages de tous les serveurs lors d'une requête GET (exemple : GET http://www.univ-st-etienne.fr/index.html) : recherche de la page index.html sur le serveur www.univ-st-etienne.fr.

De plus des URL sont aussi référencées dans les pages elle-mêmes via des liens. Ceci permet de lier les différentes ressources pour créer des hyperdocuments.

La syntaxe complète des adresses URL est précisée dans la RFC3986.

La syntaxe globale est la suivante :

<scheme>:<scheme-specific-part>

Le schéma (<scheme>) peut-être différent de http (Hypertext Transfer Protocol), par exemple, il existe aussi :ftp File Transfer protocol (transfert de fichiers)gopher The Gopher protocol (concurrent de HTTP mais quasi disparu)mailto Electronic mail addressnews USENET newsnntp USENET news using NNTP accesstelnet Reference to interactive sessionsfile Host-specific file names (fichiers locaux)

Ils ne sont pas forcément supportés par le navigateur.

La partie spécifique (<scheme-specific-part>) est séparée du schéma par le caractère « : ». Elle se compose de plusieurs éléments dont certains sont rarement utilisés(tout au moins d'un point de vue manuel) :

scheme://[username[:password]@](hostname|ip)[:port][/url-path/][?query][#fragment]

la partie spécifique commence par « // ». Certaines parties sont optionnelles ou dépendent des protocoles.

Username : premier élément optionnel, il permet de se connecter via une authentification directe dans la requête.

213

Password : le mot de passe peut être omis, mais ne peut apparaître sans nom d’utilisateur dont il est séparé par un caractère « : ».

Le séparateur @ est présent seulement s’il y a un nom d’utilisateur.De ce point de vue, il faut bien distinguer un champ vide, d’un champ omishttp://@istase.com/> : champ user vide http://istase.com/> : champ user omis

http://jacquet:@istase.com/> : utilisateur « jacquet », avec un mot de passe vide

Hostname|ip : nom ou adresse IP d’une machine, si un nom littéral est utilisé, il doit être résolu par DNS. Ce champ Hostname|ip ne peut être omis ou être vide.

Port : numéro du port (TCP ou UDP) de connexionLe port peut être omis (cas général) quand le numéro de port de destination correspond au protocole associé par défaut au schéma.Dans ce cas, le « : » entre le host et le « / » est omis (le port ne peut pas être vide).

url-path est la désignation précise de la ressource demandée. La syntaxe de ce champ dépend du schéma.Le « / » situé après le hostname ou le port n’en fait pas partie

Le champ query situé après le ? Permet de passer des informations supplémentaires dans la requête. C'est souvent une chaîne de caractères avec des affectations (exemple :?name=jacquet,surname=gerard).

Le dernier champ précédé d'un # va aussi permettre de passer des informations mais à destination du client.

L'avant-dernier champ est souvent utilisé pour identifier la personne qui clique (par exemple à partir d'un mailing ou chaque mail contient un lien différent par ce champ). Le dernier champ permet par exemple de personnaliser ce qui s'affiche sur la page lorsque l'on clique à partir d'un lien mail pour ouvrir un navigateur (du style bonjour Mr X).

Concernant l'usage des liens (URL) dans les pages Web, ceux-ci peuvent être absolus ou relatifs au répertoire de la page appelante, lors de la recherche sur le serveur.URL relative : un lien vers "images/test.gif" dans la page http://www.istase.fr/doc.html indique la ressource : http://www.istase.fr/images/new.gifRemarque : la balise HTML <BASE href="url"> permet de positionner la racine pour les URLs relatives du document.

Concernant les champs, les caractères autorisés (basés sur le code ASCII US) sont :• les lettres de a … z Il n'y a pas de différence entre majuscules et minuscules sauf dans les

noms (identifiant, mot de passe …).• les chiffres• les caractères + ; . ; - ; $ ; _ .

Certains caractères sont réservés : ; ; / ; ? ; : ; @ ; & ; = car ils sont utilisés comme séparateurs. De manière général, il faut éviter d'utiliser des caractères moins courants qui peuvent être compris différemment suivant le contexte.

214

Pour insérer un caractère où il y a doute il faut taper : %hexhex, où hexhex est le codage hexadécimal de l’octet en US-ASCII Afin de permettre un accès plus large au web, une internationalisation des noms est en cours, elle permet d'utiliser des alphabets différents (un codage ASCII y est tout de même associé : xn— puis un suite de code).

14.2 Principe du protocole HTTP.

14.2.1 Principe

HTTP : Hyper Text Transfer Protocol est un protocole régissant le dialogue entre des clients Web et un serveur. Il fonctionne sur un mode Client/Serveur simple. Une transaction HTTP comprend une demande (une requête) et une réponse.HTTP est un protocole intermédiaire situé au dessus de la couche transport en TCP (sur le port 80) : il va en général transporter du contenu HTML ou un autre contenu multimédia. Un modèle en couche d'une PDU basée sur HTTP peut être la suivante :

Ce modèle peut aider à la compréhension, mais ne correspond pas exactement aux fonctionnalités des couches session et présentation, même si HTML (ou un autre format) permet de coder du contenu, le contenu final est directement inclus dans la zone HTML, l'encapsulation est donc diffuse. Quant à HTTP, il n'a pas vraiment les fonctions d'une couche session, mais est directement lié avec l'application.

14.2.2 Format général

Le format général d'une PDU HTTP (requête/réponse) est : • le type de la requête ou de la réponse (commande ou réponse HTTP)

215

Couche « Présentation »

Couche Application

HTML...

HTTP

TCP

IP

Liaison

Physique

Application

Couche « session »

Couche Transport

• un en-tête (rfc 2616)• une ligne vide servant de séparateur• un contenu (parfois vide pour certaines requêtes), il correspond à la couche supérieure

(HTML...)

Il y a très peu de types de requêtes ou de réponses :

Les requêtes sont des commandes permettant de déclencher une action sur le serveur, elles sont transmises en ASCII, elles commencent donc par le nom de la requête (GET, PUT, HEAD...) suivi du nom de la ressource et de la version du protocole.La première ligne d'une réponse est composée d'un code sur 3 chiffres et d'une chaîne littérale précisant la signification du code (suivant le même principe que FTP, POP, SMTP...).

14.2.3 Exemples

La PDU HTTP étant en ASCII, on peut la lire directement lors de l'échange. Un échange simple peut-être le suivant :

Demande du document index.html au serveur www.istase.com :

GET /www.istase.com/index.html HTTP/1.1User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr) Firefox/3.6.15Host: www.istase.comAccept: text/html,image/gif, image/jpegKeep-Alive: 115(une ligne vide)

Réponse du serveur :HTTP/1.1 200 OKDate: Sun, 21 May 2009 17:15:01 GMTServer: Apache/2.2.8 (Debian GNU/Linux) PHP/3.0.18Last-Modified: Sun, 15 Mar 2007 21:12:12 GMTContent-Length: 154Content-Type: text/html; charset=iso-8859-1(une ligne vide)Contenu <HTML>

14.3 Format du protocole HTTP

14.3.1 Les requêtes du protocole http

Il existe peu de requêtes (méthodes) différentes dans le protocole HTTP (environ une dizaine), mais seulement 2 ou 3 sont utilisées de manière fréquente :

• Méthode GET : chargement d'un document• Méthode POST : envoi de données vers le serveur

216

• Méthode HEAD : récupération des informations sur une page sans la télécharger

D'autres méthodes qui ne sont pas souvent utilisées voire supportées par les serveurs :• Méthode OPTIONS : récupération des options de communication d'un serveur• Méthode CONNECT : liée à l'utilisation d'un proxy• Méthode TRACE : utilisée pour du test (un ping au niveau HTTP)• Méthode PUT : dépôt d'un document sur un site (à condition d'avoir les droits)• Méthode DELETE : destruction d'un document sur un site (à condition d'avoir les droits)

14.3.2 La méthode GET

C'est la méthode standard de requête d'un document. Elle permet de récupérer un fichier, une image, … sur un serveur et de l'afficher (elle peut aussi activer un script sur le serveur en lui transmettant des données). Le contenu de la requête est toujours videRéponse à GETLe serveur répond avec une ligne décrivant l'état de la requête, un en-tête et le contenu demandéSi la requête échoue, le contenu de la réponse décrit la raison de l'échec : fichier non présent, accès non autorisé, …

Trame HTTP GET (toujours sans contenu HTML) :

GET /cgi-bin/test.cgi HTTP/1.1Accept: */*Accept-Language: frAccept-Encoding: gzip, deflateUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)?Host: 192.168.1.166Connection: Keep-Alive

et la réponse :

HTTP/1.1 200 OKDate: Mon, 02 Jun 2008 15:58:31 GMTServer: Apache/2.2.3 (Debian) mod_ssl/2.2.3 OpenSSL/0.9.8cContent-Length: 90Keep-Alive: timeout=15, max=100Connection: Keep-AliveContent-Type: text/html\n\n; charset=UTF-8

<html><head><title>ISTASE</title> </head><body><h1>ISTASE TELECOM</h1></body></html>

14.3.3 La méthode POST

Elle permet de transmettre des données au serveur dans le corps de la requête. Elle est donc souvent associée à l'appel d'un script sur le serveur.Exemple :POST /cgi-bin/prog.cgi HTTP/1.1

217

User-Agent: Mozilla/4.0 (compatible;MSIE 6.0;Windows NT 5.1)?Host: localhostAccept: */*Content-type: application/x-www-form-urlencodedContent-length: 36

email=toto@site.fr&pass=toto&s=login

La réponse sera du même type que celle associée à un GET.

14.3.4 La méthode HEAD

Elle permet de récupérer l'en-tête relatif à un document. Elle permet de connaître la date de dernière modification du document (important pour les caches, JavaScript), la taille du document (pour estimation du temps d'arrivée), le type du document (le client peut sélectionner le type de documents qu'il accepte), le type du serveur (permet de faire des requêtes spécifiques selon le type du serveur).

Remarque : le serveur ne fournit pas nécessairement toutes ces informations

14.3.5 Les réponses

Les codes de réponse sont en trois parties : • version HTTP,• code de statut,• description textuelle du code

Exemples : HTTP/1.1 200 OK ; HTTP/1.1 404 Not Found

Le code est un entier sur 3 chiffres classé en catégories100-199 : message d'information200-299 : succès de la requête cliente300-399 : la requête n'est pas directement exécutable, le client doit préciser certaines choses400-499 : échec de la requête qui incombe au client500-599 : échec de la requête qui incombe au serveur (par ex. erreur d'exécution d'un CGI)

14.3.6 En-tête de requête

Un certain nombre d'informations sont transmises dans l'en-tête d'une requête, les principales sont :• Host: « nom littéral du serveur » : champ obligatoire en HTTP1.1, il permet d'identifier le

serveur dans le cas de plusieurs serveurs hébergés par la même machine(même adresse IP).• User-Agent: « description du navigateur », ce champ va permettre au serveur de choisir une

version de site adapté au client• Accept: liste des types MIME acceptés par le client (text/html,application/xml,...)• Accept-Langage: liste de langues, Accept-Charset: liste de polices, ces champs sont liés au

caractère international des pages affichées (accents, caractères spéciaux...).

218

• Accept-Encoding : méthodes de compression (compress, gzip, …) afin d'accélérer le chargement des pages, celles-ci sont compressées, le serveur doit donc savoir les méthodes de décompression acceptées par le client.

• Referer: URL d'où l'on vient, cela permet de suivre la navigation et de savoir quelle page initiale a inclus le document demandé.

• Connection: type de connexion HTTP (en général Connection: keep-alive)

D'autres champs peuvent être présents dans l'en-tête, ils sont liés aux préférences du client, donnent des informations au serveur. Ils peuvent avoir des fonctions plus complexes liées au contrôle de session même après un laps de temps important (Cookies) ou à une gestion des relais intermédiaires (caches) avec des conditions sur la réponse (If-Modified-Since, If-Unmodified-Since, If-Match).Nous en reverrons certains lors de l'étude de ces fonctionnalités.

14.3.7 En-tête de réponse

Elles vont contenir des informations sur le serveur et sur le contenu du document :• Server : type de serveur• Content-Type: type MIME du document• Date : la date et l'heure de génération de la page• Content-Length : longueur en chiffres, cela va permettre de gérer une barre de progression

lors du chargement• Content-Encoding : le type de codage• Last-Modified : date de dernière modification de la page• Transfer-Encoding: Chunked si la page est transmise avant d'être générée totalement (page

dynamique) elle est alors codée en plusieurs morceaux (taille puis données).

14.4 Cookies

HTTP est un protocole sans état, aucune information n'est conservée entre deux connexions. Cela permet d'alléger le travail du serveur HTTP. Afin de garder mémoire du passage d'un client sur un serveur, le serveur stocke des informations au niveau du client. Ceci va permettre de conserver des informations entre deux transactions via une structure de données appelée « cookie ».

Un « cookie » est une chaîne de caractères url-encodée stockée sur le disque dur du client. Ces informations sont associées à un ensemble d'URL. Le contenu du cookie est alors envoyé lors de toute requête vers l'une de ces URL.

Les cookies permettent par exemple :• de propager un code d'accès,• d'éviter une authentification lors de chaque requête,• de réaliser une identification dans une base de données,• fournir des éléments statistiques au serveur (compteurs de pages visitées par un client, …)

Les cookies permettent aussi de personnaliser les pages affichées en fonction des sites visités et sont un moyen d'espionnage du comportement du client ou plutôt de la personne qui l'utilise. Normalement un ensemble de cookies est associé à un site web et ne peut être accéder par un autre site, mais souvent des liens (publicitaires par exemple) sont insérés dans des sites tiers et permettent alors l'accès à ces cookies et donc la personnalisation de l'affichage. La conservation des informations d'un client sur un serveur peut se faire via l'adresse IP du demandeur, mais cette

219

opération reste imparfaite surtout derrière des relais (proxy...) ou via un opérateur attribuant des adresses dynamiques. Les cookies permettent donc ce stockage, ils peuvent être associés à des informations plus complètes stockées sur le serveur, mettant en cause la vie privée des individus.

D'un point de vue technique, ce mécanisme est mis en place en 2 étapes :• Installation d'un cookie sur le client par un serveur• envoi du contenu du cookie lors d'une connexion ultérieure

Installation d'un cookie sur le client :Cette opération est effectuée par la Directive Set-Cookie dans l'en-tête de réponse HTTP (envoyé lors de la première connexion).

Set-Cookie: nom=valeur; expires=date;path=chemin_accès; domain=nom_domaine; secure

Le couple nom/valeur est le contenu du cookie (seul champ obligatoire), sans espace. Le cookie devient invalide après la date indiquéepath=/pub signifie que le cookie est valable pour toutes les requêtes dont l'URL contient /pubdomain indique le nom de domaine (associé au serveur) pour lequel le cookie est valablesecure : le cookie n'est valable que lors d’une connexion sécurisée

Le serveur peut insérer plusieurs directives Set-Cookie

Utilisation ultérieure :

Pour chaque requête, le client vérifie dans sa liste de cookies s'il y en a un qui est associé à cette requête, si c'est le cas, le client utilise la directive Cookie dans l'en-tête de requête HTTP.

Cookie: nom1=valeur1; nom2=valeur2; …

Il peut exister des limitations au stockage de cookies, en terme de taille (4ko) et de nombre (300), ou de nombre par site (20). Si ce n'était le cas, une saturation du disque pourrait être réalisée par un site malveillant.

14.5 Serveur mandataire, proxy, cache

Le trafic http représente une part importante du trafic sur Internet, afin de réduire ce trafic et de diminuer le temps de réponse à une requête, l'infrastructure web utilise des sauvegardes intermédiaires (caches). Dans un même ordre d'idée, afin de canaliser et de contrôler le trafic http dans une entreprise, ce dernier est centralisé sur une machine spécifique, un serveur mandataire ou proxy. Les 2 fonctions (cache et proxy) sont souvent associées sur la même machine.

14.5.1 Serveur mandataire (Proxy)

Un serveur mandataire (serveur proxy) va relayer les requêtes d’un client spécifique vers un serveur quelconque. Toutes les requêtes vers l’extérieur passent par ce poste unique, ce qui va contribuer :

• à la sécurité (anonymat) car il n'y a pas d’adresses IP internes qui circulent sur internet, seule celle du proxy est vue de l'extérieur.

• à la surveillance (log des transactions), le proxy permet de détecter un trafic anormal (trop important, de nature interdite...), ou l'accès à des sites non autorisés.

220

• À un contrôle de l'accès web par les machines internes, le passage par un proxy (donc vers l’extérieur) peut être protégé par mot de passe, ou lié à une identification de la machine (adresses MAC, IP ou nom de machine). Le lien pouvant être fait avec un serveur DNS.

Cette fonction n'est pas réservée au protocole HTTP mais peut aussi être utilisée pour du trafic FTP ou autre.Le serveur proxy est placé en limite du réseau de l'entreprise (un peu comme un firewall) en ce qui concerne les protocoles qui doivent être interceptés.

Les relations entre le client et son proxy vont être gérées par des champs de l'en-têtes HTTP :Proxy-Authenticate, Proxy-Authorization et Proxy-Authentication-Info (rfc2617) vont permettre d'échanger une authentification initiale du poste vers le proxy.

Le champ Via permet de connaître le nom des proxy traversés.

D'autres directives peuvent être utilisées pour gérer la connexion : Proxy-Connection, Keep-Alive..., leur usage est complexe et souvent n'ont pas d'incidence sur les échanges, les paramètres des clients et serveurs prenant le dessus.

14.5.2 Cache et Proxy-cache

La consultation de pages web pouvant être assez répétitive (pages d'accueil, recul de pages, sites très consultés...), une mémorisation temporaires des pages permet d'accélérer la navigation et de diminuer le trafic réseau sur Internet. Cette mémorisation se fait dans des caches (mémoires caches) situés sur le poste hébergeant le navigateur mais aussi au niveau du proxy, ce qui permet dans ce dernier cas de mutualiser la sauvegarde de pages pour toute une entreprise.

Si cette sauvegarde locale permet d'accélérer le chargement des pages les plus couramment consultées, elle peut générer des problèmes lorsque ces pages sont générées dynamiquement ou modifiées très souvent. Le client affiche alors une version obsolète de ces pages. C'est pourquoi les navigateurs proposent toujours une fonction d'effacement du cache en cas de doute.

221

Client webHTTP

Proxy

Serveur HTTPRéseau

Interne Internet

Serveur FTP

HTTP

FTP

Client webHTTP

Proxy

Serveur HTTP

Réseau Interne Internet

Cache

Serveur FTP

Cache

HTTP

FTP

De plus plusieurs champs de l'en-tête HTTP vont permettre de gérer au mieux ce stockage temporaire.

Gestion du cache client :

Champs de l'en-tête : If-modified-since: <date> et Last-modified: <date>

Le client spécifie la date de la copie en cache dans la requête http GET par le champ if-modified-since. La réponse du serveur est vide si la copie en cache est à jour, sinon il y a retransmission simple avec une nouvelle date via le champ Last-modified.

Exemple :Requête de la page http://www.istase.com/index.htmlGET http://www.istase.com/index.html HTTP/1.1champs de l'en-têteif-modified-since: 07/04/2013autres champs de l'en-tête

Réponse si le cache est à jour :HTTP/1.1 304 Not Modifieden-tête HTTPpuis rien Réponse si le cache est obsolète :HTTP/1.1 200 OKen-tête HTTPLast-modified: 08/04/2013

contenu de la page

Gestion des caches intermédiaires :

Plusieurs champs de l'en-tête de la réponse vont permettre de renseigner les informations sur l'origine de la page (serveur origine ou cache...) :champ X-Cache : il prend 2 valeurs (HIT or MISS from nom du cache) suivant si la page a été trouvé sur le cache ou non, champ X-Cache-Lookup: idemChamp Age: il donne la date de la page dans le cache.Expires : il permet de savoir quand le cache doit obligatoirement détruire la page stockée

14.5.3 Serveur reverse-proxy

A l'inverse (!) du serveur proxy, le serveur reverse-proxy se situe côté serveurs, il va permettre de répartir les requêtes vers plusieurs serveurs tout en ayant un point d'entrée unique. Cela va permettre de diminuer la charge sur chaque serveur et de concentrer certaines fonctions sur un serveur unique (compression...). De même qu'un serveur proxy, le serveur reverse-proxy peut contribuer à la sécurité car les clients ne connaissent pas l'adresse IP des vrais serveurs. Enfin, le reverse-proxy peut être couplé à un cache, permettant de réduire le trafic réseau à l'intérieur de la ferme de serveurs et d'alléger la charge de ces derniers.

222

Infrastructure d'ensemble des interactions client/serveur Web

14.6 MIME

La diversité des formats de documents encapsulés dans une trame HTTP a été prise en compte dans le protocole à partir de la version 1.0. Les commandes MIME (Multi-purpose Internet Mail Extensions) y ont été intégrées. Elles permettent l'échange de fichiers multimédias entre machines quelconques en spécifiant le type du fichier. Les types de documents étant en perpétuelle évolution, il suffit que la machine cliente (via des add-on par exemple) puisse associer l'exécution d'une application à chaque type MIME pour pouvoir afficher ces documents. Le caractère modulaire permet de réduire la complexité des navigateurs.Le serveur positionne Content-type à partir de l'extension du document demandé (sous UNIX les liens sont contenus dans le fichier /etc/mime.types), le client va alors choisir sa méthode d'affichage en fonction de ce format.Le type MIME est composé d'un type général (text, image, audio, video, application…) et d'un sous-type (image/gif, image/jpeg, application/pdf, application/rtf, text/plain, text/html).L'usage des types MIME n'est pas propre au format HTTP, on retrouve son usage dans tous les protocoles qui nécessitent des échanges multimédia (messagerie...).

14.7 WEB interactif

14.7.1 Principe

Le développement des fonctionnalités associées au protocole HTTP a conduit les concepteurs de sites WEB à ne pas se contenter de pages statiques (issues de fichiers stockés sur le serveur) mais à modifier l'apparence et le contenu des pages en fonction de différents critères (client requérant, mise

223

Client webHTTP

Proxy

Serveur HTTP

Réseau Interne Internet

Cache

Serveur HTTP

Serveur FTP

Cache Serveur HTTP

Reverse Proxy

Cache

HTTP

FTP

HTTP

à jour immédiate de certaines informations...). Ceci a conduit à la définition de nouveaux langages (PHP...), qui ne sont pas du domaine de ce cours, quoi qu'il en soit il est important d'étudier l'incidence de ces nouvelles possibilités sur le fonctionnement des serveurs et les protocoles associés.

Deux solutions peuvent être envisagées pour parvenir à un fonctionnement dynamique des sites WEB :

• soit le client charge non seulement du code HTML, mais aussi le code de fonctions qui vont être exécutées sur le client et interagir avec les éléments locaux du poste client. Comme aucune relation ne peut être faite entre le support matériel d'exécution du client et celui du serveur, ce code doit être sous forme de langage interprété (scripts), le client devant posséder une machine virtuelle d'exécution de ce code.

• Soit le client continue de charger uniquement du code HTML, mais ce code va être généré en temps réel par le serveur à l'instant de la requête. Dans ce cas, les ressources demandées vont déclenchées l'exécution d'un programme sur le serveur, le résultat d'exécution étant alors du code HTML affichable sur le client.

Client Passif, exécution de code sur le serveur

Client Actif, le code exécuté provient du serveur

Ces 2 solutions peuvent bien entendu être mises en oeuvre simultanément.

Cette approche va permettre de construire des pages WEB mises à jour sans intervention direct du Webmaster, construite par exemple grâce à la connexion du serveur avec une base de données.

De la même manière, ceci va ajouter de l'interactivité en permettant de faire évoluer les pages en fonction d'informations renvoyées par le client (autre que le clic sur de nouveaux liens).

Lorsque les pages sont construites dynamiquement sur le serveur, la réponse peut être envoyée en plusieurs morceaux, et le début transmis avant la fin de la génération, le serveur ne peut alors pas toujours déterminer la longueur totale de la réponse. C'est pourquoi un type chunked a été créé pour

224

Client webHTTP

Serveur HTTP Exécution d'un

programme :Création du code HTML

Requête spécifique

Retour de la page HTML

Affichage

1 2

3

4

Client webHTTP

Serveur HTTP Lecture de la

page HTML et du code à

renvoyer au client

Requête générique

Retour de la page HTML avec du code spécifique

Affichage

1 2

34

Exécution

5

le champ Transfer-Encoding de l'en-tête HTTP. Chaque morceau du contenu de la trame HTTP est constitué d'une ligne comportant la taille du morceau en hexadécimal puis des données. Après les morceaux, une ligne contenant 0 et éventuellement des en-têtes supplémentaires

14.7.2 Les formulaires

Un des éléments d'interactivité et l'envoi possible de données du client vers le serveur.

L'acquisition des informations que le client peut être fait via des zones de dialogue : on construit alors un formulaire.Le formulaire n'est qu'une interface de saisie. Selon les choix de l'utilisateur, il faut y associer un traitement sur le client avec JavaScript par exemplesur le serveur par l'intermédiaire de CGI, PHP, …

Exemples d'utilisation de formulaires :• commandes, devis via Internet• moteurs de recherche• interactions avec une base de données

On décrit à l'aide de balises HTML les différents champs de saisieChaque zone est identifiée par un nom symbolique auquel sera associée une valeur par l'utilisateurQuand le formulaire est soumis, les couples (nom/valeur) de toutes les zones sont transmis dans la requête HTTP au serveur si ce transfert est fait par la méthode GET (car son contenu est vide). Les valeurs peuvent aussi être transmises par la méthode POST.

A chaque zone de saisie peut être associé un traitement sur le client par l'intermédiaire d'un événement JavaScript

Exemple de génération d'une zone texte d'entrée: <FORM>Enregistrement d'un utilisateur<TABLE BORDER=0><TR>

<TD>Nom</TD><TD><INPUT type=text name="nom"></TD>

</TR> </TABLE> </FORM>

Résultat

Lors de la validation du formulaire, la transmission des paramètres du formulaire se fait du client vers le serveur.

225

Enregistrement d'un utilisateur

Nom

Comme le contenu d'une requête GET est vide, les données du formulaire sont transmises via l'URL après un ? Exemple : GET /ma-page/form_zonetext.html?nom=jacquet HTTP/1.1

Ici, le champ de la zone texte est transmis dans la requête (un mot de passe éventuel est transmis en clair !). Les champs multiples sont séparés par un & :

GET .....?nom=jacquet&prenom=gerard HTTP/1.1

Cela permet de conserver dans un bookmark les données saisies dans le formulaire. Une limite est que l'URL a une taille maximum de 4Ko.

Exemple : Génération d'une liste déroulante avec bouton d'envoi:

<FORM> Enregistrement d'un utilisateur<TABLE BORDER=0><TR><TD>Fonction</TD><TD><SELECT name="fonction"><OPTION VALUE="enseignant">Enseignant</OPTION><OPTION VALUE="etudiant">Etudiant</OPTION><OPTION VALUE="ingenieur">Ingénieur</OPTION><OPTION VALUE="touriste">Retraité</OPTION><OPTION VALUE="autre">Autre</OPTION></SELECT></TD></TR><TR><TD COLSPAN=2><INPUT type="submit" value="Envoyer"></TD></TR></TABLE></FORM>

14.7.3 Scripts CGI (Exécution sur le serveur).

Un des premiers outils pour créer des pages dynamiques a été l'utilisation de scripts CGI (Common Gateway Interface).Les scripts CGI définissent une interface de base permettant la communication entre le serveur HTTP et un programme d'application.

CGI spécifie comment des navigateurs clients peuvent communiquer avec des programmes qui s'exécutent sur le serveur Web et qui génèrent des pages HTML dynamiques créées à la volée à partir du résultat des exécutionsUn programme CGI est un programme exécuté sur la machine hébergeant le serveur HTTP, en langage compilé (binaire) ou interprété (script), en fait toute commande lancée par une fenêtre terminal du système d'exploitation. Pour construire la page web de retour, il y a redirection de la sortie standard du programme vers la page créée.

Un script CGI permet aussi de récupérer les données du formulaire à l'aide d'un parser : pour chaque champ, un couple NAME/VALUE est transmis au serveur, il effectue des traitements (lecture/écriture dans une base de données, stockage d'une information (compteurs, identifiant de

226

connexion, …). Ensuite le script CGI va générer un résultat qui est renvoyé au client : page HTML, image, document postcript, …

Les scripts CGI sont un outil puissant mais dangereux car il permet d'exécuter tout et n'importe quoi par le démon HTTP du serveur, à condition que le script soit sur le serveur.Un CGI doit s'exécuter rapidement car il y a risque de surcharge du serveur : pendant que le CGI s'exécute, le client attend la réponse sans savoir pourquoi elle n'arrive pas…Il ya toutefois possibilité d'envoyer dès le début de l'exécution une page qui permet d'indiquer à l'utilisateur que le résultat va arriver

Exemple de script :

#! /bin/sh# Date.cgiecho 'Content-type: text/html'echo ' '#Création du corps du documentecho '<HTML><HEAD><TITLE>'echo 'Date.cgi'echo '</TITLE></HEAD><BODY>'echo '<H1>Date sur le serveur</H1>'echo -n "On est le `date +%D`, il est "echo "`date +%H`h `date +%M`m"echo '</BODY></HTML>'

Réponse du serveuristase@test:~/public_html/ cgibin$./Date.cgiContent-type: text/html

<HTML><HEAD><TITLE>Date.cgi</TITLE></HEAD><BODY><H1>Date sur le serveur</H1>On est le 09/04/13, il est 11h30m</BODY></HTML>

Affichage sur le client de l’exécution du CGI :

227

Date sur le serveur

On est le 09/04/13, il est 11h30

Dans ce cas, le programme CGI n'utilise aucune donnée en provenance du client, il récupère simplement la date sur le serveur et affiche sur sa sortie standard le code d'une page HTML minimale contenant la date et l'heure.La ligne "Content-type: text/html" est une information destinée au serveur pour la construction de l'en-tête HTTP constituant la réponse renvoyée au client (ici, il s'agit d'indiquer que le type des données générées par le CGI est une suite de commandes HTML).

14.7.4 PHP : Exécution sur le serveur

Il est possible de mettre un œuvre une exécution sur le serveur basée sur un langage complet, contrairement au CGI qui utilise des utilitaires internes au serveur. Par exemple, un module PHP (Hypertext Preprocessor) correspond à un véritable langage générant des pages Web. L'interpréteur PHP est un composant du serveur WEB. Il va permettre de mettre en place une interaction complète avec les ressources du système serveur (lecture de fichiers, accès base de données...). Au même titre que les scripts CGI, il peut représenter une faille de sécurité sur le serveur.

14.7.5 Javascript : exécution sur le client

Afin de permettre une interactivité plus immédiate (sans rechargement de pages), il est possible de charger du code exécutable sur le client. Ce code est associé à une partie de la page (formulaire) et permet une évolution des pages (vérification des entrées, calculs locaux...). Un outil très utilisé est le Javascript qui définit des scripts sur le client. Le code est chargé à partir du serveur mais exécuté sur le client. Cela peut générer des problèmes de sécurité car le client ne voit pas directement le contenu du code.

14.8 APACHE

14.8.1 Principe général.

Apache est un des serveurs HTTP (serveurs Web) les plus connu. Il existe des versions sous Linux, ainsi que des versions adaptées pour Windows. Il représente une part importante des serveurs Web installés. Sur les 600 millions de sites web (statistiques netcraft 2012), Apache est le plus représenté (360 millions) devant IIS de Microsoft (80 millions) et loin devant nginx (serveur libre d'origine russe) et le serveur web de google et des concurrents asiatiques.

Apache est présent (voire activé) par défaut sur les dernières versions de Linux (CD n°1). Sa version apache2.2 est proposé sous linux debian « squeeze ».

14.8.2 Elements constitutifs d'un serveur Apache

Apache est constitué d'un certain nombre de fichiers exécutables, ceux-ci sont placés lors de l'installation dans des répertoires système (/usr/bin...). Le gestionnaire du serveur n'a pas à les modifier. Pour agir sur le fonctionnement, il a sa disposition de nombreux fichiers de configuration. Nous allons les détailler maintenant.

Fichiers de configuration d'Apache

Ils comprennent :

228

• Les fichiers de base : (apache2.conf, httpd.conf) Ils décrivent le fonctionnement général du serveur, il n'y a pas de modifications nécessaires si on travaille sur une installation simple

• Les fichiers décrivant chaque site : sous le répertoire sites-available (un fichier pour chaque site)

• Les fichiers décrivant les modules supplémentaires à ajouter : sous le répertoire mods-available (un fichier par module). Ces modules permettent de rajouter des fonctionnalités à Apache sans en modifier le code principal.

Fichiers de configuration « maître » : apache2.conf

Configuration de base d'apacheParamètres généraux (nombre de threads, langages acceptés...)Niveau de log (report des erreurs et warning)

En fait les autres fichiers de configuration sont inclus dans ce fichier principal, via des directives include en fin de fichier.

Fichiers de configuration inclus dans apache2.conf

Ils comprennent :• Les modules activés sous /etc/apache2/mods-enabled• httpd.conf : personnalisation des paramètres généraux (vide si configuration standard)• ports.conf : les ports d'écoute (directive listen)• Les fichiers sous /etc/apache2/conf.d (jeux de caractères supplémentaires...)• Les fichiers sous /etc/apache2/sites-enabled

Activation des modules supplémentaire :

Cette activation se fait par association de fichiers sous /etc/apache2/mods-available et de liens dans le répertoire /etc/apache2/mods-enabledLe répertoire mods-enabled contient des liens symboliques vers les scripts de mods-available, ce qui permet d'activer les modules à la demande en créant ou supprimant des liens sans toucher aux fichiers actifs sous /etc/apache2/mods-available.

Le répertoire mods-available contient des scripts pour charger les modules optionnels d'Apache (Directive LoadModule). Ces fichiers ont comme extensions *.load, *.conf suivant leur fonction.

L'inclusion doit être placé en début de fichier apache2.conf. Un module chargé définit de nouvelles directives dans les fichiers de configuration des sites (c'est pour cela qu'ils doivent être placés avant dans le fichier de configuration).

Choix des sites WEB actifs :

Un serveur apache peut héberger plusieurs sites simultanément. La définition des sites virtuels se fait sur le même principe que les modules supplémentaires.Les paramètres de chaque sites sont dans un fichier de configuration sous sites-available. Seuls sont activés les sites avec un lien défini dans sites-enabled en créant des liens sous le répertoire sites-enabled :

ln -s /etc/apache2/sites-available/monsite monsite

Une directive servername peut être définie pour chaque site

229

Fonctionnement et lancement d'Apache :

Apache est supporté par un ou plusieurs démons httpd. Ils sont lancés par le script : "/etc/init.d/apache2 start"

Ce script va aussi permettre de contrôler le fonctionnement d'Apache et par exemple de l'arrêter proprement (/etc/init.d/apacheZ2 stop).

Fonctionnement interne1 processus fils de httpd est créé par chaque client wwwApache fonctionne en ayant toujours un certain nombre de processus fils de libre (entre une valeur min et une valeur max)On retrouve pour cela 3 paramètres dans apache2.conf :StartServers 10 (Nb de processus lancé au démarrage d'Apache)MinSpareServers 5MaxSpareServers 10 (Nb min et max de processus libre)?

14.8.3 Directives de contrôles du serveur.

Nom d'utilisateur associé à ce service :User www-dataGroup www-data

Nom du Webmaster : ServerAdmin adresseEmailRépertoire d'Apache : ServerRoot /etc/apache2Fichiers de Log : ErrorLog répertoire/fichierNom du serveur Web : ServerName nom (Sinon résolu par DNS sur l'adresse IP propre)

Répertoire de base des fichiers html :DocumentRoot « répertoire »L'utilisateur attribué au service web doit avoir le droit de lecture sur ce répertoire

scriptAlias chemin-requete-www repertoireDéfinition d'un alias pour les scripts CGIExemple : scriptAlias /cgi-bin/ /usr/local/apache/cgi-bin/

Alias chemin-requete-www repertoireExemple : Alias /www/ /home/istase/www/

Page d'accueil (Accessible lorsqu'on précise uniquement le nom du site) :C'est normalement la racine du site Directive DocumentRootExemple : DocumentRoot /home/webdirUn fichier index.html doit être présent, sinon on liste le répertoire (ce qui n'est pas souhaitable)

Redirection vers un répertoire : Directive RedirectMatch

Définition de propriétés par répertoire

230

Directives <directory nom> et </directory>Ces directives délimitent des directives ne s'appliquant qu'au répertoire nomméExemple

<directory /www/htdocs>Options Indexes FollowSymLinks

...</directory>

Une autre possibilité est de positionner un fichier .htaccess dans le répertoire à contrôler (mêmes directives).

14.8.4 Contrôle

Il existe plusieurs niveaux de contrôle :• Pour tout le site• Répertoire par répertoire

Le contrôle d'accès peut se faire par nom d'hôte, domaine, adresse IP, utilisateurs...

Exemple :<directory /www/htdocs/private>order deny,allow allow from monDomaine.comdeny from all </directory>

Il faut faire attention à l'ordre d'évaluation et à la gestion du cas par défaut si aucune directive ne correspond. La gestion de ces contrôles reste tout de même un peu mystérieuse et n'a pas la logique d'une access-list. L'utilisation habituelle et de mettre la directive deny from all et de n'autoriser que ce que l'on veut avec un order deny,allow.

14.8.5 Répertoire utilisateur.

Configuration automatique de ~toto comme un alias vers un répertoire de l'utilisateur totoCe répertoire porte le même nom pour tous les utilisateursSpécifié par la directive : userDir public-htmlExemple :URL : www.serveur.com/~user1/index.html équivaut à /home/user1/public-html/index.htmlParticulièrement intéressant pour les fournisseurs internet pour supporter des sites web personnel (ils sont alors stockés dans une zone accessible en w pour l'utilisateur).

14.8.6 Authentification

L'authentification peut se faire par un couple username/password. C'est une authentification en interne à apache :Directive : AuthUserFile /usr/local/etc/httpd/conf/usersCette directive définit le fichier qui contient la liste des utilisateurs avec leur password (crypté).

Directive : AuthGroupFile /usr/local/etc/httpd/conf/group

231

Identique pour les groupes d'utilisateurs

Directive : AuthType BasicType d'authentification (Basic uniquement pour http 1.0)

Directive : require valid userAutorisation pour un usernameDirective : require user <liste d'utilisateur>Permet de définir des conditions à satisfaire pour chaque ressource (répertoire)Exemple : require user userweb1

Il y a 2 phases : authentification puis autorisation

Authentification externe : On peut utiliser un mécanisme externe pour l'authentification et l'autorisation, par exemple Ldap...Directive AuthBasicProvider ldap

14.8.7 Fichiers .htaccess

Le fichier .htaccess est placé dans le répertoire dans lequel il doit agir. Il agit ainsi sur les permissions du répertoire qui le contient et de tous ses sous-répertoires. Un fichier .htaccess est composé de deux sections :

1. Une première section contient les chemins vers les fichiers contenant les définitions de groupes et d'utilisateurs :

o AuthUserFile /repertoire/de/votre/fichier/.FichierDeMotDePasseo AuthGroupFile /repertoire/de/votre/fichier/.FichierDeGroupeo AuthName "Accès protégé"o AuthType Basic

� AuthUserFile définit le chemin d'accès absolu vers le fichier de mot de passe.

� AuthGroupFile définit le chemin d'accès absolu vers le fichier de groupe.

� AuthName entraîne l'affichage dans le navigateur Internet de : « Tapez votre nom d'utilisateur et votre mot de passe. Domaine: "Accès protégé" »

� AuthType Basic précise qu'il faut utiliser AuthUserFile pour l'authentification.

2. Une seconde section contient la définition des conditions d'accès :

o <Limit GET POST>o Require valid-usero {instruction d'accès à satisfaire }o </Limit>

� La balise LIMIT possède en attribut la valeur GET (en majuscule) et/ou la valeur POST, afin de définir le type de méthode du protocole HTTP auxquelles la restriction s'applique

232

� require valid-user précise que l'on autorise uniquement les personnes identifiées. Il est également possible de préciser explicitement le nom des personnes autorisées à s'identifier : require user {username}

14.8.8 Type MIME.

Un type MIME est associé à chaque objet transmis via Http. Lorsqu'un navigateur demande un objet à un serveur www, celui ci le transmet en indiquant son type MIME dans une directive content-typeLa spécification des types MIME se fait dans mime.types.mime.types : fichier commun pour toutes les applications utilisant un type MIMEFichier situé dans le répertoire /etcPour d'ajouter un type MIME : il faut modifier ce fichier et il faut avoir le module qui permet le codage/décodage.

Apache autorise le transfert de fichiers codés, par exemple les fichiers compressés.Directive spécifiant le type de codage : AddEncoding x-gzip gz

Tout fichier d'extension gz sera ensuite transmis avec une entêteEncoding-type x-gzipLes navigateurs récents savent alors qu'il faut décompacter le fichier avant de l'afficher.

14.8.9 CGI : Common Gateway Interface

Les CGI sont soit dans un répertoire particulier (via commande scriptalias) soit dans le même répertoire que les fichiers html (ils ont un type MIME dédié : addtype application/x-httpd-cgi cgi).

Ils présente un problème de Sécurité : une requête CGI est exécutée par le client sur le serveur.

Solutions : • CGI étant lié à un utilisateur "nobody", il ne doit avoir que les droits strictement nécessaires• Interdire l'exécution de scripts CGI dans certains répertoires

Exemple :

#autorisation d'exécution<directory /home/htdocs/>options Indexes FollowSymLinks Includes Multiviews ExecCGIallow override none</directory>

#pas d'autorisation d'exécution<directory /home/htdocs/users>options Indexes SymLinks IfOwnerMatch Includes NoExecMultiviewsallow override none</directory>

233

14.9 Performances

Dimensionnement de serveurs WebLa performance d'un site Web dépend beaucoup plus de la bande passante des moyens de communication permettant d'accéder au serveur que du serveur lui mêmeVeillez cependant à ce que votre serveur travaille toujours en RAMLe swap sur disque détruit les performancesSolutions :augmenter la RAMdiminuer le nombre de connexions simultanées (MAxClients)?

234

OptionRX1

N°05 : Configuration d’un serveur WEB Apache2

Objectifs du TP:● Mise en œuvre d’un serveur Apache sous Debian Linux :

Ressources nécessaires au TP✔ Durant le TP, vous allez utiliser un PC client Windows, un sous Linux et un PC serveur

Debian Linux à configurer avec l’adresse IP 10.20.N°poste.N°PC.✔ Pour mettre en œuvre la liaison physique entre ces PC, vous utiliserez un switch.

Phase 1 : Configuration des PC sous Windows et Linux

1. Configurer les adresses IP avec 192.168.1.N°PC et le masque.2. Tester les accès avec un ping.

Phase 2 : Configuration de base du serveur Apache2

Chapitre1 : Où se trouve apache2 sur votre machine Linux (commande whereis apache2) ? Chapitre2 : Visualiser le contenu du répertoire /etc/apache2. Combien y a t-il de fichiers de configurations? Que contiennent les fichiers httpd.conf et ports.conf ?Chapitre3 : Ouvrir le fichier apache2.conf sans le modifier. La dernière ligne de ce fichier contient une directive Include qui vous indique le chemin du fichier de configuration que vous allez modifier. Visualiser le contenu de ce chemin. De quel type est l'élément listé 000-default dans ce chemin. Comment atteindre et visualiser le fichier de configuration default ?Chapitre4 : Lancer le service apache2 par la commande /etc/init.d/apache2 start. A chaque modification d'un des fichiers de configuration, le service doit être relancé (/etc/init.d/apache2 stop puis start ou seulement restart).Chapitre5 : Connecter vous au serveur à l'aide du PC client. Que se passe t-il? Quelle est la page active? Dans quel répertoire se trouve cette page? Est-ce conforme à ce qui est écrit dans le fichier de configuration?Chapitre6 : Créer un utilisateur webmaster avec comme home directory /home/webmasterChapitre7 : Se loguer sous webmaster par la commande su webmaster. Sous /home/webmaster créer les sous répertoires dir1, dir2 et dir3Chapitre8 : Se déloguer par la commande exit pour revenir sous root (vous pouvez connaître à chaque instant qui est logué par la commande whoami). Ouvrir le fichier default. Mettre en commentaire la ligne RedirectMatch . Modifier le répertoire des documents HTML afin qu'il pointe vers le sous-répertoire /home/webmaster.Chapitre9 : Vérifier la syntaxe de votre fichier de configuration par la commande apache2 -tChapitre10 : Connecter vous au serveur à l'aide du PC client. Que se passe t-il?Chapitre11 : En vous loguant en webmaster, créer sous /home/webmaster un fichier vide index.htmlChapitre12 : Reconnecter vous au serveur à l'aide du PC client. Que constatez vous? Chapitre13 : Configurez votre serveur Apache afin de réaliser plusieurs zones (dir1, dir2) dans votre serveur Web, une zone (dir1) en accès autorisé à tout le monde, une zone (dir2) dont l’accès est restreint par adresse IP.

Chaque répertoire auquel Apache accède peut être configuré spécifiquement (ceci s'applique aussi à ses sous répertoires) Le paramétrage de rep se précise dans un conteneur, ensemble de clauses situées entre les balises <Directory rep> et </Directory>

Pour un répertoire donné, dans son conteneur <Directory>, on peut préciser les hôtes dont les requêtes seront traitées, et ceux dont les requêtes seront rejetées. On précise d'abord une règle générale avec la directive order allow, deny ou l'inverse, qui précise la règle à appliquer aux machines qui figurent sur les listes explicites qui suivent les clauses allow from et deny from

235

Phase 3 : Configuration des pages personnelles des utilisateurs

1. Créer un utilisateur user1 avec comme home directory /home/user12. En vous loguant en user1 par la commande su user1, créer un répertoire public_html

sous /home/user1. Sous public_html, créer ou copier un fichier index.html.3. Visualiser le contenu du fichier /etc/apache2/mods-available/userdir.conf sans le

modifier. Ce fichier est le fichier de configuration du module qui permet de disposer ses pages personnelles directement dans son répertoire personnel sans avoir à les exporter sous le répertoire normal de publication des pages HTML.

4. Par contre pour que ce fichier soit pris en compte, il faut créer les 2 liens symboliques sous le répertoire /etc/apache2/mods-enabled avec les commandes suivantes:

ln –s ../mods-available/userdir.conf userdir.confln –s ../mods-available/userdir.load userdir.loadRemarquer le nom des répertoires: available comme disponible et enabled comme autorisé. Pour autoriser, il faut créer un lien sous /etc/apache2/mods-enabled.

1. Vérifier la syntaxe de votre fichier de configuration par la commande apache2 –t2. Relancer le service.3. Accéder au serveur en tapant dans le navigateur: http://adresse IP du serveur/~user1

Phase 4 : Protection d'un répertoire L’objectif est de protéger l'accès au site privé d'un établissement. Supposons qu'il soit

contenu dans le sous répertoire /home/webmaster/dir3. Une requête s'adressant à ce répertoire protégé provoquera l'affichage d'une boîte de dialogue par laquelle l'utilisateur devra s'authentifier (nom et mot de passe). Pour cela nous utiliserons les fichiers .htaccess.

(1) Pour la création des utilisateurs et des mots de passe, se placer dans le répertoire /etc/apache2/ et utiliser la commande "htpasswd -c users". Créer l'utilisateur user2 avec le mot de passe user2.

(2) Que contient le fichier /etc/apache2/users qui vient d'être créé par la commande ci dessus?(3) Ecrivez un fichier .htaccess dans le répertoire dir3 afin de n’autoriser que user2 à y entrer.

Recopier ce fichier dans votre compte rendu.(4) Modifier le fichier default en remplaçant AllowOverride None par AllowOverride All.

AllowOverride précise la manière avec laquelle des directives contenues dans un fichier .htaccess

seront prises en compte, si ces directives supplantent ou non celles qui sont dans le présent conteneur.

(5) Vérifier la syntaxe de votre fichier de configuration par la commande apache2 –t. Relancer le service. Connecter vous au serveur à l'aide du PC client en tapant dans le navigateur: http://192.168.1.N°IP du serveur/dir3

Phase 5 : Gestion des droits d'accès au site via un annuaire LDAP

Nous allons maintenant gérer les droits d'accès aux différentes partie du site par un annuaire LDAP.

1. Configurer le client LDAP sous le deuxième poste (serveur Apache2) en modifiant le fichier /etc/ldap/ldap.conf.

URI ldap://adresse IP du poste serveurBASE dc=istase,dc=fr

2. Tester l'interrogation LDAP à partir de ce poste distant par ldapsearch -x objectclass=*. Pourquoi cela marche-t-il sans préciser l'adresse du serveur ? Visualiser les trames échangées.

236

3. Tester un enregistrement avec la fonction ldapcompare -x DistingishName attribut:value.Visualiser les trames échangées.

4. Créer 2 répertoires sous /home/webdir, dir1 et dir_ldap dans lesquels vous mettrez des fichiers index.html identifiables. Modifier si nécessaire les caractéristiques de ces répertoires.

5. Configurer le deuxième serveur hébergeant Apache2 pour qu'il utilise l'authentification LDAP sur un répertoire particulier /home/webdir/dir_ldap. Créer un serveur virtuel en créant le fichier site_ldap sous /etc/apache2/sites-available (on pourra faire une copie du fichier default pour démarrer avec une structure minimum. Editer ce fichier et ajouter :

<Directory /home/webdir/dir_ldap>...AuthType BasicAuthBasicProvider ldapAuthName « LDAP Directory »AuthzLDAPAuthoritative offAuthLDAPURL ldap://adresseIP/dc=istase,dc=frAuthLDAPBindDN « uid=root,ou=admin,dc=istase,dc=fr »AuthLDAPBindPassword admintestRequire valid-user</Directory>

Compléter la configuration avec les valeurs nécessaires pour que le site fonctionne.

6. Rajouter un lien vers ce fichier dans le répertoire /etc/apache2/sites-enabled.7. Ajouter au serveur apache les modules dynamiques authnz_ldap.load et ldap.load en créant

des liens sous le répertoire /etc/apache2/mods-enabled vers ces fichiers contenu dans le répertoire mods-available.

8. Lancer le serveur apache.9. Tester l'accès aux différents répertoires et valider l'authentification. Visualiser les trames

échangées.10. A l'authentification obligatoire rajouter un contrôle par identification dans lequel vous

autoriserez user2 et user3 mais pas user1. Rajouter la ligne suivante dans le fichier site_ldap.Require ldap-user user2 user3

Visualiser les trames échangées. Comment se déroule les différentes phases (authentification, identification)

Phase 6 : Configuration du serveur Apache2 pour gérer les scripts CGI

1. Ecrire un script CGI, affichant un message simple.

#! /bin/shecho « content-type: text/html\n\n »echo « <HTML><Head><TITLE>Essai</TITLE></Head> »echo « <body> bonjour</body></HTML> »

Placer ce script dans le répertoire /usr/lib/cgi-bin avec une extension .cgi.

2. Vérifier la bonne exécution du script.

3. Modifier ce script afin qu'il affiche les variables d'environnement du serveur (commande env).

237

4. Autoriser uniquement l'utilisateur user1 à le lancer.

5. Visualiser les paquets envoyés par wireshark.

Phase 7 : Désinstallation (Phase obligatoire)

1. Sauvegarder les configurations que vous avez modifiées. Vous devez être capable à la fin du TP de reconstruire toutes les configurations très rapidement. Pour cela vous devez sauvegarder les fichiers de configurations modifiés ainsi que créer les scripts nécessaires pour reconstruire les modifications que vous avez effectuées.

2. Les configurations initiales des machines sont reconstruites au redémarrage des

machines donc pour ne pas perturber les autres groupes vous devez : Arrêter les 3

PC et éteindre les écrans. Attention : certains ordinateurs nécessitent que l’on

appuie sur le bouton marche/arrêt après avoir cliqué sur Démarrer���� Arrêter.

238