(0) exportieren Drucken
Alle erweitern
Verwandte Hilfethemen
Loading
Keine Ressourcen gefunden
Verwandte Blog-Artikel
Loading
Keine Ressourcen gefunden
Erweitern Minimieren

Exchange-Netzwerkportreferenz

Exchange 2010
 

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

Letztes Änderungsdatum des Themas: 2012-09-25

In diesem Thema finden Sie Informationen zu Ports, zur Authentifizierung und zur Verschlüsselung aller von Microsoft Exchange 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.

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

Microsoft Exchange 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

  • 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.

    noteAnmerkung:
    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 2010 direkte 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 Microsoft Outlook 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 Microsoft Exchange-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.

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

  • 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.

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

noteAnmerkung:
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.

  • 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 Microsoft Exchange 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.

    noteAnmerkung:
    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

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.

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

  • 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.

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 (möglicherweise in englischer Sprache).

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

  • 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 (möglicherweise in englischer Sprache). Weitere Informationen zum Erstellen von Windows-Firewallregeln für dynamisches RPC finden Sie unter Zulassen von eingehendem Netzwerkdatenverkehr, der dynamisches RPC verwendet.

noteAnmerkung:
Sie können die von Exchange 2010-Setup erstellten Windows-Firewallregeln nicht ändern. Sie können darauf basierende benutzerdefinierte Regeln erstellen und diese anschließend deaktivieren oder löschen.

Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 179442 Konfigurieren einer Firewall für Domänen und Vertrauensstellungen.

 © 2010 Microsoft Corporation. Alle Rechte vorbehalten.
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft