Mettre en place

vous installez Exchange 2000 Server ou ultérieur. Pour
supporter l’OWA, l’installation crée plusieurs répertoires virtuels
IIS (Exchange, public, par exemple) que vous pouvez
visualiser au moyen du snap-in IIS Manager. Un utilisateur
entre une URL dans le champ adresse du navigateur pour indiquer
le répertoire virtuel associé à  l’application qu’il veut
exécuter. IIS invoque ensuite l’application à  laquelle l’URL
fait référence. Le fait d’invoquer l’application peut conduire
à  exécuter du code HTML ou ASP standard ou à  invoquer une
extension ISAPI, comme décrit ci-dessus. Par exemple, si
j’entre http://myserver/ Exchange dans mon navigateur, IIS
dirige la requête vers l’application associée au répertoire virtuel
Exchange. Par défaut, cette application est contenue
dans davex.dll qui interagit avec le Store pour extraire et
rendre le contenu de ma boîte à  lettres et passer le contenu
à  mon navigateur.
Comme l’OWA est installé par défaut, un navigateur Web
peut interagir directement avec tout serveur Exchange 2000
ou ultérieur et faire délivrer à  ce serveur un contenu boîte à 
lettres au dossier public par le biais du processus que je viens
juste de décrire. Mais vous pouvez choisir de marquer un serveur
Exchange comme un serveur frontal, ce qui change la
manière dont il réagit à  des requêtes URL. On est alors dans
une configuration serveur frontal/d’arrière plan ; par implication,
tout serveur non marqué comme serveur frontal est
considéré serveur d’arrière plan.
Les configurations frontales/d’arrière plan répondent à 
beaucoup d’objectifs et permettent des mises en oeuvre plus
souples et plus sûres. Ces configurations sont généralement
utilisées pour les communications cryptées SSL (Secure
Sockets Layer). Dans une configuration frontale/d’arrière
plan, le navigateur Web ne communique pas directement
avec le serveur Exchange qui rend le contenu de la boîte à 
lettres ou du dossier public. Il communique plutôt avec le
serveur frontal lequel, à  son tour, envoie par proxy la requête
à  un serveur d’arrière plan. Le serveur d’arrière plan recueille
ensuite le contenu nécessaire et le transmet au serveur frontal,
lequel renvoie le contenu au navigateur Web. Le serveur
frontal effectue toutes les requêtes de traitement et d’authentification SSL, soulageant ainsi le serveur d’arrière plan
de ce genre de traitement.
Quand vous établissez un serveur Exchange pour qu’il
fonctionne comme serveur frontal, la configuration IIS subit
certains changements subtils. Un serveur frontal exécute des
tâches différentes de celles d’un serveur d’arrière plan. La
principale tâche d’un serveur frontal est de passer par proxy
des requêtes HTTP aux serveurs d’arrière plan. Le fait de
marquer un serveur Exchange comme serveur frontal remplace
l’extension ISAPI par défaut, davex.dll, par une extension
appelée exprox.dll.
Second changement, les méthodes d’authentification
supportées par les répertoires virtuels Exchange. Un serveur
d’arrière plan supporte Integrated Windows Authentication
et l’authentification Basic, mais seule cette dernière est autorisée
sur un serveur frontal parce que celui-ci doit être capable
de s’authentifier vis-à -vis du serveur d’arrière plan
comme le client demandeur. Par conséquent, le serveur frontal
doit être en mesure de présenter les références de l’utilisateur
dans un en-tête d’hôte d’authentification d’une manière
compatible avec les méthodes que le serveur d’arrière
plan accepte.
Pour présenter l’information de l’utilisateur, le serveur
frontal devrait connaître le mot de passe de l’utilisateur et
Windows NT LAN Manager (NTML – la méthode négociée
par l’intermédiaire d’Integrated Windows Authentication)
n’implique pas l’échange d’un mot de passe entre le client et
le serveur – seul un total contrôle du mot de passe de l’utilisateur
est échangé. De ce fait, si Integrated Windows
Authentication était validé sur un serveur frontal, le serveur
n’aurait aucun moyen de déterminer le mot de passe d’un
utilisateur et ne serait pas capable de répondre aux challenges
en provenance du serveur d’arrière plan. L’authentification
Basic implique l’échange du mot de passe codé
base64 de l’utilisateur, donc le serveur frontal peut répondre
à  toute méthode d’authentification que le serveur d’arrière
plan supporte comme si le serveur frontal était le client réel.
On l’aura compris, l’authentification Basic représente
met en péril la sécurité parce qu’il est facile de décoder
base64. Une bonne sécurité impose que vous utilisiez SSL
pour protéger les serveurs frontaux. En fait, l’authentification
par formulaires requiert l’utilisation de SSL pour empêcher
un renifleur de réseau d’intercepter des références utilisateur.