Exporter (0) Imprimer
Développer tout

Référence de sécurité du chemin d'accès aux données

 

S’applique à : Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Dernière rubrique modifiée : 2009-06-05

Cette rubrique contient des informations sur les ports, l'authentification et le chiffrement de tous les chemins d'accès aux données utilisés par Microsoft Exchange Server 2007. Les sections Notes suivant chaque tableau clarifient ou définissent les méthodes d'authentification ou de chiffrement non standard.

Exchange 2007 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 2007.

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 (Transport Layer Security [TLS])

Kerberos

Kerberos

Oui (TLS)

Oui

Entre serveur de transport Hub et serveur de transport Edge

25/TCP (TLS)

Confiance directe

Confiance directe

Oui (TLS)

Oui

Entre serveur de transport Edge et serveur de transport Hub

25/TCP (TLS)

Confiance directe

Confiance directe

Oui (TLS)

Oui

Entre serveurs de transport Edge

25/TCP (TLS), 389/TCP/UDP et 80/TCP (authentification par certificat)

Anonyme, certificat

Anonyme, certificat

Oui (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 (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 (chiffrement RPC)

Oui

Messagerie unifiée vers transport Hub

25/TCP (TLS)

Kerberos

Kerberos

Oui (TLS)

Oui

Service EdgeSync de Microsoft Exchange

50636/TCP (SSL), 50389/TCP (pas de SSL)

Base

Base

Oui (LDAPS)

Oui

Service d'annuaire Active Directory Application Mode (ADAM) sur serveur de transport Edge

50389/TCP (pas de SSL)

NTLM/Kerberos

NTLM/Kerberos

Non

Non

Accès au service d'annuaire Active Directory à partir d'un 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 (chiffrement Kerberos)

Oui

Client SMTP d'utilisateur final (par exemple, Outlook Express) vers transport Hub

25/TCP (TLS), 587 (TLS)

NTLM/Kerberos

NTLM/Kerberos

Oui (TLS)

Oui

Tout le trafic entre les serveurs de transport Hub est chiffré à l'aide de TLS avec des certificats auto-signés installés par défaut lors de l'installation d'Exchange 2007. Le trafic entre les serveurs de transport Hub est authentifié à l'aide de l'authentification Kerberos.

Tout le trafic entre les serveurs de transport Edge et Hub est authentifié et chiffré. Le mécanisme sous-jacent pour l'authentification et le chiffrement est Mutual TLS. Au lieu d'utiliser une validation X.509, Exchange 2007 utilise une confiance directe pour authentifier les certificats. La confiance directe signifie que la présence du certificat dans Active Directory ou ADAM valide le certificat. Active Directory est considéré comme un mécanisme de stockage approuvé. Lorsque la confiance directe est utilisée, que le certificat soit auto-signé ou signé par une autorité de certification est sans importance. 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 EdgeSync de Microsoft Exchange met à jour ADAM avec l'ensemble des certificats de serveur de transport Hub pour validation par le serveur de transport Edge.

Par défaut, le trafic entre des serveurs de transport Edge dans deux organisations différentes est chiffré. L'installation d'Exchange 2007 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 Microsoft Exchange. Par défaut, Exchange 2007 essaie également TLS pour toutes les connexions distantes.

Les méthodes d'authentification pour le trafic entre les serveurs de transport Hub et 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 2007 prend également en charge la sécurité du domaine. La sécurité du domaine est l’ensemble des fonctionnalités d'Exchange 2007 et de Microsoft Office Outlook 2007 qui fournissent une alternative économique à S/MIME ou à d'autres solutions de sécurité au niveau message sur Internet. Le rôle de la fonctionnalité de sécurité du domaine définie est de fournir aux administrateurs un moyen de gérer les chemins de messages sécurisés entre des 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 de l'utilisateur comme « Domaine sécurisé » dans l'interface Outlook et Outlook Web Access. Pour plus d'informations, consultez la rubrique Planification 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. L'exception est le filtrage des destinataires. Celle-ci requiert des appels à ADAM ou Active Directory. Cette pratique est recommandée pour exécuter un filtrage des destinataires sur le serveur de transport Edge. Dans ce cas, le répertoire ADAM se trouve sur le même ordinateur que le serveur de transport Edge et aucune communication distante n'est requise. Si le filtrage des destinataires est installé et configuré sur le serveur de transport Hub, le filtrage des destinataires accède à Active Directory.

L'agent d'analyse de protocole est utilisé par la fonction Réputation de l'expéditeur dans Exchange 2007. 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 de blocage du courrier indésirable utilisent des données collectées, stockées et utilisées uniquement sur l'ordinateur local. Souvent, les données telles que l'agrégation de listes fiables ou les données des destinataires pour le filtrage sont transmises au répertoire ADAM local via le service EdgeSync de Microsoft Exchange.

La journalisation et la classification des messages sont effectuées sur les serveurs de transport Hub et dépendent des données d'Active Directory.

Dans le contexte du rôle serveur de boîtes aux lettres, le fait que l'authentification soit NTLM ou Kerberos dépend du contexte d'utilisateur ou de processus dans lequel le consommateur de la couche Logique métier d'Exchange opère. Dans ce contexte, le consommateur est toute application ou tout processus utilisant la couche Logique métier d'Exchange. Dans un grand nombre de cellules « Authentification par défaut » du tableau « Chemins d'accès aux données du serveur de boîtes aux lettres » figurant dans cette section, l'authentification est appelée « 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 système local du compte de l'ordinateur 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, quand un administrateur exécute une cmdlet de l'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 ?

Envoi de journaux de réplication continue en cluster et de réplication continue de secours

445/TCP

NTLM/Kerberos

NTLM/Kerberos

Oui (IPsec)

Non

Amorçage de réplication continue en cluster et de réplication continue de secours

Port aléatoire

NTLM/Kerberos

NTLM/Kerberos

Oui (IPsec)

Non

Sauvegarde du service VSS

Bloc de message serveur (SMB)

NTLM/Kerberos

NTLM/Kerberos

Non

Non

Sauvegarde héritée

Port aléatoire

NTLM/Kerberos

NTLM/Kerberos

Oui (IPsec)

Non

Clusters

135 /TCP (RPC) Consultez la section « Notes sur les serveurs de boîtes aux lettres » après ce tableau.

NTLM/Kerberos

NTLM/Kerberos

Oui (IPsec)

Non

Accès MAPI

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui (chiffrement RPC)

Oui

Assistants de boîte aux lettres

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Non

Non

Service Web de disponibilité (accès client à la boîte aux lettres)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui (chiffrement RPC)

Oui

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 (chiffrement Kerberos)

Oui

Indexation du contenu

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui (chiffrement RPC)

Oui

Accès distant Admin (Registre distant)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui (IPsec)

Non

Accès distant Admin (SMB/Fichier)

445/TCP (SMB)

NTLM/Kerberos

NTLM/Kerberos

Oui (IPsec)

Non

Accès RPC du service de mise à jour de destinataire

135/TCP (RPC)

Kerberos

Kerberos

Oui (chiffrement RPC)

Oui

Accès au service de topologie Active Directory Microsoft Exchange

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui (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 (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 (chiffrement RPC)

Oui

Carnet d'adresses en mode hors connexion accédant à Active Directory

135/TCP (RPC)

Kerberos

Kerberos

Oui (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 (chiffrement Kerberos)

Oui

DSAccess 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 (chiffrement Kerberos)

Oui

Outlook accédant au carnet d'adresses en mode hors connexion

noteRemarque :
S'applique à Outlook 2003 ou aux versions précédentes. Ce paramètre s'applique également aux clients Office Outlook 2007 lorsque la distribution Web du carnet d'adresses en mode hors connexion n'est pas activée.

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui (chiffrement RPC)

Oui

WebDav

80/TCP, 443/TCP (SSL)

De base, NTLM, Négociation

De base, NTLM, Négociation

Oui (HTTPS)

Oui

Pour l'authentification HTTP où « Négociation » est indiqué, une authentification Kerberos est d'abord tentée, puis une authentification NTLM.

Pour les communications intra-noeud, les noeuds de cluster communiquent sur un port de protocole UDP (User Datagram Protocol) 3343. Chaque noeud dans le cluster échange périodiquement des datagrammes UDP de monodiffusion séquencés avec les autres noeuds dans le cluster. Le but de cet échange est de déterminer si tous les noeuds fonctionnent correctement et de surveiller la santé des liaisons réseau.

Bien que les applications ou les clients WebDav puissent se connecter au serveur de boîtes aux lettres à l'aide d'un protocole 80/TCP ou 443/TCP, dans la plupart des cas, l'application ou les clients se connectent au serveur d'accès au client. Le serveur d'accès au client se connecte ensuite au serveur de boîtes aux lettres à l'aide d'un protocole 80/TCP ou 443/TCP.

Le chemin d'accès aux données de cluster indiqué dans le tableau « Chemins d'accès aux données du serveur de boîtes aux lettres » dans cette section utilise un RPC dynamique (TCP) pour communiquer l'état du cluster et l'activité entre les différents noeuds de 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 noeuds de cluster.

Sauf indication contraire, les technologies d'accès au client, telles que Microsoft Office Outlook Web Access, 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 le port, 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 ?

Service de découverte automatique

80/TCP, 443/TCP (SSL)

Authentification Windows de base/intégrée (Négociation)

Da base, Digest, NTLM, Négociation (Kerberos)

Oui (HTTPS)

Oui

Service de disponibilité

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM, Kerberos

Oui (HTTPS)

Oui

Outlook Web Access

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 (HTTPS)

Oui, à l'aide d'un certificat auto-signé

POP3

110/TCP (TLS), 995/TCP (SSL)

Da base, NTLM, Kerberos

Da base, NTLM, Kerberos

Oui (SSL, TLS)

Oui

IMAP4

143/TCP (TLS), 993/TCP (SSL)

Da base, NTLM, Kerberos

Da base, NTLM, Kerberos

Oui (SSL, TLS)

Oui

Outlook Anywhere (précédemment appelé RPC sur HTTP )

80/TCP, 443/TCP (SSL)

Base

De base ou NTLM

Oui (HTTPS)

Oui

Application Exchange ActiveSync

80/TCP, 443/TCP (SSL)

Base

De base, Certificat

Oui (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 (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 (IPsec)

Non

Serveur d'accès au client vers serveur de boîtes aux lettres Exchange 2007

RPC. Consultez la section « Notes sur les serveurs d'accès au client » après ce tableau.

Kerberos

NTLM/Kerberos

Oui (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 (HTTPS)

Oui, à l'aide d'un certificat auto-signé

Serveur d'accès au client vers serveur d'accès au client (Outlook Web Access)

80/TCP, 443/TCP (SSL)

Kerberos

Kerberos

Oui (HTTPS)

Oui

WebDAV

80/TCP, 443/TCP (SSL)

HTTP de base ou authentification basée sur des formulaires Outlook Web Access

De base, authentification basée de des formulaires Outlook Web Access

Oui (HTTPS)

Oui

Outlook accédant au carnet d'adresses en mode hors connexion

noteRemarque :
S'applique à Office Outlook 2007 lorsque la distribution Web du carnet d'adresses en mode hors connexion est activée.

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM/Kerberos

Oui (HTTPS)

Non

Le serveur d'accès au client communique avec le serveur de boîtes aux lettres à l'aide de nombreux ports. À quelques exceptions près, ces ports sont déterminés par le service d'appel de procédure distante (RPC) et ne sont pas fixes. Il est possible de spécifier la plage des ports dynamiques utilisés par le service RPC. Pour plus d'informations sur la limitation de la plage de ports dynamiques utilisés par le service RPC, consultez l'article 154596 de la Base de connaissances Microsoft Comment faire pour configurer l'allocation de port dynamique RPC avec un pare-feu.

importantImportant :
Nous ne prenons pas en charge les configurations dans lesquelles un pare-feu est ajouté entre les serveurs d'accès au client et les serveurs de boîtes aux lettres situés dans le même site Active Directory.
importantImportant :
Nous ne prenons pas en charge les configurations dans lesquelles un serveur d'accès au client est installé dans un réseau de périmètre. Le serveur d'accès au client doit être membre d'un domaine Active Directory et le compte d'ordinateur du serveur d'accès au client doit être membre du groupe de sécurité Exchange Servers Active Directory. Le groupe de sécurité Exchange Servers Active Directory dispose d'un accès en lecture et en écriture à tous les serveurs Exchange de votre organisation. Les communications entre le serveur d'accès au client et les serveurs de boîtes aux lettres dans l'organisation sont effectuées à l'aide du service RPC. En raison de ces exigences, l'installation d'un serveur d'accès au client dans un réseau de périmètre n'est pas prise en charge.

Pour l'authentification HTTP où « Négociation » est indiqué, une authentification Kerberos est d'abord tentée, puis une authentification NTLM.

Lorsqu'un serveur d'accès au client Exchange 2007 communique avec un serveur de boîte aux lettres exécutant Exchange Server 2003, il est recommandé d'utiliser Kerberos et de désactiver l'authentification NTLM et l'authentification de base. En outre, il est 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 2007 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 un serveur exécutant 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 937301 de la Base de connaissances Microsoft L'ID d'événement 1036 est consigné sur un serveur Exchange 2007 exécutant le rôle serveur d'accès au client 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

Les passerelles IP ne prennent en charge que l'authentification basée sur les certificats utilisant l'authentification mutuelle TLS et basée sur IP pour les connexions SIP (Session Initiation Protocol)/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.

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 et clients.

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 ?

Télécopie de messagerie unifiée

5060/TCP, 5061/TCP, 5062/TCP, un port dynamique

Par adresse IP

Par adresse IP

SIP sur TLS, mais support non chiffré

Oui pour SIP

Interaction de téléphone de messagerie unifiée (PBX)

5060/TCP, 5061/TCP, 5062/TCP, un port dynamique

Par adresse IP

Par adresse IP

SIP sur TLS, mais support non chiffré

Oui pour SIP

Service Web de messagerie unifiée

80/TCP, 443/TCP (SSL)

Authentification Windows intégrée (Négociation)

Da base, Digest, NTLM, Négociation (Kerberos)

Oui (SSL)

Oui

Messagerie unifiée vers transport Hub

25/TCP (SSL)

Kerberos

Kerberos

Oui (TLS)

Oui

Serveur de messagerie unifiée vers serveur de boîtes aux lettres

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Oui (chiffrement RPC)

Oui

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 de l'IP PBX (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 valides avec lesquelles le serveur de messagerie unifiée est autorisé à communiquer. Lors de sa création, la passerelle IP de messagerie unifiée est associée à un plan de commutation des appels 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 si elle 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.

Pour la version de publication (RTM) originale d'Exchange 2007, un serveur de messagerie unifiée peut communiquer soit sur le port 5060/TCP (non sécurisé), soit sur le port 5061/TCP (sécurisé), mais pas sur les deux.

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 de messagerie unifiée.

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.

Pour être certain de lire les informations les plus récentes et de trouver de la documentation supplémentaire sur Exchange Server 2007, visitez le site Exchange Server TechCenter.
Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.
Afficher:
© 2014 Microsoft