(0) exportieren Drucken
Alle erweitern

Konfigurieren der formularbasierten Authentifizierung für Outlook Web App

Exchange 2010
 

Gilt für: Exchange Server 2010 SP3, Exchange Server 2010 SP2

Letztes Änderungsdatum des Themas: 2010-09-10

Bei der formularbasierten Authentifizierung wird eine Anmeldeseite für Exchange Server 2010 Outlook Web App 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 App-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 App-Sitzung an den Clientzugriffsserver gesendet werden, wird ein verschlüsseltes Cookie erstellt, mit dem die Benutzeraktivität verfolgt wird. Das Cookie wird gelöscht, wenn die Benutzer den Internetbrowser wieder schließen oder auf Abmelden klicken, um sich von der Outlook Web App-Sitzung abzumelden. Benutzername und Kennwort werden nur bei der ersten Benutzeranmeldung an den Clientzugriffsserver gesendet. Nach Abschluss der ersten Anmeldung wird lediglich das Cookie für die Authentifizierung zwischen Clientcomputer und Clientzugriffsserver verwendet.

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

Das 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 App-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 App abzumelden oder den Webbrowser zu schließen, wenn sie Outlook Web App nicht mehr verwenden.

Weitere Informationen zum Konfigurieren von Timeoutwerten für Cookies auf öffentlichen Computern finden Sie unter Festlegen des Timeoutwerts für Cookies auf öffentlichen Computern bei formularbasierter Authentifizierung.

Wenn ein Benutzer auf der Outlook Web App-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 App-Sitzung automatisch beendet wird. Der Standardtimeoutwert für private Anmeldungen beträgt 8 Stunden. Aufgrund der Beziehung zwischen der Wiederverwendungszeit von Verschlüsselungsschlüsseln und dem auf dem Server konfigurierten Timeoutwert kann der tatsächliche Standardtimeoutwert für private Anmeldungen zwischen 8 und 12 Stunden liegen. Weitere Informationen finden Sie unter Informationen zur Verschlüsselung der Benutzeranmeldung auf öffentlichen und privaten Computern. Die Timeoutoption für Cookies auf privaten Computern ist für Outlook Web App-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 Festlegen des Timeoutwerts für Cookies auf privaten Computern bei formularbasierter Authentifizierung.

Zurück zum Seitenanfang

Nachdem eine Outlook Web App-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 2010 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 2010 dies als Aktivität.

    HinweisAnmerkung:
    Eine Interaktion zwischen dem Clientcomputer und dem Server, die vom Clientzugriffsserver automatisch generiert wurde, wird hingegen nicht als Aktivität betrachtet. So werden beispielsweise vom Clientzugriffsserver in einer Outlook Web App-Sitzung generierte neue E-Mail-Benachrichtigungen und Erinnerungen nicht als Aktivität angesehen.
  • In Outlook Web App werden alle Benutzerinteraktionen, einschließlich der Eingabe von Text in eine E-Mail-Nachricht oder Besprechungsanfrage, als Aktivität betrachtet. In der Light-Version von Outlook Web App werden alle Benutzeraktivitäten mit Ausnahme der Texteingabe als Aktivität betrachtet.

Statt eines Popupfensters wird bei der formularbasierten Authentifizierung eine Anmeldeseite für Outlook Web App erstellt. Die Anmeldeaufforderung für die formularbasierte Authentifzierung 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, bleibt unverändert. So können Sie die Anmeldeseite für die formularbasierte Authentifizierung beispielsweise so konfigurieren, dass Benutzer aufgefordert werden, ihre Anmeldeinformationen im Format "Domäne\Benutzername" einzugeben. Ein Benutzer kann jedoch auch seinen Benutzerprinzipalnamen (UPN) angeben, um sich erfolgreich anzumelden.

Die folgenden Anmeldeaufforderungen können für die formularbasierte Authentifizierung auf der Outlook Web App-Anmeldeseite verwendet werden. Wählen Sie die Anmeldeaufforderung aus, die für die Benutzer am einfachsten zu verstehen und zu verwenden ist.

  • Vollständige Domäne   Dies ist der Domänen- und Benutzername des Benutzers im Format "Domäne\Benutzername". Beispiel: "Contoso\Kweku".

  • Prinzipalname Dies ist der UPN (User Principal Name). 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 App zugreifen, indem sie ihre primäre E-Mail-Adresse oder ihren UPN eingeben.

  • Benutzername Nur der Benutzername. Der Domänenname ist nicht enthalten. Beispiel: "Kweku". Dieses Anmeldeformat kann nur verwendet werden, wenn der Domänenname konfiguriert wurde.

    HinweisAnmerkung:
    Bei Bedarf können Sie das Format ändern, mit dem sich der Benutzer bei Outlook Web App anmelden muss, indem Sie Active Directory 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 App.

Zurück zum Seitenanfang

Bei der Verschlüsselung der Anmeldeinformationen von Benutzern für öffentliche und private Outlook Web App-Anmeldungen wird eine Gruppe von sechs HMACs (Hashed Message Authentication Codes) verwendet. 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 verwendet wird, durchläuft der Clientzugriffsserver mit einer vorgegebenen Rate nacheinander drei verschiedene Schlüssel für jeden Anmeldetyp (öffentlich und privat). Dies wird als Wiederverwendungszeit bezeichnet. Die Wiederverwendungszeit für einen Schlüssel ist die Hälfte des für die Anmeldung konfigurierten Zeitlimits. Wird das Zeitlimit für die öffentliche Anmeldung beispielsweise auf 15 Minuten gesetzt, hat der öffentliche Schlüssel eine Wiederverwendungszeit von 7,5 Minuten.

Die sechs Anmeldeschlüssel werden vom Clientzugriffsserver beim Start der virtuellen Outlook Web App-Verzeichnisse erstellt. Drei der Schlüssel werden für Anmeldungen auf öffentlichen Computern verwendet, während die anderen drei für Anmeldungen auf privaten Computern verwendet werden. Wenn sich ein Benutzer anmeldet, wird der aktuelle Schlüssel für den betreffenden Anmeldetyp 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 für jeden Anmeldetyp stets drei Schlüssel bereit: den aktuellen Schlüssel und die beiden zuletzt verwendeten Schlüssel. Die Wiederverwendung der Schlüssel wird so lange fortgesetzt, wie Outlook Web App auf dem Clientzugriffsserver aktiv ist. 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 das konfigurierte Timeout beispielsweise 30 Minuten beträgt, kann das 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 privaten Computer.

Der standardmäßige Timeoutwert für Cookies und die Wiederverwendungszeit des Authentifizierungsschlüssels für jeden Benutzeranmeldetyp

Anmelden 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

HinweisAnmerkung:
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.

Zurück zum Seitenanfang

Standardmäßig ist die SSL-Verschlüsselung (Secure Sockets Layer) aktiviert, wenn Sie die Clientzugriffs-Serverrolle installieren. Wird kein SSL verwendet, werden Benutzername und Kennwort bei der ersten Anmeldung im Klartext übertragen. Bei Verwendung von SSL dagegen wird die gesamte Kommunikation zwischen dem Clientcomputer und dem Clientzugriffsserver verschlüsselt, sodass kritische Informationen wie Benutzernamen, Kennwörter und E-Mail-Nachrichten von Dritten nicht eingesehen werden können.

Zurück zum Seitenanfang

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