Désactivation du protocole TLS entre des sites Active Directory pour la prise en charge de l'optimisation de réseau étendu

 

S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3

Dernière rubrique modifiée : 2009-12-01

Dans Microsoft Exchange Server 2007, le chiffrement TLS est obligatoire pour toutes les communications SMTP entre les serveurs de transport Hub. Cela augmente la sécurité globale des communications de hub à hub. Cependant, dans certaines topologies utilisant des périphériques WOC (WAN Optimization Controller), le chiffrement TLS du trafic SMTP peut s’avérer indésirable. Exchange Server 2010 prend en charge la désactivation du chiffrement TLS pour les communications entre hubs appartenant à ces scénarios.

Examinez la topologie affichée dans la figure suivante : Cette topologie comprenant quatre sites suppose que les deux sites de succursale et que la filiale 2 sont bien connectés tandis que la connexion entre le Site de succursale 1 et la Filiale 1 passe par une liaison réseau étendu. L’entreprise a installé des périphériques WOC sur cette liaison pour compresser et optimiser le trafic sur le réseau étendu.

Exemple de topologie de réseau avec les périphériques WOC

Cette topologie ne permet pas la compression du trafic SMTP sur la liaison réseau étendu parce que Exchange 2010 utilise le chiffrement TLS pour la communication entre les serveurs de transport Hub. Dans l’idéal, l’ensemble du trafic SMTP sur la liaison réseau étendu ne doit pas être chiffré, tout en conservant la sécurité TLS au sein des sites bien connectés. Exchange 2010 vous donne la possibilité de désactiver le chiffrement TLS pour le trafic entre les sites en configurant les connecteurs de réception. En utilisant cette fonctionnalité dans Exchange 2010, vous pouvez configurer une exception pour le trafic SMTP entre le Site de succursale 1 et la Filiale 1, comme indiqué dans la figure suivante.

Flux de messages logique préféré

La configuration recommandée consiste à limiter le trafic SMTP non chiffré uniquement aux messages transitant sur la liaison réseau étendu Par conséquent, le chiffrement TLS est nécessaire pour le trafic intrasite de hub à hub et pour les communications intersite de hub à hub qui n’impliquent pas la Filiale 1.

Pour obtenir ce résultat final, vous devez effectuer les opérations suivantes, dans l’ordre indiqué, sur chaque serveur de transport Hub dans les sites contenant les périphériques WOC (Site de succursale 1 et Filiale 1 dans l’exemple de topologie) :

1. Activer l’authentification de serveur Exchange déclassée.

2. Créer un connecteur de réception pour traiter le trafic sur la connexion équipée de périphériques WOC.

3. Configurer la propriété de plages d’adresses IP distantes du nouveau connecteur de réception sur les pages d’adresses IP des serveurs de transport Hub dans le site distant.

4. Désactiver TLS sur le nouveau connecteur de réception.

Vous avez également besoin d’effectuer les opérations suivantes pour garantir que l’ensemble du trafic STMP sur le réseau étendu est traité par les nouveaux connecteurs de réception que vous avez créés :

• Configurer les sites qui participeront à la communication non-TLS comme des sites hub pour forcer la totalité du flux de messages à travers les nouveaux connecteurs de réception (Site de succursale 1 et Filiale 1 dans l’exemple de topologie).

• Vérifier que les coûts de liens de sites IP sont configurés pour garantir que l’itinéraire de routage le moins onéreux jusqu’à votre site distant (Filiale 1 dans l’exemple de topologie) passe par la liaison réseau équipée des périphériques WOC.

Les sections suivantes fournissent une vue d’ensemble de chacune de ces étapes. Pour obtenir des instructions détaillées sur la configuration de vos serveurs de transport de manière à désactiver le chiffrement TLS, consultez la rubrique Supprimer des connexions TLS anonymes.

Souhaitez-vous rechercher les autres tâches de gestion relatives à la gestion des serveurs de transport ? Voir Gestion des serveurs de transport.

Contenu de cette rubrique

Déclassement de l’authentification sur les connexions où TLS est désactivé

Création et configuration des connecteurs de réception

Création de sites hub

Configuration des coûts des liens de sites

Déclassement de l’authentification sur les connexions où TLS est désactivé

L’authentification Kerberos est utilisée avec le chiffrement TLS dans Exchange. Lorsque vous désactivez TLS sur les communications de hub à hub, vous devez effectuer une autre forme d’authentification. Lorsque Exchange 2010 communique avec d’autres serveurs exécutant Exchange et ne prenant pas en charge X-ANONYMOUSTLS, comme c’est le cas des serveurs Exchange Server 2003, il recourt à l’authentification GSSAPI (Generic Security Services Application Programming Interface). Toutes les communications entre les serveurs de transport Hub d’Exchange 2010 utilisent X-ANONYMOUSTLS. En configurant votre serveur de transport Hub pour qu’il utilise une authentification déclassée d’ Exchange, vous l’activez en fait pour qu’il utilise GSSAPI pour ses communications avec les autres serveurs de transport Hub d’Exchange 2010.

Retour au début

Création et configuration des connecteurs de réception

Vous avez besoin de créer des connecteurs de réception qui seront les seuls responsables du traitement du trafic non chiffré TLS. L’utilisation de connecteurs de réception séparés à cet effet garantit que l’ensemble du trafic ne transitant par la liaison réseau étendu reste protégé par le chiffrement TLS.

Pour limiter les nouveaux connecteurs de réception au trafic transitant sur le réseau étendu, vous devez configurer la propriété de plage d’adresses IP distantes. Exchange utilise toujours le connecteur avec la plage d’adresses IP distantes la plus spécifique. Par conséquent, ces nouveaux connecteurs seront préférés au connecteur de réception par défaut configuré pour recevoir des messages de toutes provenances.

Pour revenir à la topologie de l’exemple, supposons que le sous-réseau de classe C 10.0.1.0/24 soit utilisé pour le Site de succursale 1 et que le sous-réseau 10.0.2.0/24 soit utilisé pour la Filiale 1. Les opérations suivantes sont nécessaires pour préparer la désactivation de TLS entre ces deux sites :

1. Créer un connecteur de réception (appelé WAN) sur chaque serveur de transport Hub dans Site de succursale 1 et Filiale 1.

2. Configurer la plage d’adresses IP distantes 10.0.2.0/24 sur chaque nouveau connecteur de réception dans Site de succursale 1.

3. Configurer la plage d’adresses IP distantes 10.0.1.0/24 sur chaque nouveau connecteur de réception dans Filiale 1.

4. Désactiver TLS sur tous les nouveaux connecteurs de réception.

Le résultat final est présenté dans la figure suivante (la propriété de plages d’adresses IP distantes des connecteurs de réception du réseau étendu est affichée entre parenthèses). Un seul serveur de transport Hub est affiché dans Filiale 1, et Filiale 2 est omis pour des raisons de clarté.

Configuration des connecteurs de réception

Retour au début

Création de sites hub

Par défaut, un serveur de transport Hub d’Exchange 2010 tentera d’établir une connexion directe avec le serveur de transport Hub le plus proche de la destination finale d’un message spécifique. Dans la topologie de l’exemple, si un utilisateur de la Filiale 2 envoie un message à un utilisateur de la Filiale 1, le serveur de transport Hub de la Filiale 2 se connectera directement au serveur de transport Hub dans la Filiale 1 pour remettre ce message. Cette connexion sera chiffrée et donc indésirable dans la topologie. Pour que ces messages passent par les serveurs de transport Hub sur le Site de succursale 1, garantissant ainsi qu’ils ne sont pas chiffrés pendant leur transit sur la liaison de réseau étendu, le Site de succursale 1 et la Filiale 1 doivent être configurés comme sites hub. En bref, tout site qui dispose d’un serveur de transport Hub avec un connecteur de réception où TLS est désactivé devra être configuré comme site hub pour forcer les serveurs des autres sites à router le trafic via ce site. Pour plus d’informations sur les sites hub, consultez « Implémentation de sites hub » dans Présentation du routage des messages.

Retour au début

Configuration des coûts des liens de sites

Il ne suffit pas de configurer les sites hub pour garantir que l’ensemble du trafic n’est pas chiffré sur la liaison réseau étendu. En effet, Exchange routera les messages via les sites hub uniquement si le site hub se trouve sur l’itinéraire de routage le moins onéreux. Supposons par exemple que les coûts de liens de sites IP pour notre exemple de topologie soient configurés dans Active Directory, comme l’illustre la figure suivantes (le Site de succursale 2 est omis par souci de clarté).

Coûts de liens de sites IP pour l’exemple de topologie

Dans ce cas, le trajet de la Filiale 2 à la Filiale 1 via le site hub représente un coût total de 12 (6+6), tandis que le coût du trajet direct est de 10. Par conséquent, aucun des messages de la Filiale 2 à la Filiale 1 ne passera par le Site de succursale 1 et l’ensemble de ce trafic restera protégé par le chiffrement TLS.

Pour éviter ce problème, vous devez désigner un coût spécifique à Exchange qui soit supérieur à 12 pour le lien de sites IP entre le Site de succursale 2 et la Filiale 1, comme l’illustre la figure suivante. Cela assurera le passage de tous les messages via le canal non chiffré entre le Site de succursale 1 et la Filiale 1.

Exemple de topologie configurée avec des coûts des liens de sites IP spécifiques à Exchange

Pour plus d’informations sur la configuration de coûts de liens de sites IP spécifiques à Exchange, consultez « Contrôle des coûts de liens de sites IP » dans Présentation du routage des messages.

Retour au début

 © 2010 Microsoft Corporation. Tous droits réservés.