TechNet-Foren
MSDN-Foren Internationale Supportlösungen
Support anfordern
Microsoft-Kundensupport
Microsoft Community-Foren
Weitere Versionen
EHLO-Blog
(0) exportieren
Drucken Alle erweitern
TechNet-Bibliothek Office Products Exchange Exchange Server 2010 Sicherheit Sicherheitshandbuch für Exchange 2010 Exchange-Netzwerkportreferenz Zertifikate Verwandte Hilfethemen
Keine Ressourcen gefunden
Verwandte Blog-Artikel Exchange-Netzwerkportreferenz
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. 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 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 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. Anmerkung: 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. 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
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
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 Anmerkung: 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 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. Anmerkung: 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
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 (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
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 (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. Anmerkung: 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?
Nicht genau
Keine ausreichende Tiefe
Weitere Codebeispiele erforderlich (1500 verbleibende Zeichen)
Geerbt
Geschützt