Architecture de RPC sur HTTP

proxy RPC agit pour le compte
du client en vue d’établir des connexions
RPC avec le serveur back-end qui
héberge la boîte à  lettres du client demandeur.
La figure 1 montre les connexions.
On observera quelques aspects importants
de cette architecture. Premièrement,
le proxy RPC n’est pas nécessairement
un système Exchange 2003
parce que le serveur proxy n’utilise pas
de composants Exchange dans son travail.
Un filtre ISAPI (Internet Server
API) dans IIS 6.0 effectue l’activité
proxy et, par conséquent, la seule exigence
est que le système utilise
Windows 2003. Deuxièmement, comme
le serveur proxy RPC est simplement
une fonction d’IIS 6.0, on peut le
placer sur le système Exchange 2003.
Et, troisièmement, bien que ce ne soit
pas recommandé pour des raisons de
performances et de meilleure pratique,
on peut placer le serveur GC sur
le système Exchange 2003 également.
Donc, en essence, tous les composants
serveur que la figure 1 montre peuvent
exister sur la même boîte de serveur.
Il faut aussi considérer le placement
du serveur par rapport aux parefeu
internes et externes et la DMZ (demilitarized
zone) résultante. On peut
placer le serveur proxy RPC dans la
DMZ et les serveurs Exchange et autres
AD (Active Directory) dans la partie interne
du réseau, comme le montre la
figure 2. Toutefois, comme il faut ouvrir
davantage de ports sur le pare-feu
interne, cette installation fait courir
des risques inutiles et est généralement
déconseillée. Le risque est particulièrement
présent avec les ports
attribués dynamiquement que vous
ouvrez pour autoriser les communications
RPC entre le serveur proxy RPC et
le serveur de cluster Exchange 2003.
En théorie, ces ports se trouvent dans
la fourchette 1024 à  65535, mais la
mise en oeuvre de RPC sur HTTP vous
oblige à  définir une plage plus étroite
(du port 6001 au port 6004). Vous définissez
cette plage en paramétrant des
registres, ce que j’expliquerai dans la
section suivante. En plus des ports que
montre la figure 2, le serveur proxy
RPC peut demander le port 88
(UDP/TCP) pour les services Kerberos,
le port 53 (UDP/TCP) pour les requêtes
DNS, le port 445 pour le
NetLogon SMB (Server Message
Block), et les ports pour tous autres
protocoles dont vous avez besoin pour
gérer ou superviser les services.
Il est une meilleure méthode qui
consiste à  placer le serveur proxy RPC
sur la partie interne du réseau et à  utiliser
un proxy forward HTTP générique
dans la DMZ, comme on le voit figure
3. Cette configuration n’a qu’une
connexion allant du proxy forward
HTTP dans la DMZ (dans ce cas, un serveur
Microsoft Internet Security and
Acceleration – ISA) au serveur proxy
RPC dans le réseau interne. Cette connexion peut emprunter le HTTP de
base (port 80), ou elle peut être cryptée
avec Secure Sockets Layer (SSL –
port 443). On peut aussi utiliser la
fonctionnalité RPC sur HTTP cryptée
d’Outlook 2003. Dans ce cas, les communications
peuvent être sécurisées
de plusieurs manières. La méthode la
plus classique consiste à  terminer la
connexion SSL au niveau du serveur
proxy forward HTTP et à  créer une
connexion HTTP de base vers le proxy
RPC. C’est une approche courante
parce que de tels serveurs proxy HTTP
sont généralement équipés d’un matériel
accélérateur cryptographique SSL.
Vous pouvez aussi canaliser la
connexion SSL entrante par le serveur
proxy HTTP et laisser au serveur proxy
RPC le soin de traiter le cryptage SSL.
Ou bien le serveur proxy HTTP pourrait
terminer la session SSL tournée
vers l’extérieur et établir une nouvelle
session SSL vers le serveur proxy RPC.
Configurer RPC sur HTTP
sur des serveurs
Pour mettre en oeuvre des RPC sur
HTTP, il faut faire plusieurs modifications
sur les serveurs. Tout d’abord, assurez-
vous que le service RPC sur
HTTP proxy est installé sur le serveur
utilisé comme serveur proxy RPC. Pour
cela, ouvrez l’applet Add/Remove
Programs Control Panel et cliquez sur
Add/Remove Windows Components.
Cochez la case Select the networking
service. Vérifiez que la case RPC over
HTTP service est cochée, comme dans
la figure 4, puis cliquez sur OK pour
installer le service.
Après avoir installé le service RPC
sur HTTP Proxy, descendez en passant
par le snap-in Microsoft Management
Console (MMC) IIS Manager jusqu’à 
l’objet Web Sites\Default Web Site\RPC
Virtual Directory et ouvrez la boîte de
dialogue Properties de l’objet, comme
le montre la figure 5. Naviguez jusqu’à 
l’onglet Directory Security et choisissez
Authentication and access control,
puis désactivez Anonymous access et
activez soit Integrated Windows
Authentication soit, si vous utilisez SSL,
Basic authentication. Si vous choisissez
Basic authentication, les références se
transfèrent en texte clair, mais grâce à 
SSL la connexion sera sécurisée, donc
cette méthode ne pose aucun problème.
Il faut ensuite configurer le serveur
pour qu’il se comporte comme le
proxy RPC. Pour cela, ouvrez un éditeur
de registre et naviguez jusqu’à  la
sous-clé de registre HKEY_LOCAL_MACHINESOFTWARE\Microsoft\Rpc\Rpc
Proxy puis définissez la valeur Valid-
Ports à  avec un type de donnée
de REG_SZ.
Quand vous définissez la valeur
pour la sous-clé de registre ValidPorts,
vous devez spécifier chaque serveur
avec lequel le serveur proxy RPC pourrait
communiquer, y compris tous les
serveurs mailbox Exchange 2003 et les
éventuels DC ou GC, et spécifier le
port 593 pour chaque serveur. Le service
RPC sur HTTP Endpoint Mapper
utilise le port 593 pour le handshaking de connexion initial. Dans cette chaîne
de valeur, vous indiquez aussi la plage
de ports sur laquelle vous laisserez la
communication s’effectuer. La figure 6
montre un exemple de cette chaîne de
valeur pour un serveur appelé osbex01.
Selon votre environnement,
l’emplacement du serveur et la résolution
de nom associée, vous pourriez
aussi spécifier le FQDN (Fully Qualified
Domain Name) des serveurs dans l’entrée
de registre ValidPorts si les formats
abrégés n’aboutissent pas à  une résolution
correcte. En regardant
l’exemple de la figure 6, on voit qu’en
plus de spécifier les entrées pour osbex01,
je spécifie aussi les entrées correspondantes
pour osbex01.osb.cantaz.
net. Si votre serveur GC est le
même serveur sur lequel vous utilisez
Exchange 2003, il est inutile de spécifier
le GC séparément du système
Exchange.
Evidemment, si l’on a des dizaines
ou des centaines de serveurs de boîte à 
lettres et de GC, la mise à  jour de la valeur
de registre ValidPorts avec des détails
sur chacun d’eux est une tâche
énorme. Pour cette raison, attendezvous
à  voir Microsoft offrir un utilitaire
avec Exchange 2003 qui analysera
votre environnement Exchange et
mettra à  jour automatiquement ce paramétrage
de registre.