Exchange-Netzwerkportreferenz

Artikel
03/02/2017

Gilt für: Exchange Server 2010 SP2, Exchange Server 2010 SP3

Letztes Änderungsdatum des Themas: 2016-11-28

In diesem Thema finden Sie Informationen zu Ports, zur Authentifizierung und zur Verschlüsselung aller von MicrosoftExchange Server 2010 verwendeten Datenpfade. Die Anmerkungen nach den einzelnen Tabellen dienen zur Erläuterung oder Definition von Authentifizierungs- oder Verschlüsselungsmethoden, die nicht dem Standard entsprechen.

Transportserver

Exchange 2010 enthält zwei Serverrollen, die Nachrichtentransportfunktionen ausführen: Hub-Transport-Server und Edge-Transport-Server.

Die folgende Tabelle enthält Informationen über Ports, Authentifizierung und Verschlüsselung für Datenpfade zwischen diesen Transportservern und anderen Exchange 2010-Servern und -Diensten.

Transportserver-Datenpfade

Datenpfad	Erforderliche Ports	Standardauthentifizierung	Unterstützte Authentifizierung	Verschlüsselung unterstützt?	Standardmäßig verschlüsselt?
Hub-Transport-Server zu Hub-Transport-Server	25/TCP (SMTP)	Kerberos	Kerberos	Ja, mit TLS (Transport Layer Security)	Ja
Hub-Transport-Server zu Edge-Transport-Server	25/TCP (SMTP)	Direkte Vertrauensstellung	Direkte Vertrauensstellung	Ja, mit TLS	Ja
Edge-Transport-Server zu Hub-Transport-Server	25/TCP (SMTP)	Direkte Vertrauensstellung	Direkte Vertrauensstellung	Ja, mit TLS	Ja
Edge-Transport-Server zu Edge-Transport-Server	25/TCP (SMTP)	Anonym, Zertifikat	Anonym, Zertifikat	Ja, mit TLS	Ja
Postfachserver an Hub-Transport-Server über den Microsoft Exchange-Mailübergabedienst	135/TCP (RPC)	NTLM. Wenn die beiden Serverrollen Hub-Transport und Mailbox auf demselben Server installiert sind, wird Kerberos verwendet.	NTLM/Kerberos	Ja, mit RPC-Verschlüsselung	Ja
Hub-Transport- an Postfachserver über MAPI	135/TCP (RPC)	NTLM. Wenn die die Hub-Transport- und die Postfachserverrolle auf demselben Server installiert sind, wird Kerberos verwendet.	NTLM/Kerberos	Ja, mit RPC-Verschlüsselung	Ja
Unified Messaging-Server zu Hub-Transport-Server	25/TCP (SMTP)	Kerberos	Kerberos	Ja, mit TLS	Ja
MicrosoftExchange EdgeSync-Dienst von Hub-Transport-Server zu Edge-Transport-Server	50636/TCP (SSL)	Standard	Standard	Ja, mit LDAP über SSL (LDAPS)	Ja
Active Directory-Zugriff vom Hub-Transport-Server	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC-Netzwerkanmeldung)	Kerberos	Kerberos	Ja, mit Kerberos-Verschlüsselung	Ja
Active Directory-Rechteverwaltungsdienste-Zugriff (AD RMS) vom Hub-Transport-Server	443/TCP (HTTPS)	NTLM/Kerberos	NTLM/Kerberos	Ja, mit SSL	Ja*
SMTP-Clients zu Hub-Transport-Server (z. B. Endbenutzer, die Windows Live Mail verwenden)	587 (SMTP) 25/TCP (SMTP)	NTLM/Kerberos	NTLM/Kerberos	Ja, mit TLS	Ja

Anmerkungen zu Transportservern

Der gesamte Datenverkehr zwischen Hub-Transport-Servern wird unter Verwendung von TLS mit selbstsignierten Zertifikaten verschlüsselt, die standardmäßig von Exchange 2010-Setup installiert werden.

Hinweis

In Exchange 2010 kann TLS auf Hub-Transport-Servern für die interne SMTP-Kommunikation mit anderen Hub-Transport-Servern in der gleichen Exchange-Organisation deaktiviert werden. Es wird empfohlen, die Deaktivierung nur auszuführen, wenn diese unbedingt erforderlich ist. Weitere Informationen finden Sie unter Deaktivieren von TLS zwischen Active Directory-Standorten zur Unterstützung der WAN-Optimierung.
Der gesamte Verkehr zwischen Edge-Transport-Servern und Hub-Transport-Servern wird authentifiziert und verschlüsselt. Der zugrunde liegende Mechanismus für Authentifizierung und Verschlüsselung ist MTLS (Mutual TLS). Anstelle einer X.509-Gültigkeitsprüfung verwendet Exchange 2010direkte Vertrauensstellungen zum Authentifizieren der Zertifikate. "Direkte Vertrauensstellung" bedeutet, dass das Vorhandensein des Zertifikats in Active Directory oder Active Directory Lightweight Directory Services (AD LDS) die Gültigkeit des Zertifikats bestätigt. Active Directory wird als vertrauenswürdiger Speicherungsmechanismus angesehen. Wenn die direkte Vertrauensstellung verwendet wird, ist es nicht von Bedeutung, ob das Zertifikat selbstsigniert ist oder von einer Zertifizierungsstelle signiert wurde. Wenn Sie einen Edge-Transport-Server für eine Exchange-Organisation abonnieren, veröffentlicht das Edge-Abonnement das Edge-Transport-Serverzertifikat für die Überprüfung durch die Hub-Transport-Server in Active Directory. Der Microsoft Exchange-EdgeSync-Dienst aktualisiert AD LDS mit dem Satz von Hub-Transport-Serverzertifikaten, damit diese vom Edge-Transport-Server überprüft werden können.
EdgeSync verwendet eine sichere LDAP-Verbindung vom Hub-Transport-Server zu abonnierten Edge-Transport-Servern über TCP 50636. AD LDS überwacht außerdem TCP 50389. Verbindungen mit diesem Port verwenden kein SSL. Sie können LDAP-Hilfsprogramme zur Verbindungsherstellung mit dem Port und zum Überprüfen von AD LDS-Daten verwenden.
Standardmäßig wird der Verkehr zwischen Edge-Transport-Servern in zwei verschiedenen Organisationen verschlüsselt. Exchange 2010-Setup erstellt ein selbstsigniertes Zertifikat, und TLS ist standardmäßig aktiviert. Dadurch kann jedes sendende System die bei Exchange eingehende SMTP-Sitzung verschlüsseln. Ebenfalls standardmäßig versucht Exchange 2010, TLS für alle Remoteverbindungen zu verwenden.
Die Authentifizierungsmethoden für Datenverkehr zwischen Hub-Transport-Servern und Postfachservern unterscheiden sich, wenn die Hub-Transport- und die Postfachserverrolle auf demselben Computer ausgeführt werden. Bei lokaler Nachrichtenübermittlung wird Kerberos-Authentifizierung verwendet. Bei Remote-Nachrichtenübermittlung wird NTLM-Authentifizierung verwendet.
Exchange 2010 unterstützt außerdem Domänensicherheit. Domänensicherheit bezieht sich auf die Funktionalität in Exchange 2010 und MicrosoftOutlook 2010, die eine relativ kostengünstige Alternative zu S/MIME oder anderen webbasierten Sicherheitslösungen auf Nachrichtenebene darstellt. Die Domänensicherheit bietet Ihnen eine Möglichkeit, sichere Nachrichtenpfade über das Internet zwischen Domänen zu verwalten. Nachdem diese sicheren Nachrichtenpfade konfiguriert wurden, werden Nachrichten, die den sicheren Pfad von einem authentifizierten Absender aus durchlaufen haben, Benutzern von Outlook und Outlook Web Access als "domänengesichert" angezeigt. Weitere Informationen finden Sie unter Grundlegendes zur Domänensicherheit.
Auf Hub-Transport-Servern und Edge-Transport-Servern können viele Agents ausgeführt werden. Im Allgemeinen arbeiten Antispam-Agents auf der Grundlage von lokalen Informationen des Computers, auf dem der Agent ausgeführt wird. Daher ist nur minimale Kommunikation mit Remotecomputern erforderlich. Die Empfängerfilterung stellt eine Ausnahme dar. Die Empfängerfilterung erfordert Aufrufe von AD LDS oder Active Directory. Als bewährte Methode sollte die Empfängerfilterung auf dem Edge-Transport-Server durchgeführt werden. In diesem Fall befindet sich das AD LDS-Verzeichnis auf dem gleichen Computer wie der Edge-Transport-Server. Es ist daher keine Remotekommunikation notwendig. Wenn die Empfängerfilterung auf dem Hub-Transport-Server installiert und konfiguriert wurde, greift die Empfängerfilterung auf Active Directory zu.
Das Feature "Absenderzuverlässigkeit" in Exchange 2010 verwendet den Protokollanalyse-Agent. Dieser Agent nimmt auch verschiedene Verbindungen zu außerhalb befindlichen Proxyservern vor, um die Pfade eingehender Nachrichten auf verdächtige Verbindungen zu prüfen.
Alle weiteren Antispamfunktionen verwenden diese Daten zur Aggregation von Listen sicherer Adressen und Empfängerdaten zur Empfängerfilterung. Diese Daten werden gesammelt und gespeichert, und auf sie kann nur vom lokalen Computer zugegriffen werden. Häufig werden die Daten mithilfe des MicrosoftExchange-EdgeSync-Diensts in das lokale AD LDS-Verzeichnis übertragen.
IRM-Agents (Information Rights Management) auf Hub-Transport-Servern stellen Verbindungen mit Servern in der Organisation her, auf denen die Active Directory-Rechteverwaltungsdienste (AD RMS) installiert sind. AD RMS ist ein Webdienst, der als bewährte Methode durch SSL geschützt wird. Die Kommunikation mit AD RMS-Servern erfolgt über HTTPS. Für die Authentifizierung werden Kerberos oder NTLM verwendet, je nach Konfiguration des AD RMS-Servers.
Journalregeln, Transportregeln und Nachrichtenklassifikationen werden in Active Directory gespeichert. Der Zugriff auf diese Informationen erfolgt über den Journal-Agent und den Transportregel-Agent auf den Hub-Transport-Servern.

Postfachserver

Ob die NTLM- oder Kerberos-Authentifizierung für Postfachserver verwendet wird, hängt vom Benutzer- oder Prozesskontext ab, unter dem der Verbraucher der Exchange-Geschäftslogikschicht ausgeführt wird. In diesem Kontext kann jede Anwendung oder jeder Prozess, der die Exchange-Geschäftslogikschicht verwendet, den Verbraucher darstellen. Aus diesem Grund weisen viele Einträge in der Spalte Standardauthentifizierung der Tabelle Postfachserver-Datenpfade den Wert NTLM/Kerberos auf.

Die Exchange-Geschäftslogikschicht wird für den Zugriff auf den und die Kommunikation mit dem Exchange-Informationsspeicher verwendet. Die Exchange-Geschäftslogikschicht wird außerdem vom Exchange-Informationsspeicher für die Kommunikation mit externen Anwendungen und Prozessen aufgerufen.

Wenn der Verbraucher der Exchange-Geschäftslogikschicht als Konto "Lokales System" ausgeführt wird, wird als Authentifizierungsmethode vom Verbraucher zum Exchange-Informationsspeicher immer Kerberos verwendet. Kerberos wird verwendet, da der Verbraucher über das Computerkonto Lokales System authentifiziert werden und eine bidirektionale Vertrauensstellung vorliegen muss.

Wenn der Verbraucher der Exchange-Geschäftslogikschicht nicht als Lokales System ausgeführt wird, wird als Authentifizierungsmethode NTLM verwendet. Wenn Sie beispielsweise ein Exchange-Verwaltungsshell-Cmdlet ausführen, das die Exchange-Geschäftslogikschicht verwendet, wird NTLM verwendet.

Der RPC-Verkehr wird immer verschlüsselt.

Die folgende Tabelle enthält Informationen über Ports, Authentifizierung und Verschlüsselung für Datenpfade zu und von Postfachservern.

Postfachserver-Datenpfade

Datenpfad	Erforderliche Ports	Standardauthentifizierung	Unterstützte Authentifizierung	Verschlüsselung unterstützt?	Standardmäßig verschlüsselt?
Active Directory-Zugriff	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC-Netzwerkanmeldung)	Kerberos	Kerberos	Ja, mit Kerberos-Verschlüsselung	Ja
Administrator-Remotezugriff (Remoteregistrierung)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Ja, mit IPsec	Nein
Administrator-Remotezugriff (SMB/Datei)	445/TCP (SMB)	NTLM/Kerberos	NTLM/Kerberos	Ja, mit IPsec	Nein
Verfügbarkeits-Webdienst (Clientzugriffsserver zu Postfachserver)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Ja, mit RPC-Verschlüsselung	Ja
Clustering	135/TCP (RPC); siehe Anmerkungen zu Postfachservern im Anschluss an diese Tabelle.	NTLM/Kerberos	NTLM/Kerberos	Ja, mit IPsec	Nein
Inhaltsindizierung	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Ja, mit RPC-Verschlüsselung	Ja
Protokollversand	64327 (anpassbar)	NTLM/Kerberos	NTLM/Kerberos	Ja	Nein
Seeding	64327 (anpassbar)	NTLM/Kerberos	NTLM/Kerberos	Ja	Nein
Sicherung per Volumeschattenkopie-Dienst (VSS)	Lokaler Nachrichtenblock (SMB)	NTLM/Kerberos	NTLM/Kerberos	Nein	Nein
Postfach-Assistenten	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Nein	Nein
MAPI-Zugriff	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Ja, mit RPC-Verschlüsselung	Ja
Zugriff auf den Microsoft Exchange Active Directory-Topologiedienst	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Ja, mit RPC-Verschlüsselung	Ja
Legacy-Zugriff auf den Microsoft Exchange-Systemaufsichtsdienst (Überwachen auf Anforderungen)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Nein	Nein
Legacy-Zugriff vom Microsoft Exchange-Systemaufsichtsdienst auf Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC-Netzwerkanmeldung)	Kerberos	Kerberos	Ja, mit Kerberos-Verschlüsselung	Ja
Legacy-Zugriff auf den Microsoft Exchange-Systemaufsichtsdienst (als MAPI-Client)	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Ja, mit RPC-Verschlüsselung	Ja
OAB-Zugriff auf Active Directory	135/TCP (RPC)	Kerberos	Kerberos	Ja, mit RPC-Verschlüsselung	Ja
RPC-Zugriff für den Empfängerupdatesdienst	135/TCP (RPC)	Kerberos	Kerberos	Ja, mit RPC-Verschlüsselung	Ja
Empfängerupdate auf Active Directory	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC-Netzwerkanmeldung)	Kerberos	Kerberos	Ja, mit Kerberos-Verschlüsselung	Ja

Anmerkungen zu Postfachservern

Der Datenpfad Clustering in der vorstehenden Tabelle verwendet dynamisches RPC über TCP zur Kommunikation des Clusterstatus und der Aktivität zwischen den verschiedenen Clusterknoten. Der Clusterdienst (ClusSvc.exe) verwendet außerdem UDP/3343 und zufällig zugewiesene hohe TCP-Ports für die Kommunikation zwischen den Clusterknoten.
Für die knoteninterne Kommunikation kommunizieren die Clusterknoten über den UDP-Port 3343 (User Datagram Protocol). Die einzelnen Knoten im Cluster tauschen regelmäßig sequenzierte Unicast-UDP-Datagramme mit allen anderen Knoten im Cluster aus. Durch den Austausch wird ermittelt, ob aktuell alle Knoten ordnungsgemäß ausgeführt werden, und gleichzeitig wird die Integrität der Netzwerkverbindungen überwacht.
Port 64327/TCP ist der Standardport für den Protokollversand. Administratoren können einen anderen Port für den Protokollversand angeben.
Wenn für die HTTP-Authentifizierung Aushandeln aufgeführt ist, wird zunächst Kerberos und dann NTLM versucht.

Clientzugriffsserver

Sofern nicht anders vermerkt, werden Clientzugriffstechnologien wie Outlook Web App, POP3 oder IMAP4 durch die Authentifizierung und Verschlüsselung von der Clientanwendung zum Clientzugriffsserver beschrieben.

Die folgende Tabelle enthält Informationen über Ports, Authentifizierung und Verschlüsselung für Datenpfade zwischen Clientzugriffsservern und anderen Servern und Clients.

Clientzugriffsserver-Datenpfade

Datenpfad	Erforderliche Ports	Standardauthentifizierung	Unterstützte Authentifizierung	Verschlüsselung unterstützt?	Standardmäßig verschlüsselt?
Active Directory-Zugriff	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC-Netzwerkanmeldung)	Kerberos	Kerberos	Ja, mit Kerberos-Verschlüsselung	Ja
AutoErmittlungsdienst	80/TCP, 443/TCP (SSL)	Standard-/Integrierte Windows-Authentifizierung (Aushandeln)	Standardauthentifizierung, Digest, NTLM, Aushandeln (Kerberos)	Ja, mit HTTPS	Ja
Verfügbarkeitsdienst	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	NTLM, Kerberos	Ja, mit HTTPS	Ja
Postfachreplikationsdienst (Mailbox Replication Service, MRS)	808/TCP	Kerberos/NTLM	Kerberos, NTLM	Ja, mit RPC-Verschlüsselung	Ja
Outlook-Zugriff auf OAB	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	NTLM/Kerberos	Ja, mit HTTPS	Nein
Outlook Web App	80/TCP, 443/TCP (SSL)	Formularbasierte Authentifizierung	Standardauthentifizierung, Digest, Formularbasierte Authentifizierung, NTLM (nur Version 2), Kerberos, Zertifikat	Ja, mit HTTPS	Ja, mithilfe eines selbstsignierten Zertifikats
POP3	110/TCP (TLS), 995/TCP (SSL)	Standard, Kerberos	Standard, Kerberos	Ja, mit SSL, TLS	Ja
IMAP4	143/TCP (TLS), 993/TCP (SSL)	Standard, Kerberos	Standard, Kerberos	Ja, mit SSL, TLS	Ja
Outlook Anywhere (früher als "RPC über HTTP" bezeichnet)	80/TCP, 443/TCP (SSL)	Standard	Standardauthentifizierung oder NTLM	Ja, mit HTTPS	Ja
Exchange ActiveSync-Anwendung	80/TCP, 443/TCP (SSL)	Standard	Standardauthentifizierung, Zertifikat	Ja, mit HTTPS	Ja
Clientzugriffsserver zu Unified Messaging-Server	5060/TCP, 5061/TCP, 5062/TCP, ein dynamischer Port	Nach IP-Adresse	Nach IP-Adresse	Ja, mit SIP über TLS (Session Initiation Protocol)	Ja
Clientzugriffsserver auf Postfachserver, der eine frühere Version von Exchange Server ausführt	80/TCP, 443/TCP (SSL)	NTLM/Kerberos	Aushandeln (Kerberos mit Fallback auf NTLM oder optional Standardauthentifizierung), POP/IMAP unverschlüsselter Text	Ja, mit IPsec	Nein
Clientzugriffsserver zu Exchange 2010-Postfachserver	RPC. Informationen hierzu finden Sie unter Anmerkungen zu Clientzugriffsservern.	Kerberos	NTLM/Kerberos	Ja, mit RPC-Verschlüsselung	Ja
Clientzugriffsserver zu Clientzugriffsserver (Exchange ActiveSync)	80/TCP, 443/TCP (SSL)	Kerberos	Kerberos, Zertifikat	Ja, mit HTTPS	Ja, mithilfe eines selbstsignierten Zertifikats
Clientzugriffsserver zu Clientzugriffsserver (Outlook Web Access)	80/TCP, 443/TCP (HTTPS)	Kerberos	Kerberos	Ja, mit SSL	Ja
Clientzugriffsserver zu Clientzugriffsserver (Exchange-Webdienste)	443/TCP (HTTPS)	Kerberos	Kerberos	Ja, mit SSL	Ja
Clientzugriffsserver zu Clientzugriffsserver (POP3)	995 (SSL)	Standard	Standard	Ja, mit SSL	Ja
Clientzugriffsserver zu Clientzugriffsserver (IMAP4)	993 (SSL)	Standard	Standard	Ja, mit SSL	Ja
Office Communications Server-Zugriff auf den Clientzugriffsserver (wenn die Integration zwischen Office Communications Server und Outlook Web App aktiviert ist)	5075-5077/TCP (IN), 5061/TCP (OUT)	mTLS (erforderlich)	mTLS (erforderlich)	Ja, mit SSL	Ja

Hinweis

Die integrierte Windows-Authentifizierung (NTLM) wird für POP3- oder IMAP4-Clientverbindungen nicht unterstützt. Weitere Informationen finden Sie in den Abschnitten zu den Clientzugriffsfunktionen im Thema Nicht mehr verfügbare Funktionen.

Anmerkungen zu Clientzugriffsservern

In Exchange 2010 stellen MAPI-Clients wie Microsoft Outlook eine Verbindung mit Clientzugriffsservern her.
Die Clientzugriffsserver verwenden zahlreiche Ports für die Kommunikation mit Postfachservern. Mit einigen Ausnahmen werden diese Ports vom RPC-Dienst bestimmt und sind nicht festgelegt.
Wenn für die HTTP-Authentifizierung Aushandeln aufgeführt ist, wird zunächst Kerberos und dann NTLM versucht.
Wenn ein Exchange 2010-Clientzugriffsserver mit einem Postfachserver kommuniziert, der MicrosoftExchange Server 2003 ausführt, besteht die optimale Methode in der Verwendung von Kerberos und der Deaktivierung von NTLM-Authentifizierung und Standardauthentifizierung. Darüber hinaus ist es eine bewährte Methode, Outlook Web App für die Verwendung der formularbasierten Authentifizierung mit einem vertrauenswürdigen Zertifikat zu konfigurieren. Damit Exchange ActiveSync-Clients über den Exchange 2010-Clientzugriffsserver mit dem Exchange 2003-Back-End-Server kommunizieren können, muss die integrierte Windows-Authentifizierung für das virtuelle Verzeichnis "Microsoft-Server-ActiveSync" auf dem Exchange 2003-Back-End-Server aktiviert sein. Wenn Sie den Exchange-System-Manager auf dem Exchange 2003-Server verwenden möchten, um die Authentifizierung in einem virtuellen Exchange 2003-Verzeichnis zu verwalten, sollten Sie den in Microsoft Knowledge Base-Artikel 937031 Ereignis-ID 1036 wird auf einem Exchange 2007-Server protokolliert, der die Clientzugriffsserverrolle ausführt, wenn mobile Geräte eine Verbindung zum Exchange 2007-Server herstellen, um auf Postfächer auf einem Exchange 2003-Back-End-Server zuzugreifen beschriebenen Hotfix herunterladen und installieren.

Hinweis

Wenngleich sich der Knowledge Base-Artikel auf MicrosoftExchange Server 2007 bezieht, gilt er auch für Exchange 2010.
Wenn ein Clientzugriffsserver als Proxy für POP3-Anfragen auf andere Clientzugriffsserver dient, wird die Kommunikation über Port 995/TCP abgewickelt. Dies ist unabhängig davon, ob der verbindende Client POP3 verwendet und TLS anfordert (auf Port 110/TCP) oder eine Verbindung mit Port 995/TCP über SSL herstellt. Ähnlich verwendet der anfragende Server für IMAP4-Verbindungen Port 993/TCP zur Proxyweiterleitung von Anforderungen. Hierbei ist es unerheblich, ob der verbindende Client IMAP4 verwendet und TLS anfordert (auf Port 443/TCP) oder eine Verbindung mit Port 995 unter Verwendung von IMAP4 mit SSL-Verschlüsselung herstellt

Clientzugriffsserver-Konnektivität

Neben der Anforderung, an jedem Active Directory-Standort mit einem Postfachserver einen Clientzugriffsserver bereitzustellen, muss vermieden werden, dass der Datenverkehr zwischen Exchange-Servern eingeschränkt wird. Stellen Sie sicher, dass alle definierten Ports, die von Exchange verwendet werden, in beide Richtungen zwischen sämtlichen Quell- und Zielservern geöffnet sind. Die Installation einer Firewall zwischen Exchange-Servern oder zwischen einem Exchange 2010-Postfachserver oder einem -Clientzugriffsserver und Active Directory wird nicht unterstützt. Wenn der Datenverkehr nicht eingeschränkt ist und alle verfügbaren Ports zwischen den verschiedenen Exchange-Servern und Active Directory offen sind, kann jedoch ein Netzwerkgerät installiert werden.

Unified Messaging-Server

IP-Gateways und IP-PBX-Anlagen unterstützen nur die zertifikatbasierte Authentifizierung, die MTLS zum Verschlüsseln von SIP-Datenverkehr und eine IP-basierte Authentifizierung für SIP/TCP-Verbindungen (Session Initiation Protocol) verwendet. IP-Gateways unterstützen weder die NTLM- noch die Kerberos-Authentifizierung. Wenn Sie IP-basierte Authentifizierung verwenden, werden daher die Verbindungs-IP-Adresse(n) zum Bereitstellen des Authentifizierungsmechanismus für unverschlüsselte (TCP-) Verbindungen verwendet. Wenn in Unified Messaging (UM) die IP-basierte Authentifizierung verwendet wird, überprüft der Unified Messaging-Server, ob die IP-Adresse zum Herstellen von Verbindungen berechtigt ist. Die IP-Adresse wird auf dem IP-Gateway oder der IP-PBX-Anlage konfiguriert.

IP-Gateways und IP-PBX-Anlagen unterstützen MTLS für das Verschlüsseln von SIP-Datenverkehr. Nach dem erfolgreichen Import und Export der erforderlichen vertrauenswürdigen Zertifikate fordert das IP-Gateway oder die IP-PBX-Anlage ein Zertifikat vom UM-Server und dieser anschließend ein Zertifikat vom IP-Gateway bzw. der IP-PBX-Anlage an. Durch den Austausch der vertrauenswürdigen Zertifikate zwischen dem IP-Gateway oder der IP-PBX-Anlage und dem UM-Server können IP-Gateway oder IP-PBX-Anlage und UM-Server mithilfe von MTLS über eine verschlüsselte Verbindung kommunizieren.

Die folgende Tabelle enthält Informationen über Port, Authentifizierung und Verschlüsselung für Datenpfade zwischen Unified Messaging-Servern und anderen Servern.

Unified Messaging-Server-Datenpfade

Datenpfad	Erforderliche Ports	Standardauthentifizierung	Unterstützte Authentifizierung	Verschlüsselung unterstützt?	Standardmäßig verschlüsselt?
Active Directory-Zugriff	389/TCP/UDP (LDAP), 3268/TCP (LDAP GC), 88/TCP/UDP (Kerberos), 53/TCP/UDP (DNS), 135/TCP (RPC-Netzwerkanmeldung)	Kerberos	Kerberos	Ja, mit Kerberos-Verschlüsselung	Ja
Unified Messaging-Telefoninteraktion (IP-PBX/VoIP-Gateway)	5060/TCP, 5065/TCP, 5067/TCP (unsicher), 5061/TCP, 5066/TCP, 5068/TCP (sicher), ein dynamischer Port aus dem Bereich 16000-17000/TCP (gesteuert), dynamische UDP-Ports aus dem Bereich 1024-65535/UDP (RTP)	Nach IP-Adresse	Nach IP-Adresse, MTLS	Ja, mit SIP/TLS, SRTP	Nein
Unified Messaging-Webdienst	80/TCP, 443/TCP (SSL)	Integrierte Windows-Authentifizierung (Aushandeln)	Standardauthentifizierung, Digest, NTLM, Aushandeln (Kerberos)	Ja, mit SSL	Ja
Unified Messaging-Server zu Clientzugriffsserver	5075, 5076, 5077 (TCP)	Integrierte Windows-Authentifizierung (Aushandeln)	Standardauthentifizierung, Digest, NTLM, Aushandeln (Kerberos)	Ja, mit SSL	Ja
Unified Messaging-Server zu Clientzugriffsserver (Wiedergabe über Telefon)	Dynamisches RPC	NTLM/Kerberos	NTLM/Kerberos	Ja, mit RPC-Verschlüsselung	Ja
Unified Messaging-Server zu Hub-Transport-Server	25/TCP (TLS)	Kerberos	Kerberos	Ja, mit TLS	Ja
Unified Messaging-Server zu Postfachserver	135/TCP (RPC)	NTLM/Kerberos	NTLM/Kerberos	Ja, mit RPC-Verschlüsselung	Ja

Anmerkungen zu Unified Messaging-Servern

Wenn Sie ein UM-IP-Gatewayobjekt in Active Directory erstellen, müssen Sie die IP-Adresse des physischen IP-Gateways oder der IP-PBX-Anlage (Private Branch eXchange, Nebenstellenanlage) definieren. Wenn Sie die IP-Adresse im UM-IP-Gatewayobjekt definieren, wird die IP-Adresse einer Liste der gültigen IP-Gateways oder IP-PBX-Anlagen hinzugefügt (auch SIP-Peers genannt), mit denen der UM-Server kommunizieren kann. Wenn Sie das UM-IP-Gateway erstellen, können Sie es einem Satz mit UM-Wähleinstellungen zuordnen. Das Zuordnen des UM-IP-Gateways zu einem Satz mit Wähleinstellungen ermöglicht den diesen Wähleinstellungen zugeordneten Unified Messaging-Servern das Verwenden von IP-basierter Authentifizierung zum Kommunizieren mit dem IP-Gateway. Wenn der UM-IP-Gateway nicht erstellt wurde oder nicht für die Verwendung der richtigen IP-Adresse konfiguriert ist, tritt bei der Authentifizierung ein Fehler auf, und die Unified Messaging-Server akzeptieren keine Verbindungen von der IP-Adresse des betreffenden IP-Gateways. Wenn Sie außerdem MTLS und IP-Gateway oder IP-PBX-Anlage und UM-Server implementieren, muss das UM-IP-Gateway für die Verwendung des FQDN konfiguriert werden. Nachdem Sie das UM-IP-Gateway mit einem FQDN konfiguriert haben, müssen Sie der DNS-Forward-Lookupzone einen Hosteintrag für das UM-IP-Gateway hinzufügen.
In Exchange 2010 kann ein UM-Server entweder auf Port 5060/TCP (unsicher) oder auf Port 5061/TCP (sicher) kommunizieren. Der Server kann für die Verwendung beider Ports konfiguriert werden.

Weitere Informationen finden Sie unter Grundlegendes zu Unified Messaging VoIP-Sicherheit und Grundlegendes zu Protokollen, Ports und Diensten in Unified Messaging.

Von Exchange 2010-Setup erstellte Windows-Firewallregeln

Die Windows-Firewall mit erweiterter Sicherheit ist eine zustandsbehaftete, hostbasierte Firewall, die basierend auf Firewallregeln den eingehenden und ausgehenden Datenverkehr filtert. Exchange 2010-Setup erstellt Windows-Firewallregeln zum Öffnen der erforderlichen Ports für die Kommunikation zwischen Server und Client für jede Serverrolle. Es ist daher nicht länger erforderlich, diese Einstellungen mit dem Sicherheitskonfigurations-Assistenten zu konfigurieren. Weitere Informationen zur Windows-Firewall mit erweiterter Sicherheit finden Sie unter Windows-Firewall mit erweiterter Sicherheit und IPsec.

In dieser Tabelle werden die von Exchange-Setup erstellten Windows-Firewallregeln aufgeführt, einschließlich der für die einzelnen Serverrollen geöffneten Ports. Sie können diese Regeln mit dem MMC-Snap-In Windows-Firewall mit erweiterter Sicherheit anzeigen.

Regelname	Serverrollen	Port	Programm
MSExchangeADTopology - RPC (TCP eingehend)	Clientzugriff, Hub-Transport, Postfach, Unified Messaging	Dynamisches RPC	Bin\MSExchangeADTopologyService.exe
MSExchangeMonitoring - RPC (TCP eingehend)	Clientzugriff, Hub-Transport, Edge-Transport, Unified Messaging	Dynamisches RPC	Bin\Microsoft.Exchange.Management.Monitoring.exe
MSExchangeServiceHost - RPC (TCP eingehend)	Alle Rollen	Dynamisches RPC	Bin\Microsoft.Exchange.ServiceHost.exe
MSExchangeServiceHost - RPCEPMap (TCP eingehend)	Alle Rollen	RPC-EPMap	Bin\Microsoft.Exchange.Service.Host
MSExchangeRPCEPMap (GFW) (TCP eingehend)	Alle Rollen	RPC-EPMap	Beliebig
MSExchangeRPC (GFW) (TCP eingehend)	Clientzugriff, Hub-Transport, Postfach, Unified Messaging	Dynamisches RPC	Beliebig
MSExchange - IMAP4 (GFW) (TCP eingehend)	Clientzugriff	143, 993 (TCP)	Alle
MSExchangeIMAP4 (TCP eingehend)	Clientzugriff	143, 993 (TCP)	ClientAccess\PopImap\Microsoft.Exchange.Imap4Service.exe
MSExchange - POP3 (FGW) (TCP eingehend)	Clientzugriff	110, 995 (TCP)	Alle
MSExchange - POP3 (TCP eingehend)	Clientzugriff	110, 995 (TCP)	ClientAccess\PopImap\Microsoft.Exchange.Pop3Service.exe
MSExchange - OWA (GFW) (TCP eingehend)	Clientzugriff	5075, 5076, 5077 (TCP)	Alle
MSExchangeOWAAppPool (TCP eingehend)	Clientzugriff	5075, 5076, 5077 (TCP)	Inetsrv\w3wp.exe
MSExchangeAB-RPC (TCP eingehend)	Clientzugriff	Dynamisches RPC	Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RPCEPMap (TCP eingehend)	Clientzugriff	RPC-EPMap	Bin\Microsoft.Exchange.AddressBook.Service.exe
MSExchangeAB-RpcHttp (TCP eingehend)	Clientzugriff	6002, 6004 (TCP)	Bin\Microsoft.Exchange.AddressBook.Service.exe
RpcHttpLBS (TCP eingehend)	Clientzugriff	Dynamisches RPC	System32\Svchost.exe
MSExchangeRPC - RPC (TCP eingehend)	Clientzugriff, Postfach	Dynamisches RPC	Bin\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC - PRCEPMap (TCP eingehend)	Clientzugriff, Postfach	RPC-EPMap	Bin\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeRPC (TCP eingehend)	Clientzugriff, Postfach	6001 (TCP)	Bin\Microsoft.Exchange.RpcClientAccess.Service.exe
MSExchangeMailboxReplication (GFW) (TCP eingehend)	Clientzugriff	808 (TCP)	Beliebig
MSExchangeMailboxReplication (TCP eingehend)	Clientzugriff	808 (TCP)	Bin\MSExchangeMailboxReplication.exe
MSExchangeIS - RPC (TCP eingehend)	Postfach	Dynamisches RPC	Bin\Store.exe
MSExchangeIS RPCEPMap (TCP eingehend)	Postfach	RPC-EPMap	Bin\Store.exe
MSExchangeIS (GFW) (TCP eingehend)	Postfach	6001, 6002, 6003, 6004 (TCP)	Beliebig
MSExchangeIS (TCP eingehend)	Postfach	6001 (TCP)	Bin\Store.exe
MSExchangeMailboxAssistants - RPC (TCP eingehend)	Postfach	Dynamisches RPC	Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailboxAssistants - RPCEPMap (TCP eingehend)	Postfach	RPC-EPMap	Bin\MSExchangeMailboxAssistants.exe
MSExchangeMailSubmission - RPC (TCP eingehend)	Postfach	Dynamisches RPC	Bin\MSExchangeMailSubmission.exe
MSExchangeMailSubmission - RPCEPMap (TCP eingehend)	Postfach	RPC-EPMap	Bin\MSExchangeMailSubmission.exe
MSExchangeMigration - RPC (TCP eingehend)	Postfach	Dynamisches RPC	Bin\MSExchangeMigration.exe
MSExchangeMigration - RPCEPMap (TCP eingehend)	Postfach	RPC-EPMap	Bin\MSExchangeMigration.exe
MSExchangerepl - Protokollkopierdienst (TCP eingehend)	Postfach	64327 (TCP)	Bin\MSExchangeRepl.exe
MSExchangerepl - RPC (TCP eingehend)	Postfach	Dynamisches RPC	Bin\MSExchangeRepl.exe
MSExchangerepl - RPC-EPMap (TCP eingehend)	Postfach	RPC-EPMap	Bin\MSExchangeRepl.exe
MSExchangeSearch - RPC (TCP eingehend)	Postfach	Dynamisches RPC	Bin\Microsoft.Exchange.Search.ExSearch.exe
MSExchangeThrottling - RPC (TCP eingehend)	Postfach	Dynamisches RPC	Bin\MSExchangeThrottling.exe
MSExchangeThrottling - RPCEPMap (TCP eingehend)	Postfach	RPC-EPMap	Bin\MSExchangeThrottling.exe
MSFTED - RPC (TCP eingehend)	Postfach	Dynamisches RPC	Bin\MSFTED.exe
MSFTED - RPCEPMap (TCP eingehend)	Postfach	RPC-EPMap	Bin\MSFTED.exe
MSExchangeEdgeSync - RPC (TCP eingehend)	Hub-Transport	Dynamisches RPC	Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeEdgeSync - RPCEPMap (TCP eingehend)	Hub-Transport	RPC-EPMap	Bin\Microsoft.Exchange.EdgeSyncSvc.exe
MSExchangeTransportWorker - RPC (TCP eingehend)	Hub-Transport	Dynamisches RPC	Bin\edgetransport.exe
MSExchangeTransportWorker - RPCEPMap (TCP eingehend)	Hub-Transport	RPC-EPMap	Bin\edgetransport.exe
MSExchangeTransportWorker (GFW) (TCP eingehend)	Hub-Transport	25, 587 (TCP)	Beliebig
MSExchangeTransportWorker (TCP eingehend)	Hub-Transport	25, 587 (TCP)	Bin\edgetransport.exe
MSExchangeTransportLogSearch - RPC (TCP eingehend)	Hub-Transport, Edge-Transport, Postfach	Dynamisches RPC	Bin\MSExchangeTransportLogSearch.exe
MSExchangeTransportLogSearch - RPCEPMap (TCP eingehend)	Hub-Transport, Edge-Transport, Postfach	RPC-EPMap	Bin\MSExchangeTransportLogSearch.exe
SESWorker (GFW) (TCP eingehend)	Unified Messaging	Beliebig	Beliebig
SESWorker (TCP eingehend)	Unified Messaging	Beliebig	UnifiedMessaging\SESWorker.exe
UMService (GFW) (TCP eingehend)	Unified Messaging	5060, 5061	Beliebig
UMService (TCP eingehend)	Unified Messaging	5060, 5061	Bin\UMService.exe
UMWorkerProcess (GFW) (TCP eingehend)	Unified Messaging	5065, 5066, 5067, 5068	Beliebig
UMWorkerProcess (TCP eingehend)	Unified Messaging	5065, 5066, 5067, 5068	Bin\UMWorkerProcess.exe
UMWorkerProcess - RPC (TCP eingehend)	Unified Messaging	Dynamisches RPC	Bin\UMWorkerProcess.exe

Hinweise zu den von Exchange 2010-Setup erstellten Windows-Firewallregeln

Auf Servern mit installierten Internetinformationsdiensten (Internet Information Services, IIS) öffnet Windows den HTTP-Port (Port 80, TCP) sowie den HTTPS-Port (Port 443, TCP). Exchange 2010-Setup öffnet diese Ports nicht. Daher werden diese Ports nicht in der vorstehenden Tabelle aufgeführt.
Unter Windows Server 2008 und Windows Server 2008 R2 ermöglicht die Windows-Firewall mit erweiterter Sicherheit die Angabe des Prozesses oder Diensts, für den ein Port geöffnet wird. Dies ist sicherer, da die Verwendung des Ports auf den Prozess oder Dienst beschränkt wird, der in der Regel angegeben wurde. Über Exchange-Setup werden Firewallregeln mit dem angegebenen Prozessnamen erstellt. In einigen Fällen wird aus Kompatibilitätsgründen eine zusätzliche Regel erstellt, die nicht auf den Prozess beschränkt ist. Sie können Regeln, die nicht auf die Prozesse beschränkt sind, deaktivieren oder entfernen und dann die entsprechenden, auf Prozesse beschränkten Regeln beibehalten, wenn Ihre Bereitstellung dies unterstützt. Die Regeln, die nicht auf Prozesse beschränkt sind, sind durch das Wort (GFW) im Regelnamen gekennzeichnet.
Eine Reihe von Exchange-Diensten verwendet Remoteprozeduraufrufe (Remote Procedure Calls, RPCs) für die Kommunikation. Serverprozesse, die RPCs verwenden, kontaktieren die RPC-Endpunktzuordnung zum Empfangen dynamischer Endpunkte und zum Registrieren dieser Endpunkte in der Endpunktzuordnungsdatenbank. RPC-Clients kontaktieren die RPC-Endpunktzuordnung, um die vom Serverprozess verwendeten Endpunkte zu ermitteln. Standardmäßig überwacht die RPC-Endpunktzuordnung Port 135 (TCP). Beim Konfigurieren der Windows-Firewall für einen Prozess mit Verwendung von RPCs erstellt Exchange 2010-Setup zwei Firewallregeln für den Prozess. Eine Regel ermöglicht die Kommunikation mit der RPC-Endpunktzuordnung, die andere Regel ermöglicht die Kommunikation mit dem dynamisch zugeordneten Endpunkt. Weitere Informationen zu RPCs finden Sie unter Funktionsweise von RPC. Weitere Informationen zum Erstellen von Windows-Firewallregeln für dynamisches RPC finden Sie unter Zulassen von eingehendem Netzwerkdatenverkehr, der dynamisches RPC verwendet.