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.
Transportserver
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 |
Anmerkungen zu Transportservern
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.
Postfachserver
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) Hinweis 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 |
Anmerkungen zu Postfachservern
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.
Clientzugriffsserver
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) Hinweis 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 |
Anmerkungen zu Clientzugriffsservern
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.
Wichtig
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.
Wichtig
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.
Unified Messaging-Server
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 |
Anmerkungen zu Unified Messaging-Servern
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
Weitere Informationen finden Sie im Microsoft Knowledge Base-Artikel 179442 How to configure a firewall for domains and trusts (englischsprachig).