(0) exportieren Drucken
Alle erweitern

Konfigurieren der formularbasierten Authentifizierung für Outlook Web Access

 

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

Letztes Änderungsdatum des Themas: 2008-11-24

In diesem Thema wird die formularbasierte Authentifizierung für Microsoft Office Outlook Web Access in Microsoft Exchange Server 2007 erläutert. Bei der formularbasierten Authentifizierung wird eine Anmeldeseite für Outlook Web Access bereitgestellt, die ein Cookie zum Speichern der verschlüsselten Anmeldeinformationen eines Benutzers im Internetbrowser verwendet. Durch die Verfolgung der Verwendung dieses Cookies kann auf dem Exchange-Server die Aktivität von Outlook Web Access-Sitzungen auf öffentlichen und privaten Computern überwacht werden. Wenn eine Sitzung zu lange inaktiv ist, blockiert der Server den Zugriff, bis sich der Benutzer erneut authentifiziert.

Wenn der Benutzername und das Kennwort zum ersten Mal zur Authentifizierung einer Outlook Web Access-Sitzung an den Clientzugriffsserver gesendet werden, wird ein verschlüsseltes Cookie erstellt, mit dem die Benutzeraktivität verfolgt wird. Wenn der Benutzer den Internetbrowser schließt oder auf Abmelden klickt, um sich von der Outlook Web Access-Sitzung abzumelden, wird das Cookie gelöscht. Der Benutzername und das Kennwort werden nur bei der erstmaligen Benutzeranmeldung an den Clientzugriffsserver gesendet. Nachdem die erstmalige Anmeldung erfolgt ist, wird für die Authentifizierung zwischen dem Clientcomputer und dem Clientzugriffsserver nur noch das Cookie benötigt.

Wenn ein Benutzer die Option Dies ist ein öffentlicher oder freigegebener Computer auf der Outlook Web Access-Anmeldeseite auswählt, läuft das Cookie standardmäßig automatisch ab, und Benutzer werden abgemeldet, nachdem sie Outlook Web Access 15 Minuten lang nicht mehr verwendet haben.

Der automatische Timeout ist von großem Wert, da so die Benutzerkonten besser vor nicht autorisiertem Zugriff geschützt werden. Um den Sicherheitsanforderungen Ihrer Organisation gerecht zu werden, können Sie die Timeoutwerte für Inaktivität auf dem Exchange-Clientzugriffsserver konfigurieren.

Obwohl auf diese Weise das Risiko eines nicht autorisierten Zugriffs auf ein Outlook Web Access-Konto erheblich gesenkt werden kann, ist diese Gefahr dennoch nicht auszuschließen, wenn eine Sitzung auf einem öffentlichen Computer nicht beendet wird. Fordern Sie die Benutzer daher unbedingt dazu auf, Vorsichtsmaßnahmen zur Vermeidung von Risiken zu ergreifen, indem Sie sie beispielsweise bitten, sich bei Outlook Web Access abzumelden oder den Webbrowser zu schließen, wenn sie Outlook Web Access nicht mehr verwenden.

Weitere Informationen zum Konfigurieren von Timeoutwerten für Cookies auf öffentlichen Computern finden Sie unter Einrichten des Timeout-Werts für Cookies auf öffentlichen Computern bei formularbasierter Authentifizierung.

Wenn ein Benutzer auf der Outlook Web Access-Anmeldeseite die Option Dies ist ein privater Computer auswählt, lässt der Exchange-Server einen längeren Inaktivitätszeitraum zu, bevor die Outlook Web Access-Sitzung automatisch beendet wird. Der Standardtimeoutwert für private Anmeldungen beträgt acht Stunden. Die Timeoutoption für Cookies auf privaten Computern ist für Outlook Web Access-Benutzer vorgesehen, die einen eigenen Computer oder einen Computer in einem Unternehmensnetzwerk nutzen.

Es ist wichtig, Benutzer vor den Risiken zu warnen, die mit der Auswahl der Option Dies ist ein privater Computer verbunden sind. Die Option Dies ist ein privater Computer sollte nur dann verwendet werden, wenn der Benutzer den Computer allein verwendet und wenn der Computer die Sicherheitsrichtlinien Ihrer Organisation erfüllt.

Weitere Informationen zum Konfigurieren von Timeoutwerten für Cookies auf privaten Computern finden Sie unter Einrichten des Timeout-Werts für Cookies auf privaten Computern bei formularbasierter Authentifizierung.

Nachdem eine Outlook Web Access-Sitzung über einen bestimmten Zeitraum hinweg inaktiv war, verfügt der Clientzugriffsserver nicht mehr über den Schlüssel zum Entschlüsseln des Cookies. Dem Benutzer wird der Zugriff verweigert, und es muss eine erneute Authentifizierung durchgeführt werden.

Exchange 2007 verwendet die folgenden Informationen, um zu ermitteln, ob Benutzeraktivität vorliegt:

  • Eine vom Benutzer eingeleitete Interaktion zwischen dem Clientcomputer und dem Clientzugriffsserver wird als Aktivität betrachtet. Wenn ein Benutzer beispielsweise ein Element öffnet, sendet oder speichert, zwischen Ordnern und Modulen wechselt oder die Ansicht des Webbrowserfensters aktualisiert, betrachtet Exchange 2007 dies als Aktivität.
    noteHinweis:
    Eine Interaktion zwischen dem Clientcomputer und dem Server, die automatisch vom Clientzugriffsserver generiert wurde, wird nicht als Aktivität betrachtet. So werden beispielsweise vom Clientzugriffsserver generierte neue E-Mail-Benachrichtigungen und Erinnerungen in einer Outlook Web Access-Sitzung nicht als Aktivität angesehen.
  • In Outlook Web Access Light werden alle Benutzeraktivitäten mit Ausnahme der Texteingabe als Aktivität betrachtet. In Outlook Web Access Premium werden alle Benutzerinteraktionen, einschließlich der Eingabe von Text in eine E-Mail-Nachricht oder Besprechungsanfrage, als Aktivität betrachtet.

Statt eines Popupfensters erstellt die formularbasierte Authentifizierung eine Anmeldeseite für Outlook Web Access. Den Text der Anmeldeaufforderung der formularbasierten Authentifizierung können Sie mithilfe der Exchange-Verwaltungskonsole oder der Exchange-Verwaltungsshell konfigurieren. Durch die vorgenommenen Konfigurationsänderungen wird nur der Text der Anmeldeaufforderung geändert. Das Format, in dem sich der Benutzer anmelden muss, wird hierdurch nicht geändert. Sie können die formularbasierte Authentifizierungsseite beispielsweise so konfigurieren, dass Benutzer aufgefordert werden, ihre Anmeldeinformationen im Format Domäne\Benutzername anzugeben. Ein Benutzer kann jedoch auch seinen Benutzerprinzipalnamen (UPN) angeben, um sich erfolgreich anzumelden.

Die folgenden Arten von Anmeldeaufforderungen können von der formularbasierten Authentifizierung auf der Outlook Web Access-Anmeldeseite verwendet werden. Wählen Sie die Anmeldeaufforderung aus, die für die Benutzer am einfachsten verständlich und nutzbar ist.

  • FullDomain   Dies ist der Domänen- und Benutzername des Benutzers im Format Domäne\Benutzername. Beispiel: "Contoso\Kweku".
  • PrincipalName   Der UPN. Der UPN setzt sich aus zwei Teilen zusammen: dem UPN-Präfix, d. h. dem Namen des Benutzerkontos, und dem UPN-Suffix, d. h. dem DNS-Domänennamen. Das Präfix und das Suffix werden mit dem Zeichen @ miteinander verbunden, sodass sich der vollständige UPN ergibt. Beispiel: Kweku@contoso.com. Benutzer können auf Outlook Web Access zugreifen, indem sie ihre primäre E-Mail-Adresse oder ihre UPN eingeben.
  • UserName   Dies ist nur der Benutzername. Der Domänenname ist nicht enthalten. Beispiel: "Kweku". Dieses Anmeldeformat kann nur dann verwendet werden, wenn der Domänenname konfiguriert wurde.
    noteHinweis:
    Falls notwendig, können Sie das Format ändern, mit dem sich der Benutzer bei Outlook Web Access anmelden muss, indem Sie den Active Directory-Verzeichnisdienst und die Internetinformationsdienste (IIS) konfigurieren. Die Konfiguration des Benutzernamenformats für die Authentifizierung in Active Directory und IIS erfolgt unabhängig von der zuvor erläuterten Anmeldeaufforderung für die formularbasierte Authentifizierung von Outlook Web Access.

An der Verschlüsselung der Anmeldeinformationen von Benutzern für öffentliche und private Outlook Web Access-Anmeldungen ist ein Satz von sechs HMACs (Hashed Message Authentication Codes) beteiligt. Bei HMACs handelt es sich um 160-Bit-Schlüssel, die auf einem Clientzugriffsserver generiert werden. HMACs verbessern die Anmeldesicherheit, indem Hashalgorithmen mit kryptografischen Funktionen kombiniert werden, um die Anmeldeinformationen von Benutzern zu verschlüsseln. Die Verschlüsselung und Entschlüsselung von Cookies erfolgt durch denselben Clientzugriffsserver. Nur der Clientzugriffsserver, der den Authentifizierungsschlüssel generiert hat, verfügt über den Schlüssel zum Entschlüsseln des Cookies.

Wenn die formularbasierte Authentifizierung für Outlook Web Access verwendet wird, durchläuft der Clientzugriffsserver mit einer bestimmten Rate nacheinander drei verschiedene Schlüssel für jeden Anmeldetyp (öffentlich und privat). Dies wird als Wiederverwendungszeit bezeichnet. Die Wiederverwendungszeit eines Schlüssels beträgt die Hälfte des Timeoutwerts für die Anmeldung. Ist der Timeoutwert für die öffentliche Anmeldung beispielsweise auf 15 Minuten festgelegt, beträgt die Wiederverwendungszeit des öffentlichen Schlüssels 7,5 Minuten.

Die sechs Anmeldeschlüssel werden von dem Clientzugriffsserver erstellt, wenn die virtuellen Verzeichnisse von Outlook Web Access gestartet werden. Drei der Schlüssel werden mit Anmeldungen auf öffentlichen Computer verwendet, während die anderen drei mit Anmeldungen auf privaten Computern verwendet werden. Wenn sich ein Benutzer anmeldet, wird der aktuelle Schlüssel des entsprechenden Anmeldetyps verwendet, um die Authentifizierungsinformationen des Benutzers in einem Cookie zu verschlüsseln.

Nach Ablauf der Wiederverwendungszeit fährt der Clientzugriffsserver mit dem nächsten Schlüssel fort. Nachdem alle drei Schlüssel für einen Anmeldetyp verwendet wurden, löscht der Clientzugriffsserver den ältesten Schlüssel und erstellt einen neuen. Der Clientzugriffsserver hält stets drei Schlüssel für jeden Anmeldetyp bereit: den aktuellen Schlüssel und die beiden zuletzt verwendeten Schlüssel. Die Wiederverwendung der Schlüssel wird so lange fortgesetzt, wie Outlook Web Access auf dem Clientzugriffsserver ausgeführt wird. Für alle Benutzer werden dieselben Schlüssel verwendet.

Jedes Cookie, das mit einem aktiven Schlüssel verschlüsselt wurde, wird akzeptiert. Wenn der Clientzugriffsserver eine Benutzeraktivitätsanforderung erhält, wird das Cookie für diese Anforderung durch ein neues Cookie ersetzt, das mithilfe des neuesten Schlüssels verschlüsselt wurde. Eine Benutzersitzung läuft ab, wenn das Cookie für diese Sitzung mit einem älteren Schlüssel verschlüsselt wurde, der verworfen wurde.

Aufgrund der Beziehung zwischen der Wiederverwendungszeit von Verschlüsselungsschlüsseln und dem auf dem Server konfigurierten Benutzertimout, kann der tatsächliche Timeoutzeitraum für einen Benutzer zwischen dem konfigurierten Timeout und dem konfigurierten Timeout zuzüglich der Hälfte dieses Werts liegen. Wenn der konfigurierte Timeout beispielsweise 30 Minuten beträgt, kann der tatsächliche Timeout für eine Benutzersitzung zwischen 30 und 45 Minuten liegen.

Tabelle 1 enthält Informationen zu dem Timeoutwert des Cookies und der Wiederverwendungszeit des Authentifizierungsschlüssels basierend auf einer Benutzeranmeldung auf einem öffentlichen oder einem privaten Computer.

Tabelle 1   Der standardmäßige Timeoutwert für Cookies und die Wiederverwendungzeit des Authentifizierungsschlüssels für jeden Benutzeranmeldungstyp

Anmeldung Timeoutwert für Cookies Wiederverwendungszeit für Authentifizierungsschlüssel bei Verwendung des standardmäßigen Timeoutwerts

Öffentlich

Eine Minute bis 30 Tage. Der Standardwert ist 15 Minuten.

7,5 Minuten

Privat

Eine Minute bis 30 Tage. Der Standardwert ist 8 Stunden.

4 Stunden

noteHinweis:
In der Registrierung können Sie den Timeoutwert für Cookies in Minuten konfigurieren. Die Wiederverwendungszeit des Authentifizierungsschlüssels beträgt mindestens ein Drittel, aber nicht mehr als die Hälfte des Timeoutwerts des Cookies.

Standardmäßig ist die SSL-Verschlüsselung (Secure Sockets Layer) aktiviert, wenn Sie die Serverfunktion ClientAccess installieren. Wird SSL nicht verwendet, werden Benutzername und Kennwort bei der ersten Anmeldung als Klartext gesendet. Bei Verwendung von SSL wird die gesamte Kommunikation zwischen dem Clientcomputer und dem Clientzugriffsserver verschlüsselt. Auf diese Weise können vertrauliche Informationen wie zum Beispiel Benutzernamen, Kennwörter und E-Mail-Nachrichten vor dem Zugriff von Dritten geschützt werden.

Zusammen mit der Serverfunktion ClientAccess wird ein Standard-SSL-Zertifikat erstellt. Dies ist jedoch kein vertrauenswürdiges Zertifikat. Wenn Sie das SSL-Standardzertifikat verwenden, muss dieses vertrauenswürdig sein. Andernfalls wird bei jeden Anmeldung bei Outlook Web Access eine Eingabeaufforderung angezeigt, in der Benutzer gefragt werden, ob sie dem Zertifikat vertrauen. Weitere Informationen zum Verwenden des SSL-Standardzertifikats finden Sie unter Ersetzen des SSL-Standardzertifikats durch ein anderes vertrauenswürdiges Zertifikat.

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