(0) exportieren Drucken
Alle erweitern
Dieser Artikel wurde noch nicht bewertet - Dieses Thema bewerten.

Datenpfad-Sicherheitsreferenz

 

Gilt für: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007

Letztes Änderungsdatum des Themas: 2009-06-05

In diesem Thema werden Informationen über Ports, Authentifizierung und Verschlüsselung für alle von Microsoft Exchange Server 2007 verwendeten Datenpfade bereitgestellt. Der Abschnitt Anmerkungen im Anschluss an die einzelnen Tabellen verdeutlicht oder definiert nicht standardmäßige Authentifizierungs- oder Verschlüsselungsmethoden.

Exchange 2007 enthält zwei Serverfunktionen, 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 zu oder von anderen Exchange 2007-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 (Transport Layer Security [TLS])

Kerberos

Kerberos

Ja (TLS)

Ja

Hub-Transport-Server zu Edge-Transport-Server

25/TCP (TLS)

Direkte Vertrauensstellung

Direkte Vertrauensstellung

Ja (TLS)

Ja

Edge-Transport-Server zu Hub-Transport-Server

25/TCP (TLS)

Direkte Vertrauensstellung

Direkte Vertrauensstellung

Ja (TLS)

Ja

Edge-Transport-Server zu Edge-Transport-Server

25/TCP (TLS), 389/TCP/UDP und 80/TCP (Zertifikatauthentifizierung)

Anonym, Zertifikat

Anonym, Zertifikat

Ja (TLS)

Ja

Postfachserver an Hub-Transport-Server über den Microsoft Exchange-Mailübergabedienst

135/TCP (RPC)

NTLM. Wenn die beiden Serverfunktionen Hub-Transport und Mailbox auf demselben Server installiert sind, wird Kerberos verwendet.

NTLM/Kerberos

Ja (RPC-Verschlüsselung)

Ja

Hub-Transport- an Postfachserver über MAPI

135/TCP (RPC)

NTLM. Wenn die beiden Serverfunktionen Hub-Transport und Mailbox auf demselben Server installiert sind, wird Kerberos verwendet.

NTLM/Kerberos

Ja (RPC-Verschlüsselung)

Ja

Unified Messaging zu Hub-Transport

25/TCP (TLS)

Kerberos

Kerberos

Ja (TLS)

Ja

Microsoft Exchange-EdgeSync-Dienst

50636/TCP (SSL), 50389/TCP (Kein SSL)

Standardauthentifizierung

Standardauthentifizierung

Ja (LDAPS)

Ja

ADAM-Verzeichnisdienst (Active Directory Application Mode) auf Edge-Transport-Server

50389/TCP (Kein SSL)

NTLM/Kerberos

NTLM/Kerberos

Nein

Nein

Active Directory-Verzeichnisdienstzugriff von 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 (Kerberos-Verschlüsselung)

Ja

Endbenutzer-SMTP-Client (z. B. Outlook Express) zu Hub-Transport

25/TCP (TLS), 587 (TLS)

NTLM/Kerberos

NTLM/Kerberos

Ja (TLS)

Ja

Der gesamte Verkehr zwischen Hub-Transport-Servern wird mithilfe von TLS mit selbstsignierten Zertifikaten, die standardmäßig vom Exchange 2007-Setup installiert werden, verschlüsselt. Der Datenverkehr zwischen Hub-Transport-Servern wird unter Verwendung der Kerberos-Authentifizierung authentifiziert.

Der gesamte Verkehr zwischen Edge-Transport-Servern und Hub-Transport-Servern wird authentifiziert und verschlüsselt. Der zugrundeliegende Mechanismus für Authentifizierung und Verschlüsselung ist gegenseitiges TLS. Statt die X.509-Gültigkeitsprüfung zu verwenden, verwenden Exchange 2007-Benutzer direkte Vertrauensstellungen zum Authentifizieren der Zertifikate. "Direkte Vertrauensstellung" bedeutet, dass die Anwesenheit des Zertifikats in Active Directory oder ADAM die Gültigkeit des Zertifikats bezeugt. Active Directory wird als vertrauenswürdiger Speicherungsmechanismus angesehen. Wenn die direkte Vertrauensstellung verwendet wird, ist es nicht von Bedeutung, ob das Zertifikat selbstsigniert oder von einer Zertifizierungsstelle signiert ist. 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 ADAM mit dem Satz von Hub-Transport-Serverzertifikaten, damit diese vom Edge-Transport-Server überprüft werden können.

Standardmäßig wird der Verkehr zwischen Edge-Transport-Servern in zwei verschiedenen Organisationen verschlüsselt. Exchange 2007-Setup erstellt ein selbstsigniertes Zertifikat, und TLS ist standardmäßig aktiviert. Dadurch kann jedes sendende System die bei Microsoft Exchange eingehende SMTP-Sitzung verschlüsseln. Standardmäßig versucht Exchange 2007, TLS auch für alle Remoteverbindungen zu verwenden.

Die Authentifizierungsmethoden für Verkehr zwischen Hub-Transport-Servern und Postfachserver unterscheiden sich, wenn die Serverfunktionen Hub-Transport und Mailbox auf dem gleichen Computer ausgeführt werden. Bei lokaler Nachrichtenübermittlung wird Kerberos-Authentifizierung verwendet. Bei Remote-Nachrichtenübermittlung wird NTLM-Authentifizierung verwendet.

Exchange 2007 unterstützt außerdem Domänensicherheit. Domänensicherheit bezieht sich auf die Funktionssammlung Exchange 2007 und Microsoft Office Outlook 2007, die eine relativ kostengünstige Alternative zu S/MIME oder anderen Sicherheitslösungen auf Nachrichtenebene darstellt. Der Zweck der Funktion "Domänensicherheit" besteht darin, Administratoren ein Verfahren an die Hand zu geben, um gesicherte Nachrichtenpfade zwischen Domänen über das Internet verwalten zu können. Nachdem diese gesicherten Nachrichtenpfade konfiguriert wurden, werden Nachrichten, die den gesicherten Pfad von einem authentifizierten Absender aus durchlaufen haben, Benutzern in der Benutzeroberfläche von Outlook und Outlook Web Access als "domänengesichert" angezeigt. Weitere Informationen finden Sie unter Planen der Domänensicherheit.

Auf Hub-Transport-Servern und Edge-Transport-Servern werden möglicherweise viele Agents ausgeführt. Im allgemeinen, arbeiten Antispam-Agents auf der Grundlage von Informationen, die für den Computer, auf dem der Agent ausgeführt wird, lokal sind. Daher ist nur wenig Kommunikation mit Remotecomputern erforderlich. Eine Ausnahme stellt jedoch die Empfängerfilterung dar. Diese erfordert Aufrufe von entweder ADAM oder Active Directory. Es stellt das optimale Verfahren dar, Empfängerfilterung auf dem Edge-Transport-Server auszuführen. In diesem Fall befindet sich das ADAM-Verzeichnis auf dem gleichen Computer wie der Edge-Transport-Server, und es ist keine Remotekommunikation erforderlich. Wenn die Empfängerfilterung auf dem Hub-Transport-Server installiert und konfiguriert wurde, greift die Empfängerfilterung auf Active Directory zu.

Der Protokollanalyse-Agent wird vom Absenderzuverlässigkeits-Feature in Exchange 2007 verwendet. 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 anderen Antispamfunktionen verwenden Daten, die ausschließlich auf dem lokalen Computer erfasst, gespeichert und verwendet werden. Häufig werden die Daten, wie etwa Daten zur Aggregation sicherer Listen oder Empfängerdaten für die Empfängerfilterung, mithilfe des Microsoft Exchange-EdgeSync-Diensts per Push in das lokale ADAM-Verzeichnis hochgeladen.

Journal- und Nachrichtenklassifizierung werden auf Hub-Transport-Servern ausgeführt und basieren für ihre Funktion auf Active Directory-Daten.

Im Kontext der Serverfunktion Mailbox hängt es vom Benutzer- oder Prozesskontext, unter dem der Verbraucher der Exchange-Geschäftslogikschicht ausgeführt wird, ab, ob NTLM oder Kerberos als Authentifizierung verwendet wird. In diesem Kontext kann jede Anwendung oder jeder Prozess, der die Exchange-Geschäftslogikschicht verwendet, den Verbraucher darstellen. In vielen der Zellen unter "Standardauthentifizierung" in der Tabelle "Postfachserver-Datenpfade" in diesem Abschnitt ist die Authentifizierung als "NTLM/Kerberos" aufgeführt.

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, weil der Verbraucher durch die Verwendung des Computerkontos Lokales System authentifiziert sein muss, und es muss eine beiderseitige Vertrauensstellung bestehen.

Wenn der Verbraucher der Exchange-Geschäftslogikschicht nicht als Lokales System ausgeführt wird, ist die verwendete Authentifizierungsmethode NTLM. Wenn z. B. ein Administrator ein Cmdlet der Exchange-Verwaltungsshell ausführt, 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?

Protokollversand bei fortlaufender Clusterreplikation (Cluster Continuous Replication) und fortlaufender Standbyreplikation (Standby Continuous Replication, SCR)

445/TCP

NTLM/Kerberos

NTLM/Kerberos

Ja (IPsec)

Nein

CCR- und SCR-Seeding

Frei wählbarer Port

NTLM/Kerberos

NTLM/Kerberos

Ja (IPsec)

Nein

Sicherung per Volumeschattenkopie-Dienst (VSS)

Lokaler Nachrichtenblock (SMB)

NTLM/Kerberos

NTLM/Kerberos

Nein

Nein

Legacysicherung

Frei wählbarer Port

NTLM/Kerberos

NTLM/Kerberos

Ja (IPsec)

Nein

Clustering

135/TCP (RPC) Siehe "Anmerkungen zu Postfachservern" am Ende dieser Tabelle.

NTLM/Kerberos

NTLM/Kerberos

Ja (IPsec)

Nein

MAPI-Zugriff

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Ja (RPC-Verschlüsselung)

Ja

Postfach-Assistenten

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Nein

Nein

Verfügbarkeits-Webdienst (ClientAccess zu Mailbox)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Ja (RPC-Verschlüsselung)

Ja

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 (Kerberos-Verschlüsselung)

Ja

Inhaltsindizierung

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Ja (RPC-Verschlüsselung)

Ja

Administrator-Remotezugriff (Remoteregistrierung)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Ja (IPsec)

Nein

Administrator-Remotezugriff (SMB/Datei)

445/TCP (SMB)

NTLM/Kerberos

NTLM/Kerberos

Ja (IPsec)

Nein

RPC-Zugriff für den Empfängeraktualisierungsdienst

135/TCP (RPC)

Kerberos

Kerberos

Ja (RPC-Verschlüsselung)

Ja

Zugriff auf den Microsoft Exchange Active Directory-Topologiedienst

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Ja (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 (Kerberos-Verschlüsselung)

Ja

Legacy-Zugriff auf den Microsoft Exchange-Systemaufsichtsdienst (als MAPI-Client)

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Ja (RPC-Verschlüsselung)

Ja

Zugriff auf das Offlineadressbuch (OAB)Active Directory

135/TCP (RPC)

Kerberos

Kerberos

Ja (RPC-Verschlüsselung)

Ja

Empfängeraktualisierung 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 (Kerberos-Verschlüsselung)

Ja

DSAccess 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 (Kerberos-Verschlüsselung)

Ja

Zugriff von Outlook auf das Offlineadressbuch (OAB)

noteHinweis:
Gilt für Outlook 2003 oder frühere Versionen. Diese Einstellung gilt auch für Office Outlook 2007-Clients, wenn die Webverteilung des Offlineadressbuchfeatures nicht aktiviert ist.

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Ja (RPC-Verschlüsselung)

Ja

WebDav

80/TCP, 443/TCP (SSL)

Standardauthentifizierung, NTLM, Aushandeln

Standardauthentifizierung, NTLM, Aushandeln

Ja (HTTPS)

Ja

Wenn "Aushandeln" aufgelistet ist, wird für die HTTP-Authentifizierung zuerst Kerberos und anschließend NTLM probiert.

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. Der Zweck dieses Austauschs ist, zu bestimmen, ob aktuell alle Knoten ordnungsgemäß ausgeführt werden, und die Überwachung des Status der Netzwerkverbindungen.

Zwar können WebDav-Anwendungen oder Clients Verbindungen mit dem Postfachserver mithilfe von 80/TCP oder 443/TCP herstellen, in den meisten Fällen stellt die Anwendung oder stellen Clients Verbindungen jedoch zum Clientzugriffsserver her. Anschließend stellt der Clientzugriffsserver eine Verbindung mit dem Postfachserver über 80/TCP oder 443/TCP her.

Der in der Tabelle "Postfachserver-Datenpfade" in diesem Abschnitt aufgelistete Clusterdatenpfad verwendet dynamisches RPC (TCP) zum Kommunizieren von Clusterstatus und Aktivität unter den verschiedenen Clusterknoten. Der Clusterdienst (ClusSvc.exe) verwendet außerdem UDP/3343 und zufällig zugewiesene hohe TCP-Ports für die Kommunikation unter den Clusterknoten.

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

Die folgende Tabelle enthält Informationen über Port, 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?

AutoErmittlungsdienst

80/TCP, 443/TCP (SSL)

Standard-/Integrierte Windows-Authentifizierung (Aushandeln)

Standardauthentifizierung, Digest, NTLM, Aushandeln (Kerberos)

Ja (HTTPS)

Ja

Verfügbarkeitsdienst

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM, Kerberos

Ja (HTTPS)

Ja

Outlook Web Access

80/TCP, 443/TCP (SSL)

Formularbasierte Authentifizierung

Standardauthentifizierung, Digest, Formularbasierte Authentifizierung, NTLM (nur Version 2), Kerberos, Zertifikat

Ja (HTTPS)

Ja mithilfe eines selbstsignierten Zertifikats

POP3

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

Standardauthentifizierung, NTLM, Kerberos

Standardauthentifizierung, NTLM, Kerberos

Ja (SSL, TLS)

Ja

IMAP4

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

Standardauthentifizierung, NTLM, Kerberos

Standardauthentifizierung, NTLM, Kerberos

Ja (SSL, TLS)

Ja

Outlook Anywhere (früher als "RPC über HTTP" bezeichnet).

80/TCP, 443/TCP (SSL)

Standardauthentifizierung

Standardauthentifizierung oder NTLM

Ja (HTTPS)

Ja

Exchange ActiveSync-Anwendung

80/TCP, 443/TCP (SSL)

Standardauthentifizierung

Standardauthentifizierung, Zertifikat

Ja (HTTPS)

Ja

Clientzugriffsserver zu Unified Messaging-Server

5060/TCP, 5061/TCP, 5062/TCP, ein dynamischer Port

Nach IP-Adresse

Nach IP-Adresse

Ja (Session Initiation Protocol [SIP] über TLS)

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

Nein

Clientzugriffsserver auf Exchange 2007-Postfachserver

RPC. Siehe "Anmerkungen zu Clientzugriffsservern" nach dieser Tabelle.

Kerberos

NTLM/Kerberos

Ja (RPC-Verschlüsselung)

Ja

Clientzugriffsserver zu Clientzugriffsserver (Exchange ActiveSync)

80/TCP, 443/TCP (SSL)

Kerberos

Kerberos, Zertifikat

Ja (HTTPS)

Ja mithilfe eines selbstsignierten Zertifikats

Clientzugriffsserver zu Clientzugriffsserver (Outlook Web Access)

80/TCP, 443/TCP (SSL)

Kerberos

Kerberos

Ja (HTTPS)

Ja

WebDAV

80/TCP, 443/TCP (SSL)

HTTP-Standardauthentifizierung oder formularbasierte Outlook Web Access-Authentifizierung

Standardauthentifizierung, formularbasierte Outlook Web Access-Authentifizierung

Ja (HTTPS)

Ja

Zugriff von Outlook auf das Offlineadressbuch (OAB)

noteHinweis:
Gilt für Office Outlook 2007-Clients, wenn die Webverteilung des Offlineadressbuchfeatures nicht aktiviert ist.

80/TCP, 443/TCP (SSL)

NTLM/Kerberos

NTLM/Kerberos

Ja (HTTPS)

Nein

Die Clientzugriffsserver kommunizieren mit dem Postfachserver mithilfe zahlreicher Ports. Mit einigen Ausnahmen werden diese Ports vom RPC-Dienst (Remote Procedure Call, Remoteprozeduraufruf) bestimmt und sind nicht fest. Es ist möglich, den Bereich der dynamischen Ports anzugeben, die vom RPC-Dienst verwendet werden. Weitere Informationen zum Einschränken des Bereichs dynamischer Ports, die vom RPC-Dienst verwendet werden, finden Sie im Microsoft Knowledge Base-Artikel 154596 Konfigurieren der dynamischen RPC-Portzuweisung für Firewall-Einsatz.

importantWichtig:
Es werden keine Konfigurationen unterstützt, in denen eine Firewall zwischen den Clientzugriffsservern und den Postfachservern hinzugefügt wird, die sich am gleichen Active Directory-Standort befinden.
importantWichtig:
Es werden keine Konfigurationen unterstützt, in denen ein Clientzugriffsserver in einem Umkreisnetzwerk installiert ist. Der Clientzugriffsserver muss Mitglied einer Active Directory-Domäne sein, und das Clientzugriffsserver-Computerkonto muss Mitglied der Active Directory-Sicherheitsgruppe Exchange-Server sein. Die Active Directory-Sicherheitsgruppe Exchange-Server besitzt Lese- und Schreibzugriff auf alle Servercomputer mit Exchange in Ihrer Organisation. Die Kommunikation zwischen dem Clientzugriffsserver und den Postfachservern in der Organisation findet mithilfe des RPC-Diensts statt. Aufgrund dieser Voraussetzungen wird die Installation eines Clientzugriffsservers in einem Umkreisnetzwerk nicht unterstützt.

Wenn "Aushandeln" aufgelistet ist, wird für die HTTP-Authentifizierung zuerst Kerberos und anschließend NTLM probiert.

Wenn ein Exchange 2007-Clientzugriffsserver mit einem Postfachserver kommuniziert, auf dem Exchange Server 2003 ausgeführt wird, hat sich als bewährte Methode die Verwendung von Kerberos und die Deaktivierung von NTLM-Authentifizierung und Standardauthentifizierung herausgestellt. Darüber hinaus besteht eine bewährte Methode im Konfigurieren von Outlook Web Access zur Verwendung von formularbasierter Authentifizierung mit einem vertrauenswürdigen Zertifikat. Damit Exchange ActiveSync-Clients über den Exchange 2007-Clientzugriffsserver mit dem Exchange 2003-Back-End-Server kommunizieren können, muss für das virtuelle Verzeichnis Microsoft-Server-ActiveSync auf dem Exchange 2003-Back-End-Server die integrierte Windows-Authentifizierung aktiviert sein. Wenn Sie Exchange-System-Manager auf einem Server mit Exchange 2003 zum Verwalten der Authentifizierung für ein virtuelles Exchange 2003-Verzeichnis verwenden möchten, müssen Sie den Hotfix herunterladen und installieren, auf den im Microsoft Knowledge Base-Artikel 937301 Ereignis-ID 1036 wird auf einem Servercomputer mit Exchange 2007, auf dem die CAS-Rolle ausgeführt wird, protokolliert, wenn mobile Geräte für den Zugriff auf Postfächer auf einem Exchange 2003-Back-End-Server die Verbindung mit dem Servercomputer mit Exchange 2007 herstellen verwiesen wird.

IP-Gateways unterstützen nur zertifikatbasierte Authentifizierung, die MTLS- und IP-basierte Authentifizierung für SIP/TCP-Verbindungen (Session Initiation Protocol) verwendet. IP-Gateways unterstützen weder NTLM- noch 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 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.

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

Unified Messaging-Server-Datenpfade

Datenpfad Erforderliche Ports Standardauthentifizierung Unterstützte Authentifizierung Verschlüsselung unterstützt? Standardmäßig verschlüsselt?

Unified Messaging-Fax

5060/TCP, 5061/TCP, 5062/TCP, ein dynamischer Port

Nach IP-Adresse

Nach IP-Adresse

SIP über TLS, das Medium wird jedoch nicht verschlüsselt

Ja für SIP

Unified Messaging-Telefoninteraktion (PBX)

5060/TCP, 5061/TCP, 5062/TCP, ein dynamischer Port

Nach IP-Adresse

Nach IP-Adresse

SIP über TLS, das Medium wird jedoch nicht verschlüsselt

Ja für SIP

Unified Messaging-Webdienst

80/TCP, 443/TCP (SSL)

Integrierte Windows-Authentifizierung (Aushandeln)

Standardauthentifizierung, Digest, NTLM, Aushandeln (Kerberos)

Ja (SSL)

Ja

Unified Messaging zu Hub-Transport

25/TCP (SSL)

Kerberos

Kerberos

Ja (TLS)

Ja

Unified Messaging-Server zu Postfachserver

135/TCP (RPC)

NTLM/Kerberos

NTLM/Kerberos

Ja (RPC-Verschlüsselung)

Ja

Wenn Sie ein Unified Messaging-IP-Gatewayobjekt (UM) in Active Directory erstellen, müssen Sie die IP-Adresse des physikalischen 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 hinzugefügt, mit denen dem Unified Messaging-Server die Kommunikation erlaubt ist. Wenn der UM-IP-Gateway erstellt wird, wird er einem UM-Wählplan zugeordnet. Das Zuordnen des UM-IP-Gateways zu einem Wählplan ermöglicht den diesem Wählplan zugeordneten Unified Messaging-Servern das Verwenden von IP-basierter Authentifikation 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.

In der ursprünglichen RTM-Version (Release To Manufacturing) von Exchange 2007 kann ein Unified Messaging-Server entweder an Port  5060/TCP (ungesichert) oder an Port  5061/TCP (gesichert) kommunizieren, jedoch nicht an beiden.

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

Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 179442 How to configure a firewall for domains and trusts (englischsprachig).

Um zu gewährleisten, dass Sie die neuesten Informationen lesen, und zusätzliche Exchange Server 2007-Dokumentation zu finden, besuchen Sie das Exchange Server TechCenter.
Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft. Alle Rechte vorbehalten.