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

Session 2001

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 Laboratoire de transmission de données

Gaio Pascal Session 2001

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 estce 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 Check Point 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

2

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

Gaio Pascal Session 2001

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

3

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

Gaio Pascal Session 2001

Table des Matières

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

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

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

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

Flux Applicatif

4

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

Gaio Pascal Session 2001

Chapitre 5 : ISA Server Deuxième Partie ................................................. 54
5.1 5.2 5.3 5.4 5.4.1 5.4.2 5.4.3 5.4.4 5.5 5.5.1 5.5.2 5.5.3 5.5.4 5.6 5.7 5.8 5.9 5.10 5.11 5.12 Introduction.............................................................................................................................................................. 54 Fonctionnement du Serveur ISA ........................................................................................................................... 55 Test avec un seul client et une carte Ethernet sur ISA ...................................................................................... 56 Mode http Header Frequently............................................................................................................................... 57 Commande max-age envoyée par le serveur Web....................................................................................... 57 Cache présent valide sur le client et sur ISA avec rafraîchissement F5................................................... 58 Cas où le serveur Web envoi un no-cache ..................................................................................................... 60 Cache présent sur le client et sur ISA avec rafraîchissement ENTER...................................................... 63 Mode http Header Normally ................................................................................................................................ 63 Aucun cache présent sur le client mais présent sur ISA............................................................................. 64 Cache présent sur le client et présent sur ISA.............................................................................................. 65 Les autres cas ..................................................................................................................................................... 66 Différences entre les modes http Caching .................................................................................................... 67 Mode Active Caching ............................................................................................................................................ 68 Ajout d’un deuxième client .................................................................................................................................. 69 Fonctionnement du serveur ISA avec 2 cartes Ethernet .................................................................................. 70 Server Web Down................................................................................................................................................... 71 Les principales commandes HHTP rencontrées .......................................................................................... 72 Les fichiers LOG ............................................................................................................................................... 73 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 7.2 7.3 7.4 7.4.1 7.4.2 7.5 7.5.1 7.5.2 7.5.3 7.5.4 7.6 Les concepts de LDAP ........................................................................................................................................... 83 Les principes de LDAP .......................................................................................................................................... 83 Les annuaires LDAP ............................................................................................................................................... 85 Les choix effectués.................................................................................................................................................. 86 Installation du serveur iPlanet......................................................................................................................... 87 Installation du client ......................................................................................................................................... 87 Création de l’annuaire LDAP................................................................................................................................ 87 Architecture Annuaire EIG ............................................................................................................................. 88 Architecture Annuaire Elèves ......................................................................................................................... 88 Architecture Annuaire Professeurs ................................................................................................................ 89 Création de membres ........................................................................................................................................ 89 Conclusion ................................................................................................................................................................ 91

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

Flux Applicatif

5

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

Gaio Pascal Session 2001

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

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

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

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

Flux Applicatif

6

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

Gaio Pascal Session 2001

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

7

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

Gaio Pascal Session 2001

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 Adresse du site programme http://www.icmasterdata.com/ice.html Internet Cache Explorer 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. http://www.evolve.co.uk/unmozify/ 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. http://www.webknacks.com/download.htm Cache Auditor 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

8

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

Gaio Pascal Session 2001

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

9

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

Gaio Pascal Session 2001

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

10

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

Gaio Pascal Session 2001

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

11

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

Gaio Pascal Session 2001

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

12

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

Gaio Pascal Session 2001

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

13

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

Gaio Pascal Session 2001

Les deux listes Sont identiques

Une deuxième option existe dans ce menu déroulant. Cela s’appelle la saisie semiautomatique. 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

14

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

Gaio Pascal Session 2001

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

15

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

Gaio Pascal Session 2001

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.

Get Request Response (Data)

Client

Server Web

Flux Applicatif

16

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

Gaio Pascal Session 2001

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

17

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

Gaio Pascal Session 2001

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

18

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

Gaio Pascal Session 2001

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° 1 2 3 4 5 6 Nombres de paquets 338 336 296 302 303 292 Bytes envoyés 19641 18674 17376 17947 18196 16509
et

Bytes reçus 226965 229141 199843 200429 200052 199843

Bytes échangés 246606 247815 217219 218376 218248 216352

Temps de chargement 12.00 sec 13.16 sec 4.04 sec 4.45 sec 3.61 sec 4.43 sec

Bytes envoyés = client -> serveur

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

19

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

Gaio Pascal Session 2001

Date d’expiration encore valide :
Essai N° n Nombres de paquets 0 Bytes envoyés 0
et

Bytes reçus 0

Bytes échangés 0

Temps de chargement 0

Bytes envoyés = client -> serveur

bytes reçus = client <- serveur

Date d’expiration dépassée :
Essai N° 1 2 3 4 5 6 Nombres de paquets 113 118 105 104 120 81 Bytes envoyés 14598 15783 14422 14530 15249 5361
et

Bytes reçus 29936 30163 25076 20624 30167 14380

Bytes échangés 44534 45946 39498 35154 45416 19741

Temps de chargement 7.17 sec 5.89 sec 3.41 sec 4.18 sec 3.33 sec 5.95 sec

Bytes envoyés = client -> serveur

bytes reçus = client <- serveur

Nous voyons très bien ici, que le cache joue un rôle important dans le nombre d bytes e é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.

Fichiers stockés dans le cache expirés ? www.microsoft.com

Oui. Echange de données avec le serveur Web

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

Flux Applicatif

20

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

Gaio Pascal Session 2001

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é www.hotmail.com www.microsoft.com Gain total Gain par Gain par de bytes le client le serveur 80 % 20 % 85 % 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

21

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

Gaio Pascal Session 2001

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 :

Cache client

Pas de requête

Refresh avec F5

Get Request If modified since (Last Modified)

Server Web
Response OK ou Not modified 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.

Flux Applicatif

22

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

Gaio Pascal Session 2001

L’échange sera du type :

Refresh avec ENTER
Client Les fichiers stockés dans le cache sont-ils encore valides ? Test du champ Expires Oui Cache client Non Get Request If modified since (Last Modified) Response OK ou Not modified

Server Web
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.

Cache client

Pas de requêtes

Refresh avec Shift + F5

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

Server Web

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 (nocache) n’est présent du côté client même si ce n’est pas le cas.

Flux Applicatif

23

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

Gaio Pascal Session 2001

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° 1 2 3 4 5 6 Nombres de paquets 146 143 150 146 149 147 Bytes envoyés 6296 6269 6582 6673 6458 6350
et

Bytes reçus 33476 33314 33422 33366 34008 33477

Bytes échangés 39772 39610 40004 40039 40466 39827

Temps de chargement 3.45 sec 3.42 sec 12.75 sec 4.51 sec 7.35 sec 3.48 sec

Bytes envoyés = client -> serveur

bytes reçus = client <- serveur

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° 1 2 3 4 5 6 Nombres de paquets 150 157 159 158 154 160 Bytes envoyés 6491 7743 7205 7110 6685 7515
et

Bytes reçus 33460 33471 33576 34619 33514 33983

Bytes échangés 39951 41214 40781 41736 40199 41498

Temps de chargement 3.87 sec 16.75 sec 14.05 sec 9.36 sec 3.21 sec 7.46 sec

Bytes envoyés = client -> serveur

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

24

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

Gaio Pascal Session 2001

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

Machine A

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

Connexion Administrateur

Cache Administrateur

Flux Applicatif

25

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

Gaio Pascal Session 2001

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.

Machine A

Machine B

Connexion à distance Compte administrateur

Caches identiques, on a une image du cache de la machine A Cache retourné (Local) Cache visualisé (Distant)

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).

Flux Applicatif

26

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

Gaio Pascal Session 2001

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 :

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.

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.

Flux Applicatif

27

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

Gaio Pascal Session 2001

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

Get Request Response OK
Server Web

Pas de requête sur le serveur web

X

Server Web

Client

Mise en cache

Client

Chargement depuis le 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.

Flux Applicatif

28

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

Gaio Pascal Session 2001

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 c omme 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. Fichiers stockés dans le cache expirés ? (champ Expires) Oui fichiers expirés Client 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 Server Web 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.

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

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.

Flux Applicatif

29

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

Gaio Pascal Session 2001

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 KeepAlive 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

30

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

Gaio Pascal Session 2001

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

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

Server Web

Client

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.

Flux Applicatif

31

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

Gaio Pascal Session 2001

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

32

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

Gaio Pascal Session 2001

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

33

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

Gaio Pascal Session 2001

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

Client

www.eig.unige.ch

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

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

Non

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

Non

Server Web

Affichage de la page depuis le cache

Flux Applicatif

34

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

Gaio Pascal Session 2001

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).

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

Client

Get request www.eig.unige.ch If-Modified-Since: Tue, 08 May 200112:30:10 GMT Response Ok ou No t modified suivant la date du paquet Server Web précédent

Flux Applicatif

35

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

Gaio Pascal Session 2001

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 Never Chapitre 2.1

Automatically Chapitre 2.2

Every time you start Internet Explorer Chapitre 2.3

Every visit to the page Chapitre 2.4

Fonctionnalités 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. 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. 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). 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

36

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

Gaio Pascal Session 2001

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 ors d’un accès au serveur par l 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

37

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

Gaio Pascal Session 2001

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

38

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

Gaio Pascal Session 2001

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

39

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

Gaio Pascal Session 2001

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

40

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

Gaio Pascal Session 2001

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. 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. 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. 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. 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.

- max-age :

- public :

- private :

- must-revalidate :

Flux Applicatif

41

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

Gaio Pascal Session 2001

- 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. 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.

- pragma :

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.

Cache client vide

Get Request

Client

Response OK Cache -control : no-cache

Server Web

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.

Flux Applicatif

42

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

Gaio Pascal Session 2001

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 e l 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é

Cache client présent Get Request If modified since (Last Modified) Response OK ou Not modified Cache -control : max-age = 120

Client

Server Web

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 Avant de se connecter Not Modified OK Last Modified 5 Novembre 12h00 5 Novembre 12h00 18 Novembre 15h30 Expires 18 Novembre 15h00 18 Novembre 15h32 18 Novembre 15h32 Last Accessed 18 Novembre 14h58 18 Novembre 15h30 18 Novembre 15h30

Flux Applicatif

43

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

Gaio Pascal Session 2001

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.

Pour activer la fonction de Login , valider cette case

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.

Flux Applicatif

44

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

Gaio Pascal Session 2001

3.6

Conclu sion
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

45

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

Gaio Pascal Session 2001

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

46

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

Gaio Pascal Session 2001

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.

Internet

Client Server ISA mode Cache

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 ISA mode Cache Server ISA mode Firewall

Flux Applicatif

47

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

Gaio Pascal Session 2001

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.

Internet

Client Server ISA mode Integrated

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.

Flux Applicatif

48

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

Gaio Pascal Session 2001

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

49

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

Gaio Pascal Session 2001

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.

Non

Internet

Client

Serveur ISA

Serveur Web

Request Response Oui

Date de Stockage Valide ?

Request

Response

Stockage des données. Avec date de validité suivant Les paramètre de http Caching

Response

Flux Applicatif

50

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

Gaio Pascal Session 2001

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

Request Response

Request Response

Temps d’expiration de la page

Aucuns paquets

Remise à jour du cache

Request Response

Flux Applicatif

51

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

Gaio Pascal Session 2001

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

52

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

Gaio Pascal Session 2001

Voici un tableau qui résume les différents choix. Mode choisi Protocole Protocole Protocole HTTP 1.0 HTTP 1.1 HTTP 1.1 utilisé utilisé à travers le proxy

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 Use http 1.1 X Use http 1.1 through proxy connections ü Use http 1.1 ü Use http 1.1 through proxy connections ü

ü
X

X ü X ü

X X ü ü

ü 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 cachecontrol : 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

53

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

Gaio Pascal Session 2001

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

54

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

Gaio Pascal Session 2001

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

55

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

Gaio Pascal Session 2001

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 :
Client

Internet

Serveur Web

Serveur ISA

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.

Flux Applicatif

56

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

Gaio Pascal Session 2001

5.4 5.4.1

Mode http Header Frequently 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.

Client

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

Get Request Via ISA Server to Server Web
Serveur ISA
Serveur Web

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

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

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.
Flux Applicatif

57

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

Gaio Pascal Session 2001

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.

Client

Get Request From Client to Server Web If modified Since (Last Modified ) Proxy Connection : Keep-Alive 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

Get Request Via ISA Server to Server Web If modified Since (Last Modified)
Serveur ISA

Serveur Web

I 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

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.

Flux Applicatif

58

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

Gaio Pascal Session 2001

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.

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

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 maxage = 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.

Flux Applicatif

59

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

Gaio Pascal Session 2001

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.

Client

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

Get Request Via ISA Server to Server Web
Serveur Web

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

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

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. Age = heure courante – heure 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.

Flux Applicatif

60

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

Gaio Pascal Session 2001

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
pas de cache

Serveur Web
Get Request If Modified Since (Last Modified)

Get Request

données de la page stockée

data non prise en compte car Not Modified envoyé par le serveur Web : J'ai reçu Not Modified validité du cache cache control = no-cache selon ISA = 900 sec alors prends les données qui sont dans mon cache et je t'envoie ausi les données du serveur Web pour que tu les stockes.

les données de la page sont stockées

Response OK cache control = 900
données de la page stockée

Not Modified cache control : no-cache

données de la page demandée

données de la page envoyée

Une fois que j'ai envoyé les données au client, je remets à jour mon cache selon les entêtes http envoyées par le serveur Web

Flux Applicatif

61

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

Gaio Pascal Session 2001

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.

Client

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
Serveur ISA
Serveur Web

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

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

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 q lui ue non plus n’a plus la page en cache.

Flux Applicatif

62

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

Gaio Pascal Session 2001

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)

Client

Serveur ISA

Serveur Web

Oui Est-ce que les données dans mon cache sont encore valides ? Non Idem Chapitre 5.4.2

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.

Flux Applicatif

63

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

Gaio Pascal Session 2001

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.

Client

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

Gett Requestt Ge equ s Viia IS A Serrverr V a S A Se ve tto S errverr W eb o S e ve W b IIff modiifiied Siince (E xpii es)) m df e S n ce E p r es
Serveur Web

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

Response Nott M odii iied Res onse No M d f e Frrom Serrver Web F om Se ve We tto IISA S errverr o SA S e ve Cache-C onttroll:: max--age = 60 Cache C n r o max age = 0 Expirres :: 19h31 Exp e 9h31 Datte ::19h30 Da 19 30 Last Modiifiied : Datte Las Modf e d Da e Aucunes données ttrransmises sii Aucun s do nées ansmises s aucunes modiifiicatiions surr lle siite a cunes mo f c a o ns su e s t

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.

Flux Applicatif

64

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

Gaio Pascal Session 2001

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.

Client

Serveur ISA

Serveur Web

Oui Est-ce que les données dans mon cache sont encore valides ? Non Non Fichiers stockés Get Request dans le cache From Client encore valides ? to Server Web Oui Proxy Connection : Keep-Alive If modified Since (Last Modifie d) Response Not Modified Via ISA Server to Client Expires : 12h49 Date : 12h34 Last Modified : Date Age = 157 Aucune donnée transmise Aucun paquet tant que la date d’expiration des fichiers du serveur ISA n’est pas dépassée. Idem cas 5.5.1

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

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

Flux Applicatif

65

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

Gaio Pascal Session 2001

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

66

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

Gaio Pascal Session 2001

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.

Client

Serveur ISA

Serveur Web

Est-ce que je possède la page en cache ? Oui Est-ce que la page est encore valide ? Oui Chargement de la page localement

Get Request Non

Est-ce que je possède la page en cache ? Oui Est-ce que la page est encore valide ? Oui Envoi des données de la page au client

Get Request Non

Non

Non

Stockage de la page dans le cache

Response

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)

Flux Applicatif

67

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

Gaio Pascal Session 2001

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.

Client

Serveur ISA

Serveur Web

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

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.

Flux Applicatif

68

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

Gaio Pascal Session 2001

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.

Cache du site Web du client A
Client A

Echange uniquement si les fichiers ne sont plus valides dans le cache d’ISA.
Serveur Web

Serveur ISA
Client B

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

Gett Requestt Ge Req es Viia IISA S errverr V a SA S e v tto Serrverr Web Se e Web IIff modiifii d S iince ((Expiires)) modf e d S nc e Expr es

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

Response Nott modiffiied Respons No mod e d Frrom S errverr Web F om S e ve Web tto IISA Serrverr A Se ve Cache--Conttrroll :: max--age = 120 Cache Con o ax age = 120 Expiires ::15h31 r es 15h3 Exp Date :: 15h29 Da e 1 h29 Lastt Modiified :: Datte Las Mo f ed Da e Aucunes données ttrransmiises Au unes donnée an ms es

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.

Flux Applicatif

69

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

Gaio Pascal Session 2001

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.

Adresse IP interne Subnet Mask Default Gateway

10.0.0.20 255.255.0.0 129.194.184.99

Adresse IP externe Subnet Mask Default Gateway Preferred DNS Alternate DNS
ISA Server

129.194.184.99 255.255.252.0 10.0.0.20 129.194.184.212 129.194.4.6

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.

Client

Get Request From Client 10.0.0.1 To Server Web
Serveur ISA

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

Serveur Web

Response From Server ISA Adr IP 10.0.0.20 To Client 10.0.0.1

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.

Flux Applicatif

70

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

Gaio Pascal Session 2001

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.

Client

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

Tentatives de connexion
Serveur Web

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

Pas de réponse

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.

Flux Applicatif

71

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

Gaio Pascal Session 2001

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 Cette commande signifie que lorsqu’on se connecte sur le serveur ISA en mode proxy la connexion se fait en mode keep -alive. 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) Cette commande nous renseigne sur la date d’expiration du fichier. (voir chapitre 14.21 RFC 2616) Cette commande nous renseigne sur la date de connexion au site. (voir chapitre 14.18 RFC 2616) 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) 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.

Proxy connection : Keep-Alive

Via

Expire

Date

Age

Active Caching Request

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

72

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

Gaio Pascal Session 2001

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

73

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

Gaio Pascal Session 2001

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

74

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

Gaio Pascal Session 2001

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.
Client

IP : 129.194.184.206 MASK 255.255.252.0 GATEWAY : 129.194.184.3

IP : 10.0.0.1 MASK 255.255.255.0 GATEWAY : 10.0.0.20 IP : 10.0.0.20 MASK 255.255.255.0 GATEWAY : 129.194.184.99

Internet

IP : 129.194.184.99 MASK 255.255.252.0 GATEWAY : 10.0.0.20

Server ISA mode Reverse Proxy
IP : 129.194.184.203 MASK 255.255.252.0 GATEWAY : 129.194.184.3

Server Web

Client

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 ».

Flux Applicatif

75

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

Gaio Pascal Session 2001

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 Server IP Adress Display Name Authentification Paramètres Netserver1 129.194.184.99 Optionnel, nous permet de rentrer un nom plus représentatif que le nom de la machine. 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. Si le mode d’authentification doit demander un certificat, il faut entré ici le nom du certificat.

Server Certificate

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

76

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

Gaio Pascal Session 2001

Maintenant que nous avons dit sur quelle adresse IP les clients s connectent, il faut e 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.

Adresse du serveur Web interne

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 m ode proxy et en mode reverse proxy.

Flux Applicatif

77

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

Gaio Pascal Session 2001

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.

Get Request From Client to 129.194.184.99
Client

Serveur ISA

Serveur Web

Connexion impossible Il faut une authentification pour exécuter la requête OK Login et password acceptés

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

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

78

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

Gaio Pascal Session 2001

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 Host Fonctionnalités Cette commande indique simplement le nom ou l’adresse que l’on veut atteindre Voir RFC 2616 chapitre 14.23 Cette commande sert au serveur Web pour savoir à qui il doit répondre. Voir RFC 2616 chapitre 14.36

Referer

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

79

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

Gaio Pascal Session 2001

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.

Client A

Get Request from client A To Server Web

Œ
Serveur ISA

Serveur Web

Get Request from client B To Server Web
Client B

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 deuxième requête

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

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.

Flux Applicatif

80

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

Gaio Pascal Session 2001

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

81

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

Gaio Pascal Session 2001

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.

o=eig

ou = telecommunication

ou = informatique

cn = TE3

cn = TE2

cn = IN3

cn = IN2

uid = pgaio

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. LDAP TCP IP ETHERNET 82

Flux Applicatif

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

Gaio Pascal Session 2001

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 = d

Flux Applicatif

uid = d 83

uid = b

uid = b

uid = d

uid = x

uid = y

uid = b

uid = x

uid = a

uid = c

uid = e

uid = c

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

Gaio Pascal Session 2001

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 o Organization ou cn Organization Unit Group

uid

User

Commentaire Généralement en haut de l’arbre Généralement en dessous de l’Organization. Ces groupes peuvent être créés où l’on veut dans l’annuaire. C’est uniquement ici que l’on peut ajouter des membres. 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 ObjectClass : inetOrgPerson Postal Adress Défini les entrées pour les personnes Common Name (obligatoire) Surname (obligatoire) ObjectClass : organizationalUnit Défini les entrées pour les Organization Unit Telephone Number Postal Adress Description Telephone Number Postal Adress Description BusinessCategory

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

Flux Applicatif

84

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

Gaio Pascal Session 2001

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 Search Compare Add Modify Delete Rename (Modify DN) Bind Unbind Abandon Extended

Description Recherche dans l’annuaire d’objets à partir de critères Comparaison d’un contenu de deux objets Ajout d’une entrée Modification du contenu d’une entrée Suppression d’une entrée Modification du DN d’une entrée Connexion au serveur Déconnexion Abandon d’une opération en cours 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

Scope = base
ou = telecommunication ou = informatique

cn = TE3

cn = TE2

cn = IN3

cn = IN2

uid = toto

Flux Applicatif

85

Ecole d’Ingénieurs de Genève HES - SO Laboratoire de transmission de données
o=eig

Gaio Pascal Session 2001

Scope = onelevel search
ou = telecommunication ou = informatique

cn = TE3

cn = TE2

cn = IN3

cn = IN2

uid = toto

Scope = subtree

o=eig

ou = telecommunication

ou = informatique

cn = TE3

cn = TE2

cn = IN3

cn = IN2

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.

Flux Applicatif

86

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

Gaio Pascal Session 2001

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 plateforme 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

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

ral fer Re

Server iPlanet Eleves
Connexion sur l'annuaire

Client LDAP

Server iPlanet EIG

Re fer ral

Flux Applicatif

Server iPlanet Professeurs

87

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

Gaio Pascal Session 2001

7.5.1

Architecture Annuaire EIG

o=eleves

o=eig

o=professeurs

Referral sur le serveur eleves

ou = telecommunication

ou = informatique

Referral sur le serveur professeurs

cn = TE3

cn = TE2

cn = IN3

cn = IN2

Liste des membres dynamiques du serveur élèves (TE3) + professeurs (TE3)

Liste des membres dynamiques du serveur élèves (IN3) + professeurs (IN3)

7.5.2

Architecture Annuaire Elèves

o=eleves

cn = IN3
Liste des membres statiques (X)

cn = TE3
Liste des membres statiques (XX)

ou = Liste d'élèves

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

Flux Applicatif

88

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

Gaio Pascal Session 2001

7.5.3

Architecture Annuaire Professeurs

o=professeurs

cn = IN3
Liste des membres statiques (X)

cn = TE3
Liste des membres statiques (XX)

ou = Liste des professeurs

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

Liste des 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.
serveur iPlanet LOCAL o=eig Referall Liste d'élèves sur le serveur iPlanet DISTANT

ou = telecommunication

ou = informatique

uid = PGaio uid = DCotte uid = PLogean uid = MPasquali uid = YSouchon uid = SBorsa uid = SBancal

cn = TE3 Membre STATIQUE IMPOSSIBLE

Flux Applicatif

89

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

Gaio Pascal Session 2001

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.

serveur iPlanet LOCAL o=eig

Referral

serveur iPlanet DISTANT o=eleves ou = telecommunication ou = informatique

cn = TE3 Membres Dynamiques

cn = TE3
Liste des membres statiques (X)

ou = Liste des élèves

Membres statiques

uid = PGaio uid = DCotte uid = PLogean uid = MPasquali uid = YSouchon uid = SBorsa uid = SBancal

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.
serveur iPlanet LOCAL o=eig serveur iPlanet DISTANT o=eleves ou = telecommunication ou = informatique Referral

cn = TE3

ou = Liste des élèves

Membres Dynamiques avec lien sur un uid précis

uid = PGaio uid = DCotte uid = PLogean uid = MPasquali uid = YSouchon uid = SBorsa uid = SBancal

Flux Applicatif

90

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

Gaio Pascal Session 2001

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

91

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

Gaio Pascal Session 2001

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.
Connexion TCP Bind Request (0) Bind Response (1) Search Request (3) Search Response (4)

Client

Search Response Simple (5)

Server iPlanet

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.

Flux Applicatif

92

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

Gaio Pascal Session 2001

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 Type Class

6

5 Primitive Construct

4

3

2 Tag Value

1

0

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

0

0

Universal

0

1

Application

Commentaires Ce type de classe peut être Primitif ou construit. C’est ici que l’on défini le type de données à transmettre. 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

93

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

Gaio Pascal Session 2001

Bit N°7 Bit N°6 1 0

Type Class Private

1

1

Context Specific

Commentaires Ce type est spécifique à une entreprise. Application entièrement privée. 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 Universal 1 Universal 2 Universal 3 Universal 4 Universal 5 Universal 6 Universal 10 Universal 16 Universal 17

Primitif construit Primitif Primitif Primitif Primitif Primitif Primitif Primitif Construit Construit

Type des données Boolean Integer Bit String Octet String Null Object Identifier (OID) Enumerated Sequence 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 0 Type Application

6 1

5 0

4 0

3 0

2 0 Application N°3

1 1

0 1

Flux Applicatif

}

}
Primitif

Search Request

}
94

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

Gaio Pascal Session 2001

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 0 1 2 3 4 5 6 7 8 9 10 11 14 15 16 19 23 24 Nom de l’application Bind Request Bind Response Unbind Request Search Request Search Response Search Response Simple Modifiy Request Modify Response Add Request Add Response Del Request Del Response Compare Request Compare Response Abandon Request Search Response Reference Extended Request Extended Response

8.1.2

Le champ Length
le second champ présent dans une structure de type ASN1 est le champ Length . Celuici à 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. Valeur de codage = 82 en hexadécimal et suite du codage Length > 256 Bits de la longueur sur les deux prochains octets.

Flux Applicatif

95

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

Gaio Pascal Session 2001

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 :

Type

Length

Content

Type

Length

Content

Type

Length

Content

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.

Flux Applicatif

96

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

Gaio Pascal Session 2001

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 Annuaire LDAP 129.194.187.52 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 Destination Adresse Client LDAP 129.194.184.203

Flux Applicatif

97

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

Gaio Pascal Session 2001

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 Type Length Type Content Length Content 5E 02 01 04 Data en hexadécimal 30 Décodage 00 1 1000 Univeral (00) de type construit (1) et de type Sequence (10000 = 16) Length = 94 bytes restant à transmettre Donnée de type Integer De longueur = 1 byte 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 trame Type 59 04 2B 63 6E 3D 54 45 33 2C 6F 75 Content 3D 74 65 6C 65 63 6F 6D 6D Content 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 Length Type Length Data en hexadécimal 64 Décodage 01 1 00100 Application (01) de type construit (1) et le choix N°4= SearchResponse Length = 89 bytes restant à transmettre Donnée de type Octet String De longueur = 43 bytes cn=te3,ou=telecommunication,o=filiere,o=eig

Flux Applicatif

98

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

Gaio Pascal Session 2001

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 30 2A 30 Décodage 00 1 1000 Univeral (00) de type construit (1) et de type Sequence (10000 = 16) Length = 42 bytes restant à transmettre 00 1 1000 Univeral (00) de type construit (1) et de type Sequence (10000 = 16) De longueur = 40 bytes Donnée de type Octet String De longueur = 11 bytes

Type Length Type Content Length Type Length Content Content

28 04 0B 6F 62 6A 65 63 74 objectclass 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 Structure de la trame Type Length Type Content Length Content Type Length Content Content Data en hexadécimal Décodage 00 1 10001 Universal (00) de type construit (1) et de type Set (10001 = 17) Length = 19 bytes restant à transmettre Donnée de type Octet String De longueur = 3 bytes TOP Donnée de type Octet String De longueur = 3 bytes groupofuniquenames

31 19 04 03 74 6F 70 04 12 67 72 6F 75 70 6F 66 75 6E 69 71 75 65 6E 61 6D 65 73

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

99

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

Gaio Pascal Session 2001

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.

Connexion TCP

Bind Request (0)

Bind Response (1)

Client Server iPlanet

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 p être atteinte, la connexion TCP n’arrivera pas à as 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.

Flux Applicatif

100

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

Gaio Pascal Session 2001

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.

SearchRequest (3)

SearchResponse (4)

SearchResponseSimple (5)

Client Server iPlanet

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), } 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

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.
o=Elèves

cn = TE3

uid = toto

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.

Flux Applicatif

101

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

Gaio Pascal Session 2001

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.
Add Request (8)

Add Response (9)

SearchRequest (3)

SearchResponse (4)

Client
SearchResponseSimple (5)

Server iPlanet

Si l’on regarde de plus prêt les paquets Add Request et Add Response voici ce q l’on ue obtient.
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

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.

Flux Applicatif

102

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

Gaio Pascal Session 2001

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.

Del Request (10)

Del Response (11)

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

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

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).

Search Request (3) search des données se trouvant dans la branche Search Response (4) o=eleves Search Response (4) uid = pgaio Search Response Simple (5 ) Del Request (10) uid = pgaio

Client

Del Response (11)

Server iPlanet
Del Request (10) o=eleves Del Response (11)

Flux Applicatif

103

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

Gaio Pascal Session 2001

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).
TCP SYN

TCP SYN

TCP SYN

Client

Server iPlanet

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.
Search Request (3) Search Request (3) Search Request (3) Search Request (3) Search Request (3)

Client

Server iPlanet

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 Numéro 1 Numéro 2 Numéro 3 Numéro 4 Numéro 5
Flux Applicatif

Time 0.1 sec 0.4 sec 1.0 sec 2.2 sec 4.6 sec

Différence des fréquences des paquets 0 + 0.3 sec + 0.6 sec + 1.2 sec + 2.4 sec 104

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

Gaio Pascal Session 2001

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)

Bind Request (0)

Bind Response (1)

SearchRequest (3) Size Limit = 0x00000001 SearchResponse (4)

SearchResponseSimple (5) success

Client

SearchRequest (3) Size Limit = 0x00000001 SearchResponse (4)

Server iPlanet

SearchResponseSimple (5) Size Limit Exceeded

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)

Flux Applicatif

105

Ecole d’Ingénieurs de Genève HES - SO Laboratoire de transmission de données
o=eig Niveau 0

Gaio Pascal Session 2001

ou = telecommunication

ou = informatique

Niveau 1

cn = TE3

cn = TE2

cn = IN3

cn = IN2

Niveau 2

uid = dcotte

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.
o=eig Niveau 0

Niveau 1 ou = telecommunication ou = informatique

Niveau 2 cn = TE3 cn = TE2 cn = IN3 cn = IN2

2 uid trouvés

2 uid trouvés

2 uid trouvés

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.

Flux Applicatif

106

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

Gaio Pascal Session 2001

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.

Unbind Request

Client Server iPlanet

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.

Flux Applicatif

107

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

Gaio Pascal Session 2001

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.
o=eig

ou = telecommunication

ou = informatique

cn = TE3

cn = TE2

cn = IN3

cn = IN2 Referral incorrect nom incorrect type incorrect

t rrec rect inco cor ral ype in fer Re é et t n érro nom

Ref e cor rral rec t

cn = classe

ou = IN2

cn = IN2

cn = IN3

cn = IN2

uid=dcotte

cn = sbancal

uid=dcotte

cn = sbancal

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.

Annuaire A
ral fer Re

Re fer ral

INTERBLOCAGE

Referral

Annuaire B

Annuaire C

Flux Applicatif

108

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

Gaio Pascal Session 2001

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.
o=eig

Serveur A

ou = telecommunication

ou = informatique

cn = TE3

cn = TE2

cn = IN3

cn = IN2

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

Referral

cn = IN2

Serveur B

uid=dcotte

cn = sbancal

Flux Applicatif

109

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

Gaio Pascal Session 2001

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.
o=eig ou = telecommunication Default Referral o = eig ou = informatique

cn = TE3

cn = TE2

cn = IN3

cn = IN2 Smart Referral cn = IN2

Serveur A pas d'informations trouvées sur le dn recherché

Serveur B Information trouvée

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

cn = sbancal

Serveur C Information retournée au client
Default Referral

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.

Flux Applicatif

110

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

Gaio Pascal Session 2001

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. 2. 3. 4. 5. 6. 7. Dans la console Directory Server, sélectionner l’onglet directory. Choisir dans l’annuaire, quelles données seront appelées depuis un autre serveur. Double cliquer sur cette donnée. (cliquer sur le bouton Advanced ). Cliquer sur la cellule indiquant l’attribut « Object class » et cliquer sur Add Value. Sélectionner referral dans la liste qui apparaît et cliquer sur OK. Cliquer sur Add Attribute. 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é.
Connexion TCP Bind Request (0) Bind Response (1) Search Request (3) Search Response Reference (19) Search Response Simple (5)

Server iPlanet 129.194.187.52

Connexion TCP

Client

Bind Request (0) Bind Response (1) Search Request (3) Search Response (4) Search Response Simple (5)

Server iPlanet référencé 129.194.184.203
Flux Applicatif

111

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

Gaio Pascal Session 2001

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.
Search Request sur o=eleves Search Response Reference ldap://129.194.184.203:389/o=eleves Search Response Simple

Server iPlanet
Search Request sur o=eleves Search Response uid=dcotte , uid = sbancal Search Response Simple

Client

Server iPlanet référencé

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.

Flux Applicatif

112

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

Gaio Pascal Session 2001

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.

Sauvegarde des données dans un fichier LDIF

Copie des données sur un autre serveur

Server iPlanet

Server iPlanet répliqué

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.

Flux Applicatif

113

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

Gaio Pascal Session 2001

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)
Connexion TCP

Bind Request

BindResponse

Search Request

Search Reponse

Search Response Simple

Server iPlanet
Extended Request

Server iPlanet répliqué

Extended Response

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.

Flux Applicatif

114

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

Gaio Pascal Session 2001

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.
Extended Request

Extended Reponse

Add Request

Add Response

Extended Request

Server iPlanet

Extended Response

Server iPlanet répliqué

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

Flux Applicatif

115

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

Gaio Pascal Session 2001

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.

Search Request LDAP : Attribute Type : objectclass LDAP : Attribute Value : supportedcontrol LDAP: Attribute Value : supportedextension

Server iPlanet

Server iPlanet répliqué

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.

Search Response Attribute 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.5 1.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 = supportedextension Server iPlanet
2.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

Server iPlanet répliqué

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.

Flux Applicatif

116

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

Gaio Pascal Session 2001

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.
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

Server iPlanet

Server iPlanet répliqué

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.

Extended Reponse (success)
LDAP: Response Name = 2.16.840.1.113730.3.5.4

Server iPlanet

Server iPlanet répliqué

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

Flux Applicatif

117

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

Gaio Pascal Session 2001

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

Extended Request
LDAP: Request Name = 2.16.840.1.113730.3.5.6

Server iPlanet

Server iPlanet répliqué

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.

Extended Reponse
(success)

Server iPlanet

Server iPlanet répliqué

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

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

Server iPlanet

Server iPlanet répliqué

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

Flux Applicatif

118

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

Gaio Pascal Session 2001

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

Extended Response
Success

Server iPlanet

Server iPlanet répliqué

Le serveur consommateur confirme la fin de la transaction. En résumant cette échange, voici ce qui se passe.
Connexion TCP

Bind Connexion

Search Request Quelles sont les attributs que tu supportes ? Search Response Voici les attributs que je supporte Search Reponse Simple Fin des données à envoyer Extended Request Voilà ce que j'ai dans mon annuaire Extended Response Ok Success j'ai reçu tes données Extended Request J'ai fini d'envoyer des données ; on se quitte Extended Response Success

Server iPlanet

Server iPlanet répliqué

Connexion close

Connexion close

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.

Flux Applicatif

119

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

Gaio Pascal Session 2001

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 ’ouverture l 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.

Add Request
Divers Attributs Transmis concernant l'utilisateur

Abandon Request

Server iPlanet

Server iPlanet répliqué

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

Flux Applicatif

120

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

Gaio Pascal Session 2001

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.

Add Request
DATA utilisateur 1

Add Request
DATA utilisateur 2

Add Request
DATA utilisateur 3

Add Request
DATA utilisateur 4

Add Request Server iPlanet
DATA utilisateur 5

Abandon Request

Server iPlanet répliqué

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

Add Response Success

Server iPlanet

Server iPlanet répliqué

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 ( nbind Request), il n’y a pas de réponse à la U commande Abandon Request. Les deux parties savent qu’elles doivent arrêter là le transfert des données.

Flux Applicatif

121

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

Gaio Pascal Session 2001

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..

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

Server iPlanet

Server iPlanet répliqué

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.

Extended Response
Success

Server iPlanet

Server iPlanet répliqué

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.

Unbind Request

Server iPlanet

Server iPlanet répliqué

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.

Flux Applicatif

122

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

Gaio Pascal Session 2001

On peut résumé l’échange de données entre les deux serveurs de la manière suivante.
Extended Request début de la réplication Extended Response ok je suis prêt Add Request voici un nouvel utilisateur ajoute-le dans ta liste Abandon Request c'est fini. C'était la dernière donnée à ajouter Add Response ok success

Server iPlanet

Extended Request J'ai fini d'envoyer des données ; on se quitte Extended Response Success Unbind Request je me deconnecte

Server iPlanet répliqué

Connexion close

Connexion close

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 c onsidère comme bon pour faire de la réplication car il n’est pas trop compliqué à utiliser et fonctionne relativement bien.

Flux Applicatif

123

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

Gaio Pascal Session 2001

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 (Cisco 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 :

IE 6.0 SP2 Win 2k Pro IP = 129.194.184.206

Firewall Check Point V 4.1 SP5 Win NT 4 Server IP Machine = 129.194.184.82 IP Machine = 10.0.0.1

IIS 5.0 SP2 Win 2k Server IP Machine = 10.0.0.2

Internet Client Firewall Check Point Server Web
IP Web par translation (NAT) 129.194.186.210

Server LDAP iPlanet Directory Server 5.0
IP Machine = 10.0.0.3 iPlanet 5.0 SP2 Win 2k Pro

Une configuration du Firewall est nécessaire afin que celui-ci accède au serveur LDAP p our 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.

Flux Applicatif

124

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

Gaio Pascal Session 2001

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

125

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

Gaio Pascal Session 2001

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

126

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

Gaio Pascal Session 2001

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.
Firewall Check Point V 4.1 SP5 Win NT 4 Server IP Machine = 129.194.184.82 IP Machine = 10.0.0.1

IE 6.0 SP2 Win 2k Pro IP = 129.194.184.206

IIS 5.0 SP2 Win 2k Server IP Machine = 10.0.0.2

Get Request 129.194.186.210 Reponse Unauthorized authentification requise
Client

Get Request 129.194.186.210 login et password

Firewall Check Point

Server Web
IP Web par translation (NAT) 129.194.186.210

Server LDAP iPlanet Directory Server 5.0
IP Machine = 10.0.0.3 iPlanet 5.0 SP2 Win 2k Pro

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.

Flux Applicatif

127

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

Gaio Pascal Session 2001

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: GE Request (from client using port 2269) T 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 0 … 25 26 … 51 52 … 61 62 63 Caractères «A » … «Z » «a » … «z» « 0 » … «9 » «+» «/ »

Codage Base 64

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 HEXA ASCII Binaire 8 bits Binaire 6 bits Codage en Hexa Codage Base 64 p g a i o 70 67 61 69 6F 01110000 01100111 01100001 01101001 01101111 011100 000110 011101 100001 011010 010110 111100 28 6 29 33 26 22 60 c G d h a W 8 Ajout de 0 pour compléter les

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/ .

Flux Applicatif

128

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

Gaio Pascal Session 2001

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.
Firewall Check Point V 4.1 SP5 Win NT 4 Server IP Machine = 129.194.184.82 IP Machine = 10.0.0.1

IE 6.0 SP2 Win 2k Pro IP = 129.194.184.206

IIS 5.0 SP2 Win 2k Server IP Machine = 10.0.0.2

Internet Client Firewall Check Point
Sea rch Req ue Equ st o=f ality irew ma all (w tch uid= hole s Sea pga ubtre io e) uid= rch R uid pga espo =p io,o n gaio =fire se ,o= wall firew B all ; ind R e aut hen quest tific atio Bin n sim dR ple esp = la suc ons bot ces e d s

Server Web
IP Web par translation (NAT) 129.194.186.210

Server LDAP iPlanet Directory Server 5.0
IP Machine = 10.0.0.3 iPlanet 5.0 SP2 Win 2k Pro

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.

Flux Applicatif

129

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

Gaio Pascal Session 2001

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.

HTTP Response Data du site web

HTTP Response Data du site web

Client

Firewall CheckPoint

Server Web

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

Flux Applicatif

130

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

Gaio Pascal Session 2001

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é.
Firewall Check Point V 4.1 SP5 Win NT 4 Server IP Machine = 129.194.184.82 IP Machine = 10.0.0.1

IE 6.0 SP2 Win 2k Pro IP = 129.194.184.206

IIS 5.0 SP2 Win 2k Server IP Machine = 10.0.0.2

Internet Client Firewall Check Point
Sea rch Req ue Equ st o=f ire ality ma wall (w tch uid= hole s Se ubtr pga ee) io uid= arch R uid pga espo =p io,o nse gaio =fir ,o= ewa firew Bin ll all ; d Re que aut hen st tific atio Bin n sim Inva d Res ple lid C pon =o balt red se d ent ials

Server Web
IP Web par translation (NAT) 129.194.186.210

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.

Server LDAP iPlanet Directory Server 5.0
IP Machine = 10.0.0.3 iPlanet 5.0 SP2 Win 2k Pro

Flux Applicatif

131

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

Gaio Pascal Session 2001

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.
Firewall Check Point V 4.1 SP5 Win NT 4 Server IP Machine = 129.194.184.82 IP Machine = 10.0.0.1

IE 6.0 SP2 Win 2k Pro IP = 129.194.184.206

IIS 5.0 SP2 Win 2k Server IP Machine = 10.0.0.2

Internet Client Firewall Check Point
Sea rch Req u Equ est o= ality firew ma all (w tch Sea uid= hole s rch oga ubtr Res ee) io pon se suc ces Simp s le

Server Web
IP Web par translation (NAT) 129.194.186.210

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.

Server LDAP iPlanet Directory Server 5.0
IP Machine = 10.0.0.3 iPlanet 5.0 SP2 Win 2k Pro

Flux Applicatif

132

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

Gaio Pascal Session 2001

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

133

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

Gaio Pascal Session 2001

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%20de s%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

134

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

Gaio Pascal Session 2001

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

135

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

Gaio Pascal Session 2001

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 N° 2251 N° 1777 N° 2830 HTTP 1.1 LDAP Version 3 LDAP Version 2 LDAP V3 Extension

Flux Applicatif

136

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

Gaio Pascal Session 2001

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 Check Point 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

137

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

Gaio Pascal Session 2001

Table des Matières

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

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

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

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

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

138

Ecole d’Ingénieurs de Genève HES - SO Laboratoire de transmission de données 5.1 5.2 5.3 5.4 5.4.1 5.4.2 5.4.3 5.4.4 5.5 5.5.1 5.5.2 5.5.3 5.5.4 5.6 5.7 5.8 5.9 5.10 5.11 5.12

Gaio Pascal Session 2001

Introduction.............................................................................................................................................................. 54 Fonctionnement du Serveur ISA ........................................................................................................................... 55 Test avec un seul client et une carte Ethernet sur ISA ...................................................................................... 56 Mode http Header Frequently............................................................................................................................... 57 Commande max-age envoyée par le serveur Web....................................................................................... 57 Cache présent valide sur le client et sur ISA avec rafraîchissement F5 ................................................... 58 Cas où le serveur Web envoi un no-cache ..................................................................................................... 60 Cache présent sur le client et sur ISA avec rafraîchissement ENTER...................................................... 63 Mode http Header Normally ................................................................................................................................ 63 Aucun cache présent sur le client mais présent sur ISA............................................................................. 64 Cache présent sur le client et présent sur ISA.............................................................................................. 65 Les autres cas ..................................................................................................................................................... 66 Différences entre les modes http Caching .................................................................................................... 67 Mode Active Caching ............................................................................................................................................ 68 Ajout d’un deuxième client .................................................................................................................................. 69 Fonctionnement du serveur ISA avec 2 cartes Ethernet .................................................................................. 70 Server Web Down................................................................................................................................................... 71 Les principales commandes HHTP rencontrées .......................................................................................... 72 Les fichiers LOG ............................................................................................................................................... 73 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 7.2 7.3 7.4 7.4.1 7.4.2 7.5 7.5.1 7.5.2 7.5.3 7.5.4 7.6 Les concepts de LDAP ........................................................................................................................................... 83 Les principes de LDAP .......................................................................................................................................... 83 Les annuaires LDAP ............................................................................................................................................... 85 Les choix effectués.................................................................................................................................................. 86 Installation du serveur iPlanet......................................................................................................................... 87 Installation du client ......................................................................................................................................... 87 Création de l’annuaire LDAP................................................................................................................................ 87 Architecture Annuaire EIG ............................................................................................................................. 88 Architecture Annuaire Elèves ......................................................................................................................... 88 Architecture Annuaire Professeurs ................................................................................................................ 89 Création de membres ........................................................................................................................................ 89 Conclusion ................................................................................................................................................................ 91

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

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

Flux Applicatif

139

Ecole d’Ingénieurs de Genève HES - SO Laboratoire de transmission de données 9.1 9.2 9.3 9.4 9.5

Gaio Pascal Session 2001

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

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

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

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

Flux Applicatif

140

Sign up to vote on this title
UsefulNot useful