Flux Applicatifs HTTP

Ecole d’Ingénieurs de Genève HES-SO Session 2001 Laboratoire de transmission de données

Flux Applicatifs

Cache Web ISA Server 2000

LDAP

GAIO Pascal Filière Télécommunication

Professeur de diplôme : M. Eric Jenny

Travail en collaboration avec M. Laurent Dutheil de Pictet&Cie

Ecole d’Ingénieurs de Genève HES - SO Gaio Pascal Laboratoire de transmission de données Session 2001

Flux Applicatif 2

Introduction

Ce mémoire est divisé en trois parties bien distinctes. Les chapitre 1,2 et 3, traiteront du cache Web standard, c’est-à-dire lorsque n’importe qui se connecte sur Internet. Le but sera de déterminer quelles données seront stockées chez le client et ce que le serveur Web garde comme informations après son passage. Nous regarderons diverses commandes http qui modifient le comportement du cache du côté client. Dans une seconde partie, j’utiliserai un logiciel appelé ISA Server 2000 (Internet Security and Acceleration Server 2000) en tant que proxy et serveur de cache. Ainsi je regarderai ce qu’apporte de plus d’ajouter un proxy entre un client et un serveur, par rapport à une connexion directe entre les deux. L’installation d’un logiciel comme ISA Server, devrait théoriquement accélérer les accès aux sites Web. Mais est-ce vraiment un gain important ou est-ce simplement une mascarade comme la plupart des logiciels qui se disent accélérateurs d’accès aux sites alors qu’ils ne font que de charger en cache les liens sur les pages que l’on visite pendant que l’utilisateur ne fait rien ? Ce logiciel ISA Server 2000 fonctionne-t-il sur le même principe ? Nous démontrerons dans les chapitres 4,5 et 6 comment ISA Server 2000 fait pour accélérer les accès aux pages sur Internet. Dans une troisième partie, nous allons regarder les possibilités des annuaires LDAP. Pour cela, il va falloir étudier comment construire un annuaire et par la suite, étudier les principes qu’offre le protocole LDAP (chapitre 7 et 8). Ensuite nous allons étudier les 2 principales applications des annuaires LDAP. Soit les références sur d’autres serveurs (referall chapitre 9) et la copie de base de données (replication chapitre 10). Dans une dernière étape consacrée au protocole LDAP, j’utiliserai un Firewall CheckPoint afin de gérer des accès à un serveur Web. Ces accès seront définis sur un annuaire LDAP. Pour mon étude, j’ai utilisé le serveur LDAP iPlanet Directory Server 5.0 pour la gestion de l’annuaire.


Flux Applicatif 3

Remerciements

A mes parents, qui m’ont soutenu tout au long de mon diplôme. A M.Litzistorf, qui ma permis de faire ce diplôme dans son laboratoire. A M.Dutheil, qui m’a indiqué les points importants à étudier lors de notre entretien. A M.Jenny, professeur de diplôme qui m’a assisté durant ces trois mois. A M.Garcia, qui m’a aidé lors de la mise en place des annuaires LDAP. A tous mes collègues de diplôme pour leur aide apportée durant ces trois mois. A tous ceux avec qui j’ai pu discuter et qui m’ont apporté leurs idées.

Convention Typographique Tous les textes en italique sont des mots en Anglais. Tous les textes soulignés sont des liens vers des sites


Flux Applicatif 4

Table des Matières Chapitre 1 : Le cache Web.......................................................................... 6

1.1 Qu’est-ce que le cache ..............................................................................................................................................7 1.1.1 Les recherches d’informations..........................................................................................................................7 1.1.2 Les programmes à disposition..........................................................................................................................8 1.2 Le cache vu par le client...........................................................................................................................................9 1.2.1 Localisation du cache.........................................................................................................................................9 1.2.2 Suppression du cache....................................................................................................................................... 11 1.2.3 L’historique........................................................................................................................................................ 12 1.2.4 Le menu déroulant ............................................................................................................................................ 13 1.3 Que se passe-t-il réellement lorsque j’accède à un site sur Internet ? ............................................................ 16 1.4 Différence entre une connexion au site avec cache ou sans cache. ................................................................ 19 1.5 Rafraîchissement des pages ................................................................................................................................... 22 1.6 Voir le cache des autres utilisateurs de la même machine ............................................................................... 24

Chapitre 2 : Gestion du cache d’Internet Explorer.................................... 27

2.1 Option Never ............................................................................................................................................................ 28 2.2 L’option Automatically........................................................................................................................................... 29 2.3 L’option Every time you start internet Explorer ................................................................................................ 32 2.4 L’option Every visit to the page ............................................................................................................................ 35 2.5 Résumé de toutes les options d’ Internet Explorer ............................................................................................. 36

Chapitre 3 : Le cache vu par le serveur Web............................................ 37

3.1 Installation du serveur Web................................................................................................................................... 37 3.2 Commandes HTTP.................................................................................................................................................. 39 3.3 L’onglet HTTP Headers ......................................................................................................................................... 40 3.4 Principales commandes HTTP.............................................................................................................................. 41 3.4.1 Commande no-cache........................................................................................................................................ 42 3.4.2 Commande max-age ......................................................................................................................................... 43 3.5 Les fichiers LOG ............................................................................................................................................... 44 3.6 Conclusion ................................................................................................................................................................ 45

Chapitre 4 : ISA Server Première Partie .................................................. 46

4.1 Configuration requise............................................................................................................................................. 46 4.2 Le mode cache................................................................................................................................................... 47 4.3 Le mode Firewall .................................................................................................................................................... 47 4.4 Le mode Integrated ................................................................................................................................................. 48 4.5 Choix décidé pour l’installation............................................................................................................................ 48 4.6 Différents modes de mise en cache ...................................................................................................................... 49 4.6.1 http Caching....................................................................................................................................................... 50 4.6.2 Active Caching................................................................................................................................................... 51 4.7 HTTP 1.0 VS HTTP 1.1......................................................................................................................................... 52


Flux Applicatif 5

Chapitre 5 : ISA Server Deuxième Partie ................................................. 54 5.1 Introduction.............................................................................................................................................................. 54 5.2 Fonctionnement du Serveur ISA ........................................................................................................................... 55 5.3 Test avec un seul client et une carte Ethernet sur ISA ...................................................................................... 56 5.4 Mode http Header Frequently ............................................................................................................................... 57 5.4.1 Commande max-age envoyée par le serveur Web....................................................................................... 57 5.4.2 Cache présent valide sur le client et sur ISA avec rafraîchissement F5................................................... 58 5.4.3 Cas où le serveur Web envoi un no-cache ..................................................................................................... 60 5.4.4 Cache présent sur le client et sur ISA avec rafraîchissement ENTER...................................................... 63 5.5 Mode http Header Normally ................................................................................................................................ 63 5.5.1 Aucun cache présent sur le client mais présent sur ISA............................................................................. 64 5.5.2 Cache présent sur le client et présent sur ISA.............................................................................................. 65 5.5.3 Les autres cas ..................................................................................................................................................... 66 5.5.4 Différences entre les modes http Caching .................................................................................................... 67 5.6 Mode Active Caching ............................................................................................................................................ 68 5.7 Ajout d’un deuxième client .................................................................................................................................. 69 5.8 Fonctionnement du serveur ISA avec 2 cartes Ethernet .................................................................................. 70 5.9 Server Web Down................................................................................................................................................... 71 5.10 Les principales commandes HHTP rencontrées .......................................................................................... 72 5.11 Les fichiers LOG ............................................................................................................................................... 73 5.12 Qu’a-t-on gagné avec ISA ? ............................................................................................................................ 74

Chapitre 6 : Reverse Proxy........................................................................ 75

6.1 Installation de ISA Server en mode Reverse Proxy ........................................................................................... 76 6.2 Tests en mode Reverse Proxy ................................................................................................................................ 78 6.2.2 Connexion de deux clients sur le serveur Web............................................................................................ 80 6.3 Conclusion ................................................................................................................................................................ 81

Chapitre 7 : LDAP Principes .................................................................... 82

7.1 Les concepts de LDAP ........................................................................................................................................... 83 7.2 Les principes de LDAP .......................................................................................................................................... 83 7.3 Les annuaires LDAP ............................................................................................................................................... 85 7.4 Les choix effectués.................................................................................................................................................. 86 7.4.1 Installation du serveur iPlanet......................................................................................................................... 87 7.4.2 Installation du client ......................................................................................................................................... 87 7.5 Création de l’annuaire LDAP................................................................................................................................ 87 7.5.1 Architecture Annuaire EIG ............................................................................................................................. 88 7.5.2 Architecture Annuaire Elèves ......................................................................................................................... 88 7.5.3 Architecture Annuaire Professeurs ................................................................................................................ 89 7.5.4 Création de membres ........................................................................................................................................ 89 7.6 Conclusion ................................................................................................................................................................ 91

Chapitre 8 : LDAP Protocole .................................................................... 92

8.1 Structure de la trame du protocole LDAP ........................................................................................................... 93 8.1.1 Le champ Type.................................................................................................................................................. 93 8.1.2 Le champ Length............................................................................................................................................... 95 8.1.3 Le champ Content............................................................................................................................................. 96 8.2 Etude détaillée du paquet Search Response........................................................................................................ 97 8.3 Accès à un annuaire .............................................................................................................................................. 100 8.4 Recherches de données dans l’annuaire............................................................................................................ 101 8.5 Ajout d’un utilisateur............................................................................................................................................ 102 8.6 Delete d’une branche de l’annuaire .................................................................................................................... 103 8.7 Server LDAP Down............................................................................................................................................... 104 8.8 Connexion avec Size Limit limité....................................................................................................................... 105 8.9 Déconnexion de l’annuaire .................................................................................................................................. 107 8.10 Conclusion......................................................................................................................................................... 107


Flux Applicatif 6

Chapitre 9 : LDAP Referral .................................................................... 108 9.1 Syntaxe d’un Referral ........................................................................................................................................... 109 9.2 Les types de referrals ........................................................................................................................................... 109 9.3 Comment ajouter un referral avec iPlanet ........................................................................................................ 111 9.4 Etude d’un referral au niveau du protocole...................................................................................................... 111 9.5 Conclusion......................................................................................................................................................... 112

Chapitre 10 : LDAP Réplication............................................................. 113

10.1 Le fichier LDIF................................................................................................................................................. 113 10.2 Réplication entre serveur ................................................................................................................................ 114 10.2.1 La réplication totale (Méthode 1) .................................................................................................................. 114 10.3 Etude de protocole de la réplication totale................................................................................................... 115 10.4 Etude de protocole de la réplication des modifications ............................................................................. 120 10.5 Conclusion......................................................................................................................................................... 123

Chapitre 11 : Application LDAP............................................................. 124

11.1 Création d’un compte utilisateur ................................................................................................................... 125 11.2 Accès au serveur Web par le client ............................................................................................................... 126 11.3 Analyse d’une connexion sur le serveur Web............................................................................................. 127 11.4 Connexion avec password erroné.................................................................................................................. 131 11.5 Connexion avec un login erroné .................................................................................................................... 132 11.6 Reconnexion au serveur Web ......................................................................................................................... 133 11.7 Conclusion......................................................................................................................................................... 133

Chapitre 12 : Bibliographie..................................................................... 134


Flux Applicatif 7

Chapitre 1 : Le cache Web

1.1 Qu’est-ce que le cache

Le cache (aussi appelé antémémoire) est l'espace sur le disque dur et dans la mémoire vive (RAM) de notre ordinateur où notre navigateur enregistre les copies des pages Web consultées récemment. Le navigateur se sert du cache comme mémoire à court terme. Au lieu de télécharger une image d'un site que l’on vient de visiter, il charge l'image enregistrée du cache (chapitre 1.2.1), ce qui accélère la navigation. Le cache est donc un système conçu pour améliorer le rendement de l’utilisation d'Internet en réduisant les accès au réseau.

1.1.1 Les recherches d’informations

Avant de commencer à étudier les diverses fonctionnalités des caches, j’ai essayé de trouver de la documentation sur le sujet. Cependant, je savais que cela allait être difficile du fait qu’Internet Explorer 5.0 / 6.0 est un produit de la gamme Microsoft et la documentation que j’allais trouver serait maigre (Microsoft gardant certaines données secrètes à l’utilisateur). Après plusieurs jours de recherches, les informations collectées étaient très basiques. Les renseignements qui en ressortent sont : « comment vider le cache », « limiter la taille du cache » ou « effacer les cookies », mais rien ne montre à quels endroits sont stockés les informations du cache mis à part ceux visibles par tout le monde à travers l’explorateur Windows (Internet Temporary Files par exemple). C’est donc par une méthode de scrutation des dossiers et des registres que j’ai recherché les emplacements de ces caches. Cette méthode n’est cependant pas la meilleure parce qu’elle est longue et pénible. C’est pourquoi certains logiciels ont été créés afin de faciliter la tâches des utilisateurs. Leurs caractéristiques seront énoncées au chapitre 1.1.2. Les sites où les informations sont les meilleures à ce sujet restent : http://www.microsoft.com/ http://technet.com http://www.msdn.microsoft.com/ www.crackinguniversity2000.it (qui propose une série d’informations importantes et permet aussi d’accéder à des livres sur Internet) http://www.mnot.net/cache_docs (qui propose un document intéressant pour une première étude du cache) Une liste plus complète se trouve dans la bibliographie (chapitre 12)


Flux Applicatif 8

1.1.2 Les programmes à disposition

Afin de nous aider à mieux comprendre les phénomènes de cache sur les machines possédant Internet Explorer 5.0 (Netscape n’étant pas traité dans mon diplôme), nous avons à disposition plusieurs outils trouvés sur Internet afin de trier les informations du cache. Au niveau du cache, il n’y a pas de différences majeures entre Internet Explorer 5.0 et ses versions supérieures. En effet, certains logiciels nous permettent de voir directement les cookies qui sont présents dans notre cache tandis que d’autres nous permettent uniquement de visualiser les fichiers qui s’y trouvent. J’ai donc téléchargé plusieurs de ces logiciels qui me semblaient intéressants et les ai comparés. Voici donc la liste des logiciels trouvés et une appréciation sur leurs caractéristiques.

Nom du programme

Adresse du site

Internet Cache

Explorer

http://www.icmasterdata.com/ice.html

Commentaire : Le plus complet de tous. Il nous permet de voir en même temps les noms des sites visités, les cookies , l’emplacement sur le disque et les dates d’accès sur un même écran.

UnMozify http://www.evolve.co.uk/unmozify/

Commentaire : intéressant par le fait qu’il nous permet de visualiser toutes les pages consultées. Il nous permet aussi de voir l’heure d’accès aux pages d’un site et de mettre en archive les pages consultées. Ainsi on pourra consulter des pages d’un site même après avoir vidé le cache.

Cache

Auditor http://www.webknacks.com/download.htm

Commentaire : Version Shareware. Pas très utile à moins de l’utiliser pour trier les caches en fonctions des types de données stockées (son, image, text, etc…)

Cache Sentry http://www.mindspring.com/~dpoch/enigmatic/cachesentry.html Commentaire : Peu intéressant. Possibilité d’effacer les données en cache, y compris les cookies (option ajoutée dans Internet Explorer 6.0). Les fichiers que l’on doit enlever sont paramétrables suivant des critères de taille ou de temps d’inactivité dans le cache.

Rappel : Un cookie est un petit fichier texte envoyé par un serveur sur notre ordinateur lors de la connexion sur le site. Ce petit fichier enregistre un certain nombre d'informations du client, qui pourront être relues et modifiées ultérieurement si notre ordinateur se connecte à nouveau au serveur qui a créé le cookie en question. Il sert en quelque sorte à identifier l’ordinateur qui se connecte au site.


Flux Applicatif 9

1.2 Le cache vu par le client Dans ce chapitre, je vais montrer ce qui se passe au niveau du cache du côté client.

En effet, lorsqu’un client se connecte sur un site en tapant l’url correspondant, le serveur Web va envoyer certaines informations concernant la page à afficher outre la page en question. Ces données vont être stockées sur le disque dur du client.

1.2.1 Localisation du cache Afin de pouvoir localiser le contenu du cache du côté client, il faut permettre à l’explorateur Windows, d’afficher les fichiers systèmes ainsi que les fichiers cachés qui se trouvent sur le disque. Pour cela, il faut aller sous Tools -> Folder options -> View -> Files and Folders et cocher Show hidden files and folders et enlever la croix sur Hide protected operation system files. Lorsque le client se reconnecte sur une page qui se trouve en cache sur son disque dur, il faut que la machine sache où se trouvent ces données. En parcourant les répertoires, on voit que ces données sont stockées sous : C:/Documents and Settings/Userx/Local Settings/Temporary Internet Files Userx est l’administrator dans mon cas . Sinon c’est le nom de l’utilisateur en cours qui est présent.


Flux Applicatif 10

Cependant ce chemin peut être modifié. En effet, lorsque l’on accède aux propriétés d’Internet Explorer, nous avons plusieurs possibilités, dont une est celle qui concerne le chemin où seront stockés les données. (dans la barre de menu cliquer sur tools et Internet Options) En cliquant sur settings, on peut modifier l’emplacement du fichier où seront stockées les données du cache. L’utilisateur peut en faisant la même opération, visualiser les fichiers stockés dans le cache ou bien modifier les paramètres de mise en cache (voir chapitre 2). Dans mon mémoire, je ne parlerai que du cache au niveau http. Cependant, il faut savoir qu’au niveau du cache ftp, le comportement est identique à celui http. Lors de l’étude LDAP, j’ai constaté que les données transmises au niveau de la base de données n’étaient pas stockées chez le client. J’en déduis que pour le protocole http et ftp le fonctionnement du cache est sensiblement le même, tandis que pour le protocole LDAP, il n’y a pas de mise en cache des données.


Flux Applicatif 11

1.2.2 Suppression du cache Les données qui se trouvent dans ce répertoire Temporary Internet Files, peuvent être supprimées. Si le cache est supprimé, cela aura pour conséquence le téléchargement complet des pages visitées auparavant et dont les fichiers ont été effacés par cette opération. Pour effacer le contenu du cache, il suffit d’exécuter la procédure suivante.

Une fois cliqué sur Delete Files, il suffit de cliquer sur ok. Si l’on active l’option Delete all offline content, plus aucune page ne pourra être vue même celles qui étaient visibles offline.

Cette opération a pour effet, de vider le cache. La comparaison ci-dessous montre bien que les fichiers du cache ont été vidés.

Avant Après


Flux Applicatif 12

Cependant, comme on peut le constater, tous les fichiers textes, images, html etc… correspondant aux pages où l’on s’est connecté se sont effacés à l’exception des cookies. Les cookies ici présents doivent malheureusement être effacés manuellement. Dans la version 6.0 d’Internet Explorer, il y a une option supplémentaire qui nous permet d’effacer les cookies automatiquement, de la même manière que l’on efface le contenu du cache. Il existe pourtant encore une trace des passages sur les sites après avoir tout effacé dans ce répertoire. En effet, à chaque fois que l’on visite un url, un historique des pages visitées est remis à jour.

1.2.3 L’historique

L’historique est présent afin de stocker les pages visitées lors des anciennes sessions. Il permet non seulement de savoir l’url tapé mais aussi sur quelles pages du site et à quelle heure, l’utilisateur s’y est connecté. De plus il nous permet de savoir quelles sont les recherches qui ont été effectuées sur un moteur de recherche. (www.google.ch par exemple)

Le répertoire en question se trouve sous : C:\Documents and Settings\userx\Local Settings\History Userx est l’administrator dans mon cas . Sinon c’est le nom de l’utilisateur en cours qui est présent. Voilà ce que l’on peut y voir : En cliquant sur l’icône History, il apparaît une fenêtre à gauche dans laquelle est stockée l’historique des sites visités. A l’intérieur de ce répertoire, il y a pour chaque jour de l’année un sous répertoire afin de savoir à quelle période les sites ont été visités. Le nombre de jours de stockage est configurable dans les options d’Internet Explorer. Pour effacer l’historique, il suffit de cliquer sur Clear History dans la fenêtre « Internet Options » (voir figure de la page précédente)


Flux Applicatif 13

Je peux donc aller voir pour chaque jour, les pages consultées pour chaque utilisateur. Lorsque l’on accède à un site, ce répertoire est donc remis à jour. Ce n’est cependant pas le seul a être mis à jour en ce qui concerne l’historique. En effet, lorsque l’on navigue sur Internet, nous avons un menu déroulant qui nous facilite la tache, afin de ne pas taper entièrement l’url à chaque fois que l’on veut accéder à une page.

1.2.4 Le menu déroulant

Ce menu déroulant est la copie conforme de l’historique et est stocké dans les registres Windows contrairement à l’historique, qui lui est stocké sur le disque dur de l’utilisateur. Ces registres sont accessibles en faisant start -> run et en tapant regedt32. Dans les registres de Windows, ils se trouvent sous le registre HKEY_CURRENT_USER on Local Machine et sous HKEY_CURRENT_USER -> Software -> Microsoft -> Internet Explorer -> TypedURLs


Flux Applicatif 14

Les deux listes Sont identiques Une deuxième option existe dans ce menu déroulant. Cela s’appelle la saisie semi-automatique. Son principe consiste à taper plusieurs lettres et les sites visités avec ces premières lettres apparaissent dans le menu. Contrairement au cas d’avant, ces données sont directement issues de l’historique. En effet, lorsque j’accède à celui-ci, je vois les urls où je me suis connecté ainsi que les pages du même site que j’ai visité. Ce sont ces pages qui s’affichent lorsque je commence à taper le premières lettres, dans le menu déroulant. En résumé, les données issues de la saisie semi-automatique sont tirées de l’historique tandis que les données du menu déroulant sont tirées des registres de Windows.


Flux Applicatif 15

Les deux urls correspondent exactement. Il en est de même pour tous les autres.

Ces paramètres de la saisie semi-automatique, peuvent être modifié dans Tools -> Internet options -> Content -> Personnal informations -> AutoComplete


Flux Applicatif 16

1.3 Que se passe -t-il réellement lorsque j’accède à un site sur Internet ? Ici je résumerai les chapitres vu précédemment en faisant une démonstration de ce qui se passe lorsque je me connecte sur un site. Je ne traiterai pas de l’analyse de protocole qui sera vu dans les chapitres suivants mais simplement aux emplacements du cache après avoir visité une page. Prenons l’exemple d’une connexion au site eig.unige.ch Je fais l’hypothèse que les caches, l’historique et les registres soient vides. Dans Internet Explorer, je tape l’adresse eig.unige.ch et j’obtiens ma page.

L’étude de protocole montrera comment les paquets sont transmis entre le client et le serveur Web. Dans l’état des choses, on peut simplement dire qu’un échange de données au niveau http est présent.

Client Server Web

Get Request

Response (Data)


Flux Applicatif 17

Mais voici réellement ce qui c’est passé sans que l’on s’en aperçoive. Dans l’historique, apparaît la page que j’ai visité. Donc dans today j’aurais ma page www.eig.unige.ch J’aurai si j’ouvre le répertoire, toutes les pages sous-jacentes du site. Je vois donc la première page de mon site car je n’ai été que sur celle-ci. Ensuite, dans le Temporary Internet Files, je trouverai les fichiers chargés lors de l’accès à la page. �

� Avec la date d’expiration des fichiers dans le cache (sert à tester la validité du fichier local) � Avec la date de la dernière modification de la page (sert au serveur à savoir s’il y a eu modification sur la page entre la dernière connexion et l’heure courante) � Avec la date du dernier accès fait par le client � Avec la date de la dernière vérification faite par le client sur la page

� � � �


Flux Applicatif 18

Un dernier endroit où se stockent des informations lorsque j’accède à un site, se trouve dans les registres de Windows. Lorsque je vais voir le registre concerné, je ne voit rien. Il est vide.

En effet, il faut savoir que les données des registres se modifient uniquement lorsque la page en question est quittée. Il faut que l’on ferme Internet Explorer pour que les valeurs soient affectées. Le simple fait de quitter le site et accéder à une autre page ne suffit pas. C’est donc uniquement lorsque je quitterai Internet Explorer que mes registres seront mis à jour. Je ferme donc simplement la fenêtre du browser et le site www.eig.unige.ch apparaît dans le registre.


Flux Applicatif 19

1.4 Différence entre une connexion au site avec cache ou sans cache. A première vue, il est normal de penser que lorsque je me connecte à un site avec les fichiers de la page dans mon cache, l’affichage de celle-ci se fasse plus rapidement du fait qu’elle est chargée localement. Cependant à la suite de plusieurs essais, il s’est avéré que cela n’était pas toujours le cas. En effet il existe encore des requêtes entre le client et le serveur Web afin de vérifier si des modifications ont été faites sur le site. De plus ces temps de réponses sont sensibles à la charge sur le réseau. Il se peut que notre page se trouve déjà en cache et que celle-ci mette plus de temps à se charger que si l’on accède au site pour la première fois car la réponse du serveur Web est tardive. C’est pourquoi dans les options d’Internet Explorer, nous pouvons sélectionner divers modes de chargement de la page en fonction du cache. Ceux-ci seront détaillés dans le chapitre 2. Les tests effectués, concernent les charges engendrées sur le réseau lorsque le client possède ou non le cache et le temps que l’on met pour charger la page entièrement. Cette partie consistera à se connecter sur le site www.microsoft.com Tests dans le cas où aucun cache n’est présent sur le disque.

Essai N° Nombres de

paquets Bytes envoyés Bytes reçus Bytes échangés Temps de

chargement 1 338 19641 226965 246606 12.00 sec 2 336 18674 229141 247815 13.16 sec 3 296 17376 199843 217219 4.04 sec 4 302 17947 200429 218376 4.45 sec 5 303 18196 200052 218248 3.61 sec 6 292 16509 199843 216352 4.43 sec

Bytes envoyés = client -> serveur et bytes reçus = client <- serveur

Tests dans le cas où le cache est présent sur la machine de l’utilisateur

Remarque : Dans le cas où la date d’expiration du fichier est toujours valide dans le

cache (test du champ Expires voir chapitre 1.3), la machine ne fait aucune requête vers le site en question et charge tout localement. Le temps de chargement ainsi que la charge sur le réseau sera nulle. La validité des fichiers est définie par le programmeur du site.


Flux Applicatif 20

Date d’expiration encore valide :

Essai N° Nombres de paquets

Bytes envoyés Bytes reçus Bytes échangés Temps de chargement

n 0 0 0 0 0 Bytes envoyés = client -> serveur et bytes reçus = client <- serveur

Date d’expiration dépassée :


Nous voyons très bien ici, que le cache joue un rôle important dans le nombre de bytes échangés entre le client et le serveur. En regardant plus attentivement, les échanges entre le client et le serveur Web, on s’aperçoit que lors du premier accès (sans cache du côté client), le serveur Web dit au client de stocker en cache les données transmises. Lors d’un prochain accès, suivant le résultat du test du champ Expires, les données seront chargées du cache ou non. Voici un organigramme qui montre comment est géré le cache du côté client.

Essai N° Nombres de paquets

Bytes envoyés Bytes reçus Bytes échangés Temps de chargement

1 113 14598 29936 44534 7.17 sec 2 118 15783 30163 45946 5.89 sec 3 105 14422 25076 39498 3.41 sec 4 104 14530 20624 35154 4.18 sec 5 120 15249 30167 45416 3.33 sec 6 81 5361 14380 19741 5.95 sec

Server Web

www.microsoft.com

Fichiers stockés dans le cache expirés ?

Non. Fichiers encore valides Alors chargement de la page depuis le cache

Oui. Echange de données avec le serveur Web


Flux Applicatif 21

Une fois les premiers tests effectués, nous pouvons voir que si le cache est présent ou non sur le disque cela change quelques données. En effet, on peut voir que les bytes échangés sont réduit de 80 % si la page est présente dans le cache. Cette réduction est due en partie au client avec un gain de 20% sur les bytes envoyés et surtout grâce au serveur qui a un gain de 85% environ sur ses bytes envoyés. Suivant les pages sur lesquelles on se connecte, ces valeurs vont varier. Par exemple, lors d’une connexion au site www.hotmail.com, le gain sur les bytes échangés est de 65% (75% client, 60% serveur).

Site testé Gain total de bytes

Gain par le client

Gain par le serveur

www.hotmail.com 80 % 20 % 85 % www.microsoft.com 65 % 75 % 60 %

Cette variation dépend de la quantité des données à transmettre. En effet, plus cette quantité est importante, plus le nombre de bytes envoyés avec un cache présent chez l’utilisateur sera réduit. Ainsi le gain sera augmenté. Je voulais faire une étude plus réaliste du gain en temps, mais le réseau « Internet » de l’école étant quasiment identique en prestation que le réseau « Intranet » , je ne voyais aucune différence au niveau d’un éventuel gain de temps. C’est pourquoi je n’ai pas été plus loin dans cette étude. Cependant, malgré le gain de bytes échangés, le temps d’accès à la page n’en n’est pas réduit. En effet, ce temps de réponse est en fonction de la charge du réseau, qui elle est très variable. Pour le site de Microsoft, nous n’avons aucun gain de temps malgré un grand gain de bytes échangés. Au contraire lors de l’accès au site de Hotmail, le temps de réponse est réduit de moitié. Ceci prouve bien qu’une étude sur le temps de réponse ne peut pas être juste dans le cas où l’on accède à des sites sur Internet.


Flux Applicatif 22

1.5 Rafraîchissement des pages Lorsque l’on a déjà la page d’un site dans le cache, nous pouvons y accéder grâce à l’historique (chargement toujours effectué depuis le cache), en tapant soit l’adresse (chargement de la page dépendant des dates d’expirations) ou lorsque l’on y est déjà, faire un refresh de la page pour voir si des modifications ont été faites sur celle-ci. Cependant, le comportement du cache n’est pas le même dans tout les cas. En effet, lorsque je suis sur une page et je fais un refresh avec la touche F5, le client va faire une requête au serveur Web pour savoir si des modifications sont intervenues depuis son dernier accès. Les dates d’expiration dans ce cas n’ont plus lieu d’être.

L’échange sera du type :

Client Une requête sera automatiquement faite sur le serveur pour savoir si une modification est intervenue. La réponse retournée par le serveur sera soit Not modified (pas de modification sur le serveur Web) et la page sera chargée depuis le cache du client, soit OK (modification sur le serveur Web entre le dernier accès et l’heure courante) et les nouvelles données seront transmises par le serveur Web. Un deuxième moyen de rafraîchir une page est de retaper l’url en question. On peut même penser à quitter Internet Explorer et revenir. C’est une forme de rafraîchissement. Dans ce cas, les dates de validité des fichiers sont nécessaires. En effet, lorsque le client possède déjà la page dans son cache et que celui-ci entre un url et presse ENTER, alors ces dates vont être testées. Si elles sont encore valides, la page sera chargée du cache sinon une requête sera faite au serveur.

Server Web

Get Request If modified since (Last Modified)

Response OK ou Not modified

Cache client Pas de

requête

Refresh avec F5


Flux Applicatif 23

L’échange sera du type : Client Dans les deux cas énoncés précédemment, si la page n’a pas été modifiée sur le serveur Web, aucune donnée utile ne sera renvoyée au client. Cependant il existe un moyen de recharger la page entièrement et que toutes les données soient retransmises par le serveur Web même si aucune modification n’a eu lieu sur celui-ci. Il suffit de taper la touche Shift et F5. Client La réponse du serveur Web sera ici toujours OK. On voit que le client envoi un paramètre pragma : no-cache. Cette commande est présente, afin que le browser et le serveur Web sachent qu’il ne faut pas tenir compte du cache de l‘utilisateur. Il faut considérer qu’aucun cache (no-cache) n’est présent du côté client même si ce n’est pas le cas.

Cache client

Server Web

Les fichiers stockés dans le cache sont-ils encore valides ? Test du champ Expires


Response OK ou Not modified

Oui

Non

Server Web

Get Request If modified since (Last Modified) Pragma : no-cache

Response OK Pragma : no-cache

Cache client Pas de

requêtes

Refresh avec ENTER

Refresh avec Shift + F5


Flux Applicatif 24

1.6 Voir le cache des autres utilisateurs de la même machine Une question vient à l’esprit lorsque plusieurs utilisateurs sont sur une même machine à des moments différents. Est-ce qu’il se peut que l’un bénéficie du cache de l’autre ? Pour répondre à cette question, j’ai fait un test en me connectant au site www.hotmail.com et j’ai testé la charge du réseau lorsque le cache est présent ou non sur le disque dur de la machine, mais à un autre endroit que dans le cache de l’utilisateur qui à la session courante. Par exemple, dans le cache d’un autre utilisateur. Tests dans le cas où le cache n’est pas présent dans le répertoire de l’administrateur et l’on se connecte sans cache chez le user

Essai N° Nombres

de paquets Bytes envoyés Bytes

reçus Bytes échangés Temps de



Tests dans le cas où le cache est présent dans le répertoire de l’administrateur et l’on se connecte sans cache chez le user

Essai N° Nombres

de paquets Bytes envoyés Bytes

reçus Bytes échangés Temps de


Bytes envoyés = client -> serveur et bytes reçus = client <- serveur A l’aide de ces mesures on se rend bien compte qu’un autre utilisateur qui possède déjà le cache de la page accédée, n’affecte en rien les performances de l’utilisateur avec la session courante. De ce fait l’utilisateur connecté ne fera aucun gain de temps ni de charge sur le réseau si un autre utilisateur local possède dans son cache la page demandée. J’en conclus donc que le cache soit présent ou non chez un autre utilisateur connecté sur la même machine ne change en rien dans le cache de l’autre utilisateur. Ils sont donc complètement indépendants. Afin de vérifier cela, je vais essayer de me connecter sur un utilisateur existant et de voir son cache depuis le compte administrateur (sur la même machine).


Flux Applicatif 25

Lorsque je me connecte sur la machine avec le compte administrateur, j’ai la possibilité de voir tous les fichiers des utilisateurs sans restriction aucune. C’est pourquoi, normalement, lorsque je vais voir sous C:/Documents and Settings/Administrator/Local Settings/Temporary Internet Files, je dois voir mes fichiers stockés dans le cache. En outre lorsque je vais voir sous C:/Documents and Settings/Userx/Local Settings/Temporary Internet Files, je dois voir les fichiers stockés dans le cache du Userx. Cache de l’administrateur Cache de UserX

En regardant bien les deux caches, on constate qu’ils sont identiques.

En réalité, le répertoire C:/Documents and Settings/userx/Local Settings/Temporary Internet Files est remapé vers le répertoire identique mais qui appartient au compte courant. Ceci est certainement fait pour des questions de confidentialité. De ce fait même en ayant les droits ou en s’étant procuré les droits administrateur, il est impossible de voir le cache d’un autre utilisateur. Pour mieux comprendre ce phénomène, j’ai fait une représentation graphique des différents cas présentés tout au long de ce sous-chapitre.

Cache user X Cache user Y Cache user Z Connexion Administrateur Cache Administrateur

Machine A

Si j’essaye depuis le compte administrateur de visualiser le cache d’un utilisateur, je verraitoujours le cache du compte courant


Flux Applicatif 26

De plus, j’ai essayé de me connecter depuis une machine distante sur une machine dont je connaissais le mot de passe de l’administrateur et j’ai regardé le cache d’un utilisateur. J’ai remarqué que le même phénomène se produisait. Soit que je voyais le cache de la personne qui était connectée en ce moment sur la machine sur laquelle est effectuée la requête. Connexion à distance Compte administrateur Caches identiques, on a une image du cache de la machine A

En outre j’ai essayé de partager le répertoire Internet Temporary Files où est stocké le cache d’un utilisateur. Lorsque je me connecte à distance sur cet utilisateur pour visualiser le contenu de ce fichier, j’obtiens le même résultat que précédemment. Soit que le répertoire est remapé et c’est le contenu de ma machine qui s’affiche. A la suite de ces diverses études, j’en conclu finalement que le cache est indépendant entre chaque utilisateur et en plus, un utilisateur ou administrateur n’a pas le droit de voir le cache d’un autre. Cependant, ces résultats me surprennent. En effet, j’imagine mal dans le réseau d’une entreprise, qu’aucune personne ne puisse voir le cache de la personne connectée sur une machine. De ce fait je pense que l’on peut changer ces caractéristiques mais étant donné qu’aucune documentation à ce sujet n’est présente sous la moindre forme sur Internet et que sans doute Microsoft garde ses nouvelles plus ou moins secrètes, je ne m’attarderai pas plus sur ce problème. De plus cela ne nous apprendrai pas grand chose sur le comportement du cache. C’est pourquoi je laisserai cette étude en l’état. (M.Dutheil étant du même avis).

Machine A Machine B

Cache visualisé (Distant)

Cache retourné (Local)


Flux Applicatif 27

Chapitre 2 : Gestion du cache d’Internet Explorer Lorsque l’on se connecte à un site pour la première fois, les documents sont mis en cache chez le client. Par la suite les données seront chargées entièrement ou partiellement en fonction des paramètres dans le cache Pour mes tests j’ai utilisé Internet Explorer 5.0 et 6.0 . Il se comporte au niveau du cache, exactement de la même façon. Diverses options d’Internet Explorer nous permettent de modifier le comportement du cache chez le client et ceci indépendamment de la configuration du serveur Web distant. Pour y accéder, ouvrir Internet Explorer et aller sous tools -> Internet Options -> Settings

Plusieurs options s’offrent à nous :

Dans les chapitres qui suivront, je vais traiter toutes les options d’Internet Explorer (au nombre de quatre) dans le détail. Ainsi pour chaque option, je ferai une analyse de protocole dans le cas où le cache est présent sur le disque et dans le cas où il ne l’est pas.

En changeant ces 4 options, on modifie les propriétés du cache ce qui a pour effets plusieurs modifications du comportement du cache. Celles-ci seront énoncées plus loin dans ce chapitre.


Flux Applicatif 28

2.1 Option Never Cette option est assez simple à comprendre. En effet, sans le cache, la page est chargée normalement comme tout autre option. Au contraire, si le cache est présent sur le disque, alors les données de la page seront toujours rechargées localement. Sans cache Avec cache

Comme on peut le constater, l’option Never, ne charge qu’une seule fois la page. Une fois que celle-ci s’y trouve, elle sera toujours chargée depuis le cache. Dans le cas où la page aurait changé de forme, des liens ne fonctionneront peut-être plus, des nouveautés ne seront pas perçues ou des images ne seront pas remises à jour. La page sera toujours chargée depuis le cache.

Server Web Client

Server Web Client

X Get Request

Response OK

Mise en cache

Chargement depuis le cache

Pas de requête sur le serveur web


Flux Applicatif 29

2.2 L’option Automatically

Cette option est celle qui vient par défaut lorsque l’on installe Internet Explorer. En regardant les principes de celle-ci, nous nous rendons bien compte qu’il est normal par rapport aux autres de l’avoir mise par défaut. En effet si lors de la première connexion au site, la page se met dans le cache comme avec les autres options, une fois que l’on se reconnecte au site, cette option va regarder la validité des fichiers se trouvant dans le cache (chapitre 1.3). Si l’on se reconnecte simplement avant que la date d’expiration du fichier soit dépassée (champ Expires), alors les fichiers sont chargés entièrement du cache de l’utilisateur. Dans le cas contraire le client va demander au serveur Web si des modifications sont intervenues sur la page accédée.

Je vais maintenant détailler un peu plus une séquence Request – Response afin de voir les données qui sont transmises en plus de celles pour afficher la page. Tous les paquets Request et Response vu, sont de la même forme que ceux présenté dans les pages suivantes.

Server Web

Get request www.eig.unige.ch If-Modified-Since: Tue, 08 May 2001 12:30:10 GMT

Response OK si le fichier a été modifié après la dernière

connexion du client et envoi des DATAs. Sinon Not Modified et la page sera chargée depuis le cache de l’utilisateur. Les dates de validité (champ Expires par

exemple) seront changées.

Client

Fichiers stockés dans le cache expirés ? (champ Expires)

Oui fichiers expirés

Non. Fichiers encore valides Alors chargement de la page depuis le cache


Flux Applicatif 30

Détails d’un paquet GET Request : Voici les principaux paramètres concernant le cache que l’on retrouve dans ce paquet. GET /images/supix.gif Dans ce paquet, je vais accéder au fichier supix.gif du serveur Web Referer: http://www.eig.unige.ch/ On envoie l’adresse du site où se trouve le fichier.

If-Modified-Since : Fri, 04 Feb 2000 19:02:16 GMT

Le client envoie dans la requête, la date de la dernière modification du fichier connue par lui-même.

Connection: Keep-Alive

Ce type de connexion est très répandu. En effet lors d’une connexion à un site, le client et le serveur vont transférer des données. Lors de cet échange, il se peut que la connexion doive être coupée en raison d’un mauvais mot de passe rentré ou d’une redirection sur une autre page. Dans le cas où le mode Keep-Alive est activé, cette connexion reste active. Ce qui a pour but de diminuer le trafic sur le réseau. Ce mode est donc très intéressant lorsque beaucoup de personnes se connectent en même temps sur le site.


Flux Applicatif 31

Détails d’un paquet Response : Voici les principaux paramètres concernant le cache que l’on retrouve dans ce paquet. HTTP/1.1 304 Document not modified Last-Modified: Fri, 04 Feb 2000 19:02:16 GMT Date: Mo 01 Oct 2001 19:4 4:09 GMT

Les fichiers n’ayant pas été modifiés sur le site depuis la dernière visite, la réponse du serveur Web sera du type Document not modified. De ce fait les données seront chargées du cache. Celles-ci seront cependant remises à jour avec une date de validité qui aura changé. Ceci a pour objectif d’avoir une réduction du trafic dans le cas où le client est en train de naviguer et revient souvent sur cette même page. Si cependant, le serveur Web a subi des modifications entre temps, alors la réponse de celui-ci sera OK et les données de la page seront transmises au client.

La question qui me viens à l’esprit est : comment fait le serveur à savoir si le client a déjà les données de la page en cache ou non ? Pour le savoir, il suffit de comparer 2 analyses de protocoles (avec une autre option) et de voir la différence lorsque le client possède le cache ou non. On s’aperçoit vite que lors du premier paquet GET request lorsque le cache est présent, une ligne de commande est présente en plus. If-Modified -Since: Tue, 08 May 200112:30:10 GMT

Cette ligne de commande demande au serveur Web si la page que le client à visité a été modifiée ou non. Or si le client pose cette question c’est qu’il possède déjà le cache dans sa machine. Dans le cas contraire, il ne la posséderait pas.

Server Web

Get request www.eig.unige.ch If-Modified-Since: Tue, 08 May 200112:30:10 GMT

Response Ok ou Not modified suivant la date du paquet précédent Client


Flux Applicatif 32

2.3 L’option Every time you start internet Explorer Lorsque le client se connecte au site, il doit pour la première fois ouvrir Internet Explorer. A partir de ce moment, toute page visitée pour la première fois, après réouverture d’Internet Explorer sera remise en cache. Si sans avoir fermé la fenêtre de navigation je revisite une page, alors celle-ci sera entièrement chargée du cache. Ici je fais l’exemple comme pour toutes les autres options, en me connectant au site www.eig.unige.ch Lors du premier accès au site, les données sont mises en cache.

Si par exemple, je quitte cette page et je navigue, tout se passe comme si c’était la première fois que je consultais les pages. C’est au moment où je me reconnecte sur l’url déjà tapé, que les propriétés de cette option, vont se faire remarquer.

En effet, comme on peut voir avec l’analyse de protocole suivante, je n’ai aucun paquet http qui passe entre le client et le serveur suite à la reconnexion au site sans avoir quitter au préalable Internet Explorer.


Flux Applicatif 33

Cette option, a pour objectif de charger automatiquement les pages depuis le cache lorsque je garde Internet Explorer ouvert. Aucune demande ne sera donc faite au serveur Web. Cependant, lorsque que je ferme Internet Explorer et le rouvre, pour aller consulter la même page, les données seront à nouveau stockées dans le cache mais comme pour l’option automatically, la validité des fichiers va être testée pour le renvoi par le serveur Web de données plus récentes.

En résumé, lorsque l’on quitte Internet Explorer, les données d’un url sont toujours en cache, celui-ci se comporte exactement comme l’option Automatically . Ce n’est que lorsque l’on garde Internet Explorer ouvert que l’option joue un rôle en chargeant automatiquement les données du cache (comme l’option Never). Voir page suivante pour une représentation graphique du fonctionnement de cette option.


Flux Applicatif 34

Résumé de l’option Every time you start internet Explorer Client

Est-ce que le fichier est stocké dans le cache ?

Est-ce que Internet Explorer a été quitté entre le dernier accès et

maintenant ?

Server Web

Oui Non

www.eig.unige.ch

Est-ce que les fichiers dans le cache sont encore valides ?

Oui

Non

Oui

Non

Affichage de la page depuis le cache


Flux Applicatif 35

2.4 L’option Every visit to the page

Cette option, comme son nom l’indique va recharger les données de la page à chaque fois que l’on visite la page en question même si les données sont déjà stockées dans le cache. Au contraire des autres options, celle-ci ne testera pas des heures de validité dans le cache mais regardera chaque fois s’il y a des modifications sur la page.

Sans cache Avec cache Si j’essaye de me connecter un certain nombre de fois sur la page, j’obtiendrai toujours l’analyse de droite (Avec cache).

Server Web

Get request www.eig.unige.ch If-Modified-Since: Tue, 08 May 200112:30:10 GMT

Response Ok ou Not modified suivant la date du paquet

précédent

Client

Cache

Aucune requête pour savoir s’il y a un cache valide


Flux Applicatif 36

2.5 Résumé de toutes les options d’Internet Explorer Dans ce chapitre j’essayerai de résumé brièvement toutes ces options et ces principes. Pour avoir plus de détails sur chaque option, se référer au chapitre concerné.

Option Fonctionnalités

Never

Chapitre 2.1

Lorsque l’on accède pour la première fois au site, les données de la page seront mises en cache. Lors d’un prochain accès, les pages seront réaffichées depuis le cache et ne seront pas remises à jour.

Automatically

Chapitre 2.2

Lorsque l’on accède pour la première fois au site, les données de la page seront mises en cache. Lors d’un prochain accès, le client va regarder la validité des fichiers qui se trouvent dans le cache à l’aide de l’heure de validité de ceux-ci (champ Expires). S’ils sont encore valides alors la page sera affichée depuis le cache. Dans le cas contraire, le client va demander pour chaque fichier, si celui-ci a été modifié ou non (champ Last Modified ) et suivant le résultat, les données dans le cache seront modifiées ou non. Cependant, lorsque le client se sera reconnecté sur la page, une nouvelle heure de validité sera présente.

Every time you start Internet Explorer

Chapitre 2.3

Lorsque l’on accède pour la première fois au site, les données de la page seront mises en cache. Lors d’un prochain accès, dans le cas ou Internet Explorer n’a pas été fermé, la page concernée sera entièrement chargée depuis le cache (idem option Never). Dans le cas contraire, donc si Internet Explorer a été fermé entre-temps, le client va devoir recharger le cache de la page en demandant au serveur Web si les fichiers se trouvant sur la page ont été modifiés (champ Last Modified) ou non (idem mode Automatically).

Every visit to the page

Chapitre 2.4

Lorsque l’on accède pour la première fois au site, les données de la page seront mises en cache. Lors d’un prochain accès, le client demandera au serveur Web si les fichiers se trouvant sur la page ont été modifiés ou non (champ Last Modified ). Il n’y a pas dans ce cas d’heure de validité.


Flux Applicatif 37

Chapitre 3 : Le cache vu par le serveur Web Ce chapitre contrairement au précédent ne traitera que du serveur Web. En effet je vais montrer certaines commandes lors de la création du site qui affecte le cache du côté client. De plus, je vais présenter ce que l’on peut trouver comme traces lors d’un accès au serveur par n’importe quel client. Avant de regarder les commandes propres au cache, il faut créer notre site. Pour cela, j’ai récupéré la page du site du laboratoire de transmissions de données. Pour récupérer le fichier, il suffit simplement de faire un save as de la page.

Une fois cette opération terminée, je vais installer le serveur Web.

3.1 Installation du serveur Web Le serveur Web que j’ai créé (Machine Vectra 11 , IP = 129.194.187.52) se trouve sur une machine Windows 2000 Professional. Je vais donc devoir installer IIS 5.0 pour gérer mon site Web. Pour cela, il suffit d’installer un nouveau composant Windows depuis le CD d’installation de la version Windows 2000 Server par exemple. Ensuite, il faut que je configure IIS. Je dois donc définir la page par défaut de mon site. Les paramètres du site sont accessibles sous : IIS -> Vectra11 -> Default Web Site -> Properties. Sous l’onglet Documents, j’insérerai la première page de mon site.


Flux Applicatif 38

En cliquant sur Properties, et en

allant sous l’onglet Documents, on obtient la fenêtre suivante.

Nous avons donc ici la première page de notre site qui s’appelle tdd.htm De plus, il faut indiquer le répertoire où se situe cette page. Dans notre cas il se trouve sous c:\site . Dans l’onglet Home Directory, donner le chemin de l’emplacement sur le disque de la première page du site.

Maintenant que nous avons installé le serveur Web, il nous suffit de le gérer. Le but ici est de regarder les commandes http que l’on peut avoir sur le serveur Web. De ce fait, je ne m’attarderai pas sur des problèmes d’authentifications sur le serveur Web.


Flux Applicatif 39

3.2 Commandes HTTP

Plusieurs méthodes sont possibles afin d’envoyer des commandes pour stocker en cache les données depuis le serveur. La première consiste à mettre des commandes directement dans la page html. Ceci est donc du ressort du programmateur de la page. Pour cela, on utilise des Meta Tag qui sont plus ou moins semblables aux entêtes http. Cependant je ne les étudierai pas dans mon mémoire. Une deuxième méthode (celle que j’étudierai) est celle qui nous permet depuis IIS de mettre des entêtes HTTP personnalisées sur le site Web. En effet, dans ces entêtes, il nous suffit de taper les commandes HTTP et le tour est joué. Cette méthode est plus facile à mettre en œuvre c’est pourquoi j’ai décidé de l’étudier. Ces commandes peuvent être insérées sous l’onglet HTTP Headers dans les propriétés du site Web. (voir chapitre 3.3) Les commandes principales concernant la mise en cache se trouvent dans la RFC 2616 chapitre 13 et 14 principalement.


Flux Applicatif 40

3.3 L’onglet HTTP Headers

C’est l’endroit où l’on rentre les commandes http. Pour cela, il faut cliquer sur add et rentrer les commandes. Dans la fenêtre qui nous apparaît, il faut taper cache-control dans le premier champ et le type de commande que l’on veut. Par exemple : cache-control et max-age = 120 Voici donc l’apparition d’une nouvelle commande http sur notre page. Toutes les commandes peuvent être tapées une par une par cette méthode. Cependant, en ce qui concerne les commandes pour l’expiration du cache comme max-age, sur ce même onglet, nous avons la possibilité de choisir des dates d’expirations de façon plus simple sans connaître les commandes http.

.


Flux Applicatif 41

En effet, on peut avoir les paramètres Expire Immediately, Expire after ou Expire. Pour cela, cliquer sur la case Enable Content Expiration dans la figure dans la figure de la page précédente. Expire immediatelly est identique à taper : Cache-control : max-age = 0 Expire after est identique à taper : Cache-control : max-age = xxxx Expire est identique à taper : Expire : Thu 13 Dec 2001 18 :00 :00 GMT Elle est présente pour simplifier la commande max-age. En effet, la valeur de max-age étant en seconde, il est plus facile de rentrer une date que de devoir calculer le nombre seconde qu’il y a d’ici la date d’expiration choisie.

3.4 Principales commandes HTTP Voici une liste des principales commandes HTTP utilisées. - no-cache : Le serveur Web force le browser ou le proxy à ne pas mettre en

cache les données qu’il envoie. Ainsi à chaque fois que l’on se connecte au site, la page sera entièrement rechargée et il n’y aura aucune donnée présente dans le cache. Malheureusement cette commande affecte la charge du réseau de façon négative, du fait qu’à chaque fois qu’une requête est émise sur le serveur, celui-ci devra renvoyé ses données intégralement. Elle sera décrite plus précisément au chapitre 3.4.1.

- max-age : Cette valeur nous renseigne sur la durée de la validité de la page.

Elle est définie en seconde. C’est une des commandes les plus souvent utilisées. Elle sera décrite plus précisément au chapitre 3.4.2.

- public : Normalement une page avec un contenu authentifié ne peut pas

être cachée. Cependant si cette commande est présente, cela veut dire que la page peut être mise dans le cache si le client accepte cela.

- private : Cette commande ne permet pas à d’autres utilisateurs de

s’emparer du cache. Par exemple, si on a un proxy (ISA) voir chapitre 5 entre le client et le serveur, celui-ci ne pourra pas avoir dans son cache les pages du site.

- must-revalidate : Il se peut que la configuration d’un browser soit faite de manière

à ne pas recharger le contenu à chaque accès au site (option Never par exemple). Avec cette commande, le serveur force le client à recharger les données à chaque fois que l’on veut accéder au site.


Flux Applicatif 42

- proxy-revalidate : Idem que must-revalidate mais pour un serveur proxy. - expire : Est identique à max-age mais cette fois-ci on rentre directement

une date et une heure au lieu de donner un temps en seconde.

- pragma : Cette commande sert lorsque le serveur a beaucoup de données à envoyer. En effet afin de ne pas envoyer par exemple no-cache pour chaque fichier, on rentre une seule fois lors du premier accès pragma : no-cache et pour la suite du transfert, le client sait qu’aucune donnée ne doit être mises en cache.

3.4.1 Commande no-cache

Comme énoncé dans le chapitre 3.4, cette commande a pour but de forcer le browser ou le proxy à ne pas mettre en cache les données. Pour vérifier cela, j’ai fait une étude de protocole et voici ce que j’ai pu en tirer. Client Si l’on regarde l’état du cache après cette opération, on constate qu’il est bel et bien vide. Cette commande est souvent utilisée sur des sites qui demandent une authentification. Typiquement, ce sont les sites de messagerie ou les sites sécurisés où cette commande est le plus fréquemment utilisée.

Server Web

Get Request

Response OK Cache-control : no-cache

Cache client vide


Flux Applicatif 43

3.4.2 Commande max-age

C’est la commande la plus couramment utilisée de toutes celles énoncées au chapitre 3.4. En effet, elle permet de définir une date de validité des fichiers stockés dans le cache. C’est cette date qui va déterminer si le browser va ou non faire une requête sur le serveur pour savoir si des données ont été modifiées sur le site précédemment consulté (elle va affecté le champ Expires dans le cache du côté client voir page 1.3). De la même manière que pour la commande no-cache, je vais regarder ce qui c’est réellement passé Client

La différence avec la commande no-cache, c’est que maintenant des données sont stockées dans le cache. Cependant, la date d’expiration des fichiers sera de 120 secondes. Ce qui correspond donc a 2 minutes. Ainsi lorsque l’on regarde notre cache on s’aperçoit que la date d’expiration du fichier sera de 2 minutes plus vieille que celle de la date du dernier accès. Si le serveur Web répond Not modified, cela veut dire que le fichier n’a pas été modifié depuis le dernier accès. Donc le champ Last Modified ne changera pas. Au contraire si le serveur Web répond OK, il a donc modifié des données sur la page accédée, alors ce champ Last Modified aura une nouvelle valeur. Type de réponse Last Modified Expires Last Accessed Avant de se connecter 5 Novembre 12h00 18 Novembre 15h00 18 Novembre 14h58

Not Modified 5 Novembre 12h00 18 Novembre 15h32 18 Novembre 15h30 OK 18 Novembre 15h30 18 Novembre 15h32 18 Novembre 15h30

Server Web


Response OK ou Not modified Cache-control : max-age = 120

Cache client présent


Flux Applicatif 44

3.5 Les fichiers LOG Il est normal que lorsque les clients se connectent sur le serveur Web, ils laissent une trace de leur passage. Ainsi à l’aide d’IIS , nous pouvons avoir un fichier log qui nous servira pour savoir qui s’est connecté. Ces fichiers log sont au nombre de 4 et le format peut être choisi dans l’onglet Web Site.

Nous pouvons aussi choisir quelles seront les données affichées dans ce fichier. Une liste avec des choix multiples peut être modifiée dans Extended Properties

Cependant, ces fichiers log ne servent pas vraiment. Certes ils nous renseignent sur qui s’est connecté sur notre site mais ces renseignements ne sont pas trop importants pour l’administrateur, si ce n’est pour des détections d’intrusions. Pour cela, il faudrait installé un firewall ou un proxy afin de surveiller beaucoup mieux qui se connecte sur notre serveur. C’est pourquoi je ne m’attarderai pas plus sur ces fichiers log.

Pour activer la fonction de Login , valider cette case


Flux Applicatif 45

3.6 Conclusion Avec ce deuxième chapitre, nous avons pu montrer les emplacements du cache du côté client ainsi que les commandes qui doivent être écrites du côté serveur afin que le cache soit plus ou moins contrôlé. Cependant, le cache qui a aussi un rôle de réduction de temps d’accès aux pages, n’est pas vraiment efficace suivant les commandes http présentent sur une page html. C’est pourquoi lors d’une seconde phase, nous étudierons le phénomène d’accélération des accès aux sites grâce au cache avec un logiciel appelé ISA (Internet Security and Acceleration) qui lui a la fonctionnalité de réduire le temps d’accès aux pages. Dans quelle mesure ? A quel prix ? Toutes ces questions seront traitées dans les chapitres suivants (voir chapitre 4 à 6).


Flux Applicatif 46

Chapitre 4 ISA Server

Première Partie Lors du chapitre précédent, nous avons pu constater que le cache d’un utilisateur n’était pas visible par quelqu’un d’autre. De ce fait aucune machine ne bénéficiera du cache de la page visitée qui est déjà stockée chez un autre utilisateur. Le logiciel ISA (Internet Security and Acceleration) propose un Firewall ainsi qu’un serveur de cache réuni en un seul logiciel. Dans mon diplôme, je ne m’attarderai pas sur les fonctionnalités du Firewall, mais me concentrerai uniquement sur la partie cache et proxy . Ainsi à l’aide de ce logiciel, nous pourrons faire bénéficier un autre utilisateur du cache présent sur une autre machine. Les accès à Internet, devraient théoriquement, être plus rapide. C’est pourquoi dans les chapitres 5 et 6, je vais tester les différentes possibilités qu’offre ce logiciel, afin d’améliorer ce phénomène. Dans ce premier chapitre je résumerai brièvement les possibilités qu’offre ISA Server. Pour ne pas charger cette partie, j’ai fait un guide d’ISA Server beaucoup plus complet en annexe, une théorie sur les possibilités de ce logiciel serait trop volumineuse. De plus, cela ne nous apporterait pas beaucoup sur la compréhension de ce logiciel au niveau traitement des données reçues et analyses de protocole. Si l’on regarde la documentation sur le site de Microsoft (fondateur du logiciel), on s’aperçoit que plusieurs avantages devraient être tiré en installant dans notre réseau un serveur ISA. Les différentes améliorations énoncées sont :

• Réduction de la bande passante du réseau • Réduction du temps d’accès aux pages • Rafraîchissement automatique des pages • Réduction de l’utilisation du processeur et du réseau

4.1 Configuration requise

• PII 300 MHz • Windows 2000 Server Service Pack 1

(dans le cas ou le Service Pack 2 est installé, il faut installer le Hotfix Q301625 à l’adresse : http://support.microsoft.com/support/kb/articles/Q301/6/25.ASP )

• 256 Mo de mémoire vive • Partition formatée en NTFS

Selon le nombre d’utilisateurs et la place que l’on réserve dans le cache, il faut augmenter respectivement la taille de la mémoire vive et la taille du disque dur.


Flux Applicatif 47

Ce logiciel, nous offre plusieurs possibilités d’utilisation selon le type d’installation. Les trois modes proposés sont : .

- Le mode cache (Chapitre 4.2) - Le mode Firewall (Chapitre 4.3) - Le mode Integrated (Chapitre 4.4)

4.2 Le mode cache

Ce mode est celui que nous allons utilisé. En effet, il nous servira à faire la comparaison entre une connexion avec un serveur de cache et l’étude précédente qui était de se connecter simplement à un serveur Web. Ainsi nous pourrons constater la différence entre ces deux modes et voir si ce logiciel est un investissement intéressant pour les entreprises et si oui dans quelles mesures. Les temps d’accès sont-ils vraiment améliorés et de combien ? Les utilisateurs dans le réseau peuvent-ils bénéficier du cache des autres ? Toutes ces questions seront traitées dans le chapitre 5.

4.3 Le mode Firewall

Ce mode d’installation ne sera pas traité dans l’étude d’ISA. En effet, le but est de tester la problématique du cache et non de la sécurité des utilisateurs qui se trouvent derrière celui-ci, ni de la sécurité du serveur lui-même. Lorsque l’on installe le Firewall et le mode cache, il est préférable de les installer chacun sur une machine différente.

Internet

Client

Server ISAmode Cache

Internet

Client

Server ISAmode Cache

Server ISAmode Firewall


Flux Applicatif 48

4.4 Le mode Integrated

Ce mode est un mixte des deux. Il permet non seulement de stocker le cache des utilisateurs comme dans le mode cache, il permet aussi d’avoir les propriétés du Firewall installées sur la même machine. Si l’on veut installer un vrai Firewall et non simplement un filtre, il faut installer les deux modes séparément. Cependant, si l’on veut juste faire un filtrage des paquets, on peut utiliser le mode integrated . Lorsque l’on veut publier notre site sur Internet depuis l’intérieur du réseau, nous sommes forcés d’avoir au moins le mode Integrated à disposition si l’on veut un minimum de sécurité. En effet, lors de la publication du site Web, il faut des filtres pour ne pas laisser pénétrer tout le monde dans le réseau.

4.5 Choix décidé pour l’installation

L’installation doit se faire avec le CD Standard Edition si possible. Etant donné que dans le laboratoire de transmission de données, la version disponible est Entreprise Edition, je suis obligé d’installer celle-ci. Cela ne pose pas de problème si ce n’est que cette version a un coût beaucoup plus cher par rapport à la version Standard.

Lorsque l’installation commencera, je choisirai le mode Standalone, car je n’ai qu’un seul serveur ISA.

Ensuite je n’utiliserai que le mode cache. L’étude du cache étant la partie essentielle de ce rapport.

Au début, j’ai utilisé une seule carte ethernet. C’est la configuration qui est recommandée dans tout les documents trouvés sur ISA Server. Par la suite j’utiliserai une deuxième carte et je verrai la différence. Voir Annexe Guide d’ISA Server.

Maintenant je suis prêt pour me lancer dans l’installation du logiciel.

Pour plus de détails consulter le guide d’ISA Server en annexe.

Une fois que l’on a installé le logiciel, nous avons plusieurs moyens de mettre en cache les données reçues par le serveur Web.

Internet

Client

Server ISAmode Integrated


Flux Applicatif 49

4.6 Différents modes de mise en cache

Avec ISA Server installé en mode cache, nous avons la possibilité de stocker des pages d’une façon dynamique. En effet, il est possible qu’ISA fasse des requêtes sur le serveur Web sans qu’aucun client fasse de demande. Ce mode s’appelle Active Cache. Bien sûr, le mode cache par défaut n’a pas cette option. Il est simplement configuré pour que toutes les pages qui traversent ISA, soient stockées avec une date de validité plus ou moins grande selon les paramètres choisis. Ce mode s’appelle HTTP Cache. Un troisième mode de cache qui est l’Advanced Caching ne sera pas traité avec une étude de protocole particulière. Celui-ci permet de créer certaines règles sur les fichiers qui nous arrivent. Par exemple, de ne pas stocker les pages plus grandes que x bytes. Un dernier mode de mise en cache, est la mise en cache automatique mais non plus en fonction des paramètres d’Active Caching. Cette fois il faut rentrer directement une heure, une date et le site sur lequel on veut charger la page. Pour finir un mode Scheduled Caching, nous permet de dire à ISA d’aller charger une page à une date donnée. En résumé les différents mode de mise en cache sont :

• Http Caching • Active Caching • Advanced Caching • Scheduled Caching

Afin d’accéder à ces options, sous Cache Configuration , cliquer sur Properties.

Pour plus de détails sur les modes Advanced Caching et Scheduled Caching, consulter l’annexe Guide d’ISA Server.


Flux Applicatif 50

4.6.1 http Caching

C’est le mode par défaut d’ISA Server. Lorsqu’un client effectue une requête sur le serveur Web, il doit passer par le proxy. Celui-ci va alors regarder dans son cache, s’il possède la donnée recherchée. Si tel est le cas, il regarde si cette donnée est encore valide ou non. Suivant le résultat de ce test, il va aller rechercher les données sur le serveur Web et va envoyer depuis son cache les données au client. Le temps de stockage peut varier suivant la configuration du serveur ISA. Voir guide d’ISA Server en annexe.

Internet

Client Serveur ISA Serveur Web

Request Date de Stockage Valide ? Response

Oui

Request

Response

Stockage des données.

Avec date de validité suivant

Les paramètre de http Caching

Non

Response


Flux Applicatif 51

4.6.2 Active Caching

Lorsque le client accède à un site Web, les pages en questions sont mises en cache suivant les paramètre de http Cache. Cependant ces fichiers peuvent arriver à expiration. C’est pourquoi ce type de cache est présent. Si une page est modifiée souvent, alors il serait dommage qu’à chaque fois que le client se connecte sur celle -ci, il doive la recharger. Or avec Active Caching, c’est le serveur qui fera la requête automatiquement sans qu’aucune requête ne soit émise par un client. La fréquence de mise à jour des pages peut être gérer. Voir guide d’ISA server en annexe.

Internet

Client Serveur ISA Serveur Web

Remise à jour du cache

Request Request

Response Response

Temps d’expiration de la page

Request Response Aucuns paquets


Flux Applicatif 52

4.7 HTTP 1.0 VS HTTP 1.1

Lorsque le client se connecte sur un serveur Web à travers ISA, il doit utiliser une connexion de type proxy. Il faut donc modifier une option dans Internet Explorer.

Elle s’effectue sous l’onglet Advanced.

Il faut sélectionner Use http 1.1 through proxy connections au lieu de Use http 1.1. Ainsi on voit qu’Internet Explorer, peut être utilisé de 4 manières différentes. La première est celle qui consiste à ne cocher aucune des deux cases énoncées précédemment, le browser utilise alors le protocole HTTP 1.0 pour communiquer avec le serveur Web. Si la première case uniquement est cochée, cela signifie que l’on utilise le protocole HTTP 1.1. Si l’on coche uniquement la deuxième case, nous utiliserons alors le protocole HTTP 1.1 à travers le proxy et le protocole HTTP 1.0 pour une requête sans proxy . Si les deux cases sont cochées, alors le protocole HTTP 1.1 sera toujours utilisé.


Flux Applicatif 53

Voici un tableau qui résume les différents choix.

Mode choisi Protocole HTTP 1.0

utilisé

Protocole HTTP 1.1

utilisé

Protocole HTTP 1.1 à travers le proxy

Use http 1.1 X Use http 1.1 through proxy connections X ü X X Use http 1.1 ü Use http 1.1 through proxy connections X

X ü X Use http 1.1 X Use http 1.1 through proxy connections ü ü X ü Use http 1.1 ü Use http 1.1 through proxy connections ü X ü ü

Mais pourquoi utiliser HTTP 1.1 et non pas 1.0 ? La réponse est simple, le protocole HTTP 1.0 ne défini pas de commande en ce qui concerne la mise en cache des données. Dans la norme HTTP 1.0, les champs cache-control : no-cache, max-age, public, private etc… n’existaient pas. Ils ont été ajoutés dans la norme HTTP 1.1. Pour connaître les modifications entre HTTP 1.0 et HTTP 1.1, consulter l’adresse : http://groups.yahoo.com/group/http-wg/message/8289 Tout ces champs auront une influence sur le comportement du cache et donc du serveur ISA. Nous les verrons plus en détails dans les chapitres 5 et 6.


Flux Applicatif 54

Chapitre 5 ISA Server

Deuxième Partie

5.1 Introduction

Dans les chapitres qui vont suivre, je vais essayer de présenter les différents modes de fonctionnement du serveur ISA avec pour chacun des tests. Une étude de protocole sera faite afin de comprendre le fonctionnement du logiciel. La première partie servira à comprendre les principes de fonctionnement avec un seul client connecté sur le serveur de cache. Nous montrerons ainsi la différence avec la partie cache Web (chapitre 1 et 2). Nous comparerons une connexion avec ou sans proxy. Une deuxième partie sera consacrée à ajouter un deuxième client afin de lui faire bénéficier du cache d’un autre utilisateur. Pour rappel, ceci n’était pas possible avec un cache Web traditionnel (chapitre 1). Toutes ces mesures se feront avec une seule carte Ethernet. Une troisième étude se fera avec la même configuration client mais avec 2 cartes Ethernet. Ainsi nous verrons les problèmes de routage entre cartes et regarderons ce que cela apporte de plus au niveau de la sécurité. Une quatrième et dernière étude, portera sur le reverse proxy. Celui-ci étant souvent utilisé, nous essayerons d’expliquer ses principes.


Flux Applicatif 55

5.2 Fonctionnement du Serveur ISA

Afin de mieux comprendre le fonctionnement du serveur ISA, j’ai trouvé un schéma sur Internet à l’adresse : www.microsoft.com/technet/prodtechnol/isa/proddocs/isadocs/CMT_Cache.gif qui montre bien le fonctionnement du serveur ISA.

A l’aide de cette figure très importante pour la compréhension, nous pouvons effectuer les tests nécessaire à la compréhension des transferts de données entre les différentes machines. Il faudra donc toujours garder cette figure à l’esprit.


Flux Applicatif 56

5.3 Test avec un seul client et une carte Ethernet sur ISA

L’architecture du réseau lorsque l’on installe une seule carte Ethernet est la plus simple. En effet, le réseau a la typologie suivante :

Afin de mieux comprendre le transfert de données entre les différentes machines, je vais remettre le dessin a plat. Cependant il faudra bien tenir compte que l’on utilise qu’une seule carte ethernet.

En effet, lorsque l’on utilise une seule carte Ethernet, il faut savoir que le serveur ISA récupère les données du client pour les renvoyer via la même carte sur le serveur Web.

Internet

Serveur ISA

Serveur Web

Client


Flux Applicatif 57

5.4 Mode http Header Frequently

5.4.1 Commande max-age envoyée par le serveur Web Lorsque je me connecte pour la première fois, je ne possède aucun cache local. Le serveur ISA a aussi son cache vide.

Lors de cette première étude, nous voyons tout de suite les modifications, suite au proxy installé, entre le client et le serveur Web. En effet, maintenant le client envoie le paramètre Proxy Connection . Quand au serveur ISA il modifie un champ http. Le champ Source Adress est remplacé par un Via . En ce qui concerne les réponses, on voit que l’on a simplement un Source Adress qui est remplacé par un Via . Sinon la réponse du serveur Web au serveur ISA est tout à fait identique à la réponse du serveur ISA au client.

Ici le paramètre max-age est présent (voir chapitre 3.4.2). La différence entre la Date et Expires est exactement la valeur de max-age. En effet, 900 secondes = 15 minutes = 15h44 – 15h29 (Date – Expires).

Maintenant une date d’expiration est valide. Si l’on refait un requête sur la page, alors aucun paquet ne devrait sortir du client tant que les fichiers ne sont pas expirés du côté client. En effet, aucune requête ne part du client au cas où le rafraîchissement de la page se fait avec ENTER. Cependant, si F5 est tapé, alors une requête sur le serveur ISA est faite. (voir différence entre les modes de rafraîchissement au chapitre 1.5). C’est pourquoi le deuxième test effectué sera de faire un rafraîchissement de la page avec F5 sur une page qui est encore en cache et valide du côté client.

Client Serveur WebServeur ISA

Get Request From Client to Server Web Proxy Connection :

Keep-Alive

Get Request Via ISA Server to Server Web

Response OK From Server Web to ISA Server Cache-Control : max-age = 900 Expires : Wed, 17 Oct 2001 15:44:44 GMT Date : Wed, 17 Oct 2001 15:29:44 GMT Last Modified : Wed, 17 Oct 2001 12:05:41 GMT Données utiles de la page

Response OK Via ISA Server to Client Cache-Control : max-age = 900 Expires : Wed, 17 Oct 2001 15:44:44 GMT Date : Wed, 17 Oct 2001 15:29:44 GMT Last Modified : Wed, 17 Oct 2001 12:05:41 GMT Données utiles de la page


Flux Applicatif 58

5.4.2 Cache présent valide sur le client et sur ISA avec rafraîchissement F5

Ici le client qui effectue le rafraîchissement, envoie dans son paquet http Get Request, le paramètre Last Modified. Dans mon cas il vaut : 17 Oct 12h05. Ainsi le serveur Web va regarder cette date pour savoir si une modification est intervenue.

I

Ici, Last Modified , nous donne la date d’expiration des fichiers dans le cache. Le serveur renvoie le paramètre Not modified et renvoi la même date (Last Modified) qu’auparavant. Ce qui est normal vu qu’aucune modification n’est intervenue sur la page consultée. Si cette modification est parvenue entre temps, alors le serveur Web envoie un OK et retransmet les données modifiées, et le paramètre Last Modified aura une nouvelle valeur.

Client

Serveur WebServeur ISA

Get Request From Client to Server Web If modified Since

(Last Modified ) Proxy Connection :

Keep-Alive

Get Request Via ISA Server to Server Web If modified Since

(Last Modified)

Response Not Modified From Server Web to ISA Server Cache-Control : max-age = 900 Expires : 25 Oct 15h15 Date : 25 Oct 15h00 Last Modified : 17 Oct 12h05

Response Not Modified Via ISA Server to Client Cache-Control : max-age = 900 Expires : 25 Oct 15h15 Date : 25 Oct 15h00 Last Modified : 17 Oct 12h05


Flux Applicatif 59

Une question qui vient à l’esprit est : Comment se fait-il que du côté ISA je sois avec le http cache en mode Frequently et que le client envoie un paramètre If modified Since (Last modified) ? En effet, lorsque l’on se trouve en mode Frequently, le cache ne doit jamais être valide ni du côté ISA ni du côté client. La réponse est simple. Il suffit de lire la petite remarque lorsque l’on configure les différentes options du mode http Caching .

De ce fait, si le serveur Web envoie une date d’expiration, celle-ci prendra le dessus sur le type d’option du serveur ISA. C’est-à-dire que si le serveur Web envoie un max-age = 900, et que le serveur ISA est configuré pour avoir un cache qui expire immédiatement, les données du serveur Web, forcent alors à avoir une validité des fichiers dans le serveur ISA et chez le client, de 900 secondes.

Mettre en cache les données à moins que la source indique l’expiration de la page.


Flux Applicatif 60

5.4.3 Cas où le serveur Web envoi un no-cache

Le cas précédent, montrait comment réagissait le serveur ISA lorsque le serveur Web envoyait un paramètre max-age = xxx. Maintenant je vais regarder le cas où le serveur Web envoie un no-cache. Ce qui devrait maintenant se passer, c’est que le serveur ISA devra toujours recharger les données du serveur Web du fait qu’il ne les possédera pas dans son cache vu la commande http no-cache envoyée. Voyons si tel est bien le cas :

Premier accès sans le cache du côté client mais avec le cache du côté ISA.

Comme on peut le constater à l’aide de ce diagramme en flèche, lorsque le serveur Web envoie un no-cache, le serveur ISA renvoi ce même paramètre au client. Cependant, un champ est ajouté. C’est le champ Age. Sa valeur nous renseigne simplement sur la différence entre le temps courant et le temps du dernier accès.

Je n’ai malheureusement pas trouvé d’algorithme pour le calcul de ce champ Age. La formule ci-dessus étant la seule trouvée, je considère ce champ comme très simple à calculer.

Cette commande Age peut servir lorsque l’on cascade plusieurs serveurs ISA. Ainsi le serveur pourra savoir si les données qui lui sont transmises sont encore valides ou non.


Get Request From Client to Server Web Proxy Connection : Keep-Alive

Get Request Via ISA Server to Server Web

Response OK ou Not Modified From Server Web to ISA Server Cache-Control : no-cache Expires : 7h00 Date : 7h00 Last Modified : Date

Response OK ou Not Modified Via ISA Server to Client Cache-Control : no-cache Expires : 7h00 Date : 7h00 Last Modified : Date Age = 0

Age = heure courante – heure du dernier accès


Flux Applicatif 61

Il pourra les accepter ou les rejeter suivant les critères de mise en cache de chacun des serveur ISA cascadé. En ce qui concerne le client, cette commande n’affecte en rien l’affichage de la page. Elle est transparente.

Cependant il se peut que le serveur Web était configuré au préalable avec la commande max-age et que l’administrateur du site décide de changer avec la commande no-cache.

Cela pose un petit problème au niveau du proxy . En effet, celui-ci ayant dans son cache les données, lorsque le client demande la page, c’est le proxy qui va la lui renvoyé. Les paramètres de mise en cache envoyés seront donc les anciennes valeurs. Ainsi ce n’est qu’au deuxième accès que la modification sera prise en compte.

Le champ cache control sera à nouveau présent avec max-age = 900 et avec cache control = no-cache.

Ainsi les données stockées dans le cache de l’utilisateur, n’auront pas une expiration immédiate comme avec no-cache mais celle-ci sera de 15 minutes (max-age = 900 secondes).

Voici donc en réalité ce qui se passe :

Client

Serveur ISA Serveur Web

données de lapage stockée

données de lapage stockée

données dela page

demandée

pas de cache Get Request Get RequestIf Modified Since (Last Modified)

les donnéesde la page

sont stockéesNot Modified

cache control : no-cache

Response OKcache control = 900

data non prise en compte car NotModified envoyé par le serveur Web :

cache control = no-cache J'ai reçu Not Modifiedalors prends les donnéesqui sont dans mon cache

et je t'envoie ausi lesdonnées du serveur Webpour que tu les stockes.

validité du cacheselon ISA = 900 sec

données de lapage envoyée

Une fois que j'ai envoyéles données au client, jeremets à jour mon cache

selon les entêtes httpenvoyées par le serveur

Web


Flux Applicatif 62

Lors de la réponse du serveur ISA au client, celui-ci envoi les nouvelles données concernant la mise en cache du côté client. Mais le serveur ISA envoi aussi son ancienne valeur du cache. En effet, si le serveur Web envoi un Not modified au serveur ISA, alors celui-ci croit que la page n’a pas été modifiée et le paramètre no-cache ne sera pris en compte que lors de la prochaine connexion au site.

Si l’on regarde le cache du côté client, on s’aperçoit que la date d’expiration des fichiers est bel et bien de 15 minutes. Cependant lors de la prochaine connexion, le paramètre no cache sera envoyé tout seul. Ce n’est donc que lors d’une deuxième connexion au site que les dates d’expiration du cache seront correctes.

La raison de tout ceci est que si l’on avait entré ces modifications dans la page html en code pur, le serveur Web aurait renvoyé un OK pour dire que la page était modifiée et dans ce cas, les dates de validité auraient été modifiées correctement.

C’est un des problème que l’on peut rencontrer lorsque l’on utilise cette méthode au lieu de programmer en html pur les pages Web.

Si maintenant, j’ai reçu la commande no-cache du serveur ISA correctement, et j’accède à nouveau au site, le client n’enverra plus les même paramètres au serveur ISA.

Le client n’ayant pas les données de la page demandée dans le cache, car ayant reçu la commande no-cache lors du dernier accès, il renvoie le paramètre pragma : no-cache au serveur ISA. Celui-ci en faisant la requête successive, fera de même du fait que lui non plus n’a plus la page en cache.


Get Request From Client to Server Web Proxy Connection : Keep-Alive Pragma : no-cache

Get Request Via ISA Server to Server Web Pragma : no-cache

Response OK From Server Web to ISA Server Cache Control : no-cache Expires : 7h54 Date : 7h54 Last Modified : Date Data transmises mais pas mises en cache dans ISA

Response Not Modified Via ISA Server to Client Cache Control : no-cache Expires : 7h54 Date : 7h54 Last Modified : Date Data transmises mais pas mises en cache localement


Flux Applicatif 63

5.4.4 Cache présent sur le client et sur ISA avec rafraîchissement ENTER

Lors du chapitre 5.4.2, nous avons vu le cas où le client rafraîchissait sa page en tapant sur la touche F5. Mais que se passe-t-il si maintenant si je tape le nom du site entièrement et je fais ENTER ?

Avant de répondre en faisant une étude de protocole, il faut savoir que comme pour le cache Web classique (sans le serveur ISA), Internet Explorer va tester si les fichiers stockés dans le cache sont encore valides ou non.

Si la réponse est non, alors le comportement lorsque l’on tape ENTER sur Internet Explorer est identique à lorsque l’on tape F5. Si ISA est en mode Frequently, il faudra à chaque fois rechargé la page. Ainsi pour voir l’analyse de protocole, se référer au chapitre 5.4.2 (Cache présent valide sur le client et sur ISA avec rafraîchissement F5)

5.5 Mode http Header Normally

Lors des chapitres précédents, nous avions regardé les paquets qui traversaient le serveur ISA lors d’un accès par un client sur un serveur Web. Cependant dans le mode Frequently, les pages n’étaient pas stockées dans le cache d’ISA. En fait ISA ne jouait que le rôle de proxy et non de cache. Maintenant, je vais regarder ce qui se passe lorsque le serveur ISA possède les données de la page dans son cache. Normalement du fait que les pages sont accessibles sur le serveur ISA, aucune requête ne devrait sortir de celui-ci.


Est-ce que les données dans mon cache sont encore valides ?

Oui

Idem Chapitre 5.4.2

Non


Flux Applicatif 64

5.5.1 Aucun cache présent sur le client mais présent sur ISA.

Le premier cas que je vais regardé est celui où le serveur ISA possède le cache de la page accédée par le client. Imaginons que le client ne la possède plus car il a effacé le contenu de son cache.

Si le cache du client n’est pas présent, alors le serveur ISA va automatiquement, et seulement si les fichiers ne sont plus valides, demander au serveur Web s’il y a eu des modifications depuis le dernier accès sur la page. Dans le cas où les données sont encore valides, alors ISA renvoi les données directement au client depuis sont cache, sans passer par le serveur Web.

Si les fichiers stockés dans le cache de ISA ne sont plus valides et qu’aucune modification n’est advenue, alors le cas énoncé à la page précédente est correct.

Dans le cas où la page a été modifiée entre temps, alors le serveur Web répondra OK au lieu de Not modified et il transmettra les données modifiées.

On remarque que quelque soit la réponse du serveur Web au serveur ISA, celui-ci répondra au client OK. Ce qui est tout à fait normal car le client ne possédant aucune donnée dans son cache, il faut que le serveur ISA les lui envoi.


Get Request From Client to Server Web Proxy Connection : Keep-Alive

GGGeeettt RRR eeeqqquuueeesssttt VVViiiaaa IIISSSAAA SSSeeerrrvvveeerrr tttooo SSSeeerrrvvveeerrr WWWeeebbb IIIfff mmmooodddiiifffiiieeeddd SSSiiinnnccceee (((EEExxxpppiiirrreeesss)))

RRReeessspppooonnnssseee NNNooottt MMMooodddiiifffiiieeeddd FFFrrrooommm SSSeeerrrvvveeerrr WWWeeebbb tttooo IIISSSAAA SSSeeerrrvvveeerrr CCCaaaccchhheee---CCCooonnntttrrrooolll ::: mmmaaaxxx---aaagggeee === 666000 EEExxxpppiiirrreeesss ::: 111999hhh333111 DDDaaattteee ::: 111999hhh333000 LLLaaasssttt MMMooodddiiifffiiieeeddd ::: DDDaaattteee AAAuuucccuuunnneeesss dddooonnnnnnéééeeesss tttrrraaannnsssmmmiiissseeesss sssiii aaauuucccuuunnneeesss mmmooodddiiifffiiicccaaatttiiiooonnnsss sssuuurrr llleee sssiiittteee

Response OK Via ISA Server to Client Cache-Control : max-age = 60 Expires : 9h31 Date : 9h30 Last Modified : Date Age = 0 Data transmises et mise en cache localement avec date d’expiration = 9h31


Flux Applicatif 65

5.5.2 Cache présent sur le client et présent sur ISA.

Lorsque que le cache est présent chez le client, deux cas se présentent, Le premier est lorsque le cache est présent et encore valide, le deuxième lorsqu’il ne l’est plus.

Dans le premier des cas, si le cache est encore valide chez le client alors les données seront chargées depuis le cache local. Deuxième cas, elles seront chargées depuis le serveur ISA.

Ici l’Age représente la durée de stockage de la page sur le serveur ISA depuis son dernier accès au site


Est-ce que les données dans mon cache sont encore valides ?

Oui

Get Request From Client to Server Web Proxy Connection : Keep-Alive If modified Since (Last Modifie d)

Non

Response Not Modified Via ISA Server to Client Expires : 12h49 Date : 12h34 Last Modified : Date Age = 157 Aucune donnée transmise

La différence entre la date d’expiration (Expires) et la date courante (Date) est égale à la date d’expiration dans les paramètres du serveur ISA. En effet en mode Normally, le temps d’expiration d’une page est de 15 minutes. 12h49 – 12h34 = 15 minutes

Aucun paquet tant que la date d’expiration des fichiers du serveur ISA n’est pas dépassée. Idem cas 5.5.1

Fichiers stockés dans le cache encore valides ?

Oui

Non


Flux Applicatif 66

5.5.3 Les autres cas

Les deux cas traités dans le chapitre précédent, sont les seuls où l’on peut voir le comportement du mode Normally . En effet, dans les autres cas, le serveur Web envoi une commande de type cache-control = xxx, et c’est cette commande qui prend alors le dessus. Donc, si ISA reçoit une commande HTTP de ce type, le mode Normally réagi identiquement au mode Frequently ainsi qu’à tout les autres modes. C’est pourquoi je ne ferai pas d’autres tests pour des modes de mise en cache. Afin de voir le fonctionnement du cache dans d’autres cas, se référer au chapitre 5.4 (mode Frequently).


Flux Applicatif 67

5.5.4 Différences entre les modes http Caching

Nous avons pu voir le comportement de 2 modes de mise en cache. Les autres modes fonctionnent identiquement à ceux-ci mais avec une durée de mise en cache différente (stockage de la page dans le serveur ISA variant suivant la configuration du serveur ISA).

Par contre ce que l’on peut dire c’est que suivant le mode de configuration du serveur ISA, les requêtes se feront ou non sur le serveur Web.

Pour comprendre le phénomène, il faut toujours faire référence à la figure du chapitre 5.2, qui résume le fonctionnement du cache du serveur ISA. Je vais cependant le résumé succinctement suivant les deux cas testés.

Au niveau de la requête sur la page, les cases teintées de gris, sont les cas où le mode Frequently peut se trouver. Dans le mode Normally, tous les cas peuvent être possibles. Ici bien sûr on suppose que le serveur Web, n’envoie aucun type de commandes spéciales sur la mise en cache des données. (voir chap 5.10)


Est-ce que je possède la page en cache ?

Est-ce que la page est encore valide ?

Get Request

Oui

Non

Est-ce que je possède la page en cache ?

Est-ce que la page est encore valide ?

Oui

Chargement de la page localement

Oui

Non

Get Request Non

Envoi des données de la page au client

Oui

Stockage de la page dans le cache

Response

Non


Flux Applicatif 68

5.6 Mode Active Caching

Ce mode de mise en cache ne fonctionne pas sur le principe du client qui fait une requête au serveur ISA, comme pour les autres modes. En effet, ce mode de mise en cache se fait automatiquement sans l’intervention du client.

Pour ce mode de mise en cache, je n’ai utilisé que le mode Frequently. Les autres modes étant identiques sur le principe de fonctionnement, si ce n’est que la fréquence des requêtes sur le serveur Web sera réduite. De plus, toutes les autres options vont réactualiser les pages dans le cache suivant des critères que ne peut régler l’administrateur avec le simple CD d’installation du logiciel. Les critères de rafraîchissement des pages sont : fréquentation du site, délai d’expiration, charge du réseau.

Cependant, lorsque l’on est en mode Frequently, on sait que le rafraîchissement automatique par le serveur ISA, se fera environ à la moitié de son délai d’expiration.

Comme on peut le remarquer, ici le serveur ISA fait une requête sur le serveur Web. La requête étant faite pour remettre à jour le cache, alors celui-ci envoi une commande Active Caching Request. Le serveur qui reçoit cette commande, réagi de la même façon qu’auparavant et donne l’information au serveur ISA s’il y a eu des modifications sur la page qu’il accède.

La commande max-age dit au serveur ISA, que les données seront stockées et retenues comme valide pendant 120 secondes. Du fait que l’on se trouve en mode Frequently , chaque moitié de ce temps (60 secondes), le serveur ISA ira redemander au serveur Web si des modifications ont eu lieu.


Aucun paquet n’est transmis dans ce mode c’est le serveur ISA qui gère seul le rafraîchissement des pages.

Get Request Via ISA Server Active Caching Request Connection : Keep-Alive If modified Since (Expires)

Response Not modified Expire : 14h23 Date : 14h21 Cache control : max-age = 120


Flux Applicatif 69

5.7 Ajout d’un deuxième client

Tous les tests effectués jusqu’à présent étaient basés entre un échange client - serveur ISA - serveur Web. Mais maintenant, je vais rajouter un deuxième client afin de voir si celui-ci peut bénéficier du fait que quelqu’un d’autre soit déjà allé visiter la page qu’il demande. Normalement, le serveur ISA ayant déjà en cache la page, celui-ci ne devrait faire aucune requête vers l’extérieur. Pour rappel lorsqu’au début de mon diplôme je me connectais sur un serveur Web directement, un autre utilisateur, sur la même machine, ne pouvait pas bénéficier de mon cache.

On remarque bien dans le diagramme en flèche, que le nouveau client peut bénéficier du fait qu’un autre utilisateur soit déjà allé visiter le site sur lequel il veut se connecter.

On peut donc en tirer la conclusion que lorsque l’on a plusieurs clients connectés sur le serveur ISA, tous peuvent bénéficier du cache des différentes pages visitées par le autres.

Client B


Get Request From Client B to Server Web Proxy Connection : Keep-Alive

Response OK Via ISA Server to Client B Cache-Control : max-age = 120 Expires : 15h31 Date : 15h29 Last Modified : Date Age = 0 Données de la page transmise Proxy connection : Keep-Alive

Client A

Cache du site Web du client A

GGGeeettt RRReeeqqquuueeesssttt VVViiiaaa IIISSSAAA SSSeeerrrvvveeerrr tttooo SSSeeerrrvvveeerrr WWWeeebbb IIIfff mmmooodddiiifffiiieeeddd SSSiiinnnccceee (((EEExxxpppiiirrreeesss)))

RRReeessspppooonnnssseee NNNooottt mmmooodddiiifffiiieeeddd FFFrrrooommm SSSeeerrrvvveeerrr WWWeeebbb tttooo IIISSSAAA SSSeeerrrvvveeerrr CCCaaaccchhheee---CCCooonnntttrrrooolll ::: mmmaaaxxx---aaagggeee === 111222000 EEExxxpppiiirrreeesss ::: 111555hhh333111 DDDaaattteee ::: 111555hhh222999 LLLaaasssttt MMMooodddiiifffiiieeeddd ::: DDDaaattteee AAAuuucccuuunnneeesss dddooonnnnnnéééeeesss tttrrraaannnsssmmmiiissseeesss

Echange uniquement si les fichiers ne sont plus valides

dans le cache d’ISA.


Flux Applicatif 70

5.8 Fonctionnement du serveur ISA avec 2 cartes Ethernet

Tous les tests intéressants au niveau d’une configuration avec une seule carte Ethernet étant conclus, je vais maintenant rajouter une deuxième carte Ethernet. Ce qui aura pour effet d’isoler les deux parties du réseau. Au préalable il me faudra configurer la table de routage du serveur ISA afin que les deux cartes communiquent et vice-versa.

Pour se faire, il suffit de dire à une des cartes , de donner l’adresse du gateway comme l’adresse IP de la deuxième carte.

Avec cette configuration la table de routage se met toute seule à jour et de façon permanente.

Ainsi avec ce type de configuration, tout paquet qui arrivera vers le serveur ISA sera toujours redirigé vers le serveur Web mais avec une adresse source qui ne sera plus la même que l’adresse qui servira à recevoir les données du client.

Au niveau de l’étude de protocole, celle -ci se fait de la même manière, avec les mêmes commandes que lorsque l’on avait une seule carte. Malheureusement, en rajoutant une carte, des questions de sécurité sont résolues mais l’accès au serveur Web est beaucoup plus lent. Ces ralentissements sont très difficilement calculables car ils sont très variables. L’ordre de grandeur reste cependant en secondes.


Get Request From Client 10.0.0.1 To Server Web

Get Request From Server ISA Adr IP 129.194.184.99 To Server Web Response From Server Web To Server ISA Adr IP 129.194.184.99

Response From Server ISA Adr IP 10.0.0.20 To Client 10.0.0.1

ISA Server

Adresse IP interne 10.0.0.20 Subnet Mask 255.255.0.0 Default Gateway 129.194.184.99

Adresse IP externe 129.194.184.99 Subnet Mask 255.255.252.0 Default Gateway 10.0.0.20 Preferred DNS 129.194.184.212 Alternate DNS 129.194.4.6


Flux Applicatif 71

En effet Windows 2000 ne gère pas très bien les 2 cartes Ethernet ensemble. M.Borsa aussi diplômant, a rencontré pas mal de problèmes avec une configuration présentant 2 cartes Ethernet. Pour ma part j’en ai rencontrés aussi, car lorsque l’on modifie certains paramètres (passage du mode proxy en mode standard par exemple sur le browser), le système ne fonctionne plus. Soit il faut attendre longtemps, soit booter les machines client et serveur. Ma configuration étant simple (peu de machines), cela ne pose pas trop de problèmes. Cependant d’un instant à l’autre, le système devient instable sans aucune modification de ma part.

5.9 Server Web Down

Il peut arriver que le serveur Web tombe en panne ou soit en réfection. De ce fait, personne ne peut plus accéder à une page du site. Cependant avec le serveur ISA, si le serveur Web est down, alors il va envoyer les données stockées dans son cache aux clients.

Warning : 111 ISA Server. Some of this informations may be out of date because of network problems. An attempt to reposnd this r equest from a remote location was unsuccessful. The response has an expired version of the object found in the cache.

Warning : 110 ISA Server. Some of this informations may be out of date

Lorsque le serveur Web est tombé, le serveur ISA, s’il possède les pages en cache, peut envoyé les données de celles-ci à un client. Par contre comme on peut voir, un message d’erreur est envoyé afin de communiquer au client qu’il y a un problème réseau et que les données envoyées peuvent être périmées. Pour le client, c’est comme si rien ne s’était passé. Pour lui, le serveur est toujours accessible. Ces warnings sont présents surtout lorsque l’on cascade des serveurs ISA. Une entreprise possédant un serveur ISA peut refuser d’afficher des pages périmées.


Get Request From Client To Server Web If modified Since (Expires)

Tentatives de connexion

Pas de réponse

Response OK From ISA Server To Client Expires : 15h30 Date : 15h30 Age : 118 Cache control : max-age = 120 Messages d’erreurs Données de la page transmises


Flux Applicatif 72

5.10 Les principales commandes HHTP rencontrées

Certaines commandes http ont été découvertes grâce à l’utilisation du serveur ISA et de la connexion proxy.

Ces commandes supplémentaires perçues sont au nombre de six.

Commande Explication

Proxy connection : Keep-Alive Cette commande signifie que lorsqu’on se connecte sur le serveur ISA en mode proxy la connexion se fait en mode keep -alive.

Via

Cette commande est présente uniquement lors de l’utilisation d’un proxy ou d’un gateway. Elle fait simplement l’intermédiaire entre le client et le serveur Web. Avec cette méthode on peut savoir du côté serveur Web si la demande vient d’un client ou si elle a été redirigée comme avec un serveur proxy . (voir chapitre 14.45 RFC 2616)

Expire Cette commande nous renseigne sur la date d’expiration du fichier. (voir chapitre 14.21 RFC 2616)

Date Cette commande nous renseigne sur la date de connexion au site. (voir chapitre 14.18 RFC 2616)

Age

Cette commande nous donne la différence entre l’heure courante et l’heure de la dernière connexion. Cette valeur sert uniquement au serveur ISA. Ainsi le client peut savoir si les données envoyées par le serveur ISA sont récentes ou non. (voir chapitre 14.16 RFC 2616)

Active Caching Request

Cette commande est envoyée par le serveur ISA lorsque celui-ci veut remettre à jour son cache de façon automatique. Cette commande n’a pas d’influence sur la réponse du serveur Web.

Il existe cependant plusieurs commandes http qui font que le serveur ISA ne mettra pas en cache les données. Ce sont souvent celles qui concernent les problèmes d’authentification. Ces commandes sont :

• Cache control : no-cache • Cache control : private • Pragma : no-cache • www-authenticate • set-cookie

voir page : http://www.microsoft.com/TechNet/prodtechnol/isa/proddocs/isadocs/cmt_cachewhat.asp


Flux Applicatif 73

Lorsque l’on se connecte à un site avec un de ces paramètres sur le serveur Web, alors les données ne seront pas stockées dans le cache ISA. Cette étude a déjà été menée lorsque l’on se connectait sur le serveur Web et celui-ci nous retournait une commande cache control : no-cache. C’est pourquoi je ne la referai pas ici.

5.11 Les fichiers LOG

Comme lorsque l’on était dans la configuration Client - Serveur Web (chapitre 3.5), des fichiers log peuvent être créés. Même si ceux-ci ont plus d’informations que les fichiers log sur IIS, ils restent pauvres. C’est pourquoi je ne les étudierai pas en détail. En effet, ce que l’on peut en tirer comme informations se trouve dans une liste que l’on peut configurer. Elle se trouve sous : Monitoring dans la fenêtre principale du serveur ISA En cliquant sur Properties et en allant dans l’onglet Fields, nous pouvons choisir les différents paramètres à afficher dans le fichier log.


Flux Applicatif 74

5.12 Qu’a-t-on gagné avec ISA ? Avec l’installation d’un tel logiciel, nous remarquons que les données transférées entre le serveur de cache ISA et le serveur Web sont diminuées. En effet, les données étant stockées dans le serveur ISA, lorsqu’un client se connecte sur une page, alors celui-ci se verra envoyer les données directement depuis ce serveur. Certes des requêtes existent entre le serveur ISA et le serveur Web mais c’est juste pour savoir si des fichiers ont été modifiés depuis le dernier accès sur la page et si le serveur ISA possède dans son cache la page demandée. Il faut savoir que généralement, le client se trouve dans un réseau local avec des liaisons à 10 ou 100 Mbits/s. Ce chiffre est de beaucoup supérieur à la liaison physique entre le serveur ISA et le serveur Web. De ce fait lorsque le serveur ISA possède les données dans le cache, celles-ci sont très rapidement chargées (vitesse du réseau local).

Les résultats que je trouve sont faussés par le fait que je ne simule que 2 clients et non un réseau complet de clients. Par faute de temps, je ne pourrai pas tester le cas plus réel en simulant un nombre plus grand de clients. De plus, le réseau de l’EIG étant très rapide, je ne vois pas de différence lorsque je me connecte sur un site Web avec ou sans le serveur ISA. Ce que je constate c’est qu’en rajoutant une deuxième carte Ethernet sur le serveur ISA, cela ralenti beaucoup le système. Par contre, je peux faire une étude sur le gain de trafic. Lorsque je me connecte à un site pour la première fois, ce gain est nul c’est comme si je n’avais pas de serveur ISA. Par contre si les données, une fois transmises, sont stockées dans le cache, alors lors de mon prochain accès mon gain sera de 100% par rapport à l’échange entre ISA Server et le Web Server (aucun paquet échangé). A cause des problèmes énoncés tout au long de ce chapitre, je n’irai pas plus loin dans l’étude de gain de temps avec ISA. Il faut savoir que dans un cas réel le serveur ISA devrait avoir un bon rendement au niveau du gain de temps. Mais de toute façon il est sûr qu’un gain important au niveau du trafic est perçu (0 paquet sortant du serveur ISA si le cache est encore valide ou quelques paquets de demande si la page a été modifiée dans le cas où le cache ISA est expiré). Une chose importante que l’on a avec le serveur ISA, est que l’adresse source que ce soit avec une configuration d’une ou deux cartes Ethernet, ne sera jamais celle du client mais toujours celle du serveur ISA.


Flux Applicatif 75

Chapitre 6 : Reverse Proxy Lors des chapitres précédents, nous avons toujours testé le cas où le serveur Web se trouvait hors de l’entreprise. Maintenant, je vais tester le cas où le serveur Web se trouve à l’intérieur de l’entreprise avec une adresse privée, et un client se connecte sur celui-ci via l’adresse publique du proxy. Le fait d’accéder à un serveur interne depuis l’extérieur s’appelle donc reverse proxy. Le but de cette fonction est d’isoler le serveur Web interne de l’entreprise par rapport à l’extérieur. En effet, souvent les serveurs font l’objet d’attaques de personnes mal intentionnées. A l’aide de cette fonction de reverse proxy, on fait croire au client qu’il se connecte sur une adresse IP pour accéder à la page de l’entreprise, mais avec la fonction NAT (Network Adress Translator), l’adresse du serveur Web n’est pas celle que le client tape. ISA Server, nous permet de réaliser cette fonction de reverse proxy. Dans un cas réel, il faudrait installer un Firewall afin que personne n’accède au serveur Web interne sans s’authentifier. La fonction NAT du serveur ISA devrait être aussi installée. Cependant pour installer la fonction NAT et/ou Firewall sur le serveur ISA qui se trouve installé en mode cache, il faudrait installer le mode Integrated (voir chapitre 4.4). C’est pourquoi ISA propose un service de publication du serveur Web interne simplifié. Afin de l’installer correctement, il faut lui donner quelques paramètres. Voici en résumé les paramètres à entrer. Pour plus d’informations concernant l’installation du reverse proxy, voir le livre « Configuring ISA Server 2000 » à partir de la page 612 chapitre « Publishing Services to the Internet ».

Internet

Client

Client

Server ISAmode

Reverse Proxy

Server Web

IP : 10.0.0.1MASK 255.255.255.0GATEWAY : 10.0.0.20

IP : 10.0.0.20MASK 255.255.255.0GATEWAY : 129.194.184.99

IP : 129.194.184.99MASK 255.255.252.0GATEWAY : 10.0.0.20

IP : 129.194.184.203MASK 255.255.252.0GATEWAY : 129.194.184.3

IP : 129.194.184.206MASK 255.255.252.0GATEWAY : 129.194.184.3


Flux Applicatif 76

6.1 Installation de ISA Server en mode Reverse Proxy

Tout d’abord, il faut ouvrir ISA Management. Ensuite sous Netserver1 et properties, on obtient une fenêtre

En cliquant sur Add, il faut rajouter la règle qui dit sur quelle adresse IP, le serveur ISA va écouter les requêtes des clients. Les paramètres à choisir sont les suivants :

Champs Paramètres Server Netserver1 IP Adress 129.194.184.99 Display Name Optionnel, nous permet de rentrer un nom plus

représentatif que le nom de la machine. Authentification Integrated, Basic, Client Certificate. Ce champ nous

permet de dire comment le client doit s’authentifier sur le serveur ISA pour accéder au serveur Web.

Server Certificate Si le mode d’authentification doit demander un certificat, il faut entré ici le nom du certificat.

Dans cette fenêtre, on peut aussi donner le nombre de connexion TCP possibles sur le serveur ISA. Les différents paramètres que l’on peut régler sont visibles dans la fenêtre à droite.


Flux Applicatif 77

Maintenant que nous avons dit sur quelle adresse IP les clients se connectent, il faut encore pouvoir diffuser les données du serveur Web vers l’extérieur. Pour cela il faut aller dans Publishing -> Web Publishing Rules -> New .

Ensuite, il suffit de suivre les instructions qui apparaissent à l’écran. Cependant, lorsque l’on nous demande si l’on veut rejeter les demandes (Discard the request) ou rediriger vers un serveur Web interne (Redirect the request to this internal Web server (name or IP address)), il faut indiquer cette deuxième option et donner l’adresse du serveur Web comme dans la capture ci-dessous.

Maintenant le serveur Web est prêt à être vu par les clients externes à l’entreprise. Il reste à effectuer quelques tests afin de voir la différence entre une connexion en mode proxy et en mode reverse proxy.

Adresse du serveur Web interne


Flux Applicatif 78

6.2 Tests en mode Reverse Proxy

Deux tests seront effectués dans ce mode de fonctionnement d’ISA serveur. Le premier, consistera simplement à ce qu’un client externe de l’entreprise se connecte sur le serveur Web interne. Le second sera simplement le fait qu’un deuxième client se connectera en même temps que le premier et nous verrons comment le serveur ISA gère cela. Est-ce que le cache peut-être partagé avec le mode reverse proxy, comme il l’est avec le mode proxy ? Toutes ces questions seront traitées dans les différentes études qui suivront.

6.2.1 Connexion d’un client sur le serveur Web interne

Lorsque le client se connecte sur le serveur Web d’une entreprise, il doit taper www.domaine.ch par exemple. Dans mon cas, pour simplifier la chose, je n’ai pas mis de serveur DNS (donc pas d’Active Directory, ni de création de domaine). C’est pourquoi lorsque celui-ci se connecte sur le serveur, il devra taper l’adresse IP pour s’y connecter. Soit 129.194.184.99. Le serveur ISA se chargera de router la requête vers le serveur Web interne.

Client


Get Request From Client to 129.194.184.99

Connexion impossible Il faut une

authentification pour exécuter la requête

On tape les données du login et du password et éventuellement du domaine (voir chapitre 11.3 partie codage Base 64)

OK Login et

password acceptés

Get Request Via ISA 10.0.0.20 Host 10.0.0.1 If modified Since (Last Modified) Referer http://129.194.184.99

Response Not Modified ou OK Date : Date Cache control : max-age = 60

Response Not Modified ou OK Date : Date Cache control : max-age = 60


Flux Applicatif 79

Lors de cette première acquisition, nous remarquons que plusieurs commandes http sont venues s’ajouter à celles précédemment utilisées en mode proxy . Celles-ci sont :

Commandes Fonctionnalités Host Cette commande indique simplement le nom ou l’adresse que

l’on veut atteindre Voir RFC 2616 chapitre 14.23

Referer Cette commande sert au serveur Web pour savoir à qui il doit répondre. Voir RFC 2616 chapitre 14.36

En ce qui concerne la commande Referer, elle est toujours présente dans le paquet http, mais elle nous aide à mieux comprendre le principe du Reverse Proxy. C’est pourquoi je l’ai décrite ici. On la retrouve également dans le mode proxy . On voit donc que le serveur ISA, demande d’abord une authentification de différents types suivant sa configuration. Le client entre le login et le password (Codage en Base 64). Si le login et le password sont corrects, alors il envoie une requête au serveur Web pour savoir si la page a été modifiée ou non. Il rajoute dans les commandes le champ Host et Referer comme énoncé ci-dessus. La réponse du serveur est simple. Il dit simplement au serveur ISA si la page a été modifiée et l’heure de la connexion, avec bien sûr le champ http concernant la validité de la page max-age = xxx ou autre. Dans le cas où le login et le password sont erronés, alors le serveur ISA refuse l’accès et affiche au bout de trois erreurs, une page indiquant que la connexion est impossible.

Le principe que j’avais exposé pour le proxy qui concerne la validité des fichiers sur ISA est aussi valable en reverse proxy.

C’est pourquoi je ne traiterai pas tous les cas possibles comme je l’ai fait en mode proxy. Je pense que l’acquisition de la page précédente, suffit à la compréhension du reverse proxy.

Il reste un point à faire. C’est celui, où plusieurs clients accèdent à la même page en même temps.


Flux Applicatif 80

6.2.2 Connexion de deux clients sur le serveur Web

Maintenant, je vais simuler un deuxième client qui se connecte sur le même serveur Web au même moment que le premier client. Les deux clients qui se connectent, doivent s’authentifier. Une fois cette étape passée, le serveur Web ou le Serveur ISA (suivant les paramètres du cache de ISA) doit retourner les données au client.

La première requête arrive au serveur Web, si les données ne sont pas dans le cache. Cependant, si ISA possède les données de la page dans son cache mais expirées, il va tout de même demander au serveur Web si les données ont été modifiées. Si oui elles sont renvoyées et stockées dans le cache. Sinon le serveur Web envoie Not modified.

Si l’on admet qu’ISA ne possède pas la page en cache, alors la première requête du premier client aura une réponse du serveur. La requête du deuxième client n’ira pas jusqu’au serveur Web mais s’arrêtera au serveur ISA puisqu’entre temps, ISA aura stocké la page accédée par le premier client dans son cache.

Dans le cas où les données dans le cache d’ISA sont encore valides, celles-ci seront entièrement chargée depuis ISA (comme pour le proxy) et aucune requête ne sera faite au serveur Web.

Comme on peut s’apercevoir avec la figure de la page précédente, une seule requête arrivera jusqu’au serveur Web. Les autres s’arrêteront au serveur ISA et les pages demandées seront chargées depuis le cache de celui-ci.

Client A Serveur WebServeur ISA

Get Request from client A To Server Web

Client B

Get Request from client B To Server Web

Login et Password Client A et Client B

OK

Première requête qui arrive Get Request If modified Since (Date)

Response OK ou not modified à la première requête

Response OK ou not modified à la première requête

Response OK ou not modified à la deuxième requête

�

�

��

�

�


Flux Applicatif 81

6.3 Conclusion

L’étude d’ISA à montré qu’il est possible simplement avec le mode cache, de créer un serveur de cache, un proxy et un reverse proxy. Ce dernier étant néanmoins restreint du fait qu’aucune sécurité « sévère » n’est implémentée sur le serveur ISA lorsque l’on installe uniquement le mode cache. Dans le cas ou l’on installe le mode integrated, alors le serveur devient beaucoup plus sûr au niveau des accès (IP Packet Filtering actif). Ce type de serveur (au niveau cache) est intéressant lorsque la connexion vers l’extérieur n’a pas un trop gros débit utile. En effet, plus le débit utile est grand, plus le gain que l’on aura avec un serveur de ce type sera petit. Les diverses fonctionnalités d’ISA sont faciles d’utilisation. Il est malheureusement dommage que les différents modes de mise en cache aient des paramètres plus ou moins fixes et que l’on ne puisse pas les modifier à sa guise. Il est aussi dommage qu’ISA ne permette pas de stocker diverses pages comme celles avec les champs décrit au chapitre 5.10. Ceci étant compréhensible d’un point de vue sécurité mais pour un logiciel qui se dit aussi Firewall, il serait intéressant que l’administrateur du serveur ISA puisse accéder à ces données sans pour autant que d’autres utilisateurs puissent y accéder. En ce qui concerne son installation, elle est très simple. Il suffit de suivre les indications qui apparaissent à l’écran et le tour est joué. Pour conclure, je dirai que même si ce logiciel a plus de fonctionnalité au niveau du Firewall qu’au niveau du cache, il reste un logiciel simple et intéressant pour des entreprises avec un connexion à Internet pas trop rapide. J’imagine typiquement ce logiciel pour une entreprise possédant RNIS ou ADSL avec un maximum de 1000 employés. Même si les tests de Microsoft disent que le serveur ISA peut supporter plus, j’estime qu’au delà, une connexion vers l’extérieur plus rapide est conseillée.


Flux Applicatif 82

Chapitre 7 : LDAP Principes Il y a encore quelques années, lorsqu’une entreprise possédait une base de donnée, elle devait la tenir à jour régulièrement. Ce phénomène s’est compliqué avec l’arrivée de plusieurs bases de données au sein d’une même entreprise. Imaginons par exemple, que celle -ci se divise en départements, que chacune possède une base de données identique (par exemple de clients) et que celui-ci change d’adresse. Celle-ci doit être modifiée dans chacun des serveurs et de façon manuelle. Maintenant, si plusieurs entreprises sont sur des systèmes d’exploitations différents et qu’elles se partagent des bases de données, il n’est pas possible de faire une duplication de la base. Il faut reprendre la base de données à zéro et ajouter une par une les données inscrites. C’est pourquoi est né le protocole LDAP (Lightweight Directory Access Protocol). Il permet de gérer les modifications de données dans la base et de faire en sorte que celles-ci se répercutent sur les autres serveurs même sur les systèmes d’exploitations différents. Il permet aussi de copier des bases de données complètes (Replication) ou d’aller consulter une autre base de données distante (Referral). De plus ce protocole s’applique donc à tout système d’exploitation. Le serveur LDAP ainsi que le browser du côté client peuvent parfaitement fonctionner sous Windows, Linux ou Unix. Avec LDAP, nous ne parlerons plus de base de données mais d’annuaire. Sa fonction première est de retourner un ou plusieurs attributs d’un objet suivant des critères de recherche. Un annuaire LDAP peut être représenté sous forme d’un arbre de la manière suivante. Lorsque l’on recherche une donnée dans l’annuaire LDAP, celle-ci prendra un temps quasi nul. En effet, nous n’avons pas besoin de scruter l’annuaire comme on le fait avec une base de données pour trouver la valeur recherchée. Cet fois, l’emplacement de la valeur recherchée est connue car à l’arborescence de l’annuaire. Cependant, l’annuaire LDAP est beaucoup moins performant en écriture. Le protocole LDAP utilisé pour accéder à ce type d’annuaire, se situe au dessus de TCP.

o=eig

ou = telecommunication ou = informatique

cn = TE3 cn = TE2 cn = IN3 cn = IN2

uid = pgaio

LDAP TCP

IP ETHERNET


Flux Applicatif 83

7.1 Les concepts de LDAP

Le protocole LDAP définit une communication entre client et serveur. Il fournit à l’utilisateur, des commandes pour se connecter, se déconnecter, rechercher, comparer, créer, modifier ou effacer des données dans l’annuaire. La plupart des logiciels serveurs LDAP proposent également un protocole de communication serveur/serveur permettant ainsi l’échange de données entre annuaires (Replication par exemple). Ils permettent aussi de faire référence à d’autres serveurs dans le cas où la valeur recherchée ne se trouverait pas sur le serveur en question (Referral) Le protocole LDAP est normalisé et défini par la RFC 2251. Dans sa version 3, il définit la communication serveur/serveur ainsi que les referrals. En ce qui concerne la réplication, la RFC n’a pas encore été crée mais un semblant de RFC est présent à l’adresse http://globecom.net/ietf/draft/draft-merrells-ldup-model-01.txt. Dans la version 2 du protocole, il n’était pas possible de faire des referral ainsi que de la replication. (voir l’adresse ci-dessous pour les différence entre LDAP V2 et V3). http://developer.novel.com/research/devnotes/1998/august/02/d980802_.pdf Le protocole LDAP utilise le format de codage Basic Encoding Rule (BER). Nous verrons plus tard, que la syntaxe ASN1 entre aussi en jeu.

7.2 Les principes de LDAP

Un annuaire LDAP a des attributs normalisés. Lorsque l’on crée notre annuaire, nous le créons sous forme d’un arbre. Ce qui facilite la recherche dans l’annuaire. Chaque entrée de l’annuaire aura un DN (Distinguish Name) unique, qui correspondra à l’endroit où se trouve l’objet en question. Exemple d’annuaire :

o = entreprise

ou = Genève ou = Vaud

cn = Carouge cn = Meyrin cn = Pully cn = Ouchy

uid

= a

uid

= b

uid

= c

uid

= d

uid

= e

uid

= b

uid

= d

uid

= x

uid

= y

uid

= b

uid

= c

uid

= x

uid

= d


Flux Applicatif 84

Ainsi grâce à cette arborescence, nous pouvons directement donner le dn d’une personne. Si je recherche par exemple le uid = d, l’annuaire me retournera deux valeurs : dn : uid=d, cn=Carouge, ou=Genève, o=entreprise dn : uid=d, cn=Ouchy, ou=Lausanne, o=entreprise. les noms d’attributs les plus communs sont : Attribut Définition Commentaire o Organization Généralement en haut de

l’arbre ou Organization Unit Généralement en dessous de

l’Organization. cn Group Ces groupes peuvent être créés

où l’on veut dans l’annuaire. C’est uniquement ici que l’on peut ajouter des membres.

uid User C’est là où l’on rentre les données des utilisateurs. Où ils sont créés.

D’autres attributs existent, cependant, je ne les énoncerai pas ici. Pour les consulter, se référer au très bon document sur le site : http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/ldap-livre.html Plusieurs données sont présentes à chaque niveau de l’annuaire. En effet, on ne peut pas rajouter tous les attributs optionnels à l’organisation. Par exemple, on ne pourra pas ajouter le mail à l’organisation. Ces attributs sont classés dans un tableau toujours à cette même adresse. En voici un petit résumé. L’attribut général s’appelle ObjectClass. Sans cette classe, on ne pourrait pas ajouter par exemple, un utilisateur. C’est elle qui va gérer toutes les possibilités d’entrées dans l’annuaire LDAP.

Type d’attribut Attributs optionnels possibles Mail Mobile Postal Adress Common Name (obligatoire)

ObjectClass : inetOrgPerson Défini les entrées pour les personnes

Surname (obligatoire)

Telephone Number Postal Adress

ObjectClass : organizationalUnit Défini les entrées pour les Organization Unit

Description

Telephone Number Postal Adress Description

ObjectClass : organization Défini les entrées pour les organisations

BusinessCategory


Flux Applicatif 85

7.3 Les annuaires LDAP

Un annuaire est une base de données spécialement optimisée pour la recherche, le survol et la lecture rapide d'informations. Les annuaires contiennent de manière générale des informations descriptives caractérisées par des attributs (nom, mail, téléphone etc…) et proposent des filtres de recherche. Les annuaires sont configurés pour répondre en un temps quasi nul à de grands volumes de requêtes d'interrogations ou de recherches. Ils peuvent en outre avoir des fonctions de replication ou de referral. Ainsi les commandes qui peuvent être effectuées seront définies dans le tableau de la page suivante.

Opération LDAP Description Search Recherche dans l’annuaire d’objets à partir de critères Compare Comparaison d’un contenu de deux objets Add Ajout d’une entrée Modify Modification du contenu d’une entrée Delete Suppression d’une entrée Rename (Modify DN) Modification du DN d’une entrée Bind Connexion au serveur Unbind Déconnexion Abandon Abandon d’une opération en cours Extended Opérations étendues (LDAP Version 3) Lors d’une recherche d’une donnée, celle-ci peut s’effectuer sur plusieurs niveau de l’annuaire. Le champ scope défini cette profondeur. Il peut contenir trois valeurs :

o=eig



uid = toto

Scope = base


Flux Applicatif 86

o=eig



uid = toto

o=eig



uid = toto

7.4 Les choix effectués Il existe diverses possibilités concernant le serveur et le client à utiliser. A la suite de la discussion avec M.Dutheil, j’avais le choix entre OpenLDAP ou iPlanet comme serveur. M.Garcia ancien étudiant de l’école d’Ingénieurs de Genève, travaillant maintenant dans une entreprise informatique et ayant fait des projets sur LDAP, m’a conseillé le serveur iPlanet. C’est pourquoi ma décision finale a été de choisir ce serveur pour la gestion de mon annuaire. En ce qui concerne le choix du client, il y avait aussi deux possibilités. Soit le logiciel sur une base JAVA ou un soft tournant sur Windows uniquement. Mon choix c’est finalement porter sur le premier, car le client qui tournait sous Windows ne me permettait pas de faire des recherches dans l’annuaire. De plus la version freeware que l’on trouve sur Internet du logiciel tournant sur Windows est limitée.

Scope = onelevel search

Scope = subtree


Flux Applicatif 87

7.4.1 Installation du serveur iPlanet

Tout d’abord, il faut charger le logiciel iPlanet Directory Server 5.0 sur le site www.iplanet.com Ensuite, il faut le décompresser et pour finir l’installer. Je ne décrirai pas l’installation dans ce chapitre car elle est plus que basic. Il suffit juste d’indiquer les mots de passe à utiliser et le nom de l’administrateur qui peut se connecter sur ce serveur en plus du Directory Manager qui est un « super administrateur ». C’est lui qui peut modifier des données dans l’annuaire et à distance via le browser du client.

7.4.2 Installation du client

Deux logiciels sont à notre disposition, le premier est un browser LDAP sur un plate-forme JAVA. Il suffit de le télécharger à l’adresse http://www.iit.edu/~gawojar/ldap . Pour l’installation, il suffit de suivre le guide d’installation fourni sur le site. De plus il nous faudra télécharger JAVA. Toute la procédure est indiquée dans le document. Ce logiciel se nomme : LDAP Browser/Editor 2.8.1

Le deuxième programme à disposition est un software de Softerra. Il suffit de le télécharger à l’adresse : http://www.softerra.com/ et de choisir le lien download. Aucune installation n’est requise. Il suffit de lancer l’application. Ce logiciel se nomme : Softerra LDAP Browser/Editor 1.0

Après avoir installé les deux logiciels et les avoir comparé, j’estime que le premier est sensiblement meilleur, car il permet de rechercher une donnée dans l’annuaire auquel on se connecte.

7.5 Création de l’annuaire LDAP

Server iPlanetEIG

Server iPlanetEleves

Server iPlanetProfesseurs

Client LDAP

Referral

Referral

Connexion sur l'annuaire

Maintenant que nous avons tout les logiciels à disposition, nous sommes prêts à créer notre annuaire. Voici l’architecture choisie :


Flux Applicatif 88

7.5.1 Architecture Annuaire EIG

7.5.2 Architecture Annuaire Elèves

o=eig



Liste des membresdynamiques du

serveur élèves (TE3)+

professeurs (TE3)

Liste des membresdynamiques du

serveur élèves (IN3)+

professeurs (IN3)

o=eleves o=professeurs

Referral sur le serveur eleves

Referral sur leserveur professeurs

o=eleves

cn = TE3 ou = Liste d'élèvescn = IN3

uid = PGaio (XX)uid = DCotte (X)

uid = PLogean (XX)uid = MPasquali (XX)uid = YSouchon (XX)

uid = SBorsa (XX)uid = SBancal (X)

Liste d'élèves

Liste desmembresstatiques

(X)


(XX)


Flux Applicatif 89

7.5.3 Architecture Annuaire Professeurs

7.5.4 Création de membres

Maintenant que nous avons créé nos annuaires, il reste à ajouter des membres dans des groupes. En effet, un élève appartient à une classe bien définie (TE3 ou IN3 en l’occurrence) et de même pour un professeur.

Cependant le fait de créer des membres posent quelques problèmes. Nous pouvons créer des membres statiques ou dynamiques. Il faut savoir que l’ajout d’un membre statique peut se faire uniquement d’un point de vue local. C’est-à-dire, que l’utilisateur qui va être choisi doit se trouver dans l’annuaire de la machine en question. Nous ne pouvons donc pas faire un referral sur un autre serveur et créer un membre statique d’un groupe local qui se trouve sur une machine distante.

o=professeurs

cn = TE3 ou = Liste des professeurscn = IN3

uid = EJenny (X) + (XX)uid = GLitzistorf (XX)

Liste des professeurs


(X)


(XX)

o=eig


cn = TE3

Liste d'élèvessur le serveur iPlanet

DISTANT

uid = PGaiouid = DCotte

uid = PLogeanuid = MPasqualiuid = YSouchon

uid = SBorsauid = SBancal

serveur iPlanet LOCALReferall

Membre STATIQUE IMPOSSIBLE


Flux Applicatif 90

A cause de cette restriction, j’ai dû créé des membres dynamiques. Cependant, deux configurations sont possibles avec les membres dynamiques. La première consiste à créer sur le serveur distant des groupes de membres statiques. Ainsi la gestion des membres ne se fera pas sur le serveur local.

Comme on peut le voir sur ce schéma, nous avons à l’intérieur du serveur distant, une liste d’élèves en vrac, avec la création d’un groupe de membres statiques correspondant aux élèves de la TE3. A l’aide d’un referral sur le serveur o=eleves, je pourrai créer des membres dynamique du groupe TE3 distant sur mon serveur local.

Cependant cette architecture a une restriction. L’administration des membres se fait sur le serveur distant. Il se peut que si cette base de données soit commune à plusieurs entreprises, l’administrateur de celle-ci ne veuille pas s’amuser à gérer les différents annuaires. C’est pourquoi, une deuxième architecture propose de créer des membres dynamiques d’une façon plus précise en indiquant le nom (uid) de la personne qui sera membre du serveur local.

o=eig


cn = TE3

serveur iPlanet LOCAL

o=eleves

cn = TE3 ou = Liste des élèves


(X)uid = PGaiouid = DCotte


uid = SBorsauid = SBancalMembres statiques

serveur iPlanet DISTANT

Referral

Membres Dynamiques

o=eig


cn = TE3

serveur iPlanet LOCAL

o=eleves

ou = Liste des élèves

uid = PGaiouid = DCotte


uid = SBorsauid = SBancal

serveur iPlanet DISTANT

Referral

Membres Dynamiquesavec lien sur un uid précis


Flux Applicatif 91

Avec cette seconde architecture, l’administrateur local, peut gérer les membres de l’annuaire distant. Pour ma part je considère la première solution comme la plus simple au niveau de la gestion des membres. Certes le fait que l’administrateur distant ne veuille pas gérer les membres des autres est un problème mais il me semble que dans une entreprise sérieuse, la gestion des utilisateurs ne doit pas poser de problèmes de ce genre.

7.6 Conclusion

Dans ce chapitre, j’ai exposé quelques principes de LDAP. Cependant l’objectif principal est de comprendre le protocole qui est utilisé pour un échange de données dans l’annuaire. C’est pourquoi la théorie sur LDAP ne sera pas plus détaillée. Pour plus de renseignements sur LDAP au niveau théorique, se référer aux très bons documents aux adresses : http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/ldap-livre.html http://www.cru.fr/ldap/tutorial/tutorial_ldap.pdf . Lors des chapitres suivants, je montrerai comment mettre en place un referral (chapitre 9) ainsi qu’une replication (chapitre 10) et ce que cela implique au niveau du protocole. Cependant avant d’étudier ces applications, il faut d’abord étudier et comprendre le protocole LDAP. Pour cela, je ferai plusieurs tests entre un client et un serveur iPlanet (chapitre 8).


Flux Applicatif 92

Chapitre 8 : LDAP Protocole Dans ce chapitre, je vais présenter le protocole LDAP à un niveau beaucoup plus approfondi. Je ne me contenterai pas d’énoncer ces principes comme au chapitre 7, mais j’irai dans l’étude au niveau hexadécimal du protocole. En effet, la première partie de ce chapitre consistera à comprendre comment le protocole LDAP est transmis. Comme pour TCP ou IP, j'essayerai de faire ressortir la structure de la trame du protocole LDAP. Par la suite j’étudierai un simple échange LDAP lorsque l’on accède à un annuaire. Je ferai aussi une étude sur le comportement d’un referral. Pour terminer, je ferai une réplication entre deux serveurs et regarderai toujours au niveau du protocole, ce que cela engendre comme trafic. Cependant, avant de regarder attentivement les paquets qui sont transmis, regardons comment se passe un échange entre client et serveur LDAP. Lorsque l’on initialise la connexion avec l’annuaire, une connexion TCP est tout d’abord établie. Ensuite c’est une connexion LDAP qui est établie par le biais des paquets Bind Request et Bind Response. Une fois connecté, le client fait une recherche (Search Request) sur le serveur LDAP et celui-ci lui renvoie les données avec Search Response . Une fois que le serveur a envoyé toutes les données, alors celui-ci envoi Search Response Simple pour dire qu’il a fini d’émettre. Le numéro inscrit à côté de ces paquets est le numéro d’application LDAP. Tout les paquets seront décrits en détail dans les chapitres suivants.

Server iPlanet

Client

Connexion TCP

Bind Request (0)

Search Request (3)

Bind Response (1)

Search Response (4)

Search Response Simple (5)


Flux Applicatif 93

8.1 Structure de la trame du protocole LDAP

Comme énoncé dans le chapitre précédent, le protocole LDAP se situe au dessus de la couche TCP. En regardant plus attentivement un paquet LDAP, on s’aperçoit que les données transmisent à l’intérieur de ceux-ci sont en réalité issues de la structure du langage ASN1 (Abstract Syntax Notation 1) et ensuite codés en BER (Basic Encoding Rules). Ainsi chaque paquet de type ASN1 (donc chaque paquet LDAP) est composé d’un champ type (Type) suivi d’un champ longueur (Length), suivi d’un champ contenu (Content).

Type Length Content Dans le cas où le champ Length est nul (00), le champ Content ne sera pas transmis.

8.1.1 Le champ Type

Le champ Type est défini sur 8 bits et de la manière suivante :

7 6 5 4 3 2 1 0

Type Class Primitive Construct Tag Value

Les deux premiers bits de ce champ type contiennent des informations sur le type des informations qui seront transmises. Voici les différents cas possibles :

Bit N°7 Bit N°6 Type Class Commentaires

0 0 Universal

Ce type de classe peut être Primitif ou construit. C’est ici que l’on défini le type de données à transmettre.

0 1 Application

Ce type est spécifique à une application. Dans mon cas au serveur iPlanet.

Ces deux types sont les plus répandus dans le standard LDAP. Cependant, il en existe encore deux qui sont plus spécifiques aux programmeurs d’une entreprise.


Flux Applicatif 94

Bit N°7 Bit N°6 Type Class Commentaires

1 0 Private

Ce type est spécifique à une entreprise. Application entièrement privée.

1 1 Context Specific

Ce type permet d’ajouter une application de type privé.

Le type de classe Universal est le seul à être normalisé. Dans le tableau ci-dessous, je vais énoncés quelque unes des valeurs possibles. Pour voir toutes les valeurs possibles, consulter le site http://people.ne.mediaone.net/wasser/ASN1/BasicEncodingRules.html Suivant les types de ces valeurs, ceux-ci seront alors définis comme primitifs (0) ou construits (1). Cela affectera la valeur du bit N°5 du champ Type. Un type primitif contient une seule valeur dans son champ Content, tandis que le type Construit, peut contenir plusieurs valeurs à la suite.

Type Tag Primitif construit

Type des données

Universal 1 Primitif Boolean Universal 2 Primitif Integer Universal 3 Primitif Bit String Universal 4 Primitif Octet String Universal 5 Primitif Null Universal 6 Primitif Object Identifier (OID) Universal 10 Primitif Enumerated Universal 16 Construit Sequence Universal 17 Construit Set

Il nous reste maintenant, à définir la valeur du champ Tag Value. Cette valeur est simplement la valeur soit universal soit de l’application utilisée. Par exemple, si je veux faire une application LDAP de type Search Request ces 8 bits seront :

7 6 5 4 3 2 1 0 0 1 0 0 0 0 1 1 } }

}

Type Application Primitif Application N°3 Search Request


Flux Applicatif 95

Avec le tableau de la page précédente, nous voyons que LDAP à défini des numéros d’applications pour chacune de ses requêtes ou réponses. En effet, voici les commandes LDAP les plus courantes. Voir RFC 1777 (LDAP Version 2) et RFC 2251 (LDAP Version 3)

Numéro de l’application

Nom de l’application

0 Bind Request 1 Bind Response 2 Unbind Request 3 Search Request 4 Search Response 5 Search Response Simple 6 Modifiy Request 7 Modify Response 8 Add Request 9 Add Response

10 Del Request 11 Del Response 14 Compare Request 15 Compare Response 16 Abandon Request 19 Search Response Reference 23 Extended Request 24 Extended Response

8.1.2 Le champ Length

le second champ présent dans une structure de type ASN1 est le champ Length . Celui-ci à priori nous indique simplement la longueur des données du champ Content. Cependant, si ce champ est plus petit que 128 bits, alors la valeur hexadécimale du champ Length sera de la longueur du champ Content. Si le nombre de bits dépassent cette valeur alors le champ Length indiquera 81 en hexadécimal et la longueur du champ content sera définie dans l’octet suivant. Il se peut cependant que le champ Content soit d’une longueur indéfinie. Dans ce cas le champ Length indiquera toujours la valeur 80 en hexadécimale. Ce cas peut se produire lorsque l’on transmet le sommet d’un arbre sans savoir qui se trouve en dessous ou lorsque le décodage n’arrive pas à ce faire.

Length ≤ 128 Bits Codage normal en hexadécimal Length > 128 bits Valeur de codage = 81 en hexadécimal et suite du codage

de la longueur sur le prochain octet.

Length > 256 Bits Valeur de codage = 82 en hexadécimal et suite du codage de la longueur sur les deux prochains octets.


Flux Applicatif 96

8.1.3 Le champ Content

C’est le champ où les données sont transmises réellement. La structure de ce champ est la suivante :

Si l’on a le type primitif comme Type Class, alors dans le champ Content, il y aura uniquement, la donnée correspondant à ce type. Au contraire, si on a le type construit, cela veut dire que dans ce champ, plusieurs valeurs seront transmises.

Ainsi avec le type primitif on a :

Type Length Content Tandis qu’avec le type construit on aura :

Grâce à cette encapsulation, plusieurs données de même type (Application ou Universal), pourront être insérées l’une derrière l’autre. Ceci aura pour effet, un gain de temps et de trafic.

Maintenant que nous avons décrit toutes les possibilités qu’offre LDAP au niveau de son protocole, il reste à étudier un paquet pour que l’explication soit plus parlante. Pour cela j’ai choisi un paquet Search Response que je détaillerai de fond en comble. Il faut bien se rendre compte que la structure de ce paquet est la même que pour un autre. C’est pourquoi je n’en étudierai qu’un seul.

Type Length Content

Type Length Content Type Length Content


Flux Applicatif 97

8.2 Etude détaillée du paquet Search Response Ce paquet est la réponse au paquet Search Request . Nous avons dans ce paquet toutes les données transmises par le serveur lors d’un accès à distance sur l’annuaire. Voici ce que l’analyseur nous donne : (Je ne détaillerai que le protocole LDAP) Source Adresse Destination Adresse Annuaire LDAP Client LDAP 129.194.187.52 129.194.184.203

TCP : Length 96 bytes Source port : 389 Destination port : 4300 LDAP : ProtocolOP : SearchResponse (4) LDAP : Message ID LDAP : ProtocolOp = SearchResponse LDAP : Object Name = cn=te3,ou=telecommunication,o=filiere,o=eig LDAP : Attribute Type = objectclass LDAP : Attribute Value = top LDAP : Attribute Value = groupofuniquenames Maintenant, si l’on regarde ce qui correspond en hexadécimal, nous aurons :

LDAP : ProtocolOP : SearchResponse (4) 30 5E 02 01 LDAP : Message ID 04 LDAP : ProtocolOp = SearchResponse 64 59 04 2B LDAP : Object Name = cn=te3,ou=telecommunication,o=filiere,o=eig 63 6E 3D 54 45 33 2C 6F 75 3D 74 65 6C 65 63 6F 6D 6D 75 6E 69 63 61 74 69 6F 6E 2C 6F 3D 66 69 6C 69 65 72 65 2C 6F 3D 65 69 67 LDAP : Attribute Type = objectclass 30 2A 30 28 04 0B 6F 62 6A 65 63 74 63 6C 61 73 73 LDAP : Attribute Value = top 31 19 04 03 74 6F 70 LDAP : Attribute Value = groupofuniquenames 04 12 67 72 6F 75 70 6F 66 75 6E 69 71 75 65 6E 61 6D 65 73


Flux Applicatif 98

Pour comprendre à quoi correspondent exactement ces valeurs hexadécimales représentées au dessous des champs LDAP, se référer aux pages suivantes qui montrent dans le détail, quelles sont les informations contenues dans chaque paquet. La toute première valeur en hexadécimal est de 30. Ce n’est pas un hasard, c’est comme cela que l’on reconnaît que les données qui suivent sont du type ASN1. Regardons plus en détail ces parties de paquets. Il faut toujours tenir d’œil, la forme d’une trame : Type, Lenght, Content

LDAP : ProtocolOP : SearchResponse (4) 30 5E 02 01

LDAP : Message ID 04

Structure de la

trame Data en hexadécimal Décodage

Type 30 00 1 1000

Univeral (00) de type construit (1) et de type Sequence (10000 = 16)

Length 5E Length = 94 bytes restant à transmettre Type 02 Donnée de type Integer

Length 01 De longueur = 1 byte Content Content 04 Message ID

LDAP : ProtocolOp = SearchResponse 64 59 04 2B

LDAP : Object Name = cn=te3,ou=telecommunication,o=filiere,o=eig 63 6E 3D 54 45 33 2C 6F 75 3D 74 65 6C 65 63 6F 6D 6D 75 6E 69 63 61 74 69 6F 6E 2C 6F 3D 66 69 6C 69 65 72 65 2C 6F 3D 65 69 67

Structure de la


Type 64 01 1 00100

Application (01) de type construit (1) et le choix N°4= SearchResponse

Length 59 Length = 89 bytes restant à transmettre Type 04 Donnée de type Octet String

Length 2B De longueur = 43 bytes

Content Content

63 6E 3D 54 45 33 2C 6F 75 3D 74 65 6C 65 63 6F 6D 6D 75 6E 69 63 61 74 69 6F 6E 2C 6F 3D 66 69 6C 69 65 72 65 2C 6F 3D 65 69 67

cn=te3,ou=telecommunication,o=filiere,o=eig


Flux Applicatif 99

LDAP : Attribute Type = objectclass 30 2A 30 28 04 0B 6F 62 6A 65 63 74 63 6C 61 73 73

Structure de la trame Data en

hexadécimal Décodage

Type 30 00 1 1000 Univeral (00) de type construit (1) et de type Sequence (10000 = 16)

Length 2A Length = 42 bytes restant à transmettre

Type 30 00 1 1000 Univeral (00) de type construit (1) et de type Sequence (10000 = 16)

Length 28 De longueur = 40 bytes Type 04 Donnée de type Octet String

Length 0B De longueur = 11 bytes

Content

Content Content 6F 62 6A 65 63 74

63 6C 61 73 73 objectclass

LDAP : Attribute Value = top 31 19 04 03 74 6F 70 LDAP : Attribute Value = groupofuniquenames 04 12 67 72 6F 75 70 6F 66 75 6E 69 71 75 65 6E 61 6D 65 73

Structure de la


Type 31 00 1 10001 Universal (00) de type construit (1) et de type Set (10001 = 17)

Length 19 Length = 19 bytes restant à transmettre Type 04 Donnée de type Octet String

Length 03 De longueur = 3 bytes Content Content 74 6F 70 TOP

Type 04 Donnée de type Octet String Length 12 De longueur = 3 bytes

Content Content 67 72 6F 75 70 6F 66 75 6E

69 71 75 65 6E 61 6D 65 73 groupofuniquenames

A l’aide de ces captures, on remarque bien que la suite Type, Length , Content est bel et bien respectée. Ensuite suivant le type de données à transmettre, le codage va être différent (Application Search Request(63), Application Search Response (65), etc…). De plus lorsque l’on veut transmettre plusieurs données de même type, il n’est pas nécessaire de renvoyer un nouveau paquet entier avec le champ type = universal ou Application par exemple. C’est le cas dans le dernier paquet traité.


Flux Applicatif 100

8.3 Accès à un annuaire

Lorsque j’accède à un annuaire, je dois me connecter sur celui-ci. Je dois tout d’abord effectuer une connexion TCP classique, puis une connexion LDAP. Pour cela, deux paquets servent à la connexion. Le paquet Bind Request qui demande la connexion et le paquet Bind Response qui répond à la requête avec des paramètres suivant le résultat de la requête.

Dans le paquet Bind Request, plusieurs informations sont envoyées par le client.

En effet, celui-ci envoie aussi la version du protocole choisi, le nom de la personne qui se connecte sur l’annuaire et le type d’authentification sur le serveur. Il faut juste savoir que l’on peut se connecter sur le serveur en anonyme ou en authentifié, ce qui impliquera des restrictions sur les possibilités de gestion de l’annuaire. Les options avancées d’authentification servent lors de l’accès par d’autres serveurs pour une réplication par exemple. En ce qui concerne le paquet Bind Response, celui-ci renverra juste l’état de la réponse. Elle peut être de type success, protocol Error, ou encore bien d’autres valeurs. Toutes les valeurs possibles sont décrites dans la RFC 2251.

Dans le cas où le serveur ne peut pas être atteinte, la connexion TCP n’arrivera pas à s’établir et de ce fait aucun paquet LDAP ne sera émis. Il faut obligatoirement que la connexion TCP soit ouverte pour que le premier paquet Bind Request soit émis.

Server iPlanet

Client

Connexion TCP

Bind Request (0)

Bind Response (1)


Flux Applicatif 101

8.4 Recherches de données dans l’annuaire

Une fois connecté correctement, il faut que le serveur LDAP envoie les données au client. Comme pour tout échange LDAP client-serveur, c’est le client qui commence l’échange.

Le client qui fait la requête, envoie cette fois-ci beaucoup plus de données au serveur. En effet, si l’on regarde la RFC 1777 ou 2251 qui définit exactement les champs transmis, on s’aperçoit que les plus importants sont :

SearchRequest ::= [APPLICATION 3] SEQUENCE { baseObject LDAPDN, scope ENUMERATED { }, sizeLimit INTEGER (0 .. maxInt), timeLimit INTEGER (0 .. maxInt), }

baseObject est le nom de l’annuaire sur lequel on se connecte. Typiquement o=eig scope est le niveau de la recherche (voir chapitre 7.3) size Limit est la taille limite des données que le client est prêt à recevoir time Limit est le temps maximum que peut attendre le client pour recevoir les données.

Le serveur a maintenant reçu la requête de la part du client., il est prêt à lui envoyer les données. Il le fait simplement en indiquant, le chemin de la donnée dans l’arbre. Si par exemple un user (uid) est dans l’annuaire Elèves et dans la classe TE3.

Le serveur renverra uid=pgaio, cn=TE3, o=Elèves Une fois que le serveur a renvoyé toutes les données qui se trouvent chez lui, il envoi un paquet Search Response Simple au client pour lui dire que la transaction est terminée. Dans ce paquet est envoyé le paramètre success.

Server iPlanet

Client

SearchRequest (3)

SearchResponse (4)

SearchResponseSimple (5)

o=Elèves

cn = TE3

uid = toto

LDAP: ProtocolOp: SearchRequest (3) LDAP: MessageID LDAP: ProtocolOp = SearchRequest LDAP: Base Object = o=eleves, o=eig LDAP: Scope = Single Level LDAP: Deref Aliases = Always Deref Aliases LDAP: Size Limit = No Limit LDAP: Time Limit = No Limit


Flux Applicatif 102

8.5 Ajout d’un utilisateur

Lorsque je me connecte sur mon serveur iPlanet par le biais du client LDAP, j’ai la possibilité d’ajouter de nouveaux utilisateurs dans le cas où je me connecte en tant que « Super Manager ». En effet, une seule personne est apte à modifier des données dans l’annuaire LDAP. Dans mon cas, il s’appelle Directory Manager (nom par défaut dans le serveur iPlanet 5.0). Ainsi une fois connecté avec ce login et son mot de passe correspondant, je peux ajouter un utilisateur. Dans le cas où je me connecte sous un autre compte valide, je ne pourrai que consulter les données de l’annuaire. J’ajoute donc un utilisateur, et vois ce que j’obtient au niveau du protocole.

Si l’on regarde de plus prêt les paquets Add Request et Add Response voici ce que l’on obtient.

On voit très bien ici que le nouveau compte a été créé dans l’annuaire à l’emplacement cn=gaio, o=eleves, o=eig et que les champs entrés lors de l’activation du compte sont sn=pascal et cn=gaio. Ces deux champs sont ceux à remplir obligatoirement lors de la création de l’utilisateur. En ce qui concerne la réponse du serveur, elle dit simplement que le nouvel utilisateur a été ajouté. Les paquets suivants (Search) sont présents afin d’afficher physiquement la nouvelle valeur entrée sur le browser du client.

Server iPlanetClient

SearchRequest (3)

SearchResponse (4)

SearchResponseSimple (5)

Add Request (8)

Add Response (9)

LDAP: ProtocolOp: AddRequest (8) LDAP: MessageID LDAP: ProtocolOp = AddRequest LDAP: Object Name = cn=gaio, o=eleves, o=eig LDAP: Attribute Type = objectclass LDAP: Attribute Value = top LDAP: Attribute Value = person LDAP: Attribute Type = sn

LDAP: Attribute Value = pascal

LDAP: ProtocolOp: AddResponse (9) LDAP: MessageID LDAP: ProtocolOp = AddResponse

LDAP: Result Code = Success


Flux Applicatif 103

8.6 Delete d’une branche de l’annuaire

Lorsque l’on effectue maintenant un effacement d’une donnée de l’annuaire (personne qui quitte l’entreprise par exemple), cela se passe de la même manière que lorsque l’on ajoute un nouvel utilisateur. Bien sûr, il s’agit ici de l’enlever et pas de l’ajouter mais le principe au niveau protocole est identique.

Lors de l’opération Del Request, le client envoie simplement le dn (cn=gaio, o=eleves, o=eig) de l’utilisateur auquel il faut enlever l’entrée dans l’annuaire. Contrairement à l’ajout, il n’y a pas besoin de faire un search car il n’y a pas de données à afficher. Lorsque l’on effectue cette opération la donnée disparaît physiquement dans l’annuaire. Nous avons aussi la possibilité d’effacer directement toute une branche de l’annuaire. Afin que le client puisse effacer toutes les données de l’arbre, il faut qu’il connaisse toutes les données se trouvant dans la branche. Pour cela, le client va effectuer un search Request sur toute la branche et effacer une par une toutes les données qui s’y trouvent. Pour finir il effacera le haut de la branche. Ici la branche o=eleves contient une seule donnée (uid = pgaio).


Del Request (10)

Del Response (11)

LDAP: ProtocolOp: DelRequest (10) LDAP: MessageID LDAP: ProtocolOp = DelRequest LDAP: Object Name = cn=gaio, o=eleves, o=eig

LDAP: ProtocolOp: DelResponse (11) LDAP: MessageID LDAP: ProtocolOp = DelResponse LDAP: Result Code = Success

Server iPlanet

Client

Search Response (4)uid = pgaio

Search Response Simple (5 )

Search Request (3)search des données se trouvant dans la branche

Search Response (4)o=eleves

Del Request (10)uid = pgaio

Del Response (11)

Del Request (10)o=eleves

Del Response (11)


Flux Applicatif 104

8.7 Server LDAP Down

Il se peut que le serveur LDAP soit hors service (machine éteinte ou serveur arrêté) pour diverses raisons. De ce fait, plus personne ne devrait pouvoir consulter des données dans celui-ci. Nous avons vu dans le chapitre 5 concernant ISA Server ce qui se passait au niveau protocole lorsqu’un serveur Web était hors service. Voyons comment cela se passe avec un serveur LDAP. Il faut rappeler que pour atteindre un serveur LDAP il faut d’abord établir une connexion TCP puis une connexion LDAP. De ce fait si j’essaye de me connecter sur le serveur alors que celui-ci est éteint, c’est au niveau TCP que la connexion n’aboutira pas (après plusieurs essais de connexion).

Maintenant, je prends le cas où l’on est connecté depuis un moment sur l’annuaire LDAP via le browser du client et que le serveur s’arrête brusquement. Les connexions TCP et LDAP sont établies. Si l’on essaye d’atteindre une donnée voici ce qui arrive.

De la même manière qu’avant, le paquet Search Request va se répéter jusqu’à 5 fois car aucune réponse n’est envoyée par le serveur iPlanet (down) Remarque : La fréquence entre deux paquets Search Request est toujours multipliée par deux entre chaque paquet.

Paquet Search Request Time

Différence des fréquences

des paquets Numéro 1 0.1 sec 0 Numéro 2 0.4 sec + 0.3 sec Numéro 3 1.0 sec + 0.6 sec Numéro 4 2.2 sec + 1.2 sec Numéro 5 4.6 sec + 2.4 sec


TCP SYN

TCP SYN

TCP SYN


Search Request (3)

Search Request (3)

Search Request (3)

Search Request (3)

Search Request (3)


Flux Applicatif 105

8.8 Connexion avec Size Limit limité

Il est possible de se connecter avec des paramètres spéciaux sur le serveur iPlanet. En effet, le client peut demander à ce que le serveur ne lui envoie pas toutes les données de son annuaire lors de la connexion. C’est le but du paramètre Size Limit. Il permet de limiter les données transmises par le serveur LDAP. Prenons l’exemple d’un annuaire qui contient 500 données. Moi client, je ne veux pas que le serveur me retourne ses 500 données, car je perdrai du temps. Ainsi je lui dit de m’envoyer uniquement 50 éléments de son annuaire. Il faut bien voir que c’est le client qui envoit ce paramètre au serveur lorsqu’il se connecte sur l’annuaire et fait sa première recherche. Mais voyons au niveau du protocole comment cela se passe. Pour ma part j’ai configuré le client pour qu’il n’accepte qu’une seule donnée (Size Limit = 1)

Après cette étude de protocole, on constate que le serveur LDAP a envoyé deux données malgré que le paramètre Size Limit est de 1. Cela vient du fait que ce paramètre affecte le nombre de données transmises par niveau de l’annuaire. Ainsi, si j’ai un annuaire qui est construit de façon « horizontal », alors une seule donnée par niveau sera retournée au client (voir figure de la page suivante)


SearchRequest (3)Size Limit = 0x00000001

SearchResponse (4)

SearchResponseSimple (5)success

Bind Request (0)

Bind Response (1)

SearchRequest (3)Size Limit = 0x00000001

SearchResponse (4)

SearchResponseSimple (5)Size Limit Exceeded


Flux Applicatif 106

Seules les données en gras seront retournées au client. Le reste sera ignoré. La priorité des données envoyées sont en fonction de l’ordre alphabétique. Lorsque le serveur veut envoyer une autre donnée se trouvant sur le même niveau de l’arbre, celui-ci se refuse de le faire ayant reçu le paramètre Size Limit = 1 du client. Par contre, il peut envoyer plusieurs données sur un niveau différent. Ainsi le serveur LDAP envoi un message d’erreur au client en lui disant Size Limit Exceeded . Ce message inclus dans le paquet Search Reponse Simple indique que les données transmises ont étés faites correctement mais qu’il a envoyé la capacité maximale requise par le client. Pour mieux comprendre le phénomène du Size Limit par niveau, prenons le cas où Size Limit = 2.

Ici on se rend bien compte que le paramètre Size Limit n’est valable que pour un seul niveau et pas pour tout l’arbre.

o=eig



uid = dcotte

Niveau 0

Niveau 1

Niveau 2

o=eig



Niveau 0

Niveau 1

Niveau 2

2 uid trouvés 2 uid trouvés 2 uid trouvés


Flux Applicatif 107

8.9 Déconnexion de l’annuaire

Lorsque l’on se déconnecte de l’annuaire, le client envoie un Unbind Request. Le serveur n’est pas obligé de répondre. Il sait que la connexion avec le client est terminée. Par la suite la déconnexion au niveau TCP se fait de façon standard à l’aide de ACK. Il se peut parfois que ce soit le serveur qui ferme la connexion. Ceci pour plusieurs raisons par exemple quand l’administrateur le force à redémarrer. Dans ce cas c’est le serveur qui envoie la commande Unbind Request. Le client comprend qu’il doit fermer la connexion. Mais généralement c’est le client qui se déconnecte de l’annuaire et c’est donc lui qui envoie cette commande.

Ainsi la connexion est terminée.

8.10 Conclusion Dans ce chapitre, nous avons vu les différents paquets ainsi que les différents paramètres qui sont transmis à l’intérieur. Il est évident que lorsque l’on regarde la RFC 2251 ou 1777, cela correspond exactement à ce que l’on a au niveau de l’analyseur de protocole. Ce qui facilite grandement la compréhension des différents paquets émis. Ce que l’on peut constater, c’est que c’est toujours le client qui effectue les opérations d’ajout, d’effacement des données ou autre chose encore. Le serveur n’est là « que pour répondre ». A chaque Request du client, le serveur effectue l’opération et répond par un paquet Response s’il doit transmettre une donnée et un paquet Response Simple lorsqu’il a terminé de transmettre ses données. Je constate donc que le protocole LDAP n’est pas très compliqué et qu’il fonctionne sur un échange de Question-Réponse. De plus les commandes utilisées pour les applications LDAP sont très faciles à comprendre et selon moi très explicites. En effet, pour effacer une donnée, on a un paquet Del Request, pour ajouter une donnée, un paquet Add Request. Je pourrai tous les citer, mais cela sera à chaque fois la même chose. Des mots simples pour une meilleure compréhension, voilà que je retiens de plus frappant du protocole LDAP.

Server iPlanet

Client

Unbind Request


Flux Applicatif 108

Chapitre 9 : LDAP Referral Il se peut certaines fois que des données ne soient pas toutes stockées dans un même annuaire et que le serveur renvoie au client l’adresse d’un autre serveur LDAP où il peut aller chercher l’information demandée. Ce principe de renvoie de référence s’appelle un Referral. Ce mécanisme est assez simple à comprendre mais il faut tenir compte de plusieurs restrictions. Lorsque l’on fait un referral d’un serveur vers un autre, la branche sur laquelle on accède doit porter le même nom et être du même type (o, ou , cn, etc…) que d’où part le renvoi de référence. Un autre problème qui peut se créer avec ces referrals, c’est le cas où l’on ne fait pas attention et plusieurs referrals sont présents sur le même serveur. Il peut y avoir un interblocage.

cn = IN2

uid=dcotte cn = sbancal

ou = IN2


cn = classe

o=eig



cn = IN3 cn = IN2

Referral incorrect

nom érroné et type incorrect

Ref

erra

lin

corr

ect

nom

inco

rrec

tty

pe in

corr

ect

Referralcorrect

Annuaire A

Annuaire B Annuaire C

Refer

ral

Referral

Referral

INTERBLOCAGE


Flux Applicatif 109

9.1 Syntaxe d’un Referral

Un referral LDAP contient un url qui sera renvoyé au client. Les informations transmises dans ce referral sont :

- Host Name du serveur à contacter - Port sur lequel il faut se connecter (port LDAP = 389 par défaut) - DN pour savoir sur quel base il doit se connecter

Par exemple, un client qui recherche la liste d’élèves aura deux moyens de l’atteindre. Soit en se connectant sur le serveur des élèves, soit en se connectant au serveur de l’eig qui fera un referral sur le serveur des élèves. Dans ce cas, le serveur renverra au client la référence du serveur élèves avec la syntaxe : ldap://129.194.184.203:389/o=eleves. Ici le port par défaut du protocole LDAP est 389. Il est cependant possible comme pour HTTP (port 80), de modifier le numéro de port à sa guise.

9.2 Les types de referrals

Il existe plusieurs types de referrals. Le plus couramment utilisé est le smart referral. Il consiste simplement à renvoyer au client l’adresse d’un second serveur sur lequel il pourra trouver la donnée.

cn = IN2


o=eig



Ref

erra

l

Serveur A

Serveur B

Ici le client fait la recherche de dn : uid=dcotte, cn=IN2, ou=informatique, o=eig sur le Serveur A de l’eig


Flux Applicatif 110

Le deuxième type de referral est le default referral. Lorsque que le client recherche une donnée et que le serveur ne la possède pas, alors il renverra au client l’adresse d’un autre serveur sur laquelle il pourra éventuellement trouver l’information recherchée. Contrairement au smart referral, le serveur questionné, ne donnera plus l’adresse d’un autre serveur où la donnée se trouve à coup sûr. En effet, il renvoie au client, une adresse fixe d’un serveur LDAP. Le client va ainsi interrogé ce serveur pour savoir s’il sait où la donnée se trouve. Il pourra soit la lui transmettre si elle est présente localement, soit renvoyer un smart referral au client pour lui indiquer où elle se trouve. C’est ce cas que j’ai montré dans le schéma ci-dessus. Un default referral pourra à nouveau être émis depuis ce deuxième serveur LDAP. Tout les scénarios sont possibles. C’est toujours le client qui, une fois reçu le referral, va se connecter sur un autre serveur.

Le principe de default referral ne sera pas étudié dans ce chapitre. Seul le smart referral fera l’objet d’une étude détaillée.

cn = IN2


o = eig

ou = informatique

o=eig

ou = telecommunication

cn = TE3 cn = TE2

Serveur Apas d'informationstrouvées sur le dn

recherché

Serveur BInformation

trouvée

cn = IN3 cn = IN2

Default Referral

Sm

art R

efer

ral

Serveur CInformationretournéeau client

Default Referral

Ici le client fait la recherche de dn : uid=dcotte, cn=IN2, ou=informatique, o=eig sur le Serveur A de l’eig


Flux Applicatif 111

9.3 Comment ajouter un referral avec iPlanet

Maintenant que nous avons vu comment fonctionne un referrral, il reste à le mettre en place sur le serveur iPlanet. Cette marche à suivre est uniquement valable pour le serveur iPlanet Directory Server 5.0. Cette description est aussi décrite dans l’annexe B.

Voici la procédure à suivre lorsque l’on veut ajouter un referral

1. Dans la console Directory Server, sélectionner l’onglet directory. 2. Choisir dans l’annuaire, quelles données seront appelées depuis un autre serveur. 3. Double cliquer sur cette donnée. (cliquer sur le bouton Advanced ). 4. Cliquer sur la cellule indiquant l’attribut « Object class » et cliquer sur Add Value. 5. Sélectionner referral dans la liste qui apparaît et cliquer sur OK. 6. Cliquer sur Add Attribute. 7. Sélectionner ref dans la liste qui apparaît et cliquer sur OK.

L’attribut ref apparaît dans la boîte de dialogue 8. Dans la cellule correspondant, entrer la valeur du referral.

ldap://HostName:Port/dn (voir chapitre 9.1 pour la syntaxe) 9. Cliquer sur OK pour sauvegarder les changements.

9.4 Etude d’un referral au niveau du protocole

Lorsque l’on se connecte sur un serveur et que celui-ci renvoie au client un referral, c’est le client qui se connecte sur le serveur référencé.

Server iPlanet129.194.187.52

Connexion TCP

Bind Request (0)

Search Request (3)

Bind Response (1)

Search Response Reference (19)


Server iPlanetréférencé

129.194.184.203

Connexion TCP

Bind Request (0)

Search Request (3)

Bind Response (1)

Search Response (4)


Client


Flux Applicatif 112

Par rapport à un simple recherche, on voit qu’un paquet Search Response Reference est envoyé par le serveur iPlanet. Voici de quoi est composé ce paquet :

LDAP: ProtocolOp: SearchResponse Reference (19)

LDAP: MessageID LDAP: ProtocolOp = SearchResponse Reference

LDAP: Referral Server = ldap://129.194.184.203:389/o=eleves

Comme on peut le constater, le serveur envoie simplement l’adresse sur lequel le client doit se connecter.

Ainsi le paquet important ici, est le paquet Search Reponse Reference. C’est là où l’adresse du serveur référencé va être transmis.

9.5 Conclusion

Dans ce chapitre, j’ai défini comment mettre en œuvre les referrals et comment ils fonctionnent. Il faut bien avoir à l’esprit que le serveur LDAP ne fait qu’indiquer au client sur quel autre serveur LDAP il peut trouver l’information. Il n’est en aucun cas responsable de rediriger la recherche. Il faut aussi bien comprendre que lors d’un referral, les types des attributs (o, ou, cn, etc..) doivent être identiques entre les deux serveurs. Il faut aussi que les noms correspondent. Le principe de referral est assez simple dans son concept, c’est pourquoi je n’irai pas plus loin dans son analyse. J’ai, dans la mise en place des referalls, eu un problème sur le serveur iPlanet. En effet, lorsque je crée le referall sur un autre serveur, le browser d’iPlanet, ne fonctionne plus. En effet, la souris passe du sablier à la flèche et le serveur iPlanet est bloqué. Si je me connecte distance avec un autre browser LDAP, le referall s’effectue correctement. J’en déduis que le browser proposé avec le serveur iPlanet à un bug. En effet, la version utilisée pour mon diplôme a été téléchargée depuis Internet. Peut-être que la version payante n’a pas ce problème. Il faudrait tester cela.

Server iPlanet

Client

Search Requestsur o=eleves

Search Response Referenceldap://129.194.184.203:389/o=eleves

Search Requestsur o=eleves

Search Responseuid=dcotte , uid = sbancal

Search Response Simple

Server iPlanetréférencé



Flux Applicatif 113

Chapitre 10 : LDAP Réplication Le principe du referral est de partager les annuaires. Ainsi chacun des serveurs LDAP dans le réseau, ont plusieurs informations mais pas la totalité. Cependant, une fois que nous avons créé notre annuaire, il faut faire en sorte que la totalité des données soient sauvegardées sur une autre machine au cas où un problème surgirait. Le referral ne faisant qu’un lien sur un autre serveur, il faut trouver un moyen de copier les données d’une database. C’est pourquoi le protocole LDAP a défini une norme appelée Replication. La réplication peut se faire uniquement entre serveurs. Cette norme est en partie définie dans la RFC 2830. Ainsi on peut copier une partie ou l’intégralité de l’arbre sur un autre serveur LDAP. Auparavant il était possible de le faire mais en sauvegardant l’annuaire sous forme d’un fichier texte LDIF. Concernant la configuration des serveurs pour effectuer une réplication, consulter l’annexe Tutorial iPlanet.

10.1 Le fichier LDIF

Ce type de transfert à l’aide d’un fichier de type LDIF, peut être considéré comme une forme de réplication. En effet, le fait de stocker les informations de l’annuaire et de les transférer sur un autre serveur peut s’assimiler à ce que fait la réplication de type LDAP. Soit de copier l’intégralité ou une partie de l’annuaire sur un autre serveur LDAP.

Lorsque l’on sauvegarde une base de données sous la forme LDIF, celui-ci sera sous forme de texte. Ce qui n’est pas très pratique pour modifier des données, une représentation graphique de la base de données est plus facile à gérer.

Afin de faciliter la tache des utilisateurs, il a été mis en place un protocole pour communiquer entre serveur. Ce protocole n’est pas encore sous forme de RFC. Il est toujours à l’état expérimental.

Server iPlanet Server iPlanetrépliqué

Sauvegarde des donnéesdans un fichier LDIF

Copie des donnéessur un autre serveur


Flux Applicatif 114

10.2 Réplication entre serveur

C’est le second moyen de faire de la réplication. Le premier étant, le transfert avec un fichier LDIF de manière plus archaïque. Même si la première méthode est encore utilisée, la réplication entre serveurs prend de plus en plus d’ampleur. Il existe cependant deux modes de réplication. - La réplication totale (envoi de la base de données entière) - La réplication des modifications uniquement (envoi des modifications entre le

dernier accès à la base de données)

Le serveur iPlanet, permet ces deux modes.

10.2.1 La réplication totale (Méthode 1)

Deux paquets supplémentaires apparaissent dans cet échange par rapport à un accès standard. Ce sont les paquets Extended Request et Response. Nous verrons par la suite que dans les paquets Search Request et Response , des données concernant la configuration des serveurs seront transmises. Tous ces paquets seront décrits dans le détail au niveau du protocole dans le chapitre 10.3.


Connexion TCP

Search Reponse

Search Request

BindResponse

Bind Request


Extended Request

Extended Response


Flux Applicatif 115

10.2.2 Réplication des modifications (Méthode 2)

Lorsque l’on fait ce type de réplication, seul les données modifiées dans l’annuaire entre la dernière réplication effectuée et l’heure courante, seront transmises.

Lors du transfert de données, un paquet Add Request est présent, c’est là que l’on envoie la donnée à ajouter dans l’annuaire distant. Tous ces paquets seront décrits au niveau protocole de façon approfondie au chapitre 10.4.

10.3 Etude de protocole de la réplication totale

Si l’on regarde de plus prêt chaque paquet, on s’aperçoit qu’un échange au niveau de la configuration est transmise entre serveurs. Ces paramètres sont transmis à travers des OID (Object Identifier). Ces OIDs sont standardisés et définis sur le site http://www.alvestrand.no/objectid/. Pour trouver un OID particulier, taper le numéro de celui-ci avec .html à la suite de l’adresse donnée auparavant. Il faut savoir qu’un OID est une suite de numéro séparé par des points qui servent à définir un standard. Par exemple, l’OID 2.16.840.1.113730.3 veut dire :

2 - ISO/ITU-T jointly assigned OIDs 2.16 - Joint assignments by country 2.16.840 – USA 2.16.840.1 - US company arc 2.16.840.1.113730 - Netscape Communications Corp . 2.16.840.1.113730.3 - Netscape LDAP


Extended Reponse

Extended Request

Add Request

Add Response

Extended Request

Extended Response


Flux Applicatif 116

Maintenant que nous avons tous les éléments en main, nous pouvons comprendre les paquets transmis ainsi que leurs attributs.

Si l’on regarde la figure du chapitre 10.2.1, on voit que les 3 premiers paquets ne changent pas lors d’un échange traditionnel. Cependant à partir du paquet Search Request, nous avons des choses intéressantes à étudier.

Le serveur qui possède les données va demander au serveur qui les recevra (serveur repliqué), quels sont les objectclass qu’il accepte. Ainsi dans le paquet suivant, le serveur repliqué va envoyé sous forme d’OIDs les paramètres objectclass qu’il accepte.

Je ne définirai pas tout ce que les serveurs acceptent comme attributs. Il faut savoir que ce sont des standards. Pour consulter les différents OIDs voir les annexes, où j’ai synthétisé tous les OIDs utilisés dans ces échanges.


Search RequestLDAP : Attribute Type : objectclass

LDAP : Attribute Value : supportedcontrolLDAP: Attribute Value : supportedextension


Search ResponseAttribute Type = supportedcontrol

2.16.840.1.113730.3.4.2 2.16.840.1.113730.3.4.3 2.16.840.1.113730.3.4.4 2.16.840.1.113730.3.4.51.2.840.113556.1.4.473

2.16.840.1.113730.3.4.9 2.16.840.1.113730.3.4.16 2.16.840.1.113730.3.4.15 2.16.840.1.113730.3.4.17 2.16.840.1.113730.3.4.14 1.3.6.1.4.1.1466.29539.12 2.16.840.1.113730.3.4.13

2.16.840.1.113730.3.4.18

Attribute Type = supportedextension2.16.840.1.113730.3.5.7 2.16.840.1.113730.3.5.8 2.16.840.1.113730.3.5.3 2.16.840.1.113730.3.5.5 2.16.840.1.113730.3.5.6 2.16.840.1.113730.3.5.4


Flux Applicatif 117

Le paquet suivant est de type Search Response Simple. Il est présent juste pour informer le serveur que les informations envoyées par le paquets Search Response sont terminées.

L’extended Request, est composée de 3 champs. Si l’on traduit les OIDs, voici ce que ce paquet renvoie comme informations :

Le champ Request Name = iPlanet Start Replication Request Extended Operation Le champ Request Value = iPlanet Total Update Replication Protocol Identifier Le champ control type = Manage DSA IT LDAPv3 contro l

Si l’on interprète cela, ce paquet est présent pour initialiser la réplication. Le paquet control type = Manage DSA veut dire que l’on communique entre serveurs. Le protocole LDAP défini un DSA comme une communication entre serveurs.

Response Name = iPlanet Replication Response Extended Operation La connexion pour la réplication est effectuée correctement.


Extended Request

LDAP: Request Name = 2.16.840.1.113730.3.5.3 LDAP: Request Value = 16.840.1.113730.3.6.2 LDAP: Control Type = 2.16.840.1.113730.3.4.2


Extended Reponse (success)LDAP: Response Name = 2.16.840.1.113730.3.5.4


Flux Applicatif 118

Ensuite des couples de paquets Extended Request et Response sont présents afin de transmettre les données au consommateur.

Request Name = iPlanet Replication Entry Request Extended Operation

Dans les paquets Exetended Request, les données se trouvant dans l’annuaire sont transmises avec les heures de création.

Les données envoyées dans le paquet précédent ont été reçues correctement.

Request Name = iPlanet End Replication Request Extended Operation Control Type = Manage DSA IT LDAPv3 control


Extended Request

LDAP: Request Name = 2.16.840.1.113730.3.5.6


Extended Reponse (success)


Extended RequestLDAP: Request Name = 2.16.840.1.113730.3.5.5LDAP : Control Type = 2.16.840.1.113730.3.4.2


Flux Applicatif 119

Le serveur envoi avec ce paquet un commande au serveur consommateur pour finir la réplication.

Le serveur consommateur confirme la fin de la transaction.

En résumant cette échange, voici ce qui se passe.

Cette partie traitait de l’envoi de la database complète. Il faut savoir que l’architecture des deux bases de données (une sur chaque serveur) qui effectuent la réplication doivent avoir la même architecture. Cependant, le trafic généré avec une réplication totale est très grand. Cela peut aller jusqu’au Giga Bytes. C’est pourquoi il est préférable parfois d’utiliser la deuxième méthode qui consiste à n’envoyer que les modifications qui ont été faites sur la database après la dernière réplication.


Connexion TCP

Search Reponse SimpleFin des données à envoyer

Search ResponseVoici les attributs que je supporte

Search RequestQuelles sont les attributs que tu supportes ?

Bind Connexion

Extended RequestVoilà ce que j'ai dans mon annuaire

Extended ResponseOk Success j'ai reçu tes données

Extended RequestJ'ai fini d'envoyer des données ; on se quitte

Extended ResponseSuccess

Connexionclose

Connexionclose


Extended Response

Success


Flux Applicatif 120

10.4 Etude de protocole de la réplication des modifications

Une fois la connexion TCP effectuée, le premier couple de paquets LDAP présent est de type Extended Request et Response. C’est ensuite que les paquets deviennent plus intéressants. Si aucune modification n’a eu lieu sur le serveur, alors aucun paquet à part l’ouverture et la fermeture de la connexion de réplication ne seront présents. Dans mon cas, j’ai ajouté un utilisateur (uid = dcotte). Voilà ce que l’on constate au niveau du protocole.

Les attributs transmis sont ceux que l’on peut voir dans les propriétés de l’utilisateur dans la console iPlanet.

LDAP: Object Name = uid=dcotte,o=replication LDAP: Attribute Type = objectClass LDAP: Attribute Value = top LDAP: Attribute Value = person LDAP: Attribute Value = organizationalPerson LDAP: Attribute Value = inetorgperson LDAP: Attribute Type = givenName LDAP: Attribute Value = denis LDAP: Attribute Type = cn LDAP: Attribute Value = denis cotte LDAP: Attribute Type = uid LDAP: Attribute Value = dcotte LDAP: Attribute Type = sn LDAP: Attribute Value = cotte LDAP: Attribute Type = creatorsName LDAP: Attribute Value = cn=directory manager LDAP: Attribute Type = modifiersName LDAP: Attribute Value = cn=directory manager LDAP: Attribute Type = createTimestamp LDAP: Attribute Value = 20011121182718Z LDAP: Attribute Type = modifyTimestamp LDAP: Attribute Value = 20011121182718Z LDAP: Attribute Type = nsUniqueId LDAP: Attribute Value = 496ebc01-1dd211b2-80d4c7d8-970540e8 LDAP : ProtocolOp = AbandonRequest LDAP : Message ID


Add RequestDivers Attributs Transmis concernant l'utilisateur

Abandon Request


Flux Applicatif 121

Pour avoir la définition des différents attributs, consulter le document Tutorial iPlanet en annexe.

Comme on peut le constater, à la fin de ce paquet, il y a une commande de type Abandon Request . Celle-ci est présente lorsque l’on a fini de transmettre les données à mettre à jour. En effet, dans ce cas, une seule donnée est mise à jour. Si maintenant, je crée cinq utilisateurs et que je remets à jour le serveur consommateur, ce n’est que lorsque j’aurai transmis les données du cinquième utilisateur que cette commande apparaîtra.

Ensuite comme pour la plupart des paquets Request, une réponse est envoyée par le consommateur.

La réponse à ce paquet nous indique si les données ont été reçues correctement ou non.

Comme lors d’une déconnexion LDAP (Unbind Request), il n’y a pas de réponse à la commande Abandon Request . Les deux parties savent qu’elles doivent arrêter là le transfert des données.


Add ResponseSuccess


Add RequestDATA utilisateur 2




Abandon Request



Flux Applicatif 122

Afin de conclure la réplication, deux paquets sont envoyés de la même manière que pour l’initialisation mais cette fois-ci pour conclure l’échange..

Request Name = iPlanet End Replication Request Extended Operation

Control Type = Manage DSA IT LDAPv3 control

Le serveur envoi avec ce paquet une commande au serveur consommateur afin de terminer la réplication.

Le serveur consommateur confirme la fin de la transaction. Un dernier paquet encore présent sert à terminer la connexion LDAP.

En effet, la réplication étant terminée, il n’y a plus besoin de transmettre des données, alors les deux serveurs quittent leur connexion.

A l’aide de cette commande, les serveurs savent que la connexion doit être terminée. Il n’y a pas besoin de réponse à ce paquet. Chacun sait ce qu’il doit faire quand il émet ou reçoit ce paquet.


Extended RequestLDAP: Request Name = 2.16.840.1.113730.3.5.5LDAP : Control Type = 2.16.840.1.113730.3.4.2


Extended Response

Success


Unbind Request


Flux Applicatif 123

On peut résumé l’échange de données entre les deux serveurs de la manière suivante.

10.5 Conclusion

Dans ce chapitre, nous avons vu comment faire une réplication. Il ne faut pas oublier que normalement, le but de la réplication est de sauvegarder toutes les données régulièrement. C’est pourquoi lors de l’installation de la réplication sur le serveur iPlanet nous avons une option de configuration pour la fréquence des réplications entre serveurs. Il faut savoir aussi que cela engendre un trafic assez grand car l’annuaire atteint parfois 1 Giga Bytes dans les grandes entreprises. C’est pourquoi la réplication se fait généralement la nuit. Pour ma part, j’ai utilisé le logiciel iPlanet Directory Server 5.0 pour effectuer les tests de réplication. Il se peut que d’autres logiciels aient des options différentes de celles proposées ici. En effet, un serveur LDAP n’est pas défini comme une norme et l’utilisateur peut créer son annuaire comme il l’entend. Les logiciels ont eux aussi différentes possibilités. Ce logiciel peut soit répliquer uniquement les modifications soit tout l’annuaire. Il offre par contre la possibilité de gérer les heures où l’on veut faire la réplication. Après avoir passé 3 semaines sur ce logiciel, je le considère comme bon pour faire de la réplication car il n’est pas trop compliqué à utiliser et fonctionne relativement bien.


Add Requestvoici un nouvel utilisateur ajoute-le dans ta liste

Abandon Requestc'est fini. C'était la dernière donnée à ajouter

Extended Responseok je suis prêt

Extended Requestdébut de la réplication

Add Responseok success

Extended RequestJ'ai fini d'envoyer des données ; on se quitte

Extended ResponseSuccess

Unbind Requestje me deconnecte

Connexionclose

Connexionclose


Flux Applicatif 124

Chapitre 11 : Application LDAP Dans les chapitres précédents, nous avons vu les possibilités offertes par un annuaire LDAP. Cependant, cela ne nous sert pas à grand chose si cette annuaire n’est pas dédié à une application particulière. C’est pourquoi, nous avons décidé d’utiliser l’annuaire LDAP dans un cas plus réel. Tout d’abord, nous voulions faire une authentification d’un client sur un routeur Cisco. Malheureusement, ceux que nous avons dans le laboratoire (C isco 2600) ne supportent pas le protocole LDAP. Nous avons donc décidé d’utiliser le Firewall Check Point afin que lorsque l’on accède à un serveur Web, celui-ci va aller contrôler le login et le password du client qui s’y connecte sur le serveur LDAP. Voici l’architecture que nous avons utilisée : Une configuration du Firewall est nécessaire afin que celui-ci accède au serveur LDAP pour authentifier le client. En annexe, j’ai fait un tutorial qui explique comment configurer le Firewall (Annexe C). La connexion entre le Firewall et le serveur Web était déjà effectuée précédemment par M.Borsa (diplômant dans le laboratoire), je n’ai fait que reprendre ce que lui avait déjà fait.

Internet

Client

IE 6.0SP2

Win 2k Pro

IP = 129.194.184.206

Firewall Check Point

FirewallCheck Point

V 4.1SP5

Win NT 4Server

IP Web par translation (NAT)129.194.186.210

IP Machine = 129.194.184.82IP Machine = 10.0.0.1

IIS 5.0SP2

Win 2kServer

IP Machine = 10.0.0.2

iPlanet 5.0SP2

Win 2k Pro


Server Web

Server LDAPiPlanet Directory Server 5.0


Flux Applicatif 125

11.1 Création d’un compte utilisateur

Une fois que l’on a configuré correctement le Firewall, il nous faut créer un compte utilisateur sur le serveur iPlanet. C’est avec ce compte que l’on se connectera au serveur Web qui se trouve derrière le Firewall.

Pour cela, j’ai créé une nouvelle base de donnée appelée o=firewall, et j’ai créé un utilisateur appelé pgaio. Avec gaio comme nom et pascal comme prénom, ce qui correspond par défaut à un uid=pgaio. Cet uid peut être modifié lors de la création de l’utilisateur. Voir captures ci-dessous.

Login = pgaio Password = labotd

Pour installer une nouvelle base de données ainsi que pour ajouter un nouvel utilisateur, se référer à l’annexe C.


Flux Applicatif 126

11.2 Accès au serveur Web par le client

L’utilisateur pgaio étant maintenant créé, il va pouvoir se connecter sur le serveur Web. L’adresse de celui-ci étant une adresse privée (ip = 10.0.0.2), c’est le Firewall qui va s’occuper de translater l’adresse privée en une adresse publique (ip = 129.194.186.210) comme décris dans l’annexe C. Le client se connectant sur le serveur Web, reçoit une demande d’authentification grâce à la règle insérée dans le Firewall.

Ainsi il recevra une fenêtre de ce style :

Il suffira au client de rentrer son login et password correspondant à l’entrée sur l’annuaire LDAP et il pourra entrer sur le site.


Flux Applicatif 127

11.3 Analyse d’une connexion sur le serveur Web

Les requêtes du client qui se connecte sur le serveur Web, vont être interceptées par le Firewall (protocole http uniquement). Le Firewall va lui répondre en lui disant que la connexion est impossible car il doit s’identifier.

Si l’on analyse le paquet Response de façon plus rigoureuse, on remarque que plusieurs paramètres sont envoyés par le serveur lorsque celui-ci veut une authentification.

HTTP: Response (to client using port 2268)

HTTP: Protocol Version = HTTP/1.0 HTTP: Status Code = Unauthorized 401 HTTP: Reason = Unauthorized HTTP: WWW-Authenticate = Basic realm="FW-1. Reason: no user"

Le message « FW-1 Reason: no user » venant de la commande realm, est celui qui nous apparaît dans la boîte de dialogue (voir page précédente), lorsque le serveur nous demande une authentification. C’est le browser (dans mon cas Internet Explorer 6.0) qui va afficher la boîte de dialogue pour que l’utilisateur s’authentifie correctement à l’aide des champs mentionnés ci-dessus. Maintenant que la boîte de dialogue a été ouverte, le client doit entrer les données pour s’authentifier sur le Firewall à travers l’annuaire LDAP.

Client

IE 6.0SP2

Win 2k Pro

IP = 129.194.184.206

Firewall Check Point

FirewallCheck Point

V 4.1SP5

Win NT 4Server



IIS 5.0SP2

Win 2kServer


iPlanet 5.0SP2

Win 2k Pro


Server Web


Get Request129.194.186.210

ReponseUnauthorized authentification requise

Get Request 129.194.186.210login et password


Flux Applicatif 128

Si l’on regarde le paquet où sont transmis le login et le password du client, on s’aperçoit qu’ils sont codés.

HTTP: GET Request (from client using port 2269) HTTP: Protocol Version = HTTP/1.0 HTTP: Authorization = Basic cGdhaW86bWlsYW4=

Ce login et ce password sont transmis dans le paquet Authorization = Basic cGdhaW86bWlsYW4=. Ces informations sont codées en base64. Le principe de ce codage est assez simple. Il suffit de transformer toutes les données ASCII en binaire, de regrouper les données par groupe de 6, de les transformer en hexadécimal et de les coder suivant la table suivante :

Séquence Caractères 0 … 25 « A » … « Z » 26 … 51 « a » … « z » 52 … 61 « 0 » … « 9 »

62 « + » 63 « / »

Il faut savoir que le caractère « = » détermine la fin du codage en Base 64 Exemple : Le login et le password que j’ai tapé sont : Login = pgaio

Password = labotd

Si l’on code le login en binaire on obtient :

Lettre p g a i o HEXA ASCII 70 67 61 69 6F Binaire 8 bits 01110000 01100111 01100001 01101001 01101111 Binaire 6 bits 011100 000110 011101 100001 011010 010110 111100 Codage en Hexa 28 6 29 33 26 22 60 Codage Base 64 c G d h a W 8

Ce type de codage est assez pénible à effectuer manuellement. Un convertisseur Base64 est disponible à l’adresse suivante : http://www.wc.cc.va.us/dtod/base64 . De plus une table de codage Base64 est disponible à l’adresse : http://www.freesoft.org/CIE/RFC/1521/7.htm . La table ASCII est disponible à l’adresse : http://www.asciitable.com/ .

Ajout de 0 pour compléter les

Codage Base 64


Flux Applicatif 129

Le client envoie son login et son password via le protocole http. Le Firewall va chercher dans l’annuaire LDAP si les données entrées par l’utilisateur sont correctes via le protocole LDAP. Pour cela il va rechercher dans l’annuaire (défini lors de la configuration du Firewall), s’il existe un uid=pgaio. Si oui l’annuaire lui renvoie le chemin où il peut le trouver (uid=pgaio,o=firewall). Ensuite il va se connecter à l’annuaire avec le password et le login que l’utilisateur a taper en envoyant la commande Bind Request . L’annuaire accepte ou non la connexion à l’annuaire. S’il l’accepte, cela veut dire que le password correspond bien au login et la réponse sera Bind Response = success.

Si la réponse du serveur LDAP est success, alors le client sera authentifié correctement et une connexion sera ouverte entre le client et le serveur Web à travers le Firewall. Cet échange ne nous intéresse pas trop.

Internet

Client

IE 6.0SP2

Win 2k Pro

IP = 129.194.184.206

FirewallCheck Point

FirewallCheck Point

V 4.1SP5

Win NT 4Server



IIS 5.0SP2

Win 2kServer


iPlanet 5.0SP2

Win 2k Pro


Server Web


Search Request o=firewall (whole subtree)

Equality match uid=pgaioSearch Response

uid=pgaio,o=firewallBind Request

uid = pgaio,o=firewall ; authentification simple = labotd

Bind Responsesuccess


Flux Applicatif 130

Il faut savoir que le protocole utilisé est uniquement du http et est le même (au niveau http) que lors d’une connexion client serveur.

L’échange est maintenant terminé. Le client ayant reçu les données correctement.

FirewallCheckPoint

Server WebClient

HTTP

ResponseData du site web

HTTP

ResponseData du site web


Flux Applicatif 131

11.4 Connexion avec password erroné

Il se peut que l’utilisateur qui se connecte sur le serveur Web, se trompe en tapant son password lors de l’authentification. L’objectif de ce chapitre est de montrer comment réagi le Firewall et le serveur LDAP lorsqu’un tel cas se produit.

Jusqu’à ce que le client arrive à la fenêtre d’authentification, le principe est identique.

J’utilise toujours l’utilisateur pgaio pour me connecter. Son password correct est labotd. Cependant il se trompe et tape obaltd.

C’est une fois que le client a entré son login et son password erroné que des choses intéressantes arrivent. En effet, le Firewall fait toujours la requête sur le serveur LDAP pour savoir s’il existe un utilisateur appelé pgaio. Mais cette fois-ci lorsque le Firewall essayera de se connecter avec le password erroné (obaltd), le serveur LDAP renverra dans son paquet Bind Response la valeur Invalid Credentials qui correspond à une erreur de type password erroné.

Internet

Client

IE 6.0SP2

Win 2k Pro

IP = 129.194.184.206

FirewallCheck Point

FirewallCheck Point

V 4.1SP5

Win NT 4Server



IIS 5.0SP2

Win 2kServer


iPlanet 5.0SP2

Win 2k Pro


Server Web



Equality match uid=pgaioSearch Response

uid=pgaio,o=firewallBind Request

uid = pgaio,o=firewall ; authentification simple = obaltd

Bind ResponseInvalid Credentials

Par la suite, le Firewall proposera d’entrer à nouveau le password et refera la même opération d’authentification jusqu’à trois fois. Cette valeur peut-être modifiée dans les propriétés du Firewall mais cela ne nous apporte pas plus pour comprendre le phénomène que l’on essaye de se reconnecter une ou plusieurs fois sur le serveur Web.


Flux Applicatif 132

11.5 Connexion avec un login erroné

Maintenant, il se peut que le login que tape l’utilisateur soit lui aussi erroné. A première vue et sans faire d’étude de protocole, je dirai que lorsque le Firewall essaye de trouver l’uid correspondant, le serveur LDAP lui renverra directement une erreur et l’échange s’arrêtera là. Pour la partie connexion cela se passe toujours de la même façon jusqu’à ce que l’utilisateur entre son login erroné et son password. J’utilise toujours l’utilisateur toto pour me connecter mais cette fois-ci il entre le login ogaio au lieu de pgaio. Son password est correct (labotd).

En réalité lorsque le Serveur LDAP ne trouve pas de donnée correspondante au login entré, alors celui-ci ne renvoie pas de message d’erreur. Il n’indique rien. La commande Search Response Simple success est directement envoyée. La valeur success ici veut dire que la commande Search Request à bien été traitée.

Internet

Client

IE 6.0SP2

Win 2k Pro

IP = 129.194.184.206

FirewallCheck Point

FirewallCheck Point

V 4.1SP5

Win NT 4Server



IIS 5.0SP2

Win 2kServer


iPlanet 5.0SP2

Win 2k Pro


Server Web



Equality match uid=ogaio

Search Response Simplesuccess

L’échange s’arrête ici et le Firewall demande à nouveau d’entrer le login et le password et le phénomène se reproduit jusqu’à trois fois avant d’afficher une page d’erreur si l’authentification n’aboutit pas.


Flux Applicatif 133

11.6 Reconnexion au serveur Web

Il est normal qu’un utilisateur navigue sur Internet et qu’il revienne plusieurs fois sur le site authentifié. Il est clair que le rôle du cache est toujours valide en ce qui concerne les échanges http (voir chapitre 1, 2 et 3 et plus particulièrement le chapitre 1.5 pour l’étude du cache Web). Cependant en ce qui concerne les login et password, je constate que ceux-ci sont pendant un certain temps, stockés dans le Firewall. Ainsi si j’accède au site Web pour la deuxième fois après un certain temps, le Firewall ne testera pas le login et le password entré par l’utilisateur à travers le serveur LDAP car ces données sont stockées localement. Je ne peux malheureusement pas tester ce temps de stockage en cache des utilisateurs, car le laboratoire ne possède pas la licence LDAP pour le Firewall Check Point. Ainsi sans cette licence, je peux utiliser le protocole LDAP pour accéder à un serveur LDAP, par contre je ne peux pas gérer cet accès. Par exemple, je ne peux pas modifier les options qui font que les données de l’utilisateur, une fois authentifié sur le serveur LDAP, seront stockées pendant un certain temps dans la base de données du Firewall.

11.7 Conclusion

L’annuaire qui doit servir à valider l’accès à un site Web nécessitant une authentification de l’utilisateur a donc été créé avec succès. La mise en œuvre est assez rapide mais la gestion n’a pas pu se faire à cause de ce manque de licence. Cependant, nous avons vu comment était transmis les données entre les différentes machines (annuaire LDAP – Firewall – Client). L’accès fonctionne correctement et si le serveur LDAP ne fonctionne plus, personne ne pourra se connecter au serveur Web.


Flux Applicatif 134

Chapitre 12 : Bibliographie Tous les documents avec une étoiles sur le côté, sont des documents indispensables à la bonne compréhension du sujet. Partie Cache Web Site consultés :

http://www.isoc.org/isoc/whatis/conferences/inet/96/proceedings/a4/a4_3.htm Site très complet qui nous présente le cache de façon complète. Assez compliqué à comprendre mais très intéressant. http://www.alianwebserver.com/informatique/internet/http/default.htm#Gestion%20des%20caches Site très intéressant sur les principes http, cache et Internet. Très intéressant mais ne rentre, malheureusement, pas beaucoup dans les détails.

Partie ISA Server Livre consulté : * Configuring ISA Server 2000 De DR. Thomas W. Shinder , Debra LittleJohn Shinder et Martin Grasdal Chez SYNGRESS

Livre en Anglais mais très facile à comprendre. Il présente les points les plus importants du logiciel et est très détaillé lorsqu’il s’agit de configurer un élément du serveur ISA. Très bon livre.

Sites consultés : * http://microsoft.supinfo.com/articles/isa/

Site qui nous renseigne sur les possibilités d’ISA et de configuration du logiciel selon ce que l’on veut faire. Très utile. C’est un résumé du livre que j’ai consulté.

* http://www.adsl-facile.com/Dossiers/ISAServer/

Document très intéressant qui montre comment configurer ISA Server et qui décrit ces fonctionnalités. C’est une sorte de tutorial. Très bon document.

http://www.microsoft.com/technet/treeview/default.asp?url=/TechNet/prodtechnol/isa/proddocs/isadocs/CMT_CacheAbout.asp Présentation du fonctionnement du cache d’ISA Server. Très bon document

*


Flux Applicatif 135

Partie LDAP Livre consulté : Construire un annuaire d’entreprise avec LDAP De Marcel RIZCALLAH

Chez Eyrolles

Livre qui présente les possibilités de LDAP. Bon pour les principes LDAP au niveau des annuaires. Au niveau des referrals, c’est correct, mais au niveau réplication, pas beaucoup d’informations.

En général, bon livre pour débuter avec LDAP mais ne rentre pas assez dans les détails.

Sites consultés :

http://www.iit.edu/~gawojar/ldap/index.html Site qui permet de télécharger le browser LDAP sous java http://globecom.net/ietf/draft/draft-merrells-ldup-model-01.txt Sorte de RFC sur la réplication http://asn1.elibel.tm.fr/en/biblio/asn1-presentation_fichiers/frame.htm Site complet sur l’ASN1. Très intéressant.

http://www.vijaymukhi.com/vmis/ber.htm

Site qui permet d’avoir des informations sur le codage ber afin de décoder l’ASN1 utilisé dans le protocole LDAP

* http://cui.unige.ch/eao/www/memoires/Hugentobler/certnum.html Exemple concret de décodage de l’ASN1 sur un certificat. * http://people.ne.mediaone.net/wasser/ASN1/BasicEncodingRules.html Site très bon pour la compréhension du codage ber (le site le plus complet sur le sujet)

http://database.sarang.net/database/ldap/presentation/index.htm Présentation sous forme de slide de LDAP en général. Très bon pour comprendre les principes

* http://www-sop.inria.fr/semir/personnel/Laurent.Mirtain/ldap.html Très bon document. Tutorial LDAP très complet. * http://www.cru.fr/ldap/tutorial/tutorial_ldap.pdf Très bon document. Tutorial LDAP très complet. * http://www.alvestrand.no/objectid/

Seul site trouvé qui décrit précisément tout les OIDs. Unique inconvénient, le site n’a pas été remis à jour depuis 1998.


Flux Applicatif 136

http://www.ldapzone.com/cgi-bin/01/index.cgi Forum LDAP. Site généralement fréquenter par des programmateurs LDAP.

http://www.crackinguniversity2000.it/Paper/LDAP-FAQ-23.htm Réponse à des questions standard sur LDAP

http://www.ldapguru.com/ Site qui propose d’importantes informations à tous les niveaux LDAP.

http://listes.cru.fr/wws/arc/ldap-fr/2001-11/thrd1.html#00001 Forum LDAP du site cru.fr. Réponse généralement dans la demi-journée qui suit la question. http://docs.univ-nancy2.fr/ldap/ section LDAP de l’université de Nancy. Très intéressant mais malheureusement les applications créées sont très souvent sous Linux. http://developer.novel.com/research/devnotes/1998/august/02/d980802_.pdf Très bon document qui montre les différences entre le protocole LDAP Version 2 et la version 3.

RFC : * http://www.hotldap.com/standards/index.html Liste de toutes les RFC faisant référence au protocole LDAP

http://www.crackinguniversity2000.it/Paper/LDAP-RFCs.htm Idem. Liste de toutes les RFC. La présentation est moins claire mais il y a beaucoup plus d’informations sur les RFC. Une description est faite pour chacune des RFC présentées.

Partie Firewall Check Point Sites consultés :

www.allasso.fr/base/docs/1967035335.PDF Site qui montre les possibilités offertes par le Firewall Check Point

* http://support.checkpoint.com/kb/docs/public/firewall1/4_1/pdf/opsec_fw.pdf Site qui présente comment configurer LDAP avec le Firewall Check Point. La démonstration est faite avec un serveur LDAP Novell. Voir les annexes pour iPlanet

Liste des RFCs utilisées

N° 2616 HTTP 1.1 N° 2251 LDAP Version 3 N° 1777 LDAP Version 2 N° 2830 LDAP V3 Extension


Flux Applicatif 137

Conclusion

Ces trois mois passés dans le laboratoire, afin de réaliser mon travail de diplôme, m’ont permis d’apprendre la gestion d’un projet sur une durée beaucoup plus longue que j’en avais l’habitude. J’ai pu me rendre compte de la difficulté à gérer ce type de projet sur plusieurs mois. En ce qui concerne le travail effectué pendant ces trois mois, je pense que les résultats obtenus correspondent aux objectifs fixés. En effet, en ce qui concerne la partie qui consistait à étudier le cache Web, après diverses difficultés, j’ai enfin pu faire ressortir les différents endroits où le cache était stocké en utilisant le browser Internet Explorer 5.0 et 6.0. Mais certaines données stockées ne seront jamais visibles, Microsoft gardant des données secrètes à l’utilisateur (stockage de plusieurs informations en RAM). Par la suite en installant ISA Server, j’ai constaté que le gain au niveau des échanges de données n’était pas négligeable. En effet, lorsque le serveur ISA possède les données d’une page dans son cache, aucun paquet n’est transmis entre ISA et le serveur Web. Ainsi il n’y aura aucun trafic sortant et tout se fera localement. De ce fait les accès sur cette page se feront très rapidement (vitesse du réseau local). Le test du gain de temps n’a pas pu être fait. Par la suite j’ai pu mettre en œuvre un reverse proxy et j’ai pu constater qu’au niveau http, le mode proxy ou reverse proxy fonctionne de la même manière. Pour moi le logiciel ISA Server est un bon investissement dans le cas où le flux sortant pour les connexions à Internet n’est pas très élevé. Pour finir, j’ai pu mettre en place un annuaire LDAP et regarder les principales fonctionnalités du protocole LDAP. J’ai pu démontrer comment fonctionnait un referall et surtout comment fonctionnait une réplication entre serveurs. De plus j’ai pu mettre en œuvre une petite application qui permet à un Firewall CheckPoint d’authentifier un client à travers un annuaire LDAP. Je considère donc que j’ai atteint les objectifs fixés et je pense que les résultats obtenus, correspondent aux attentes qui m’étaient demandées tout au long de mon diplôme. Je remercie donc Messieurs Litzistorf et Jenny pour m’avoir confié un sujet si intéressant.

GAIO Pascal


Flux Applicatif 138

Table des Matières Chapitre 1 : Le cache Web.......................................................................... 1

1.1 Qu’est-ce que le cache ..............................................................................................................................................7 1.1.1 Les recherches d’informations..........................................................................................................................7 1.1.2 Les programmes à disposition..........................................................................................................................8 1.2 Le cache vu par le client...........................................................................................................................................9 1.2.1 Localisation du cache.........................................................................................................................................9 1.2.2 Suppression du cache....................................................................................................................................... 11 1.2.3 L’historique........................................................................................................................................................ 12 1.2.4 Le menu déroulant ............................................................................................................................................ 13 1.3 Que se passe-t-il réellement lorsque j’accède à un site sur Internet ? ............................................................ 16 1.4 Différence entre une connexion au site avec cache ou sans cache. ................................................................ 19 1.5 Rafraîchissement des pages ................................................................................................................................... 22 1.6 Voir le cache des autres utilisateurs de la même machine ............................................................................... 24

Chapitre 2 : Gestion du cache d’Internet Explorer.................................... 27

2.1 Option Never ............................................................................................................................................................ 28 2.2 L’option Automatically........................................................................................................................................... 29 2.3 L’option Every time you start internet Explorer ................................................................................................ 32 2.4 L’option Every visit to the page ............................................................................................................................ 35 2.5 Résumé de toutes les options d’ Internet Explorer ............................................................................................. 36

Chapitre 3 : Le cache vu par le serveur Web............................................ 37

3.1 Installation du serveur Web................................................................................................................................... 37 3.2 Commandes HTTP.................................................................................................................................................. 39 3.3 L’onglet HTTP Headers ......................................................................................................................................... 40 3.4 Principales commandes HTTP.............................................................................................................................. 41 3.4.1 Commande no-cache........................................................................................................................................ 42 3.4.2 Commande max-age ......................................................................................................................................... 43 3.5 Les fichiers LOG ............................................................................................................................................... 44 3.6 Conclusion ................................................................................................................................................................ 45

Chapitre 4 : ISA Server Première Partie .................................................. 46

4.1 Configuration requise............................................................................................................................................. 46 4.2 Le mode cache................................................................................................................................................... 47 4.3 Le mode Firewall .................................................................................................................................................... 47 4.4 Le mode Integrated ................................................................................................................................................. 48 4.5 Choix décidé pour l’installation............................................................................................................................ 48 4.6 Différents modes de mise en cache ...................................................................................................................... 49 4.6.1 http Caching....................................................................................................................................................... 50 4.6.2 Active Caching................................................................................................................................................... 51 4.7 HTTP 1.0 VS HTTP 1.1......................................................................................................................................... 52

Chapitre 5 : ISA Server Deuxième Partie ................................................. 54


Flux Applicatif 139

5.1 Introduction.............................................................................................................................................................. 54 5.2 Fonctionnement du Serveur ISA ........................................................................................................................... 55 5.3 Test avec un seul client et une carte Ethernet sur ISA ...................................................................................... 56 5.4 Mode http Header Frequently ............................................................................................................................... 57 5.4.1 Commande max-age envoyée par le serveur Web....................................................................................... 57 5.4.2 Cache présent valide sur le client et sur ISA avec rafraîchissement F5 ................................................... 58 5.4.3 Cas où le serveur Web envoi un no-cache ..................................................................................................... 60 5.4.4 Cache présent sur le client et sur ISA avec rafraîchissement ENTER...................................................... 63 5.5 Mode http Header Normally ................................................................................................................................ 63 5.5.1 Aucun cache présent sur le client mais présent sur ISA............................................................................. 64 5.5.2 Cache présent sur le client et présent sur ISA.............................................................................................. 65 5.5.3 Les autres cas ..................................................................................................................................................... 66 5.5.4 Différences entre les modes http Caching .................................................................................................... 67 5.6 Mode Active Caching ............................................................................................................................................ 68 5.7 Ajout d’un deuxième client .................................................................................................................................. 69 5.8 Fonctionnement du serveur ISA avec 2 cartes Ethernet .................................................................................. 70 5.9 Server Web Down................................................................................................................................................... 71 5.10 Les principales commandes HHTP rencontrées .......................................................................................... 72 5.11 Les fichiers LOG ............................................................................................................................................... 73 5.12 Qu’a-t-on gagné avec ISA ? ............................................................................................................................ 74

Chapitre 6 : Reverse Proxy........................................................................ 75

6.1 Installation de ISA Server en mode Reverse Proxy ........................................................................................... 76 6.2 Tests en mode Reverse Proxy ................................................................................................................................ 78 6.2.2 Connexion de deux clients sur le serveur Web............................................................................................ 80 6.3 Conclusion ................................................................................................................................................................ 81

Chapitre 7 : LDAP Principes .................................................................... 82

7.1 Les concepts de LDAP ........................................................................................................................................... 83 7.2 Les principes de LDAP .......................................................................................................................................... 83 7.3 Les annuaires LDAP ............................................................................................................................................... 85 7.4 Les choix effectués.................................................................................................................................................. 86 7.4.1 Installation du serveur iPlanet......................................................................................................................... 87 7.4.2 Installation du client ......................................................................................................................................... 87 7.5 Création de l’annuaire LDAP................................................................................................................................ 87 7.5.1 Architecture Annuaire EIG ............................................................................................................................. 88 7.5.2 Architecture Annuaire Elèves ......................................................................................................................... 88 7.5.3 Architecture Annuaire Professeurs ................................................................................................................ 89 7.5.4 Création de membres ........................................................................................................................................ 89 7.6 Conclusion ................................................................................................................................................................ 91

Chapitre 8 : LDAP Protocole .................................................................... 92

8.1 Structure de la trame du protocole LDAP ........................................................................................................... 93 8.1.1 Le champ Type.................................................................................................................................................. 93 8.1.2 Le champ Length............................................................................................................................................... 95 8.1.3 Le champ Content............................................................................................................................................. 96 8.2 Etude détaillée du paquet Search Response........................................................................................................ 97 8.3 Accès à un annuaire .............................................................................................................................................. 100 8.4 Recherches de données dans l’annuaire............................................................................................................ 101 8.5 Ajout d’un utilisateur............................................................................................................................................ 102 8.6 Delete d’une branche de l’annuaire .................................................................................................................... 103 8.7 Server LDAP Down............................................................................................................................................... 104 8.8 Connexion avec Size Limit limité....................................................................................................................... 105 8.9 Déconnexion de l’annuaire .................................................................................................................................. 107 8.10 Conclusion......................................................................................................................................................... 107

Chapitre 9 : LDAP Referral .................................................................... 108


Flux Applicatif 140

9.1 Syntaxe d’un Referral ........................................................................................................................................... 109 9.2 Les types de referrals ........................................................................................................................................... 109 9.3 Comment ajouter un referral avec iPlanet ........................................................................................................ 111 9.4 Etude d’un referral au niveau du protocole...................................................................................................... 111 9.5 Conclusion......................................................................................................................................................... 112

Chapitre 10 : LDAP Réplication............................................................. 113

10.1 Le fichier LDIF................................................................................................................................................. 113 10.2 Réplication entre serveur ................................................................................................................................ 114 10.2.1 La réplication totale (Méthode 1) .................................................................................................................. 114 10.3 Etude de protocole de la réplication totale................................................................................................... 115 10.4 Etude de protocole de la réplication des modifications ............................................................................. 120 10.5 Conclusion......................................................................................................................................................... 123

Chapitre 11 : Application LDAP............................................................. 124

11.1 Création d’un compte utilisateur ................................................................................................................... 125 11.2 Accès au serveur Web par le client ............................................................................................................... 126 11.3 Analyse d’une connexion sur le serveur Web............................................................................................. 127 11.4 Connexion avec password erroné.................................................................................................................. 131 11.5 Connexion avec un login erroné .................................................................................................................... 132 11.6 Reconnexion au serveur Web ......................................................................................................................... 133 11.7 Conclusion......................................................................................................................................................... 133

Chapitre 12 : Bibliographie..................................................................... 134

Flux Applicatifs HTTP

Documents

Transcript of Flux Applicatifs HTTP