> Mobilité > OUTLOOK 2003, EXCHANGE 2003 : Un régime sans compromis (2e partie)

OUTLOOK 2003, EXCHANGE 2003 : Un régime sans compromis (2e partie)

Mobilité - Par iTPro.fr - Publié le 24 juin 2010
email

par Christophe Leroux - Mis en ligne le 06/01/06- Publié en Janvier 2005

Lors du précédent numéro, nous avons étudié quelques facettes du trafic réseau généré par les clients de messagerie utilisant le protocole MAPI. A ce stade de l’article, nous pouvons déjà considérer qu’un important travail a été fait sur le couple Outlook 2003/Exchange 2003 afin de diminuer la consommation réseau.

Nous allons maintenant voir ce qui a été changé sur le client WEB appelé « Outlook Web Access »

Outlook Web Access, a été entièrement re-développé. Les interfaces utilisateurs d’OWA 2003 et d’Outlook 2003 sont désormais très proches. Le client OWA ne peut cependant pas remplacer Outlook pour l’ensemble des utilisateurs. En effet, malgré l’ajout de nouvelles fonctions (gestion des règles, classifications des messages par importances…), ce client Web ne dispose pas d’un mode autonome et ne sait pas gérer de dossiers d’archivages. Il ne convient donc pas aux utilisateurs gérant de gros volumes de messages et désirant travailler lors de déplacements.

Le client Outlook Web Access 2000 était usuellement appelé « client léger » avec bien souvent, une confusion sur la signification de « léger ». En effet, ce mot était associé à « trafic léger » et consommait donc moins de réseau qu’Outlook. De nombreux architectes étaient donc tentés de déployer ce client lorsque l’accès aux serveurs Exchange ne pouvait se faire qu’au travers de liens à faible débit. Cette interprétation était une erreur puisque OWA 2000 nécessitait la même bande passante qu’Outlook 2000. Le mot « léger » devait être pris dans le sens « léger en matière d’installation », par opposition à Outlook qui requiert l’installation d’un minimum de 50Mo sur le poste de travail.

Nous avons vu précédemment, que le couple Exchange 2003 / Outlook 2003 a considérablement diminué la bande passante réseau consommée par la messagerie. Outlook Web Access 2003 a également bénéficié d’amélioration dans ce sens.

Mode Premium ou Basic

OWA 2003 dispose de deux interfaces : Premium ou Basic. L’interface Basic a été développée pour offrir une vision simple de sa boîte aux lettres, ne travaillant que dans une seule fenêtre d’Internet Explorer et dispose de fonctionnalités réduites. Voir Figure 6.

L’interface Premium dispose quant à elle, d’un graphisme très proche de celui d’Outlook 2003 ainsi que de fonctionnalités également proches de ce dernier, comme la vérification d’orthographe, la gestion des marques de couleur pour classer ses messages, ou encore, la gestion des règles. Voir Figure 7.

Par défaut, lorsqu’un utilisateur se connecte à l’interface OWA 2003, le serveur lui présente la version Premium. L’utilisateur n’a pas la possibilité de se connecter en mode Basic, par contre, l’administrateur du serveur a la possibilité de forcer l’interface qui sera affichée en utilisant la segmentation OWA. Cette segmentation consiste à placer globalement sur le serveur dans le registre ou au niveau de l’utilisateur dans l’attribut msExchMailbox- FolderSet, une valeur correspondant à ce que l’on désire montrer lors de la connexion à OWA. Pour afficher plusieurs composants, il suffit de faire la somme des valeurs hexadécimales. Le tableau suivant donne la liste des valeurs possibles : Voir Tableau 1.

Si l’on souhaite laisser aux utilisateurs, le choix du mode d’affichage, il faut activer les « Forms Based Authentication ».

Les « Forms Based Authentication »

L’activation des « Forms Based Authentication » se fait au niveau du serveur virtuel HTTP du serveur Exchange. Le pré-requis à leur activation est l’utilisation de SSL. Lorsque qu’un utilisateur se connecte à un serveur OWA 2003 et que les « Forms Based Authentication » sont activés, une page Web apparaît afin de demander les informations de connexion de l’utilisateur, alors que, sans l’activation de cette fonction, ces informations de connexion sont demandées par l’intermédiaire d’un popup.

Comme vous pouvez le voir sur la capture d’écran (Figure 8), la page Web de connexion propose également à l’utilisateur de choisir son interface ainsi que de définir sur quel type d’ordinateur il est connecté. Ceci est important puisque, lors d’une connexion OWA utilisant les « Forms Based Authentication », un cookies est stocké sur le poste de travail tout au long de la session. Quand l’utilisateur choisit l’option « ordinateur public », la durée de vue du cokkies est de 15 minutes, alors qu’elle est de 24h pour le choix « ordinateur privé ». Ces valeur sont paramétrables coté serveur par clé de registre :

Lieu: HKEY_LOCAL_MACHINE \ System\ CurrentControlSet \ Services \ MSExchangeWEB \ OWA
Clé: TrustedClientTimeout
Type: REG_DWORD

Valeur: Nombre de minutes avant le timout du cookie. Si la clé de registre n’existe pas, la valeur est de 1440 (24 heures). Le minimum est 1, le maximum est 43200 (30 jours)

Lieu: HKEY_LOCAL_MACHINE \ System\ CurrentControlSet \ Services \ MSExchangeWEB \ OWA
Clé: PublicClientTimeout
Type: REG_DWORD

Valeur: Nombre de minutes avant le timeout du cookie. Si la clé de registre n’existe pas, la valeur est de 15 minutes. Le minimum est 1, le maximum est 43200 (30 jours)

En plus de l’utilisation du SSL qui crypte le trafic entre le serveur et le client, obligatoire pour activer les « Forms Based Authentication », cette durée de vie du cookies participe à la sécurité en cas d’oubli de fermeture de la session par l’utilisateur dans un cyber café ou un poste partagé.

L’activation des « Forms Based Authentication » n’a pas uniquement un rôle à jouer sur la sécurité, mais également sur le trafic généré par OWA.

En effet, dans le même onglet d’activation des « Forms Based Authentication » sur le serveur Exchange, il est possible de choisir si le trafic doit être compressé. Je ne vois pas, à ce jour, de raison de ne pas activer la compression, si ce n’est, l’utilisation d’Exchange sur un serveur aux ressources très limitées. L’option alors activée, IIS utilise le process GZIP pour compresser le trafic à destination du client OWA 2003. Le process GZIP n’existant pas coté client, le trafic venant du client à destination du serveur n’est pas compressé. Les pré-requis à l’utilisation de la compression sont :

  • Côté Client :
    • Poste de travail sous Windows 2000, Windows XP ou Windows 2003
    • Internet Explorer 6.0 + Q328970 minimum
  • Coté serveur :
    • Exchange 2003 sur Windows 2003 pour les serveurs Front-End
    • Exchange 2003 sur Windows 2000 ou Windows 2003 sur les serveur Back-End
       

    La mise en oeuvre de la compression diminue considérablement le trafic OWA 2003. Le graphique (Figure 9) vous montre le trafic généré lors de l’envoi de messages. On constate, que tous les modes d’OWA 2003 sont plus générateurs de trafic qu’OWA 2000. Ceci est lié au fait que l’interface est plus riche graphiquement et que dans le sens client/serveur, il n’y a pas de compression.

    Le graphique (Figure 10) montre le trafic généré par les mêmes messages, mais lors de la lecture. L’utilisation de la compression montre ici très clairement ses avantages et l’on comprend qu’il est alors très difficile de justifier la non utilisation de ce process GZIP.

    A l’instar d’Outlook 2003, il est difficile de se rendre compte du gain réseau global lié à l’utilisation d’OWA 2003 en comparaison à OWA 2000.

       
       

Téléchargez cette ressource

Checklist de protection contre les ransomwares

Checklist de protection contre les ransomwares

Comment évaluer votre niveau de protection contre les ransomwares à la périphérie du réseau, et améliorer vos défenses notamment pour la détection des ransomwares sur les terminaux, la configuration des appareils, les stratégies de sauvegarde, les opérations de délestage... Découvrez la check list complète des facteurs clés pour améliorer immédiatement la sécurité des terminaux.

Mobilité - Par iTPro.fr - Publié le 24 juin 2010