Authentifizierung und Sicherheit bei RPC über HTTP

Artikel
10/25/2013

Letztes Änderungsdatum des Themas: 2005-05-18

Die Verwendung von RPC über HTTP bietet folgende Authentifizierungs- und Sicherheitsvorteile:

Sie brauchen außer den bereits für Microsoft® Office Outlook® Web Access, Microsoft Exchange ActiveSync® oder Outlook Mobile Access zugelassenen Anschlüssen müssen keine weiteren Internetanschlüsse zugelassen werden.
Sie müssen Secure Sockets Layer (SSL) verwenden.
Outlook muss authentifizierte Anfragen senden.
Sowohl der RPC-Proxyserver als auch der Exchange-Server authentifizieren Outlook-Anfragen, die RPC über HTTP verwenden.
Die Endpunktzuordnung wird nicht angezeigt.
Clientcomputer können nur auf festgelegte Exchange-Dienste auf bestimmten Exchange-Servern zugreifen.

HTTP-Authentifizierung

IIS (Internet Information Services) auf dem RPC-Proxyserver steuert die HTTP-Sitzungsauthentifizierung. Beim Konfigurieren des RPC-Proxyservers müssen Sie das virtuelle RPC-Verzeichnis so einrichten, dass entweder Standardauthentifizierung oder NTLM-Authentifizierung oder beides verwendet wird. Abhängig vom konfigurierten Outlook-Profil kann Outlook entweder Standardauthentifizierung oder NTLM-Authentifizierung für die HTTP-Sitzung verwenden. Der RPC-Proxyserver Internet Server API (ISAPI) akzeptiert keine Verbindungen mit anonymer Authentifizierung.

Anmerkung:
Wenn Sie die Konfiguration von RPC über HTTP mit dem Exchange-System-Manager in Exchange Server 2003 Server Pack 1 (SP1) durchführen, konfiguriert dieser automatisch die Authentifizierungseinstellungen auf dem virtuellen RPC-Verzeichnis.

Anmerkung:
Die NTLM-Authentifizierung wird auch als integrierte Windows-Authentifizierung bezeichnet.

Der Authentifizierungsmechanismus, den Sie in Ihrem Outlook-Profil konfigurieren, wird nur für die HTTP-Sitzung auf dem RPC-Proxyserver verwendet. Als Authentifizierungsmechanismus zwischen Outlook und dem Exchange-Server wird immer NTLM verwendet, wenn Outlook auf den Exchange-Server mit RPC über HTTP zugreift. Bei HTTP-Sitzungen auf dem RPC-Proxyserver sollten Sie unbedingt die SSL-Verschlüsselung verwenden, insbesondere wenn Sie für die HTTP-Sitzung die Standardauthentifizierung verwenden. Mit dieser Verschlüsselung verhindern Sie, dass Ihr Benutzername und Kennwort unverschlüsselt gesendet werden. In Outlook ist die Verwendung der Standardauthentifizierung nicht zulässig, wenn die Verbindung mit Ihrem RPC-Proxyserver ohne SSL-Verschlüsselung erfolgt.

Wenn Ihre Firewall HTTP-Datenverkehr überprüft und modifiziert, müssen Sie unter Umständen statt der NTLM-Authentifizierung die Standardauthentifizierung verwenden. Die NTLM-Authentifizierung schlägt fehl, wenn Ihr RPC-Proxyserver die Authentifizierungsinformationen als nicht vertrauenswürdig einstuft. Ihre Firewall kann beispielsweise die Internet-Sitzung beenden und eine neue Sitzung zum RPC-Proxyserver einrichten, statt die HTTPS (SSL)-Sitzung ohne Modifikation an den Exchange-Server weiterzuleiten. Dieser Prozess wird auch als Reverse-Proxy- oder Webpublishing-Vorgang bezeichnet. Bestimmte Firewalls wie Microsoft ISA Server 2004 (Internet Security and Acceleration) dazu in der Lage und können dennoch die NTLM-Authentifizierung gewährleisten.

Anmerkung:
ISA Server 2000 kann keine Reverse-Proxy- oder Webpublishing-Funktion auf die Sitzung anwenden und lässt weiterhin die NTLM-Authentifizierung zu.

Die Standardauthentifizierung wird nicht durch Reverse-Proxy oder Webpublishing beeinflusst und arbeitet unabhängig von Firewalls. Wenn Sie die Standardauthentifizierung verwenden, müssen Sie jedoch bei jedem Start einer Outlook-Sitzung Ihre Domäne, den Benutzernamen und das Kennwort eingeben.

Standardauthentifizierung und NTLM-Authentifizierung

In der folgenden Tabelle werden die Unterschiede zwischen Standard- und NTLM-Authentifizierung dargestellt.

Standardauthentifizierung	NTLM-Authentifizierung
Der Clientcomputer sendet Benutzername und Kennwort unverschlüsselt. Bei der Standardauthentifizierung sollte immer SSL verwendet werden. In Outlook kann die Standardauthentifizierung nur bei gleichzeitiger SSL-Aktivierung ausgewählt werden. Der RPC-Proxyserver benötigt ebenfalls SSL.	Der Clientcomputer sendet eine Anmeldeanfrage an den Server. Der Server antwortet dem Clientcomputer mit einem zufällig generierten "Token" bzw. einer Anfrage. Der Clientcomputer versieht das kryptografisch geschützte Kennwort des momentan angemeldeten Benutzers mit einem Anforderungs-Hash und sendet die entsprechende Antwort an den Server. Der Server empfängt die Antwort mit dem Anforderungs-Hash und vergleicht diese mit der Antwort, die ihm als korrekt bekannt ist. (Der Server nimmt eine Kopie des erzeugten Tokens und vergleicht dessen Hash mit dem des Benutzerkennworts aus seiner eigenen Benutzerkontodatenbank.) Wenn die empfangene Antwort der erwarteten Antwort entspricht, wird der Benutzer auf dem Host erfolgreich authentifiziert.
Die Standardauthentifizierung funktioniert bei Reverse-Proxy-Firewalls.	Die NTLM-Authentifizierung funktioniert unter Umständen bei einigen Reverse-Proxy-Firewalls nicht. Wenn die Firewall den Datenverkehr prüft und modifiziert, wird die NTLM-Authentifizierung möglicherweise ungültig.
Bei der Standardauthentifizierung muss der Benutzer eine Domäne, einen Benutzernamen und ein Kennwort angeben.	NTLM kann die aktuellen Anmeldeinformationen des Microsoft Windows®-Betriebssystems verwenden.

Der Clientcomputer sendet Benutzername und Kennwort unverschlüsselt.

Bei der Standardauthentifizierung sollte immer SSL verwendet werden.

In Outlook kann die Standardauthentifizierung nur bei gleichzeitiger SSL-Aktivierung ausgewählt werden.

Der RPC-Proxyserver benötigt ebenfalls SSL.

Der Clientcomputer sendet eine Anmeldeanfrage an den Server.

Der Server antwortet dem Clientcomputer mit einem zufällig generierten "Token" bzw. einer Anfrage.

Der Clientcomputer versieht das kryptografisch geschützte Kennwort des momentan angemeldeten Benutzers mit einem Anforderungs-Hash und sendet die entsprechende Antwort an den Server.

Der Server empfängt die Antwort mit dem Anforderungs-Hash und vergleicht diese mit der Antwort, die ihm als korrekt bekannt ist. (Der Server nimmt eine Kopie des erzeugten Tokens und vergleicht dessen Hash mit dem des Benutzerkennworts aus seiner eigenen Benutzerkontodatenbank.)

Wenn die empfangene Antwort der erwarteten Antwort entspricht, wird der Benutzer auf dem Host erfolgreich authentifiziert.

Die Standardauthentifizierung funktioniert bei Reverse-Proxy-Firewalls.

Die NTLM-Authentifizierung funktioniert unter Umständen bei einigen Reverse-Proxy-Firewalls nicht.

Wenn die Firewall den Datenverkehr prüft und modifiziert, wird die NTLM-Authentifizierung möglicherweise ungültig.

Bei der Standardauthentifizierung muss der Benutzer eine Domäne, einen Benutzernamen und ein Kennwort angeben.

NTLM kann die aktuellen Anmeldeinformationen des Microsoft Windows®-Betriebssystems verwenden.

RPC über HTTP-Anforderungen zur Verwendung der aktuellen Anmeldeinformationen des Windows-Betriebssystems

Damit bei RPC über HTTP die aktuellen Anmeldeinformationen des Windows-Betriebssystems verwendet werden, müssen folgende Anforderungen erfüllt sein:

Der Benutzer muss sich auf dem Clientcomputer mit den korrekten Domänenanmeldeinformationen anmelden.
Der Benutzer wählt im Outlook-Profil die NTLM-Authentifizierung aus.
Die Firewall lässt NTLM-Authentifizierung zu. Dies kann vorkommen, wenn die Firewall gerade die SSL-Sitzung an den Exchange-Server ohne Modifizierung (Anschlussfilter) übergibt, oder es sich bei der Firewall um eine erweiterte Firewall wie ISA Server 2004 handelt. ISA Server 2004 kann das Reverse-Proxy- oder Webpublishing-Verfahren auf den Exchange-Server anwenden und weiterhin die NTLM-Authentifizierung gewährleisten.
Der Benutzer sendet bei der Verbindung die NTLM-Authentifizierungsinformationen automatisch. Dies geschieht, wenn eine der folgenden Bedingungen zutrifft:
- Sie konfigurieren Outlook so, dass die gegenseitige Authentifizierung über SSL erfolgt. Diese Methode wird empfohlen.
- Auf dem Clientcomputer wird LmCompatibilityLevel auf 2 oder 3 gesetzt.

Weitere Informationen zum Festlegen von LmCompatibilityLevel finden Sie im Microsoft Knowledge Base-Artikel 820281 mit Informationen zur Angabe der Windows-Anmeldeinformationen beim Verbinden mit Exchange Server 2003 mithilfe des Outlook 2003-Features "RPC über HTTP" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=820281).

RPC-Authentifizierung

Bei den vom Exchange-Server authentifizierten RPC-Anfragen wird immer die NTLM-Authentifizierung verwendet.

SSL

Der Clientcomputer muss das für SSL verwendete Zertifikat als vertrauenswürdig einstufen. Damit der Clientcomputer das für SSL verwendete Zertifikat als vertrauenswürdig einstuft, müssen folgende Bedingungen erfüllt sein:

Der Name des Zertifikat entspricht der Website, auf die zugegriffen wird.
Das Zertifikat ist nicht abgelaufen.
Der Clientcomputer vertraut der Stelle, die das Zertifikat ausgegeben hat.

Wenn Sie Outlook Web Access, Exchange ActiveSync oder andere Webdienste bereits erfolgreich für die Verwendung Ihres Front-End-Exchange-Servers konfiguriert haben, erfüllt das Zertifikat diese Anforderungen.

Sie können mit Microsoft Internet Explorer das virtuelle RPC-Verzeichnis suchen und prüfen, ob das Zertifikat korrekt ist. Wenn das Zertifikat ungültig ist, gibt Internet Explorer eine Warnung aus.

SSL-Verschiebung

Die SSL-Verschiebung tritt auf, wenn die Firewall vor dem RPC-Proxyserver die SSL-Sitzung abbricht und eine neue Nicht-SSL-Sitzung auf dem Front-End-Server einrichtet. Es wird keine neue SSL-Sitzung erstellt.

Bei Verwendung der SSL-Verschiebung müssen Sie einen Registrierungsschlüssel festlegen, der dem RPC-Proxyserver mitteilt, dass er eine Nicht-SSL-Sitzung zulassen darf. Weitere Informationen zum Festlegen dieses Registrierungsschlüssels finden Sie unter Konfigurieren des RPC-Proxyservers für die SSL-Verschiebung auf separate Server.