(0) exportieren Drucken
Alle erweitern

Authentifizierungsmechanismen für HTTP

 

Letztes Änderungsdatum des Themas: 2005-05-24

Der Front-End-Server führt die Authentifizierung wie folgt durch: entweder er authentifiziert den Benutzer selbst (mit Standard- oder formularbasierter Authentifizierung), oder er leitet die Anfrage anonym an den Back-End-Server weiter. Der Back-End-Server wendet ebenfalls eine dieser beiden Authentifizierungsarten an.

noteAnmerkung:
Auf dem Front-End-Server ist eine anonyme Authentifizierung erforderlich, wenn er in einem Umgebungsnetzwerk positioniert ist und RPCs (Remote Procedure Calls, Remoteprozeduraufrufe) nicht verwenden kann. Die ist kein empfohlenes Szenario, da der Benutzerzugriff vom Front-End-Server nicht geblockt werden kann. Weitere Informationen zur Pass-Through-Authentifizierung finden Sie unter "Pass-Through-Authentifizierung" weiter unten in diesem Thema.
importantWichtig:
Die Verwendung der dualen Authentifizierung wird dringend empfohlen. Bei dieser Authentifizierung werden sowohl Front-End- als auch Back-End-Server zur Authentifizierung von Benutzern konfiguriert. Weitere Informationen finden Sie im Abschnitt "Duale Authentifizierung" weiter unten in diesem Thema.

Die duale Authentifizierung wird standardmäßig mit Front-End- und Back-End-Servern verwendet. Bei der dualen Authentifizierung werden sowohl die Front-End- als auch die Back-End-Server zur Authentifizierung von Benutzern konfiguriert. Konfigurieren Sie sofern möglich die Front-End-Server immer für die Authentifizierung. Wenn die Authentifizierung auf dem Front-End-Server nicht aktiviert werden kann, können sich Benutzer nicht implizit anmelden, und der Lastenausgleich von Anfragen für Öffentliche Ordner kann nicht realisiert werden. Die explizite Anmeldung ist unabhängig von der jeweils konfigurierten Authentifizierung möglich.

noteAnmerkung:
Exchange benötigt IIS zur Authentifizierung von HTTP-Anfragen. IIS verwendet die RPC-Authentifizierung für Verzeichnisserver. Wenn RPCs zwischen dem Front-End-Server und dem Verzeichnisserver nicht erlaubt sind, müssen Sie die Pass-Through-Authentifizierung verwenden. Weitere Informationen zur Aktivierung der Pass-Through-Authentifizierung und den damit verbundenen Risiken finden Sie unter "Pass-Through-Authentifizierung" weiter unten in diesem Thema.

Bei der Pass-Through-Authentifizierung ist der Front-End-Server mit anonymer Authentifizierung konfiguriert und ruft daher keinen Autorisierungsheader beim Benutzer ab. Der Front-End-Server leitet die Anfrage des Benutzers an den Back-End-Server weiter, der den Benutzer zur Authentifizierung auffordert. Die Authentifizierungsanfrage des Back-End-Servers und die Antwort des Benutzers werden unverändert über den Front-End-Server gesendet.

noteAnmerkung:
Bei der Pass-Through-Authentifizierung werden anonyme HTTP-Anfragen direkt an den Back-End-Server geleitet und authentifiziert. Die Pass-Through-Authentifizierung sollte nur in absolut dringenden Fällen verwendet werden. Die empfohlene Strategie ist die Platzierung einer erweiterten Firewall im Umgebungsnetzwerk mit dem Front-End-Server hinter der internen Firewall, so dass er uneingeschränkten RPC-Zugriff auf das interne Netzwerk hat. Wenn Sie den Front-End-Server im Umgebungsnetzwerk platzieren möchten, ist es möglicherweise sicherer, RPCs anstelle von anonymen Anfragen zur Kontaktierung von Back-End-Servern zu erlauben, da mit der Pass-Through-Authentifizierung gültige oder ungültige Anfragen aus beliebigen Quellen an Ihre Back-End-Server weitergeleitet werden können. Weitere Informationen finden Sie unter Szenarien für die Bereitstellung einer Front-End- und Back-End-Topologie.

Bei Verwendung der Pass-Through-Authentifizierung kann der Front-End-Server kein Lastenausgleich für Öffentliche Ordner-Anfragen durchführen, da er nicht über das Authentifizierungstoken zur Durchführung eines Hash-Algoritmus verfügt. Weiterhin können sich Benutzer nicht implizit anmelden. Benutzer müssen einen vollständigen URL mit ihrem Benutzernamen eingeben, um sich anzumelden.

Für Ihre Front-End- und Back-End-Serverarchitektur stehen je nach verwendeter Exchange-Version verschiedene Authentifizierungsmethoden zur Verfügung. Zudem bietet die Authentifizierung zwischen dem Client und dem Front-End-Server im Gegensatz zur Authentifizierung zwischen Front-End- und Back-End-Servern verschiedene Optionen. In den folgenden Abschnitten werden die beiden Authentifizierungsmethoden näher erläutert.

noteAnmerkung:
Front-End-Server bieten keine Unterstützung für die integrierte Windows-Authentifizierung (NTLM- und Kerberos-Authentifizierung) oder die HTTP 1.1 Digest-Authentifizierung.

Bei der Standardauthentifizierung handelt es sich um einen einfachen durch die HTTP-Spezifikation festgelegten Authentifizierungsmechanismus, der den Benutzernamen und das Kennwort des Benutzers vor dem Senden an den Server schwach kodiert. Für einen optimalen Kennwortschutz in einer Front-End- und Back-End-Topologie sollten Sie die SSL-Verschlüsselung zwischen dem Client und dem Front-End-Server verwenden.

noteAnmerkung:
Standardauthentifizierung wird von Exchange 2000 Server und Exchange Server 2003 unterstützt.

Die Standardauthentifizierung bietet keine Unterstützung für die Einzelanmeldung. Einzelanmeldung findet statt, wenn sich ein Benutzer an einem Computer unter Windows anmeldet, sich für die Domäne authentifiziert und anschließend auf alle Ressourcen und Anwendungen in der Domäne zugreifen kann, ohne seine Anmeldeinformationen erneut einzugeben. Microsoft Internet Explorer Versionen 4.0 und höher unterstützen die Einzelanmeldung für Webanwendungen, einschließlich Outlook Web Access, wenn auf dem Server, auf den zugegriffen wird, die integrierte Windows-Authentifizierung aktiviert ist. Da Front-End-Server für den Zugriff auf HTTP-Anwendungen keine Unterstützung für die integrierte Windows-Authentifizierung bieten, fordert der Front-End-Server immer zur Authentifizierung und zur erneuten Eingabe von Anmeldeinformationen auf, auch wenn diese bei der Anmeldung an Windows bereits eingegeben wurden. In einer Browsersitzung müssen Benutzer jedoch nur einmal ihre Anmeldeinformationen eingeben, da diese während der Sitzung gespeichert werden.

importantWichtig:
Achten Sie bei Verwendung eines Kiosk darauf, dass das Zwischenspeichern von Anmeldeinformationen ein Sicherheitsrisiko darstellt, wenn Sie den Browser nicht schließen können und ihn zwischen Sitzungen schließen. Dieses Risiko tritt auf, da die Benutzeranmeldeinformationen im Cache verbleiben, wenn der nächste Benutzer auf den Kiosk zugreift. Stellen Sie zur Aktivierung von Outlook Web Access im Kioskmodus sicher, dass Sie den Browser zwischen Sitzungen schließen und den Browserprozess beenden können. Verwenden Sie andernfalls ein Drittanbieterprodukt mit Zweifaktor-Authentifizierung, bei der der Benutzer ein physikalisches Token mit einem Kennwort zur Verwendung von Outlook Web Access im Kiosk angeben muss.

noteAnmerkung:
Die formularbasierte Authentifizierung wird nur in Exchange Server 2003 unterstützt. Sie können jedoch einen Front-End-Server unter Exchange Server 2003 mit einem Back-End-Server unter Exchange Server 2000 verwenden, um die Vorteile der formularbasierten Authentifizierung zu nutzen.

Die formularbasierte Authentifizierung verwendet ein Cookie, um den Benutzer nach der ersten Anmeldung zu identifizieren. Durch die Verfolgung dieser Cookie-Verwendung kann Exchange inaktive Sitzungen beenden. Vergleichbar mit der Standardauthentifizierung werden der anfänglich eingegebene Benutzername und das Kennwort jedoch nach wie vor in Klartext übertragen. Aus diesem Grund ist die Verwendung von SSL-Verschlüsselung mit formularbasierter Authentifizierung erforderlich. Weitere Informationen zur Konfiguration der formularbasierten Authentifizierung finden Sie im Abschnitt "Konfigurieren von formularbasierter Authentifizierung für Exchange Server 2003" in Konfigurieren eines Front-End-Servers als Standarddomäne.

Der Front-End-Server muss die Benutzerinformationen mit den Webanfragen an den Back-End-Server senden, damit der Back-End-Server Zugriff auf die Daten gewähren kann.

Exchange 2003-Front-End-Server verwenden Kerberos-Authentifizierung zum Sichern von Benutzeranmeldeinformationen zwischen Front-End- und Back-End-Servern. Wenn die Kerberos-Authentifizierung fehlschlägt, wird ein Warnereignis protokolliert, und der Front-End-Server schaltet auf die Verwendung von NTLM um. Wenn NTLM fehlschlägt, wird ein Fehler protokolliert und auf die Standardauthentifizierung umgeschaltet.

Um dem Front-End-Server die Verwendung der integrierten Authentifizierung zu ermöglichen, ist die Konfiguration der integrierten Authentifizierung auf den virtuellen Back-End-Servern erforderlich (Standardkonfiguration).

noteAnmerkung:
Sowohl Exchange 2003- als auch Exchange 2000-Back-End-Server unterstützen die integrierte Authentifizierung von einem Exchange 2003-Front-End-Servers.

Der Front-End-Server leitet die Anmeldeinformationen der Standardauthentifizierung über Proxy an die Back-End-Server weiter. Zum Sichern dieser Informationen wird die Verwendung von IPSec zwischen den Front-End- und Back-End-Servern dringend empfohlen.

noteAnmerkung:
Standardauthentifizierung zwischen den Front-End- und Back-End-Server wird von Exchange 2000- und Exchange 2003-Front-End-Servern unterstützt.

Bei der Authentifizierung an einem Front-End-Server muss der Benutzer standardmäßig seinen Benutzernamen in folgendem Format eingeben: domäne\benutzername. Sie können einen Front-End-Server als Standarddomäne konfigurieren, damit sich Benutzer ihre Domäne nicht merken müssen.

Eine weitere Authentifizierungsoption ist die Konfiguration eines Benutzerprinzipalnamens (User Principal Name, UPN) für Benutzer. Normalerweise entspricht der Prinzipalname eines Benutzers seiner E-Mail-Adresse. Mit dieser Option können Benutzer ihre UPN/E-Mail-Adresse als ihren Benutzernamen eingeben. Weitere Informationen finden Sie unter Konfigurieren von Exchange-Front-End-Servern.

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