Référence de port de réseau Exchange
S’applique à : Exchange Server 2010 SP2, Exchange Server 2010 SP3
Dernière rubrique modifiée : 2016-11-28
Cette rubrique fournit des informations sur les ports, l’authentification et le chiffrement de tous les chemins d’accès aux données utilisés par MicrosoftExchange Server 2010. Les sections « Notes » suivant chaque tableau clarifient ou définissent les méthodes d’authentification ou de chiffrement non standard.
Serveurs de transport
Exchange 2010 inclut deux rôles serveur qui assurent la fonctionnalité de transport de message : les serveurs de transport Hub et Edge.
Le tableau suivant fournit des informations sur les ports, l’authentification et le chiffrement des chemins d’accès aux données entre ces serveurs de transport et d’autres serveurs et services Exchange 2010.
Chemins d’accès aux données de serveur de transport
| Chemin d’accès aux données | Ports requis | Authentification par défaut | Authentification prise en charge | Chiffrement pris en charge ? | Chiffré par défaut ? |
|---|---|---|---|---|---|
Entre serveurs de transport Hub |
25/TCP (SMTP) |
Kerberos |
Kerberos |
Oui, utilisation de Transport Layer Security (TLS) |
Oui |
Entre serveur de transport Hub et serveur de transport Edge |
25/TCP (SMTP) |
Confiance directe |
Confiance directe |
Oui, à l’aide de TLS |
Oui |
Entre serveur de transport Edge et serveur de transport Hub |
25/TCP (SMTP) |
Confiance directe |
Confiance directe |
Oui, à l’aide de TLS |
Oui |
Entre serveurs de transport Edge |
25/TCP (SMTP) |
Anonyme, certificat |
Anonyme, certificat |
Oui, à l’aide de TLS |
Oui |
Entre serveur de boîtes aux lettres et serveur de transport Hub via le service de dépôt du courrier Microsoft Exchange |
135/TCP (RPC) |
NTLM. Si les rôles de transport Hub et de serveurs de boîtes aux lettres sont sur le même serveur, Kerberos est utilisé. |
NTLM/Kerberos |
Oui, à l’aide du chiffrement RPC |
Oui |
Entre serveur de transport Hub et serveur de boîtes aux lettres via MAPI |
135/TCP (RPC) |
NTLM. Si les rôles de transport Hub et de serveurs de boîtes aux lettres sont sur le même serveur, Kerberos est utilisé. |
NTLM/Kerberos |
Oui, à l’aide du chiffrement RPC |
Oui |
Serveur de messagerie unifiée vers serveur de transport Hub |
25/TCP (SMTP) |
Kerberos |
Kerberos |
Oui, à l’aide de TLS |
Oui |
Microsoft Service EdgeSync Exchange du serveur de transport Hub vers le serveur de transport Edge |
50636/TCP (SSL) |
De base |
De base |
Oui, utilisation de LDAP sur SSL (LDAPS) |
Oui |
Accès Active Directory à partir du serveur de transport Hub |
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) |
Kerberos |
Kerberos |
Oui, à l’aide du chiffrement Kerberos |
Oui |
Accès Active Directory Rights Management Services (AD RMS) à partir du serveur de transport Hub |
443/TCP (HTTPS) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide de SSL |
Oui* |
Clients SMTP sur le serveur de transport Hub (par exemple, utilisateurs finaux utilisant Windows Live Mail) |
587 (SMTP) 25/TCP (SMTP) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide de TLS |
Oui |
Notes sur les serveurs de transport
Tout le trafic entre les serveurs de transport Hub est chiffré à l’aide de TLS avec des certificats auto-signés installés lors de l’installation d’Exchange 2010.
.gif "Remarque")
Remarque :Dans Exchange 2010, vous pouvez désactiver TLS sur les serveurs de transport Hub pour la communication SMTP interne avec les autres serveurs de transport Hub de la même organisation Exchange. Nous ne vous conseillons pas d'employer cette méthode, sauf si vous n'avez d'autre choix. Pour plus d’informations, consultez la rubrique Désactivation du protocole TLS entre des sites Active Directory pour la prise en charge de l'optimisation de réseau étendu. Tout le trafic entre les serveurs de transport Edge et Hub est authentifié et chiffré. Mutual TLS est le mécanisme sous-jacent d’authentification et de chiffrement. Au lieu d’utiliser la validation X.509, Exchange 2010 utilise la confiance directe pour authentifier les certificats. La confiance directe signifie que la présence du certificat dans Active Directory ou Active Directory Lightweight Directory Services (AD LDS) valide le certificat. Active Directory est considéré comme un mécanisme de stockage approuvé. Lorsque la confiance directe est utilisée, il importe peu que le certificat soit auto-signé ou signé par une autorité de certification. Lorsque vous abonnez un serveur de transport Edge à une organisation Exchange, l’abonnement Edge publie le certificat de serveur de transport Edge dans Active Directory pour validation par les serveurs de transport Hub. Le service Microsoft Exchange EdgeSync met à jour AD LDS avec l’ensemble des certificats de serveur de transport Hub pour validation par le serveur de transport Edge.
EdgeSync utilise une connexion LDAP sécurisée à partir du serveur de transport Hub vers les serveurs de transport Edge abonnés via le port TCP 50636. AD LDS écoute également le port TCP 50389. Les connexions à ce port n’utilisent pas SSL. Vous pouvez vous servir des utilitaires LDAP pour la connexion au port et la vérification des données AD LDS.
Par défaut, le trafic entre des serveurs de transport Edge dans deux organisations différentes est chiffré. L’installation d’Exchange 2010 crée un certificat auto-signé et TLS est activé par défaut. Cela permet à tout système émetteur de chiffrer la session SMTP entrante dans Exchange. Par défaut, Exchange 2010 essaie également TLS pour toutes les connexions distantes.
Les méthodes d’authentification pour le trafic entre les serveurs de transport Hub et les serveurs de boîtes aux lettres diffèrent lorsque les rôles serveur de transport Hub et serveur de boîtes aux lettres se trouvent sur le même ordinateur. Si le dépôt de courrier est local, l’authentification Kerberos est utilisée. Si le dépôt de courrier est distant, l’authentification NTLM est utilisée.
Exchange 2010 prend également en charge la sécurité du domaine. La sécurité du domaine représente les fonctionnalités d’Exchange 2010 et de Microsoft Outlook 2010 qui fournissent une alternative économique à S/MIME ou à d’autres solutions de sécurité au niveau message sur Internet. La sécurité de domaine vous permet de gérer des chemins de messages sécurisés entre domaines sur Internet. Une fois que ces chemins de messages sécurisés sont configurés, les messages ayant voyagé avec succès sur le chemin sécurisé d’un expéditeur authentifié sont affichés à l’attention des utilisateurs Outlook et Outlook Web Access comme « Domaine sécurisé ». Pour plus d’informations, consultez la rubrique Présentation de la sécurité de domaine.
De nombreux agents peuvent s’exécuter sur les serveurs de transport Hub et Edge. Généralement, les agents de blocage du courrier indésirable utilisent des informations locales sur l’ordinateur sur lequel ils sont exécutés. C'est pourquoi, un minimum de communications avec les ordinateurs distants est requis. Le filtrage des destinataires constitue l’exception. Le filtrage des destinataires nécessite des appels à AD LDS ou Active Directory. Il est recommandé d’exécuter un filtrage des destinataires sur le serveur de transport Edge. Dans ce cas, le répertoire AD LDS se trouve sur le même ordinateur que le serveur de transport Edge. Par conséquent, aucune communication à distance n'est nécessaire. Si le filtrage des destinataires est installé et configuré sur le serveur de transport Hub, le filtrage des destinataires accède à Active Directory.
La fonctionnalité Réputation de l'expéditeur dans Exchange 2010 utilise l'agent d'analyse de protocole. Cet agent apporte également diverses connexions aux serveurs proxy extérieurs pour déterminer les chemins de message entrant en relation avec les connexions suspectes.
Toutes les autres fonctionnalités antispam utilisent ces données comme agrégation de listes fiables ou comme données de destinataire pour le filtrage. Ces données sont recueillies, stockées et accessible uniquement sur l'ordinateur local. Fréquemment, les données sont transmises au répertoire AD LDS à l'aide du service MicrosoftExchange EdgeSync.
Les agents de gestion des droits relatifs à l’information (IRM) sur les serveurs de transport Hub établissent les connexions aux serveurs AD RMS (Active Directory Rights Management Services) de l’organisation. AD RMS est un service Web sécurisé à l’aide de SSL (pratique recommandée). La communication avec les serveurs AD RMS est établie à l’aide de HTTPS. Kerberos ou NTLM est utilisé pour l’authentification en fonction de la configuration du serveur AD RMS.
Les règles de journal, les règles de transport et les classifications de messages sont stockées dans Active Directory et accessibles par l’agent de journalisation et l’agent Règles de transport sur les serveurs de transport Hub.
Serveurs de boîtes aux lettres
L’authentification NTLM ou Kerberos pour les serveurs de boîtes aux lettres dépend de l’utilisateur ou du processus sous lequel est exécuté le consommateur de la couche logique métier d’Exchange. Dans ce cas de figure, le consommateur est toute application ou tout processus utilisant la couche logique métier d'Exchange. Par conséquent, de nombreuses entrées de la colonne Authentification par défaut de la table Chemins d’accès aux données de serveur de boîtes aux lettres sont répertoriées sous NTLM/Kerberos.
La couche Logique métier d’Exchange permet d’accéder à la banque d’informations Exchange et de communiquer avec elle. La couche Logique métier d’Exchange est également appelée à partir de la banque d’informations Exchange pour communiquer avec des applications et des processus externes.
Si le consommateur de la couche Logique métier d’Exchange opère comme système local, la méthode d’authentification est toujours Kerberos entre le consommateur et la banque d’informations Exchange. Kerberos est utilisé parce que le consommateur doit être authentifié à l’aide du compte d’ordinateur système local et une confiance authentifiée bidirectionnelle doit exister.
Si le consommateur de la couche Logique métier d’Exchange n’opère pas comme système local, la méthode d’authentification est NTLM. Par exemple, lorsque vous exécutez une cmdlet de l’environnement de ligne de commande Environnement de ligne de commande Exchange Management Shell utilisant la couche logique métier d’Exchange, NTLM est utilisé.
Le trafic RPC est toujours chiffré.
Le tableau suivant fournit des informations sur les ports, l’authentification et le chiffrement des chemins d’accès aux données entre ces serveurs de boîtes aux lettres.
Chemins d’accès aux données de serveur de boîtes aux lettres
| Chemin d’accès aux données | Ports requis | Authentification par défaut | Authentification prise en charge | Chiffrement pris en charge ? | Chiffré par défaut ? |
|---|---|---|---|---|---|
Accès Active Directory |
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) |
Kerberos |
Kerberos |
Oui, à l’aide du chiffrement Kerberos |
Oui |
Accès distant Admin (Registre distant) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide d’IPsec |
Non |
Accès distant Admin (SMB/Fichier) |
445/TCP (SMB) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide d’IPsec |
Non |
Service Web de disponibilité (accès client à la boîte aux lettres) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide du chiffrement RPC |
Oui |
Clusters |
135/TCP (RPC). Voir Notes sur les serveurs de boîtes aux lettres après ce tableau. |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide d’IPsec |
Non |
Indexation de contenu |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide du chiffrement RPC |
Oui |
Envoi des journaux |
64327 (personnalisable) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui |
Non |
Amorçage |
64327 (personnalisable) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui |
Non |
Sauvegarde du service VSS |
Bloc de message serveur (SMB) |
NTLM/Kerberos |
NTLM/Kerberos |
Non |
Non |
Assistants de boîte aux lettres |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Non |
Non |
Accès MAPI |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide du chiffrement RPC |
Oui |
Accès au service de topologie Active Directory Microsoft Exchange |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide du chiffrement RPC |
Oui |
Accès hérité du service Surveillance du système Microsoft Exchange (écoute des demandes) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Non |
Non |
Accès hérité du service Surveillance du système Microsoft Exchange à Active Directory |
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) |
Kerberos |
Kerberos |
Oui, à l’aide du chiffrement Kerberos |
Oui |
Accès hérité du service Surveillance du système Microsoft Exchange (comme client MAPI) |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide du chiffrement RPC |
Oui |
Carnet d’adresses en mode hors connexion accédant à Active Directory |
135/TCP (RPC) |
Kerberos |
Kerberos |
Oui, à l’aide du chiffrement RPC |
Oui |
Accès RPC du service de mise à jour de destinataire |
135/TCP (RPC) |
Kerberos |
Kerberos |
Oui, à l’aide du chiffrement RPC |
Oui |
Mise à jour de destinataire pour Active Directory |
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) |
Kerberos |
Kerberos |
Oui, à l’aide du chiffrement Kerberos |
Oui |
Notes sur les serveurs de boîtes aux lettres
Le chemin de données de cluster répertorié dans le tableau précédent utilise des ports RPC dynamiques sur TCP pour communiquer l’état du cluster et l’activité entre les différents nœuds du cluster. Le service de cluster (ClusSvc.exe) utilise également des ports UDP/3343 et TCP haut débit alloués de façon aléatoire pour la communication entre les nœuds de cluster.
Pour les communications intra-nœud, les nœuds de cluster communiquent sur un port de protocole UDP (User Datagram Protocol) 3343. Chaque nœud dans le cluster échange périodiquement des datagrammes UDP de monodiffusion séquencés avec les autres nœuds dans le cluster. Le but de cet échange est de déterminer si tous les nœuds fonctionnent correctement et également de surveiller la santé des liaisons réseau.
Le port 64327/TCP est le port par défaut utilisé pour l’envoi des journaux. Les administrateurs peuvent spécifier un port différent pour l’envoi des journaux.
Pour l’authentification HTTP où Négociation est indiqué, l’authentification Kerberos est d’abord tentée, puis l’authentification NTLM.
Serveurs d’accès au client
Sauf mention contraire, les technologies d’accès au client, telles qu’Outlook Web App, POP3 ou IMAP4 sont décrites par l’authentification et le chiffrement de l’application cliente vers le serveur d’accès au client.
Le tableau suivant fournit des informations sur les ports, l’authentification et le chiffrement des chemins d’accès aux données entre les serveurs d’accès au client et les autres serveurs et clients.
Chemins d’accès aux données de serveur d’accès au client
| Chemin d’accès aux données | Ports requis | Authentification par défaut | Authentification prise en charge | Chiffrement pris en charge ? | Chiffré par défaut ? |
|---|---|---|---|---|---|
Accès Active Directory |
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) |
Kerberos |
Kerberos |
Oui, à l’aide du chiffrement Kerberos |
Oui |
Service de découverte automatique |
80/TCP, 443/TCP (SSL) |
Authentification Windows de base/intégrée (Négociation) |
De base, Digest, NTLM, Négociation (Kerberos) |
Oui, à l’aide de HTTPS |
Oui |
Service de disponibilité |
80/TCP, 443/TCP (SSL) |
NTLM/Kerberos |
NTLM, Kerberos |
Oui, à l’aide de HTTPS |
Oui |
Service de réplication de boîte aux lettres (MRS) |
808/TCP |
Kerberos/NTLM |
Kerberos, NTLM |
Oui, à l’aide du chiffrement RPC |
Oui |
Outlook accédant au carnet d’adresses en mode hors connexion |
80/TCP, 443/TCP (SSL) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide de HTTPS |
Non |
Outlook Web App |
80/TCP, 443/TCP (SSL) |
Authentification basée sur des formulaires |
De base, Digest, Authentification basée sur des formulaires, NTLM (v2 uniquement), Kerberos, Certificat |
Oui, à l’aide de HTTPS |
Oui, un certificat auto-signé est utilisé |
POP3 |
110/TCP (TLS), 995/TCP (SSL) |
De base, Kerberos |
De base, Kerberos |
Oui, à l’aide de SSL, TLS |
Oui |
IMAP4 |
143/TCP (TLS), 993/TCP (SSL) |
De base, Kerberos |
De base, Kerberos |
Oui, à l’aide de SSL, TLS |
Oui |
Outlook Anywhere (précédemment appelé RPC sur HTTP ) |
80/TCP, 443/TCP (SSL) |
De base |
De base ou NTLM |
Oui, à l’aide de HTTPS |
Oui |
Application Exchange ActiveSync |
80/TCP, 443/TCP (SSL) |
De base |
De base, Certificat |
Oui, à l’aide de HTTPS |
Oui |
Serveur d’accès au client vers serveur de messagerie unifiée |
5060/TCP, 5061/TCP, 5062/TCP, un port dynamique |
Par adresse IP |
Par adresse IP |
Oui, à l’aide de SIP (Session Initiation Protocol) sur TLS |
Oui |
Serveur d’accès au client vers serveur de boîtes aux lettres exécutant une version antérieure d’Exchange Server |
80/TCP, 443/TCP (SSL) |
NTLM/Kerberos |
Négociation (Kerberos avec recours à NTLM ou facultativement De base), texte brut POP/IMAP |
Oui, à l’aide d’IPsec |
Non |
Serveur d’accès au client vers serveur de boîtes aux lettres Exchange 2010 |
RPC. Voir Notes sur les serveurs d’accès au client. |
Kerberos |
NTLM/Kerberos |
Oui, à l’aide du chiffrement RPC |
Oui |
Serveur d’accès au client vers serveur d’accès au client (Exchange ActiveSync) |
80/TCP, 443/TCP (SSL) |
Kerberos |
Kerberos, Certificat |
Oui, à l’aide de HTTPS |
Oui, un certificat auto-signé est utilisé |
Serveur d’accès au client vers serveur d’accès au client (Outlook Web Access) |
80/TCP, 443/TCP (HTTPS) |
Kerberos |
Kerberos |
Oui, à l’aide de SSL |
Oui |
Serveur d’accès au client vers serveur d’accès au client (Services Web Exchange) |
443/TCP (HTTPS) |
Kerberos |
Kerberos |
Oui, à l’aide de SSL |
Oui |
Serveur d’accès au client vers serveur d’accès au client (POP3) |
995 (SSL) |
De base |
De base |
Oui, à l’aide de SSL |
Oui |
Serveur d’accès au client vers serveur d’accès au client (IMAP4) |
993 (SSL) |
De base |
De base |
Oui, à l’aide de SSL |
Oui |
Accès Office Communications Server au serveur d’accès au client (lorsque l’intégration d’Office Communications Server et d’Outlook Web App est activée) |
5075-5077/TCP (IN), 5061/TCP (OUT) |
mTLS (requis) |
mTLS (requis) |
Oui, à l’aide de SSL |
Oui |
| Remarque : |
|---|
| L'authentification Windows intégrée (NTLM) n'est pas prise en charge pour la connectivité cliente POP3 ou IMAP4. Pour plus d’informations, consultez les sections relatives aux fonctionnalités de l’accès au client dans la rubrique Fonctionnalités abandonnées. |
Notes sur les serveurs d’accès au client
Dans Exchange 2010, les clients MAPI tels que Microsoft Outlook se connectent aux serveurs d’accès au client.
Les serveurs d’accès au client utilisent de nombreux ports pour communiquer avec les serveurs de boîtes aux lettres. À quelques exceptions près, ces ports sont déterminés par le service RPC et ne sont pas fixes.
Pour l’authentification HTTP où Négociation est indiqué, l’authentification Kerberos est d’abord tentée, puis l’authentification NTLM.
Lorsqu'un serveur d'accès au client Exchange 2010 communique avec un serveur de boîte aux lettres exécutant MicrosoftExchange Server 2003, il est recommandé d'utiliser Kerberos et de désactiver l'authentification NTLM et l'authentification de base. Il est également recommandé de configurer Outlook Web Access de sorte qu’il utilise une authentification basée sur des formulaires avec un certificat approuvé. Pour que les clients Exchange ActiveSync communiquent via le serveur d'accès au client Exchange 2010 vers le serveur principal Exchange 2003, l'authentification intégrée Windows doit être activée dans le répertoire virtuel Microsoft-Server-ActiveSync du serveur principal Exchange 2003. Pour utiliser le Gestionnaire système Exchange sur le serveur Exchange 2003 pour gérer l'authentification sur un répertoire virtuel Exchange 2003, téléchargez et installez le correctif référencé dans l'article 937031 de la Base de connaissances Microsoft, l'ID d'événement 1036 est connecté à un serveur Exchange 2007 exécutant le rôle CAS lorsque des périphériques mobiles se connectent au serveur Exchange 2007 pour accéder aux boîtes aux lettres sur un serveur principal Exchange 2003.
Remarque :Bien que l’article de la base de connaissances soit propre à Microsoft Exchange Server 2007, il s’applique également à Exchange 2010. Lorsqu'un serveur d'accès au client transmet par proxy des demandes POP3 à un autre serveur d'accès au client, la communication se fait sur le port 995/TCP. Ce comportement reste vrai même si le client de connexion utilise POP3·et exige TLS (sur le port 110/TCO) ou s'il se connecte sur le port 995/TCP à l'aide de SSL. De la même manière, pour les connexions IMAP4, le serveur à l'origine de la demande utilise le port 993/TCP pour envoyer les requêtes proxy, même si le client qui se connecte utilise IMAP4 et demande TLS (sur le port 443/TCP) ou se connecte sur le port 995 à l’aide d’IMAP4 avec le chiffrement SSL
Connectivité du serveur d’accès au client
Outre le besoin d’un serveur d’accès au client sur chaque site Active Directory contenant un serveur de boîtes aux lettres, il est important d’éviter de limiter le trafic sur les serveurs Exchange. Assurez-vous que tous les ports définis utilisés par Exchange sont ouverts dans les deux sens entre tous les serveurs sources et de destination. L’installation d’un pare-feu entre des serveurs Exchange ou entre un serveur de boîtes aux lettres ou un serveur d’accès au client Exchange 2010 et Active Directory n’est pas prise en charge. En revanche, l’installation d’un périphérique réseau est possible tant que le trafic n’est pas limité et que tous les ports disponibles sont ouverts entre les divers serveurs Exchange et Active Directory.
Serveurs de messagerie unifiée
Les passerelles IP et les PBX IP ne prennent en charge que l’authentification basée sur les certificats utilisant l’authentification mutual TLS pour le chiffrement du trafic SIP et basée sur IP pour les connexions SIP/TCP. Les passerelles IP ne prennent pas en charge les authentifications NTLM ou Kerberos. C’est pourquoi, lorsque vous utilisez une authentification IP, les adresses IP se connectant sont utilisées pour fournir le mécanisme d’authentification pour les connexions non chiffrées (TCP). En cas d’utilisation d’une authentification IP dans une messagerie unifiée, le serveur de messagerie unifiée vérifie que l’adresse IP est autorisée à se connecter. L’adresse IP est configurée sur la passerelle IP ou l’IP PBX.
Les passerelles IP et les PBX IP prennent en charge l’authentification mutual TLS pour le chiffrement du trafic SIP. Après l’importation et l’exportation réussies des certificats approuvés requis, la passerelle IP ou le PBX IP exige un certificat du serveur de messagerie unifiée qui, à son tour, en exige un de la passerelle IP ou du PBX IP. L’échange de certificats approuvés entre la passerelle IP ou le PBX IP et le serveur de messagerie unifiée permet à la passerelle IP ou au PBX IP et au serveur de MU de communiquer via une connexion chiffrée à l’aide de Mutual TLS.
Le tableau suivant fournit des informations sur le port, l’authentification et le chiffrement des chemins d’accès aux données entre les serveurs de messagerie unifiée et les autres serveurs.
Chemins d’accès aux données du serveur de messagerie unifiée
| Chemin d’accès aux données | Ports requis | Authentification par défaut | Authentification prise en charge | Chiffrement pris en charge ? | Chiffré par défaut ? |
|---|---|---|---|---|---|
Accès Active Directory |
389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC netlogon) |
Kerberos |
Kerberos |
Oui, à l’aide du chiffrement Kerberos |
Oui |
Interaction du téléphone de messagerie unifiée (PBX IP/passerelle VoIP) |
5060/TC , 5065/TCP, 5067/TCP (non sécurisé), 5061/TCP, 5066/TCP, 5068/TCP (sécurisé), port dynamique de la plage 16000-17000/TCP (contrôle), ports UDP dynamiques de la plage 1024-65535/UDP (RTP) |
Par adresse IP |
Par adresse IP, MTLS |
Oui, à l’aide de SIP/TLS, SRTP |
Non |
Service Web de messagerie unifiée |
80/TCP, 443/TCP (SSL) |
Authentification Windows intégrée (Négociation) |
De base, Digest, NTLM, Négociation (Kerberos) |
Oui, à l’aide de SSL |
Oui |
Serveur de messagerie unifiée vers serveur d’accès au client |
5075, 5076, 5077 (TCP) |
Authentification Windows intégrée (Négociation) |
De base, Digest, NTLM, Négociation (Kerberos) |
Oui, à l’aide de SSL |
Oui |
Serveur de messagerie unifiée vers serveur d’accès au client (Émettre au téléphone) |
RPC dynamique |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide du chiffrement RPC |
Oui |
Serveur de messagerie unifiée vers serveur de transport Hub |
25/TCP (TLS) |
Kerberos |
Kerberos |
Oui, à l’aide de TLS |
Oui |
Serveur de messagerie unifiée vers serveur de boîtes aux lettres |
135/TCP (RPC) |
NTLM/Kerberos |
NTLM/Kerberos |
Oui, à l’aide du chiffrement RPC |
Oui |
Notes sur les serveurs de messagerie unifiée
Lorsque vous créez un objet passerelle IP de messagerie unifiée dans Active Directory, vous devez définir l’adresse IP de la passerelle IP physique ou du PBX IP (Private Branch eXchange). Lorsque vous définissez l’adresse IP sur l’objet passerelle IP de messagerie unifiée, l’adresse IP est ajoutée à une liste de passerelles IP ou de PBX IP valides (également appelés homologues SIP) avec lesquels le serveur de messagerie unifiée est autorisé à communiquer. Lorsque vous créez une passerelle IP de messagerie unifiée, vous pouvez l’associer à un plan de numérotation de messagerie unifiée. L’association de la passerelle IP de messagerie unifiée avec un plan de numérotation permet aux serveurs de messagerie unifiée associés au plan de numérotation d’utiliser l’authentification basée sur IP pour communiquer avec la passerelle IP. Si la passerelle IP de messagerie unifiée n’a pas été créée ou n’est pas configurée pour utiliser l’adresse IP correcte, l’authentification échoue et les serveurs de messagerie unifiée n’acceptent pas les connexions provenant de l’adresse IP de cette passerelle IP. De même, lorsque vous implémentez mutual TLS et une passerelle IP ou un PBX IP et des serveurs de messagerie unifiée, la passerelle IP de messagerie unifiée doit être configurée pour utiliser le nom de domaine complet. Après avoir configuré la passerelle IP de messagerie unifiée avec un nom complet, vous devez également ajouter un enregistrement hôte à la zone de recherche directe pour la passerelle IP de messagerie unifiée.
Dans Exchange 2010, un serveur de messagerie unifiée peut communiquer sur le port 5060/TCP (non sécurisé) ou sur le port 5061/TCP (sécurisé) et être configuré pour utiliser ces deux ports.
Pour plus d’informations, consultez les rubriques Présentation de la sécurité VoIP de messagerie unifiée et Présentation des protocoles, des ports et des services dans la messagerie unifiée.
Règles de pare-feu Windows créées par le programme d’installation de Microsoft Exchange 2010
Le pare-feu Windows avec fonctions avancées de sécurité est un pare-feu dynamique basé sur un hôte qui filtre le trafic entrant et sortant en fonction des règles de pare-feu. Le programme d’installation d’Exchange 2010 crée des règles de pare-feu Windows pour ouvrir les ports requis pour les communications des serveurs et des clients sur chaque rôle serveur. Ainsi, il n’est plus nécessaire d’utiliser l’Assistant Configuration de la sécurité pour configurer ces paramètres. Pour en savoir plus sur le pare-feu Windows avec fonctions avancées de sécurité, consultez la rubrique Pare-feu Windows avec fonctions avancées de sécurité et IPsec.
Ce tableau dresse la liste des règles de pare-feu Windows créées par le programme d’installation d’Exchange, y compris les ports ouverts sur chaque rôle serveur. Vous pouvez afficher ces règles à l’aide du composant logiciel enfichable MMC Pare-feu Windows avec fonctions avancées de sécurité.
| Nom de la règle | Rôles serveur | Port | Programme |
|---|---|---|---|
MSExchangeADTopology - RPC (TCP-Entrée) |
Accès client, transport Hub, boîte aux lettres, messagerie unifiée |
RPC dynamique |
Bin\MSExchangeADTopologyService.exe |
MSExchangeMonitoring - RPC (TCP-Entrée) |
Accès client, transport Hub, transport Edge, messagerie unifiée |
RPC dynamique |
Bin\Microsoft.Exchange.Management.Monitoring.exe |
MSExchangeServiceHost - RPC (TCP-Entrée) |
Tous les rôles |
RPC dynamique |
Bin\Microsoft.Exchange.ServiceHost.exe |
MSExchangeServiceHost - RPCEPMap (TCP-Entrée) |
Tous les rôles |
RPC-EPMap |
Bin\Microsoft.Exchange.Service.Host |
MSExchangeRPCEPMap (GFW) (TCP-Entrée) |
Tous les rôles |
RPC-EPMap |
N’importe lequel |
MSExchangeRPC (GFW) (TCP-Entrée) |
Accès client, transport Hub, boîte aux lettres, messagerie unifiée |
RPC dynamique |
N’importe lequel |
MSExchange - IMAP4 (GFW) (TCP-Entrée) |
Accès client |
143, 993 (TCP) |
Tous |
MSExchangeIMAP4 (TCP-Entrée) |
Accès au client |
143, 993 (TCP) |
ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe |
MSExchange - POP3 (FGW) (TCP-Entrée) |
Accès au client |
110, 995 (TCP) |
Tous |
MSExchange - POP3 (TCP-Entrée) |
Accès au client |
110, 995 (TCP) |
ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe |
MSExchange - OWA (GFW) (TCP-Entrée) |
Accès au client |
5075, 5076, 5077 (TCP) |
Tous |
MSExchangeOWAAppPool (TCP-Entrée) |
Accès au client |
5075, 5076, 5077 (TCP) |
Inetsrv\w3wp.exe |
MSExchangeAB-RPC (TCP-Entrée) |
Accès au client |
RPC dynamique |
Bin\Microsoft.Exchange.AddressBook.Service.exe |
MSExchangeAB RPCEPMap (TCP-Entrée) |
Accès au client |
RPC-EPMap |
Bin\Microsoft.Exchange.AddressBook.Service.exe |
MSExchangeAB RpcHttp (TCP-Entrée) |
Accès au client |
6002, 6004 (TCP) |
Bin\Microsoft.Exchange.AddressBook.Service.exe |
RpcHttpLBS (TCP-Entrée) |
Accès au client |
RPC dynamique |
System32\Svchost.exe |
MSExchangeRPC - RPC (TCP-Entrée) |
Accès client, boîte aux lettres |
RPC dynamique |
Bin\Microsoft.Exchange.RpcClientAccess.Service.exe |
MSExchangeRPC - PRCEPMap (TCP-Entrée) |
Accès client, boîte aux lettres |
RPC-EPMap |
Bin\Microsoft.Exchange.RpcClientAccess.Service.exe |
MSExchangeRPC (TCP-Entrée) |
Accès client, boîte aux lettres |
6001 (TCP) |
Bin\Microsoft.Exchange.RpcClientAccess.Service.exe |
MSExchangeMailboxReplication (GFW) (TCP-Entrée) |
Accès au client |
808 (TCP) |
N’importe lequel |
MSExchangeMailboxReplication (TCP-Entrée) |
Accès au client |
808 (TCP) |
Bin\MSExchangeMailboxReplication.exe |
MSExchangeIS - RPC (TCP-Entrée) |
Boîte aux lettres |
RPC dynamique |
Bin\Store.exe |
MSExchangeIS RPCEPMap (TCP-Entrée) |
Boîte aux lettres |
RPC-EPMap |
Bin\Store.exe |
MSExchangeIS (GFW) (TCP-Entrée) |
Boîte aux lettres |
6001, 6002, 6003, 6004 (TCP) |
N’importe lequel |
MSExchangeIS (TCP-Entrée) |
Boîte aux lettres |
6001 (TCP) |
Bin\Store.exe |
MSExchangeMailboxAssistants - RPC (TCP-Entrée) |
Boîte aux lettres |
RPC dynamique |
Bin\MSExchangeMailboxAssistants.exe |
MSExchangeMailboxAssistants - RPCEPMap (TCP-Entrée) |
Boîte aux lettres |
RPC-EPMap |
Bin\MSExchangeMailboxAssistants.exe |
MSExchangeMailSubmission - RPC (TCP-Entrée) |
Boîte aux lettres |
RPC dynamique |
Bin\MSExchangeMailSubmission.exe |
MSExchangeMailSubmission - RPCEPMap (TCP-Entrée) |
Boîte aux lettres |
RPC-EPMap |
Bin\MSExchangeMailSubmission.exe |
MSExchangeMigration - RPC (TCP-Entrée) |
Boîte aux lettres |
RPC dynamique |
Bin\MSExchangeMigration.exe |
MSExchangeMigration - RPCEPMap (TCP-Entrée) |
Boîte aux lettres |
RPC-EPMap |
Bin\MSExchangeMigration.exe |
MSExchangerepl - Copieur de journal (TCP-Entrée) |
Boîte aux lettres |
64327 (TCP) |
Bin\MSExchangeRepl.exe |
MSExchangerepl - RPC (TCP-Entrée) |
Boîte aux lettres |
RPC dynamique |
Bin\MSExchangeRepl.exe |
MSExchangerepl - RPC-EPMap (TCP-Entrée) |
Boîte aux lettres |
RPC-EPMap |
Bin\MSExchangeRepl.exe |
MSExchangeSearch - RPC (TCP-Entrée) |
Boîte aux lettres |
RPC dynamique |
Bin\Microsoft.Exchange.Search.ExSearch.exe |
MSExchangeThrottling - RPC (TCP-Entrée) |
Boîte aux lettres |
RPC dynamique |
Bin\MSExchangeThrottling.exe |
MSExchangeThrottling - RPCEPMap (TCP-Entrée) |
Boîte aux lettres |
RPC-EPMap |
Bin\MSExchangeThrottling.exe |
MSFTED - RPC (TCP-Entrée) |
Boîte aux lettres |
RPC dynamique |
Bin\MSFTED.exe |
MSFTED - RPCEPMap (TCP-Entrée) |
Boîte aux lettres |
RPC-EPMap |
Bin\MSFTED.exe |
MSExchangeEdgeSync - RPC (TCP-Entrée) |
Transport Hub |
RPC dynamique |
Bin\Microsoft.Exchange.EdgeSyncSvc.exe |
MSExchangeEdgeSync - RPCEPMap (TCP-Entrée) |
Transport Hub |
RPC-EPMap |
Bin\Microsoft.Exchange.EdgeSyncSvc.exe |
MSExchangeTransportWorker - RPC (TCP-Entrée) |
Transport Hub |
RPC dynamique |
Bin\edgetransport.exe |
MSExchangeTransportWorker - RPCEPMap (TCP-Entrée) |
Transport Hub |
RPC-EPMap |
Bin\edgetransport.exe |
MSExchangeTransportWorker (GFW) (TCP-Entrée) |
Transport Hub |
25, 587 (TCP) |
N’importe lequel |
MSExchangeTransportWorker (TCP-Entrée) |
Transport Hub |
25, 587 (TCP) |
Bin\edgetransport.exe |
MSExchangeTransportLogSearch - RPC (TCP-Entrée) |
Transport Hub, transport Edge, boîte aux lettres |
RPC dynamique |
Bin\MSExchangeTransportLogSearch.exe |
MSExchangeTransportLogSearch - RPCEPMap (TCP-Entrée) |
Transport Hub, transport Edge, boîte aux lettres |
RPC-EPMap |
Bin\MSExchangeTransportLogSearch.exe |
SESWorker (GFW) (TCP-Entrée) |
Messagerie unifiée |
N’importe lequel |
N’importe lequel |
SESWorker (TCP-Entrée) |
Messagerie unifiée |
N’importe lequel |
UnifiedMessaging\SESWorker.exe |
UMService (GFW) (TCP-Entrée) |
Messagerie unifiée |
5060, 5061 |
N’importe lequel |
UMService (TCP-Entrée) |
Messagerie unifiée |
5060, 5061 |
Bin\UMService.exe |
UMWorkerProcess (GFW) (TCP-Entrée) |
Messagerie unifiée |
5065, 5066, 5067, 5068 |
N’importe lequel |
UMWorkerProcess (TCP-Entrée) |
Messagerie unifiée |
5065, 5066, 5067, 5068 |
Bin\UMWorkerProcess.exe |
UMWorkerProcess - RPC (TCP-Entrée) |
Messagerie unifiée |
RPC dynamique |
Bin\UMWorkerProcess.exe |
Notes sur les règles de pare-feu Windows créées par le programme d’installation de Microsoft Exchange 2010
Sur les serveurs disposant d’Internet Information Services (IIS), Windows ouvre les ports HTTP (port 80, TCP) et HTTPS (port 443, TCP). Le programme d’installation d’Exchange 2010 n’ouvre pas ces ports. Par conséquent, ils n’apparaissent pas dans le tableau précédent.
Dans Windows Server 2008 et Windows Server 2008 R2, le pare-feu Windows et ses fonctions avancées de sécurité vous permettent de spécifier le processus ou le service pour lequel un port est ouvert. Cette méthode est plus sécurisée car elle limite l’utilisation du port au processus ou au service spécifié dans la règle. Le programme d’installation d’Exchange crée des règles de pare-feu avec le nom de processus spécifié. Dans certains cas, une règle supplémentaire qui n’est pas limitée au processus est également créée à des fins de compatibilité. Vous pouvez désactiver ou supprimer les règles qui ne sont pas limitées aux processus et conserver les règles correspondantes limitées aux processus si votre déploiement les prend en charge. Le nom des règles non limitées aux processus contient (GFW).
Beaucoup de services Exchange utilisent des appels de procédure distante (RPC) pour la communication. Les processus serveur qui utilisent des RPC contactent le mappeur de point de terminaison RPC pour recevoir des points de terminaison dynamiques et les enregistrer dans la base de données du mappeur de point de terminaison. Les clients RPC contactent le mappeur de point de terminaison RPC pour déterminer les points de terminaison utilisés par le processus serveur. Par défaut, le mappeur de point de terminaison RPC écoute sur le port 135 (TCP). Lors de la configuration du pare-feu Windows pour un processus qui utilise les RPC, le programme d’installation d’Exchange 2010 crée deux règles de pare-feu pour le processus. Une règle autorise la communication avec le mappeur de point de terminaison RPC et l’autre règle autorise la communication avec le point de terminaison affecté de manière dynamique. Pour plus d’informations sur les RPC, consultez la rubrique sur le fonctionnement de RPC. Pour plus d’informations sur la création de règles de pare-feu Windows pour le RPC dynamique, consultez la rubrique Autorisation du trafic réseau entrant qui utilise le protocole RPC dynamique.
| Remarque : |
|---|
| Vous ne pouvez pas modifier les règles de pare-feu Windows créées par le programme d’installation de Microsoft Exchange 2010. Vous pouvez créer des règles de pare-feu basées sur ces règles, puis les désactiver ou les supprimer. |
Pour plus d’informations, consultez l’article 179442 de la Base de connaissances Microsoft sur la procédure de configuration d’un pare-feu pour des domaines et des confiances.
© 2010 Microsoft Corporation. Tous droits réservés.