Topologie de serveurs frontaux/principaux Exchange 2000
|
.gif){kind=icon}
Sur cette page
.gif){kind=icon}
Introduction
Environnements multiserveurs
Fonctionnement de la topologie de serveurs frontaux/principaux
HTTP (Outlook Web Access et dossiers Web)
Recherche des boîtes aux lettres des utilisateurs
Recherche de dossiers publics
Problèmes d'authentification
POP3
Accès IMAP4 aux dossiers publics
Considérations de déploiement
Ratios et configurations de serveurs recommandés
Scénarios
Scénarios Intranet
Topologie de serveurs frontaux/principaux par défaut
Ajout d'un serveur
Groupement Web
Scénarios Extranet
Caractéristiques requises pour un pare-feu
Serveur frontal derrière le pare-feu
Zone démilitarisée
Configuration
Configuration d'un serveur frontal
Configuration HTTP
Configuration d'un serveur principal
Configuration HTTP
Configuration d'un pare-feu
Configuration d'un pare-feu Internet
Configuration d'un pare-feu Intranet
Configuration supplémentaire
Protection de la communication du client vers le serveur frontal
Protection de la communication d'un serveur frontal vers un serveur principal
Configuration d'une topologie de serveurs frontaux/principaux : aide-mémoire
Introduction
Microsoft Exchange 2000 Server prend en charge le déploiement de Exchange de telle sorte que les tâches de serveur sont distribuées entre plusieurs machines, appelées serveurs frontaux et serveurs principaux. Cette topologie de serveurs frontaux/principaux sépare la gestion des protocoles et le traitement des demandes. De manière générale, un serveur frontal accepte des demandes issues de clients et les transmet pour traitement au serveur principal approprié. Ce document traite de l'architecture générale, avec une attention particulière pour le protocole HTTP.
Connaissances préalables
Ce document considère que le lecteur connaît Outlook Web Access, POP3 et/ou IMAP4 dans une topologie Exchange standard, et, en outre, que les concepts de base de Exchange 2000 et des IIS (Internet Information Services) de Windows 2000 sont compris.
Environnements multiserveurs
Microsoft recommande l'utilisation de la topologie de serveurs frontaux et principaux dans les organisations multiserveurs qui utilisent Outlook Web Access (OWA), POP3 ou IMAP4 et dans les organisations qui souhaitent fournir un accès OWA, POP3 ou IMAP4 à leurs employés sur Internet. Lorsqu'il reçoit une demande, le serveur frontal utilise le protocole LDAP (Lightweight Directory Access Protocol) pour interroger Windows 2000 Active Directory et déterminer sur quel serveur principal se trouve la ressource demandée.
Le recours à un déploiement de serveur frontal/principal présente les avantages suivants :
****
Espace de noms unique. Le principal avantage de l'utilisation d'une architecture de serveurs frontaux/principaux est l'espace de noms unique et cohérent. Vous pouvez définir un seul espace de noms pour permettre aux utilisateurs d'accéder à leur boîte aux lettres (par exemple http://mail pour Outlook Web Access). Sans serveur frontal, chaque utilisateur doit connaître le nom du serveur sur lequel se trouve sa boîte aux lettres, ce qui complique l'administration et compromet la flexibilité : pour toute extension ou modification de votre organisation nécessitant le déplacement de tout ou partie des boîtes aux lettres sur un autre serveur, vous êtes obligé d'informer les utilisateurs. Avec un espace de noms unique, les utilisateurs peuvent utiliser la même URL ou la même configuration des clients POP3 et IMAP4, même en cas d'ajout ou de suppression de serveurs ou en cas de déplacement de boîtes aux lettres d'un serveur à un autre. En outre, la création d'un espace de noms unique garantit que l'accès à POP3, IMAP4 ou Outlook Web Access demeure évolutif à mesure que votre organisation s'agrandit.
****
Déchargement du traitement. Les serveurs Exchange 2000 peuvent être configurés pour assurer le trafic SSL entre le client et le serveur, afin d'empêcher une éventuelle interception par un tiers. Le cryptage et le décryptage des messages consomment du temps processeur. Si vous utilisez le cryptage SSL, l'architecture de serveurs frontaux/principaux présente encore un avantage : les serveurs frontaux peuvent se charger des tâches de cryptage et de décryptage, ce qui améliore les performances en réduisant le traitement dévolu aux serveurs principaux, tout en permettant quand même le cryptage des données entre le client et les serveurs Exchange. En outre, la compression HTTP peut être déchargée vers les processeurs frontaux, ce qui accélère considérablement la récupération des données pour les clients se trouvant dans des scénarios à faible bande passante, et, plus généralement, améliore la disponibilité du réseau.
****
Pare-feu. Le serveur frontal peut être positionné en tant que point d'accès unique sur ou derrière un pare-feu Internet, configuré pour n'accepter depuis Internet que le trafic destiné au serveur frontal. Aucune information utilisateur n'étant enregistrée sur le serveur frontal, ce dernier fournit une couche de sécurité supplémentaire pour l'entreprise. En outre, le serveur frontal pouvant être configuré pour authentifier des demandes avant de les transférer au proxy, les serveurs principaux sont protégés des attaques en refus de service.
****
Amélioration de l'accès IMAP4 aux dossiers publics. Lorsqu'un client IMAP4 non activé pour la redirection (voir RFC 2221 et RFC 2193) se connecte via un serveur frontal, il peut accéder à toute la hiérarchie de dossier public. Lorsqu'un serveur frontal transfère une commande à un serveur principal, il suit automatiquement toute réponse de redirection retournée en cas de demande d'accès à un dossier qui n'est pas disponible sur le serveur principal. En l'absence de serveur frontal, il appartient au client de suivre la redirection.
L'architecture de serveurs frontaux/principaux prend en charge les protocoles HTTP, POP3, IMAP et SMTP. Les clients MAPI acceptent la redirection à partir du serveur lui-même, de sorte que les utilisateurs peuvent être déplacés de serveur en serveur et le client de chaque utilisateur adapte sa configuration pour pointer vers le nouveau serveur.
Fonctionnement de la topologie de serveurs frontaux/principaux
Le mécanisme utilisé par le serveur frontal dépend du protocole. Chaque protocole pris en charge fait l'objet d'une étude distincte.
HTTP (Outlook Web Access et dossiers Web)
Qu'elles soient générées par un navigateur ou un client spécialisé tel que les dossiers Web de Windows 2000, les demandes HTTP provenant de la machine cliente sont envoyées au serveur frontal. Le serveur utilise Active Directory pour déterminer à quel serveur principal la demande doit être transférée. Le mécanisme exact de cette décision varie selon que l'accès demandé concerne des dossiers publics ou des boîtes aux lettres d'utilisateurs, mais les données recherchées sont toujours retrouvées, quel que soit leur emplacement dans l'organisation Exchange.
Une fois déterminé le serveur principal concerné, le serveur frontal transfère au serveur principal une demande, en grande partie identique à la demande originale envoyée à partir du client. En particulier, l'en-tête de l'hôte HTTP (qui est généré par le client et qui correspond au nom du serveur frontal auquel la demande a été envoyée) reste inchangé, même si la nouvelle demande n'est pas envoyée à un serveur portant ce nom. La présence de ce paramètre en-tête de l'hôte garantit que la demande est traitée par le serveur virtuel Exchange qui doit être configuré sur chaque serveur principal pour gérer des demandes frontales.
L'élément qui change (potentiellement) est le port TCP utilisé pour le passage du trafic. Le serveur frontal contacte toujours le serveur principal sur le port TCP 80 (le port HTTP par défaut), quel que soit le port utilisé par le client. Cela signifie en premier lieu que SSL n'est jamais utilisé entre un serveur frontal et un serveur principal, même si le client en communication avec le serveur frontal peut l'utiliser. En second lieu, les serveurs virtuels qui se différencient des autres uniquement par un numéro de port ne sont pas acceptés dans une topologie de serveurs frontaux/principaux.
La demande envoyée par le serveur frontal est traitée normalement sur le serveur principal et la réponse est renvoyée sans modification via le serveur frontal au client. Dans la plupart des cas, le serveur principal considère simplement le serveur frontal comme un autre client.
Par conséquent, le client n'a jamais conscience que la demande n'a pas été traitée sur le serveur frontal. Les espaces de noms des URL utilisent le nom d'hôte transmis à l'origine, de sorte qu'il reste le même.
Recherche des boîtes aux lettres des utilisateurs
Pour fournir un accès aux dossiers privés via HTTP, vous devez créer un répertoire virtuel qui pointe vers les dossiers privés. Lorsque vous configurez ce répertoire virtuel via le Gestionnaire système Exchange, vous pouvez sélectionner le nom de domaine SMTP. Il doit exister un répertoire virtuel (ou serveur virtuel) pour chaque nom de domaine SMTP dont l'accès est prévu via la racine virtuelle. La racine virtuelle par défaut, "exchange", créée lors de l'installation, pointe sur le nom de domaine SMTP par défaut de l'organisation.
Lorsque le serveur frontal détecte une demande à destination d'un emplacement situé dans les dossiers privés (selon qu'elle accède au répertoire virtuel ou au répertoire racine du serveur virtuel), il contacte un serveur de catalogue global Active Directory dans le domaine et détermine quel serveur Exchange principal possède le compte de l'utilisateur. Le serveur frontal utilise le service Annuaire Exchange interne pour exécuter la demande sur l'Active Directory à l'aide de LDAP.
Compléments d'information
Un utilisateur dispose de deux façons de se connecter à sa boîte aux lettres via HTTP. La première, nommée connection implicite, prend la forme d'un raccourci d'URL. C'est le cas lorsque le nom d'utilisateur n'est pas spécifié dans l'URL (par exemple https://server/exchange/). L'authentification est alors requise sur le serveur frontal. Une fois l'utilisateur authentifié, le jeton de sécurité est utilisé pour rechercher la boîte aux lettres associée à l'utilisateur dans Active Directory et le serveur principal sur lequel elle se trouve. L'URL est alors complétée avec le nom d'utilisateur et envoyée au serveur principal approprié.
Une connection explicite inclut le nom d'utilisateur dans l'URL (par exemple https://server/exchange/username/) ; elle est utilisée lorsque le serveur frontal n'effectue pas d'authentification ou lorsqu'un utilisateur tente d'accéder à une boîte aux lettres qui ne lui appartient pas (mais à laquelle il a accès). Le nom d'utilisateur est extrait de l'URL et combiné au nom de domaine SMTP associé au répertoire ou au serveur virtuels (cette association est effectuée lors de la création du répertoire ou du serveur virtuels). L'alias SMTP complet est ensuite recherché dans Active Directory, qui retrouve le serveur hébergeant la boîte aux lettres. La demande est alors transférée à ce serveur. Enfin, la réponse à la demande est renvoyée au serveur frontal, qui la transmet au client.
Recherche de dossiers publics
De même qu'il faut configurer des répertoires virtuels pour des dossiers privés, il faut créer des répertoires virtuels pour chaque arborescence de dossiers publics qui doivent être accessibles via HTTP par l'intermédiaire du serveur frontal. Lors de l'installation, un répertoire virtuel, "public", est créé pour permettre l'accès à l'arborescence des dossiers publics par défaut (ou accessible MAPI). Pour d'autres arborescences de dossiers publics (utilisés pour héberger des applications), les répertoires virtuels doivent être créés à l'aide du Gestionnaire de système Exchange et configurés de façon appropriée.
Une demande adressée à une URL dans une arborescence de dossiers publics est gérée légèrement différemment selon que vous accédez à l'arborescence de dossiers publics par défaut (ou accessible MAPI) ou que vous accédez aux arborescences de dossiers publics des applications (c'est à dire application TLH ou TLH non MAPI, où TLH, Top Level Hierarchy, signifie Niveau hiérarchique supérieur).
Dans les deux cas, cependant, l'objectif est double : disponibilité et cohérence. Tout d'abord, si les données recherchées sont disponibles où que ce soit dans l'organisation via HTTP, elles seront fournies à l'utilisateur. En outre, tout est mis en œuvre pour garantir que, pour un utilisateur donné, le même serveur de dossiers publics sera toujours utilisé. Ainsi, l'utilisateur verra les mêmes données chaque fois qu'il accédera aux arborescences de dossiers publics via le serveur frontal (y compris l'état lu/non lu des messages, stocké sur les serveurs individuels, mais non répercuté sur les serveurs de dossiers publics). Le fait que les utilisateurs accèdent toujours au même serveur principal est également important pour les applications réseau qui conservent l'état des sessions, telles que celles créées avec Active Server Pages.
Compléments d'information
Lors de l'accès à l'arborescence de dossiers publics par défaut, une tentative est faite pour conserver la parité avec des clients MAPI, tels que Outlook 2000. Lorsque des administrateurs configurent un profil d'utilisateur, la banque de boîtes aux lettres de l'utilisateur est associée à une banque de dossiers publics spécifique, quelque part dans l'organisation (parfois sur la même machine que la banque d'informations privée, mais parfois sur des serveurs de dossiers publics dédiés). Il s'agit de la banque de dossiers publics qui s'affiche dans le client Outlook 2000. Après l'authentification de l'utilisateur, le serveur frontal extrait cette information de Active Directory et transfère les demandes au serveur de dossiers publics de l'utilisateur authentifié. Ce mécanisme garantit que les utilisateurs basculant entre Outlook 2000 et Outlook Web Access voient les mêmes données, et il bénéficie de l'équilibrage de la charge que les administrateurs ont configuré dans le système. Si l'utilisateur authentifié n'est pas associé à une boîte aux lettres (par exemple, lorsque les utilisateurs Windows NT 4.0 sont transmis aux boîtes aux lettres Exchange 2000), le serveur frontal traite les accès à l'arborescence de dossiers publics par défaut de la même façon que les accès aux arborescences de dossiers publics des applications.
Pour l'accès aux arborescences de dossiers publics des applications, il n'existe pas d'informations de configuration comme celles de l'arborescence de dossiers publics par défaut ; le serveur frontal contacte donc le serveur Active Directory pour obtenir la liste des serveurs Exchange qui ont un réplica de la hiérarchie de l'arborescence des dossiers publics. Cette liste est filtrée pour supprimer les serveurs Exchange 5.5 de l'organisation, car ils ne reconnaissent pas les extensions HTTP (WebDAV) prises en charge par Exchange 2000. Afin d'équilibrer les demandes sur les serveurs disponibles, le jeton d'authentification de l'utilisateur est utilisé pour appliquer un algorithme de hachage1 sur la liste des serveurs, assurant une distribution équitable tout en garantissant que les utilisateurs accéderont toujours au même serveur principal.
1 Un algorithme de hachage applique un nombre donné (dans ce cas, le jeton de sécurité) pour générer une position dans une liste, telle que la distribution de toutes les entrées possibles soit également répartie dans la liste.
La présence d'une hiérarchie d'arborescence des dossiers publics n'implique pas nécessairement que le serveur principal choisi disposera d'un réplica du contenu d'un dossier particulier ; il existe donc un traitement spécial pour le cas où le serveur ne contiendrait pas de réplica du dossier demandé (ou du dossier dans lequel réside l'élément demandé). Lorsqu'une telle demande est détectée à partir d'un serveur frontal, le serveur principal renvoie une réponse spéciale. Au lieu de simplement rediriger cette demande vers un serveur contenant ces données (comme il le ferait si la demande provenait d'un client ordinaire), il donne au serveur frontal la liste précise des serveurs disposant du contenu de ce dossier particulier (informations qui ne sont pas disponibles à partir d'Active Directory). Le serveur frontal ne retourne pas ces nouvelles informations au client, mais il les utilise pour affiner le filtrage de sa liste de serveurs possibles et il recommence la procédure de sélection depuis le début. Ainsi, dans le pire des cas, le serveur frontal devra effectuer deux demandes pour satisfaire la demande du client.
Naturellement, le serveur frontal tient à jour des caches qui réduisent substantiellement le traitement réel des demandes sur Active Directory et les serveurs principaux, tant pour les accès aux dossiers publics que privés. Les informations du cache expirent au bout d'un certain délai et sont également réinitialisées lorsque des changements sont détectés dans la configuration du serveur.
Deux autres points méritent d'être abordés. Tout d'abord, si un serveur est en panne ou s'il est inaccessible via HTTP pour toute autre raison, il est marqué comme tel lors des premiers échecs de connection, et supprimé de la liste des serveurs disponibles pour une période de 10 minutes, de sorte que les demandes suivantes ne soient pas affectées. Au bout de 10 minutes, une autre tentative est effectuée. Le serveur est supprimé de la liste de telle manière que cela n'affecte pas d'autres utilisateurs. Seuls les utilisateurs qui auraient normalement été dirigés vers ce serveur sont détournés vers d'autres serveurs, selon une répartition régulière.
Le second point concerne la configuration du serveur. Si elle est changée de manière permanente, quelle qu'en soit la raison, tous les utilisateurs risquent d'être dirigés vers des serveurs différents. Un changement permanent entraîne l'ajout ou la suppression de serveurs dans la liste des serveurs qui hébergent une hiérarchie d'arborescence de dossiers publics particulière. Cela peut provoquer des problèmes temporaires avec les applications qui tiennent à jour l'état des sessions, ou entraîner, pour les utilisateurs qui parcourent des dossiers publics, une réinitialisation de l'état lu/non lu de leurs messages ; de tels changements doivent donc faire l'objet d'une notification des problèmes potentiels aux utilisateurs.
Problèmes d'authentification
Le serveur frontal peut soit authentifier l'utilisateur lui-même, ce qui présente certains avantages, soit transférer l'authentification directement aux serveurs principaux. Il est important de noter que, dans les deux cas, le serveur principal procède également à l'authentification. Microsoft recommande fortement que le serveur frontal soit configuré pour authentifier des utilisateurs, en particulier s'il est en contact direct avec Internet.
Dans un scénario de serveurs frontal/principal, seule l'authentification de base est prise en charge. Il s'agit d'un mécanisme d'authentification assez simple qui crypte légèrement le nom d'utilisateur et le mot de passe de l'utilisateur avant de l'envoyer au client. Pour une protection par mot de passe correcte, SSL doit être utilisé en association avec l'authentification de base.
Ni la Windows Integrated Security (Sécurité intégrée de Windows), module qui prend en charge l'authentification NTLM et Kerberos, ni l'authentification Digest ne sont gérées par les frontaux HTTP Exchange 2000.
Authentification directe
Dans un scénario d'authentification directe, le serveur frontal est configuré avec l'authentification anonyme. Par conséquent, aucun en-tête d'autorisation n'est demandé à l'utilisateur. Toutefois, le serveur principal interroge l'utilisateur, et la stimulation et sa réponse sont routées sans modification via le serveur frontal. L'authentification directe ne doit pas être utilisée, sauf si le serveur frontal ne peut effectuer l'authentification (par exemple, dans une DMZ, ou zone démilitarisée, verrouillée ; consultez les sections "Scénarios").
Authentification double
Dans un scénario d'authentification double, les serveurs frontal et principal sont tous deux configurés pour authentifier l'utilisateur. Certes, les deux serveurs doivent procéder à l'authentification, mais ce n'est pas vraiment gênant. Avec l'authentification HTTP de base, les informations d'authentification sont jointes à toute demande du client au serveur, et sont transmises au serveur principal par le serveur frontal. Ces informations d'authentification suffisent aux deux serveurs ; par conséquent, après la stimulation initiale émise par le serveur frontal, le serveur principal reçoit les mêmes informations et n'a pas besoin d'émettre de nouvelle stimulation. En outre, les serveurs Windows 2000 mettent les informations d'authentification en cache, ce qui accélère les demandes d'authentification suivantes. Microsoft préconise que les serveurs frontaux soient configurés pour effectuer l'authentification chaque fois qu'elle est nécessaire pour accéder à des dossiers publics ou chaque fois qu'un serveur frontal est déployé sur Internet. S'il est impossible d'activer l'authentification double, les connections implicites deviennent impossibles, de même que l'équilibrage de la charge des demandes sur les dossiers publics.
POP3
Lors de l'utilisation d'un serveur frontal, les noms des véritables serveurs qui hébergent les boîtes aux lettres ne sont pas connus des utilisateurs. La configuration des clients POP3 et IMAP4 s'en trouve simplifiée et facilement standardisée, puisque le client de chaque utilisateur est configuré pour être connecté au nom d'hôte partagé par les serveurs frontaux. Les déplacements d'utilisateurs entre les serveurs sont transparents pour l'utilisateur et ne requièrent aucune reconfiguration du client.
Compléments d'information
Un client POP3 ou IMAP4 envoie au serveur frontal une demande de connection contenant le nom de la boîte aux lettres à atteindre. Le serveur frontal n'authentifie pas l'utilisateur. Il utilise simplement Active Directory pour déterminer à quel serveur principal transférer les commandes. La demande de connection est ensuite transférée du serveur frontal à la machine principale appropriée, qui procède alors à l'authentification. Le serveur principal renvoie ensuite les résultats de l'opération de connection à la machine frontale, qui les transmet à son tour au client. Les commandes POP3 ou IMAP4 suivantes sont gérées de manière similaire.
Accès IMAP4 aux dossiers publics
Lorsqu'un client IMAP4 non activé pour la redirection se connecte à un serveur principal, seuls les dossiers publics qui ont un réplica sur le serveur associé de l'utilisateur lui sont accessibles. D'autres dossiers publics sont accessibles aux clients IMAP4, mais l'accès à ces dossiers nécessite l'utilisation d'un client activé pour la redirection des boîtes aux lettres.
Compléments d'information
Un client activé pour la redirection des boîtes aux lettres émet des commandes spéciales vers un serveur IMAP4 pour déterminer la liste complète des dossiers publics à sa disposition. En cas de sélection d'un dossier public dépourvu de réplica local, le serveur répond à la demande du client par une URL de référence contenant le nom du serveur qui détient les données. Le client activé pour la redirection crée ensuite une nouvelle connection à ce serveur, pour extraire les informations appropriées.
Lorsqu'un client IMAP4 interroge un serveur frontal, ce dernier agit en tant que client activé pour la redirection. Il mappe de manière transparente des demandes de client normales sur leurs homologues de référence, mettant la liste complète des dossiers publics à la disposition d'un client non activé pour la redirection. Lorsque le serveur frontal reçoit du serveur principal une réponse de référence, il ne retourne pas cette réponse au client, mais il suit cette référence pour le client et établit une connection au serveur principal détenant les données. Ce dernier répond alors avec l'élément demandé, que le serveur frontal renvoie ensuite au client.
Considérations de déploiement
Ratios et configurations de serveurs recommandés
La configuration d'un serveur dépend d'un grand nombre de facteurs, notamment le nombre d'utilisateurs par serveur principal, les protocoles utilisés et l'utilisation prévue. Les modèles particuliers doivent être configurés selon les recommandations d'un consultant ou d'un fournisseur de matériel. D'autres informations sur le dimensionnement des serveurs seront disponibles d'ici le lancement du produit.
En général, un serveur frontal suffit pour quatre serveurs principaux. Cependant, ce ratio n'est fourni qu'à titre indicatif. Cette règle n'est pas rigide. Cette information ne doit être utilisée que comme point de départ.
Scénarios
Cette section présente des scénarios courants dans lesquels la topologie de serveurs frontaux/principaux Exchange 2000 est déployée. En gros, ces scénarios peuvent être divisés entre scénarios Intranet et Extranet, les premiers mettant l'accent sur les performances et l'évolutivité et les seconds sur la sécurité.
Chaque scénario aborde les questions suivantes :
Scénario : Présentation du scénario et de ses applications.
Instructions d'installation : Installation du scénario, décrite en termes généraux, puis instructions de configuration spécifiques.
Discussion : Quelles sont les particularités de ce scénario ? Comment fonctionne-t-il ? Quelles sont les informations supplémentaires nécessaires pour prendre des décisions à propos de ce scénario ?
Problèmes : Limites et risques connus de ce scénario.
Scénarios Intranet
Topologie de serveurs frontaux/principaux par défaut
Scénario
Une entreprise souhaite conserver un seul espace de noms pour ses serveurs de messagerie, mais tous ses utilisateurs ne peuvent tenir sur un seul serveur.
Instructions d'installation
Installez un ensemble standard de serveurs Exchange 2000. Installez un seul serveur Exchange 2000 comme serveur frontal. Dirigez les utilisateurs vers ce serveur, et non pas vers leurs serveurs principaux. Tous les serveurs et les répertoires virtuels doivent être configurés de manière identique sur chacun des serveurs.
Discussion
Il s'agit de la configuration par défaut. Aucune autre étape n'est nécessaire que les étapes de configuration standard des serveurs frontaux et principaux.
Problèmes
Il faut noter que, du moment que le réseau permet d'établir des connections entre le client et les serveurs principaux, rien n'empêche les utilisateurs de contourner le serveur frontal et de se connecter directement au serveur principal. Si ce n'est pas souhaitable, la configuration de routage du réseau ou celle du serveur principal doit alors être modifiée pour interdire les connections directes entre les clients et les serveurs principaux.
Ajout d'un serveur
Scénario
Tous les utilisateurs d'une entreprise se trouvent sur un même serveur Exchange 2000. L'ajout d'une autre machine au serveur permettrait de mieux gérer la charge. Toutefois, les responsables de l'entreprise souhaitent ne rien modifier vis-à-vis de leurs utilisateurs (en particulier en ce qui concerne leur manière d'accéder à leur boîte aux lettres). Dans ce scénario, l'entreprise souhaite prendre un seul serveur et en ajouter un autre sur lequel décharger les données des utilisateurs.
Instructions d'installation
L'environnement d'origine est constitué d'un seul serveur Exchange 2000, le serveur A. Un second serveur Exchange, le serveur B, est ajouté au scénario. Les deux serveurs hébergent des utilisateurs et/ou des dossiers publics.
Discussion
Cette configuration est prise en charge mais il ne s'agit pas d'un scénario de serveurs frontaux/principaux au sens strict. Exchange 2000 redirige les demandes HTTP vers des dossiers tant publics que privés s'ils ne se trouvent pas sur le serveur auquel la demande a été envoyée, du moment que les dossiers existent quelque part sur le serveur Exchange. Notez que cela ne préserve pas l'illusion d'un unique espace de noms. Cette configuration renvoie au client une véritable redirection HTTP ou une orientation IMAP4 (plutôt que de transférer la demande), de sorte que le client doit renvoyer la demande vers le nouvel emplacement. En conséquence, tandis qu'Outlook Web Access (et d'autres applications de navigation) fonctionne sans autre intervention de l'utilisateur, les dossiers Web ou d'autres applications doivent modifier les URL qu'elles utilisent, à moins qu'elles ne prennent en charge les redirections. De plus, un client IMAP4 activé pour la redirection de connection est indispensable aux utilisateurs dont les boîtes aux lettres se trouvent sur le serveur B, et un client activé pour la redirection de boîtes aux lettres est nécessaire pour accéder aux dossiers publics dont il n'existe pas de réplica sur le serveur associé de l'utilisateur.
Procédure de connection unique : L'un des avantages de cette technique est d'autoriser des méthodes d'authentification autres que l'authentification de base. Dans des déploiements nécessitant une procédure de connection unique, cette topologie peut être adoptée. Il lui manque une grande partie des avantages de la topologie des serveurs frontaux/principaux et elle ne devrait être déployée qu'en toute connaissance de cause.
Pour déployer efficacement cette topologie de manière pseudo frontale, un serveur (ou un groupe de serveurs) doit être désigné comme premier serveur à traiter la demande. Aucun utilisateur ne doit se trouver sur ce serveur et aucunes données des dossiers publics ne doivent y être répliquées. Ensuite, ce serveur générera toujours les redirections vers les dossiers appropriés.
Problèmes
La redirection de serveurs Exchange virtuels supplémentaires (c'est-à-dire des serveurs virtuels autres que le serveur par défaut) n'est pas prise en charge. Les répertoires virtuels des deux serveurs doivent être configurés de manière identique pour assurer correctement la redirection.
Groupement Web
Scénario
Une société implémente Outlook Web Access pour 200 000 utilisateurs. L'objectif est d'utiliser un seul espace de noms (par exemple, http://mail) permettant aux utilisateurs d'accéder à leur boîte aux lettres. De plus, pour des raisons de performances, la société ne veut pas d'un goulet d'étranglement au niveau du serveur frontal, ni d'un seul point faible ; elle souhaite donc répartir la charge sur plusieurs serveurs frontaux à l'aide du service d'équilibrage de la charge réseau de Windows. Les autres mécanismes d'équilibrage de la charge sont soit la méthode DNS à répétition alternée (RRDNS), soit une solution matérielle.
Instructions d'installation
Installez M serveurs comme serveurs principaux dans le même domaine, avec des utilisateurs distribués entre ces serveurs. Installez N serveurs comme serveurs frontaux et installez le service d'équilibrage de la charge réseau de Windows 2000 (précédemment appelé service d'équilibrage de la charge de Windows) sur tous les serveurs.
Discussion
Consultez la documentation sur l'équilibrage de la charge réseau de Windows pour obtenir des informations détaillées sur la façon de l'installer. La configuration ne nécessite pas d'action particulière aux serveurs Exchange 2000.
Problèmes
Étant donné que seule l'authentification de base est prise en charge via le serveur frontal Exchange 2000, les utilisateurs sont toujours invités à s'authentifier, même s'ils sont déjà connectés à l'aide de Windows.
Lors de l'utilisation du cryptage SSL, la méthode DNS à répétition alternée n'est pas recommandée. Dans le cas présent, la solution adoptée devrait garantir que chaque utilisateur soit toujours dirigé vers le même serveur frontal, afin de ne pas altérer les performances. Le service d'équilibrage de la charge réseau de Windows 2000 offre cette possibilité, de même que certaines solutions matérielles.
Scénarios Extranet
Tous ces scénarios nécessitant un pare-feu, une brève présentation des conditions requises pour les pare-feu ainsi que certaines recommandations s'imposent.
Caractéristiques requises pour un pare-feu
Un pare-feu peut être constitué de solutions logicielles ou matérielles. Les solutions logicielles incluent Microsoft Proxy Server 2.0.
Le pare-feu protégeant le serveur des risques liés à Internet doit au moins assurer le filtrage de port, réalisable par une solution soit logicielle soit matérielle. Le filtrage de port limite le trafic via le pare-feu à des ports spécifiques. Pour HTTP, seuls les ports 80 et/ou 443 (pour SSL) doivent être autorisés. Étant donné que les serveurs frontaux HTTP n'autorisent que l'authentification de base, il est fortement recommandé de configurer le serveur frontal pour qu'il accepte SSL et qu'il bloque les connections non-SSL. Cette solution garantit le cryptage de tout le trafic entre le client et le serveur.
Afin que SSL fonctionne correctement sur le serveur frontal, la solution du pare-feu ne doit pas bloquer la connection SSL, ou doit la recréer lors de la communication avec le serveur frontal.
Pour une meilleure efficacité, le pare-feu peut également prendre en charge le filtrage IP . Le trafic via le pare-feu sera ainsi limité au serveur frontal.
La solution du pare-feu doit prendre en charge de manière explicite les méthodes WebDAV HTTP et "l'encapsulation des méthodes inconnues" et sinon, ne pas empêcher les méthodes WebDAV HTTP (commandes) de traverser le pare-feu. Pour obtenir une liste des serveurs proxy pour lesquels existent des informations de prise en charge WebDAV .gif)
.gif)
. Il se peut que d'autres solutions de pare-feu ou de serveur proxy acceptent WebDAV HTTP. Contactez votre fournisseur de pare-feu pour plus d'informations.
Serveur frontal derrière le pare-feu
Scénario
Afin d'assurer la sécurité tout en offrant un accès à Outlook Web Access à partir d'Internet, une société souhaite placer le système Exchange derrière le pare-feu.
Instructions d'installation
Installez un environnement normal de serveurs Exchange frontaux/principaux au sein de la société. Configurez un pare-feu entre le serveur frontal et Internet. Consultez ci-dessous la section relative à la configuration pour savoir comment configurer un pare-feu Internet à utiliser avec un serveur frontal Exchange 2000.
Discussion
Étant donné que toute la configuration se situe à l'intérieur du pare-feu, la configuration Exchange ne nécessite aucune intervention particulière. Une fois que la demande est parvenue au serveur frontal, celui-ci renvoie la réponse sans changement de configuration.
Le filtrage d'adresses IP est fortement recommandé dans ce scénario pour limiter les demandes via le pare-feu au seul serveur frontal Exchange 2000, et bloquer les demandes via le pare-feu aux autres serveurs de l'organisation.
Zone démilitarisée
Scénario
Dans ce scénario, une société place le serveur frontal entre deux pare-feu distincts. Le premier pare-feu sépare le serveur frontal d'Internet (extérieur) et n'autorise que les demandes adressées à ce serveur frontal. Le second pare-feu sépare le serveur frontal de la société (intérieur). Les systèmes compris entre les deux pare-feu se trouvent dans ce que l'on appelle une zone démilitarisée. Cette configuration offre une mesure de sécurité supplémentaire en garantissant que même si le serveur frontal présente une défaillance, l'intrus reste isolé du reste de l'entreprise, laissant à l'équipe en charge de la sécurité de l'entreprise le temps de détecter et de neutraliser l'intrusion.
Instructions d'installation
Le pare-feu extérieur, côté Internet, doit être configuré comme un pare-feu normal dans cet environnement. Il doit limiter l'accès aux seuls ports requis et au seul serveur frontal désigné. Consultez la section Configuration pour plus d'informations sur la manière de configurer un pare-feu Internet.
Le pare-feu intérieur, côté Intranet, doit simplement avoir des ports supplémentaires ouverts pour assurer l'authentification et l'accès à Active Directory. La liste exacte dépend de l'équilibre entre sécurité et fonctionnalités, déterminé par l'entreprise.
Discussion
En général, une société limite rigoureusement les ports activés sur le pare-feu Intranet. Le serveur frontal a besoin de certains ports pour fonctionner parfaitement. Consultez la section Configuration pour plus de détails sur la manière de configurer les pare-feu et le serveur frontal dans cet environnement.
Problèmes
Certaines sociétés ont des stratégies qui empêchent les serveurs placés dans la zone démilitarisée d'initialiser des connections avec les serveurs de leur intranet. Le serveur frontal Exchange 2000 n'est pas accepté dans ce scénario, puisqu'il doit initialiser les connections.
Configuration
Configuration d'un serveur frontal
Un serveur frontal doit faire partie de la même organisation Exchange que les serveurs principaux. En fait, il s'agit d'un serveur Exchange 2000 ordinaire que vous allez modifier. Un serveur frontal ne doit pas héberger d'utilisateurs ni de dossiers publics.
Pour installer un serveur frontal, installez le serveur Exchange 2000 dans l'organisation. Ensuite, dans la page des propriétés du serveur, sélectionnez la case à cocher intitulée "Ceci est un serveur frontal" et redémarrez le serveur, ou arrêtez et redémarrez les services HTTP, POP3 et IMAP4.
Avant de redémarrer ces services, démontez et supprimez les banques d'informations publiques et privées sur le serveur frontal, faute de quoi la banque d'informations publique risque de devenir inaccessible via le serveur frontal.
Tous les services Exchange ne sont pas nécessaires sur un serveur frontal ; cela dépend des protocoles utilisés. La liste suivante indique les services Exchange requis pour chaque protocole ; tous les autres services Exchange peuvent (et doivent) être arrêtés et désactivés :
HTTP : Aucun service Exchange requis, mais service HTTP de Windows (w3svc) indispensable
POP3 : Exchange POP3 (POP3Svc), service de banque d'informations de Microsoft Exchange (MSExchangeIS), Surveillance du système Exchange (MSExchangeSA)
IMAP4 : Exchange IMAP4 (IMAP4Svc), service de banque d'informations de Microsoft Exchange (MSExchangeIS), Surveillance du système Exchange (MSExchangeSA)
Pour arrêter et désactiver des services, utilisez le composant logiciel enfichable MMC Services.
Remarque Par défaut, les services Exchange IMAP4 et Exchange POP3 sont marqués comme dépendants de MSExchangeIS. En pratique, cependant, cela n'est absolument pas nécessaire lorsqu'ils fonctionnent comme un service frontal. Le fonctionnement du processus d'administration de magasin (sans boîtes aux lettres ni banque d'informations publique installées) sur le serveur frontal ne devrait pas entraîner de risque de sécurité ni affecter matériellement les performances. Cependant, il est possible de supprimer manuellement cette dépendance en supprimant MSExchangeIS de la clé de Registre suivante :
HKEY_LOCAL_MACHINE\
System\
CurrentControlSet\
Services\
IMAP4SVC | POP3SVC\
DependOnService
Insérez l'avertissement habituel sur la modification du Registre.
Si vous exécutez POP3 et IMAP4 dans une configuration où les ports RPC (135 et 1024+) ne sont pas ouverts entre le serveur frontal et les serveurs principaux, vous devez supprimer ces dépendances et ne pas exécuter le service de banque d'informations de Microsoft Exchange sur les serveurs frontaux. Référez-vous à la section Configuration d'un pare-feu pour plus d'informations sur les pare-feu.
Configuration HTTP
Les serveurs virtuels HTTP et les répertoires virtuels du serveur frontal doivent exactement correspondre à ceux du serveur principal. Dans un paramétrage par défaut, aucune configuration supplémentaire n'est nécessaire sur le serveur frontal car les répertoires virtuels Public et Exchange correspondent déjà.
Configuration d'un serveur principal
Les serveurs principaux doivent être spécialement configurés pour prendre en charge le serveur frontal. Tout d'abord, il doit s'agir de serveurs se trouvant dans le même domaine que le serveur frontal. Les utilisateurs peuvent se trouver sur n'importe quel serveur du domaine. Les dossiers publics peuvent être répliqués par tout moyen souhaité. Les serveurs principaux peuvent être atteints directement si nécessaire, sans effet sur le comportement de la configuration en serveurs frontaux/principaux.
Configuration HTTP
Des répertoires ou des serveurs virtuels supplémentaires non disponibles sur le serveur frontal peuvent être créés sur les serveurs principaux pour prendre en charge des applications spécifiques.
La principale configuration à effectuer sur le serveur principal est la création, à l'aide du Gestionnaire système Exchange, d'un serveur virtuel qui correspond à l'espace de noms de chaque serveur frontal. Dans un environnement classique, il est souhaitable que tous les serveurs frontaux soient mappés à un nom particulier, afin d'unifier l'espace de noms. Le nouveau serveur virtuel situé sur le serveur principal est mappé au nom unique qui représente tous les serveurs frontaux. Ce serveur virtuel répond aux demandes provenant du serveur frontal, et, par conséquent, il doit être configuré pour correspondre à la configuration du serveur frontal, y compris les répertoires virtuels (en particulier, les répertoires Exchange et Public dans la configuration par défaut).
Dans certaines circonstances, il peut être nécessaire de limiter l'accès aux dossiers publics ou privés du serveur frontal. Pour ce faire, supprimez les répertoires virtuels Exchange (privés) ou Public des serveurs virtuels.
Les étapes de la configuration d'un serveur principal spécifique diffèrent selon que le serveur principal est hébergé ou non sur un cluster.
Configuration d'un serveur principal non ordonné en cluster
Pour configurer le nouveau serveur virtuel, utilisez le Gestionnaire système Exchange et, dans le conteneur de protocoles HTTP du serveur principal spécifique, ajoutez un nouveau serveur virtuel (cliquez avec le bouton droit sur HTTP, sélectionnez Nouveau, Serveur virtuel…) :
Pour le nom, Microsoft recommande quelque chose sous la forme "Exchange FE VS (nom d'hôte du serveur frontal)". Choisissez un nom logique pour que l'objet du serveur virtuel soit facile à comprendre.
Cliquez sur le bouton Avancées et ajoutez une identité pour le serveur virtuel qui définit comme nom d'hôte l'espace de noms du serveur frontal. Le serveur frontal pourra ainsi communiquer correctement avec le serveur principal. Vous pouvez ajouter plusieurs entrées de nom d'hôte au serveur virtuel ; ces entrées répertorient toutes les manières d'accéder au serveur frontal pour un utilisateur. Par exemple, si un serveur frontal est destiné à être utilisé en interne et en externe, vous pouvez créer un nom court (NetBIOS) et un nom de domaine complet. Consultez la section suivante sur la réduction des créations de serveurs virtuels.
Le port TCP doit être le port 80, car il s'agit du seul port utilisé par le serveur frontal pour communiquer avec le serveur principal, quel que soit le port utilisé par le client pour communiquer avec le serveur frontal. Le port SSL peut être laissé comme port par défaut.
.jpg)
Figure 1 : Configuration du serveur virtuel sur le serveur principal
Après la création du serveur virtuel, ajoutez des répertoires virtuels pour obtenir une correspondance parfaite avec le serveur frontal. Dans la plupart des cas, un répertoire virtuel Exchange et un répertoire virtuel Public doivent être créés. Vérifiez que le domaine SMTP pour les boîtes aux lettres correspond au domaine SMTP configuré du serveur frontal. Ne créez pas de répertoire virtuel Exadmin sur le serveur virtuel. Il n'est utilisé que par l'outil d'administration sur le serveur virtuel par défaut et n'est pas transféré par le serveur frontal.
Il convient de créer un serveur virtuel Exchange pour chaque espace de noms de serveur frontal. Ainsi, dans un environnement d'hébergement, où de nombreux espaces de noms de serveur frontal (foo.com, bar.com, etc.) sont utilisés, il doit exister un nouveau serveur virtuel Exchange pour chacun. Cela offre une souplesse maximale pour déterminer les ressources disponibles pour chaque entreprise hébergée. Il n'est pas nécessaire de créer un serveur virtuel pour chaque serveur frontal, s'ils sont utilisés dans un scénario d'équilibrage de la charge.
.jpg)
Figure 2 : Un serveur principal correctement configuré
(dans le cas d'une configuration par défaut sur le serveur frontal)
De plus, si l'administrateur doit créer de nouveaux serveurs virtuels pour d'autres raisons (applications d'hébergement, par exemple), ils doivent adopter la même configuration sur les serveurs principaux (c'est-à-dire que les noms d'hôte doivent être identiques). Remarque : Les serveurs virtuels qui n'ont pas le même numéro de port (normal ou SSL) que le serveur virtuel par défaut ne sont pas pris en charge. Tout le trafic entre les serveurs frontaux et principaux a lieu via le port 80, quel que soit le port entrant utilisé.
Configuration d'un serveur principal ordonné en cluster
Dans un environnement ordonné en cluster, Exchange installe automatiquement sur chaque machine virtuelle ordonnée en cluster une instance de serveur virtuel HTTP possédant le nom d'hôte de la machine virtuelle concernée. Pour utiliser un serveur frontal avec un serveur principal ordonné en cluster, il est nécessaire de créer des serveurs virtuels supplémentaires sur le serveur principal.
Sur chaque machine constituant le cluster, utilisez le Gestionnaire système Exchange pour :
créer un serveur virtuel en suivant les mêmes instructions que pour un serveur non ordonné en cluster. Utilisez la convention d'affectation de noms suivante : "Exchange FE VS (nom de la machine ordonnée en cluster – nom d'hôte du serveur frontal)" ;
garantir que des numéros IP uniques sont affectés à chaque serveur virtuel en fonction de l'IP du nom de la machine ordonnée en cluster qui lui a été affecté. Utilisez la même adresse IP que celle affectée au serveur virtuel HTTP Exchange installé automatiquement. Ce point est très important, car si deux serveurs virtuels partagent la même configuration, l'un d'eux ne sera pas en mesure de démarrer ;
créer des répertoires virtuels comme décrit dans la section précédente pour correspondre au serveur frontal ;
démarrer le serveur virtuel avant de continuer, pour garantir qu'il est correctement configuré. Pour ce faire, cliquez avec le bouton droit sur le nom du serveur virtuel et sélectionnez "Démarrer".
Une fois créé, chaque serveur virtuel doit être ajouté à la configuration des machines virtuelles du cluster, pour que le cluster le gère correctement.
À l'aide de l'outil d'administration de cluster, sélectionnez la première machine virtuelle se trouvant dans le cluster. À l'aide du menu contextuel, créez une nouvelle ressource de cluster :
Nommez la ressource de la manière suivante : Instance Exchange FE VS (nom de la machine ordonnée en cluster – nom d'hôte du serveur frontal).
Choisissez "Instance de serveur virtuel Exchange HTTP" comme type de ressource
Configurez la ressource serveur virtuel de telle sorte qu'elle dépende de la ressource de banque d'informations Exchange.
.jpg)
Figure 3 : Première étape dans la configuration
d'une nouvelle ressource de cluster de serveur virtuel HTTP
Une fois la création terminée, cliquez avec le bouton droit sur le serveur et connectez l'instance de serveur. Répétez cette procédure pour les autres machines virtuelles du cluster.
Réduction de la création de serveurs virtuels
Dans certaines circonstances, il peut être nécessaire de réduire le nombre de serveurs virtuels créés sur les serveurs principaux (parfois, ils dépassent le millier). Cela ne doit être entrepris que par un administrateur comprenant parfaitement le fonctionnement des serveurs virtuels HTTP. Si vous le souhaitez, la création de serveurs virtuels peut alors être réduite par deux méthodes.
Première méthode : si tous les serveurs virtuels situés sur le serveur frontal sont configurés de manière identique, alors il est possible de créer un serveur virtuel unique sur chaque serveur principal, associé à plusieurs noms d'hôtes. De plus, il ne faut créer des serveurs virtuels que sur des serveurs principaux vers lesquels le serveur frontal peut rediriger le trafic. Par exemple, si un serveur frontal contient des serveurs virtuels pour foo.com et pour bar.com et si tous les utilisateurs de foo.com sont hébergés sur un serveur A, alors seul un serveur virtuel pour foo.com est requis sur le serveur A. Si des configurations changent, alors des changements risquent d'être nécessaires sur le serveur principal.
Deuxième méthode : il est possible d'analyser les utilisateurs et les données présents sur un serveur pour déterminer s'il peut arriver qu'un utilisateur soit dirigé vers un serveur principal donné. Par exemple, sur un serveur ne possédant pas de banque d'informations publique, nul n'est besoin d'un répertoire virtuel Public. De même, si un serveur frontal n'accepte que des utilisateurs contenus dans un domaine SMTP particulier, et s'il n'existe aucun utilisateur de ce domaine sur un serveur, alors il n'est pas nécessaire de créer de serveur virtuel.
Configuration d'un pare-feu
Cette section traite de la configuration des pare-feu utilisés dans une topologie de serveurs Exchange frontaux/principaux, ainsi que de n'importe quelle autre configuration requise sur les serveurs frontaux dans ces environnements.
Configuration d'un pare-feu Internet
Dans des scénarios Internet, un pare-feu doit être installé entre l'entreprise et Internet. Ce pare-feu doit être configuré pour accepter les demandes vers certaines adresses IP et via certains ports TCP et UDP. La liste qui suit indique les ports requis pour les différents services.
|
Tableau 1 : Ports qui doivent être ouverts sur le pare-feu Internet
Configuration d'un pare-feu Intranet
Pour installer une zone démilitarisée (DMZ), vous devez configurer un pare-feu entre le serveur frontal et l'Intranet de l'entreprise.
Protocoles de base
Tous les ports des protocoles pris en charge devront être ouverts sur le pare-feu interne dans tous les cas. Les ports SSL n'ont pas besoin d'être ouverts parce que SSL ne sera pas utilisé dans la communication entre les serveurs frontaux et principaux. Les ports suivants sont obligatoires.
|
Tableau 2 : Ports de protocoles requis pour le pare-feu Intranet
Communication avec Active Directory
Les ports LDAP doivent être ouverts pour que le serveur frontal Exchange puisse communiquer avec Active Directory. L'authentification Kerberos de Windows 2000 est utilisée et, par conséquent, les ports Kerberos doivent également être ouverts. Les ports suivants sont nécessaires.
|
Tableau 3 : Ports requis pour la communication
avec Active Directory et l'authentification Kerberos
Deux jeux de ports facultatifs peuvent être ouverts dans le pare-feu. La décision de les ouvrir dépend des stratégies de l'entreprise. Chaque décision repose sur un compromis entre la sécurité, la facilité d'administration et la fonctionnalité. Voici tout d'abord le choix facile.
Serveur DNS (Domain Name Service)
Pour que la recherche des noms de serveurs s'effectue correctement (après avoir été convertis en adresses IP), le serveur frontal doit pouvoir accéder à un serveur DNS ou à un fichier d'hôtes fournissant le mappage. Dans un domaine Windows 2000 par défaut, les serveurs Active Directory fonctionnent comme des serveurs DNS ; ce sont eux qui doivent être accessibles par l'intermédiaire du pare-feu via les ports DNS.
|
Tableau 4 : Ports requis pour accéder au serveur DNS.
Utilisez un fichier d'hôtes s'ils ne sont pas ouverts.
Comment effectuer la configuration si les ports DNS ne sont pas ouverts : si ces ports ne sont pas ouverts dans le pare-feu interne, un fichier d'hôtes doit être créé pour chaque mappage. La pile TCP/IP Windows 2000 utilise le fichier suivant : %SystemRoot%\System32\drivers\etc\hosts. Modifiez ce fichier pour créer un mappage entre nom et adresse IP pour chaque serveur que le serveur frontal est susceptible de contacter. Cela inclut généralement tous les serveurs Exchange 2000 de l'organisation ainsi que tous les serveurs Active Directory ou de catalogue global que le serveur frontal est susceptible de contacter. Le fichier d'hôtes par défaut contient des instructions sur la manière de créer les mappages. Le plus important lors de l'utilisation d'un fichier d'hôtes est de s'assurer qu'il est actualisé lorsque des changements interviennent dans l'organisation.
Détection de service et authentification
Windows 2000 utilise les appels RPC (appel de procédure à distance) pour détecter un service Active Directory et pour authentifier un client. Pour activer ces fonctionnalités, il faut que les ports RPC soient ouverts. Le Tableau 5 donne la liste des ports requis.
|
Tableau 5 : Ports RPC nécessaires pour la
découverte de service et l'authentification.
*Comment effectuer la configuration si les ports RPC ne sont pas ouverts * : Si l'ouverture des ports RPC n'est pas autorisée entre la zone démilitarisée et l'Intranet d'entreprise, certaines fonctionnalités du serveur frontal doivent être désactivées ou configurées de manière spéciale. Tout d'abord, sans accès RPC aux serveurs Active Directory, le serveur frontal ne peut identifier les clients. Cela signifie que les fonctionnalités qui requièrent une authentification ne fonctionnent pas correctement, notamment la connection implicite et l'accès à l'arborescence des dossiers publics. L'accès aux dossiers publics est possible mais sans identification des utilisateurs, et l'équilibrage de la charge est impossible. Si vous configurez un serveur frontal dans un tel environnement, désactivez l'authentification et activez l'accès anonyme.
D'autre part, Windows 2000 n'étant pas en mesure de localiser ses contrôleurs de domaines et ses serveurs de catalogue global sans la détection du service RPC, le serveur frontal Exchange doit être préconfiguré avec les noms de ces serveurs et leurs sauvegardes. Un fichier Registre fourni avec ce document contient certaines clés de Registre que le serveur frontal vérifiera s'il ne peut localiser les serveurs via RPC. Modifiez ce fichier en fonction de l'environnement et importez ces clés dans le Registre sur le serveur frontal. L'avertissement usuel concernant la modification du Registre s'applique ici. Comme dans le cas du fichier d'hôtes décrit précédemment, le plus important est de maintenir à jour le contenu de ces entrées de Registre.
Si vous exécutez IMAP4 ou POP3 sur les serveurs frontaux les ports RPC indiqués ci-dessus étant fermés, vous devez vous assurer que MSExchangeIS ne fonctionne pas sur la machine frontale. Référez-vous à la section Configuration d'un serveur frontal pour plus d'informations sur la manière de supprimer la dépendance d'IMAP4 et de POP3 vis-à-vis du service MSExchangeIS.
Configuration supplémentaire
Protection de la communication du client vers le serveur frontal
Afin de protéger les données transmises entre le client et le serveur frontal, Microsoft recommande l'activation de SSL sur ce serveur. De plus, pour garantir que les données des utilisateurs sont toujours protégées, l'accès au serveur frontal sans SSL doit être désactivé (l'option doit être sélectionnée dans la configuration SSL). Il est particulièrement important de sécuriser le trafic réseau par- SSL lorsque vous utilisez l'authentification de base, afin de protéger les mots de passe des utilisateurs contre les "renifleurs" du réseau.
Pour configurer SSL pour une utilisation avec HTTP, utilisez le Gestionnaire des services Internet et suivez les instructions de la documentation IIS pour demander et installer un certificat SSL sur le site Web par défaut ou n'importe quel serveur virtuel à protéger.
SSL ne doit pas être configuré sur les serveurs principaux lorsque vous utilisez un serveur frontal parce que celui-ci n'accepte l'utilisation de SSL pour communiquer avec les serveurs principaux.
Protection de la communication d'un serveur frontal vers un serveur principal
La communication HTTP entre serveur frontal et serveur principal n'est pas cryptée. Bien souvent, par exemple, lorsque ces serveurs se trouvent sur des sous-réseaux différents, cela n'a pas d'importance. Cependant, s'ils se trouvent sur des sous-réseaux séparés et que le trafic réseau doit traverser des zones non protégées de l'entreprise, il peut s'avérer nécessaire de crypter ce trafic pour protéger les mots de passe et les données.
Windows 2000 prend en charge IPSec, une norme Internet qui permet à deux serveurs Windows 2000 de crypter le trafic entre eux au niveau de la couche IP (Internet Protocol). Ce protocole peut être utilisé pour protéger le trafic entre le serveur frontal et le serveur principal. Ce type de cryptage a des répercussions sur les performances du serveur frontal et du serveur principal. La répercussion précise sur les performances dépend principalement du type de cryptage utilisé.
N'activez le protocole IPSec que si vous possédez une parfaite maîtrise de son fonctionnement et de son administration. Les étapes suivantes fournissent les instructions générales pour accomplir cette tâche.
IPSec permet au serveur de crypter tout ou partie du trafic. Cependant, il est préférable de limiter le cryptage au trafic HTTP. Le fichier de stratégie IPSec joint à ce document indique comment procéder pour filtrer la stratégie IPSec afin de l'appliquer uniquement au trafic émis par le serveur frontal vers le port 80 d'un serveur distant. Pour examiner le fichier de stratégie joint, chargez le composant logiciel enfichable de gestion de stratégie de sécurité IP à l'aide de Microsoft Management Console (MMC) et importez la stratégie. Pour l'affecter à une utilisation sur le serveur frontal, utilisez le composant logiciel enfichable.
N'utilisez pas la stratégie ci-jointe sur les serveurs principaux. Sur ces serveurs, IPSec doit être configuré de telle sorte que toute demande de communication IPSec reçoive une réponse correcte, mais qu'IPSec ne soit pas indispensable. Trois fichiers de stratégie sont inclus dans Windows 2000. L'un d'eux, intitulé "Client (en réponse seule)", convient à ce cas : d'autres clients (y compris les clients MAPI comme Outlook 2000) et d'autres serveurs peuvent communiquer avec le serveur principal sans que le protocole IPSec soit nécessaire.
Si vous utilisez IPSec dans un environnement de zone démilitarisée (DMZ), vous devez, pour qu'il soit pris en charge, modifier le pare-feu interne (ou côté Intranet). Tout d'abord, HTTP (port 80/TCP) n'est plus requis et doit être bloqué. Ensuite, le port de négociation IPSec à 500/UDP est requis. IPSec requiert également l'ouverture des ports IP numéro 50 et 51.
Configuration d'une topologie de serveurs frontaux/principaux : aide-mémoire
Utilisez cet aide-mémoire pour :
.gif)
Installer le serveur frontal
Supprimer les banques d'informations publiques et privées du serveur.
Arrêter et désactiver les services inutiles.
Facultatif : Activer le cryptage SSL.
Facultatif : Affecter une stratégie IPSec au serveur frontal.
Configurer les serveurs principaux
Créer des serveurs virtuels en correspondance avec le serveur frontal.
Créer des répertoires virtuels en correspondance avec ceux du serveur frontal.
Facultatif : Affecter une stratégie IPSec aux serveurs principaux.
Si vous placez des serveurs sur Internet :
Configurer le serveur frontal
Facultatif : Installer le fichier d'hôtes (si les ports DNS sont fermés).
Facultatif : Installer des entrées de Registre pour l'accès aux répertoires (si les ports RPC sont fermés).
Facultatif : Basculer sur l'accès anonyme (si les ports RPC sont fermés).
Configurer des pare-feu
Activer l'accès aux ports de protocoles obligatoires.
Facultatif : Activer l'accès à des ports supplémentaires.
Dernière mise à jour le vendredi 13 octobre 2000