Standortübergreifende automatische Umleitung für OWA in Exchange 2010 SP2

  • Articolo

Veröffentlichung des Originalartikels: 13.12.2011

Bis jetzt haben viele von Ihnen die Artikel über Adressbuchrichtlinien, Änderungen beim Hosting und den Hybridkonfigurations-Assistenten gelesen, aber tief drinnen weiß ich, dass Sie alle gehofft haben, wir würden das meistgesuchte Feature erläutern, das wir in Exchange 2010 SP2 eingeführt haben.

Was das ist? Ja, ich weiß, Tony sagte in seinem Ankündigungsartikel von SP2 bei Windows IT Pro, die neuen Features in SP2 würden keine große Aufregung verursachen und es gäbe nicht viele neue Features in SP2 (Ich glaube, er sprach von „relativer Sparsamkeit“).

Nun, ich bin hier, um die Sache richtig zu stellen. Es gibt ein Killerfeature in Exchange 2010 SP2, das häufig nicht erwähnt wird. Genau – lassen Sie uns über die standortübergreifende automatische Umleitung für Outlook Web App sprechen!

Definitionen

Lassen Sie uns zunächst einige Definitionen durchgehen, damit wir wissen, worüber wir sprechen.

  • Active Directory-Standort mit Internetzugriff Ein Active Directory-Standort, der Clientzugriffsserver (CAS) enthält, deren ExternalURL-Wert entsprechend dem zugeordneten Dienst (wie z. B. OWA) aufgefüllt ist. In der Regel ist dies das primäre Datencenter/der primäre Standort, an dem Exchange 2010 bereitgestellt ist.
  • Regionaler Active Directory-Standort mit Internetzugriff Ein Active Directory-Standort, der CAS enthält, deren ExternalURL-Wert entsprechend dem zugeordneten Dienst (z. B. OWA) aufgefüllt ist.
  • Active Directory-Standort ohne Internetzugriff Ein Active Directory-Standort, der CAS enthält, die nicht über einen dem zugeordneten Dienst entsprechenden ExternalURL-Wert verfügen.
  • Direkte Verbindung Der Vorgang, bei dem der CAS eine RPC-Sitzung mit dem Postfachserver einrichtet, der die Postfachdaten hostet.
  • ProxyDer Vorgang, bei dem ein CAS an einem Active Directory-Standort mit Internetzugriff eingehende Anforderungen an einen CAS an einem Active Directory-Standort ohne Internetzugriff (der sich an demselben Standort befindet wie der Postfachserver, auf den zugegriffen wird) weiterleitet.
  • UmleitungDer Vorgang, bei dem ein CAS mit Internetzugriff an einem Active Directory-Standort den Endbenutzer an einen anderen CAS mit Internetzugriff umleitet, der sich an demselben Standort befindet wie der Postfachserver, auf den zugegriffen wird.
  • Automatische UmleitungDer Vorgang, bei dem ein CAS eine automatische Umleitung zurück zum Browser des Benutzers ausführt und den Browser anweist, eine Verbindung mit einer bestimmten URL herzustellen.
  • Umleitung mit einmaligem Anmelden Der Vorgang, bei dem ein CAS eine automatische Umleitung zurück zum Browser des Benutzers ausführt und den Browser anweist, die Anforderung und die Anmeldeinformationen an einen Ziel-CAS zu senden, sodass die Anmeldung nahtlos erfolgt.

OWA-Verbindungsprozess

Für das Verständnis der Proxy- und Umleitungsszenarien ist es wichtig zu verstehen, welche Mechanismen ablaufen, wenn sich ein Benutzer bei einem Clientzugriffsserver (CAS) für den Zugriff auf OWA authentifiziert, wie dies bereits in Exchange 2010-Versionen vor SP2 geschieht:

  1. Der Benutzer greift mit dem Webbrowser auf die URL von OWA zu.
  2. Der Benutzer gibt Anmeldeinformationen ein.
  3. Der CAS authentifiziert den Benutzer und ruft per Diensterkennungsanforderung die folgenden Informationen ab:
    1. Postfachversion des Benutzers
    2. Speicherort des Postfachs des Benutzers (Active Directory-Standort), falls bekannt
  4. Der CAS sammelt weitere Informationen basierend auf den Postfachinformationen, damit er den richtigen Vorgang ausführen kann:
    1. Handelt es sich um ein lokales Exchange 2010-Postfach, stellt der CAS eine direkte Verbindung her.
    2. Handelt es sich um ein lokales Exchange 2007-Postfach, ruft der CAS die ExternalURL eines Exchange 2007-CAS ab (ist keine definiert, wird die InternalURLverwendet) und führt die automatische Umleitung durch.
    3. Handelt es sich um ein Exchange 2003-Postfach, ruft der CAS Exchange2003URLab und führt eine automatische Umleitung durch.
    4. Ist das Postfach nicht lokal, ruft der CAS die Ziel-ExternalURL (falls definiert) ab und führt eine Umleitung durch oder fungiert als Proxy, wenn am Active Directory-Zielstandort keine ExternalURLs für OWA definiert sind.

OWA-Umleitungstypen in SP1

Geringfügige Änderungen in Exchange 2010 SP1 führten zu drei Typen der Umleitung für OWA im Produkt für die lokale Bereitstellung:

  • Manuelle Umleitung
  • Temporäre manuelle Umleitung
  • Automatische Umleitung für Vorversionen

Manuelle Umleitung

Durch manuelle Umleitung bleibt es Kunden erspart, den gesamten Datenverkehr von einem zentralen Standort zu lenken und umzuleiten, wenn es CAS gibt, die näher am Postfach des Benutzers sind.

Manuelle Umleitungen werden durchgeführt, wenn CAS eine OWA-Anforderung an eine Exchange 2007- oder Exchange 2010-CAS-Infrastruktur umleiten müssen, die sich an einem anderen Active Directory-Standort befindet. Wie erwähnt muss das virtuelle OWA-Zielverzeichnis über eine ExternalURL verfügen, damit eine manuelle Umleitung erfolgt. Den Benutzern wird folgende manuelle Umleitungsmeldung und die ExternalURL des CAS am anderen Active Directory-Standort angezeigt:

1 
Abbildung 1: Manuelle Umleitung, wenn sich das Postfach an einem anderen Active Directory-Standort befindet

 

Temporäre manuelle Umleitung

In SP1 wurde ein weiterer Umleitungstyp für OWA hinzugefügt, der als temporäre manuelle Umleitung bezeichnet wird. Es gibt zwei Szenarien, in denen die temporäre manuelle Umleitung ins Spiel kommt:

  1. Bei einem Datencenteraktivierungs-Switchback-Ereignis besteht die Möglichkeit, dass der Cache des Webbrowsers des Benutzers weiterhin den falschen DNS-Eintrag enthält und so auf die CAS-Infrastruktur am Active Directory-Standort verweist, der das Postfach nicht mehr hostet. Demzufolge gibt der CAS eine manuelle Umleitung zum richtigen Active Directory-Standort aus, aber die Umleitung erfolgt zu derselben URL, die der Benutzer derzeit verwendet. Um einen Pingpongeffekt zu vermeiden, bei dem der Benutzer nicht auf seine E-Mail zugreifen kann, überprüft der CAS, ob dasselbe Sitzungscookie zurückgegeben wird. Wenn ja, wird überprüft, ob der Ziel-CAS einen FailbackURL-Wert für das virtuelle OWA-Verzeichnis aufweist. Ist eine FailbackURL angegeben, gibt der CAS eine Seite für temporäre manuelle Umleitung aus, die den Link zur FailbackURL enthält. Ist keine FailbackURL angegeben, gibt der CAS eine Fehlerseite aus, auf der der Benutzer aufgefordert wird, alle Browsersitzungen zu schließen und es erneut zu versuchen.

    3
    Abbildung 2: Temporäre manuelle Umleitung bei Datencenteraktivierungs-Switchback

  2. Im zweiten Szenario gibt der CAS die Seite für temporäre manuelle Umleitung aus, wenn er erkennt, dass der Standort des lokalen CAS dem RpcClientAccessServer-Wert der Postfachdatenbank entspricht, die Datenbank jedoch an einem anderen Active Directory-Standort bereitgestellt wurde. Der CAS gibt dann eine temporäre Umleitung mit dem ExternalURL-Wert des CAS an dem Standort mit der bereitgestellten Datenbank aus.

    2
    Abbildung 3: Temporäre manuelle Umleitung, wenn das Postfach an einem anderen Active Directory-Standort bereitgestellt wurde

Automatische Umleitung für Vorversionen

Der Exchange 2010 CAS unterstützt nicht das Rendering von Postfachdaten aus Vorversionen (Legacyversionen) von Exchange für Outlook Web Access. Abhängig von der Version und/oder dem Speicherort des Zielpostfachs wird vom Exchange 2010 CAS eines von vier Szenarien ausgeführt:

  • Wenn sich das Exchange 2007-Postfach am gleichen Active Directory-Standort wie CAS2010 befindet, leitet CAS2010 die Sitzung automatisch an den Exchange 2007 CAS um.
  • Wenn sich das Exchange 2007-Postfach an einem anderen Active Directory-Standort mit Internetzugriff befindet, leitet CAS2010 den Benutzer manuell an den Exchange 2007 CAS um.
  • Wenn sich das Exchange 2007-Postfach an einem Active Directory-Standort ohne Internetzugriff befindet, leitet CAS2010 die Verbindung als Proxy an den Exchange 2007 CAS weiter.
  • Wenn sich das Postfach auf einem Exchange 2003-Server befindet, leitet CAS2010 die Sitzung automatisch an eine vordefinierte URL um.

Wie oben erwähnt wird die automatische Umleitung für Vorversionen nur für die Umleitung am gleichen Standort zwischen einem Exchange 2010 CAS und der Legacyinfrastruktur verwendet. Bei der automatischen Umleitung für Vorversionen gibt CAS2010 eine automatische Umleitung zurück zum Browser des Benutzers aus und weist den Browser an, eine Verbindung mit der CAS2007/FE2003-Legacyinfrastruktur herzustellen. Für eine erfolgreiche Umleitung zur Legacyinfrastruktur müssen folgende Optionen konfiguriert sein:

  • Für die Umleitung von Exchange 2003-Postfächern muss das virtuelle OWA-Verzeichnis von Exchange 2010 einen Exchange2003URL-Wert aufweisen.
  • Für die Umleitung zu einem Exchange 2007 CAS muss das virtuelle OWA-Zielverzeichnis von Exchange 2007 einen ExternalURL-Wert aufweisen.

Die automatische Umleitung für Vorversionen kann auch einmaliges Anmelden ermöglichen, wenn formularbasierte Authentifizierung (FBA) in den virtuellen OWA-Quell- und Zielverzeichnissen verwendet wird. Hierzu wird ein ausgeblendetes FBA-Formular mit aufgefüllten Feldern zurück an den Webbrowser geschickt. Das ausgeblendete Formular enthält dieselben Informationen, die der Benutzer ursprünglich an die CAS2010 FBA-Seite geschickt hatte (Benutzername, Kennwort, Öffentlich/Privat-Selektor) sowie eine Umleitung zum Exchange-spezifischen Zielpfad und die Abfragezeichenfolge. Wenn das Formular geladen wurde, wird es sofort an die Ziel-URL gesendet. Daraufhin wird der Benutzer automatisch authentifiziert und kann auf die Postfachdaten zugreifen.

Was ist schlecht an der manuellen Umleitung?

Auf den ersten Blick denken Sie vielleicht: „die manuelle Umleitung ist doch toll“, und in gewissem Maße haben Sie Recht. Dies ist ein nützliches Feature für die IT-Organisation, um zu steuern, wo die Benutzer auf ihre Daten zugreifen (und so die Benutzer zu zwingen, die richtigen Netzwerklinks zu verwenden). Aber in Wirklichkeit ist dies kein optimales Verhalten für den Endbenutzer.In dem Szenario, in dem der Benutzer die falsche OWA-URL verwendet, führt er folgende Aktionen aus:

  1. Der Benutzer gibt die falsche URL in den Webbrowser ein.
  2. Der Benutzer gibt Anmeldeinformationen ein und authentifiziert sich beim CAS (falscher Standort).
  3. CAS (falscher Standort) führt Diensterkennung aus und stellt fest, dass er den Benutzer zum richtigen CAS umleiten kann.
  4. CAS (falscher Standort) zeigt dem Benutzer eine Seite an, die einen Link zum CAS (richtiger Standort) enthält.
  5. Der Benutzer klickt auf den Link, um auf OWA am richtigen Standort zuzugreifen.
  6. Der Benutzer gibt Anmeldeinformationen ein und authentifiziert sich beim CAS (richtiger Standort).

Dieses Verhalten, bei dem dem Benutzer mitgeteilt wird, dass er die falsche URL verwendet hat und seine Anmeldeinformationen erneut eingeben muss, führt zu einer unbefriedigenden Benutzererfahrung bei der manuellen Umleitung.

Standortübergreifende automatische Umleitung in Exchange 2010 SP2

Zur Vermeidung dieser suboptimalen Benutzererfahrung (Greg nennt dies übrigens sinngemäß eine lausige Erfahrung) haben wir einen vierten Umleitungstyp für OWA in Exchange 2010 SP2 eingeführt, der als standortübergreifende automatische Umleitung bezeichnet wird. Wie der Name sagt, werden dabei nur automatische Umleitungen für Anforderungen durchgeführt, die für Clientzugriffsserver (CAS) an einem anderen Active Directory-Standort bestimmt sind (in derselben Exchange-Organisation), die über eine ExternalURL für OWA verfügen.

Zur Unterstützung der standortübergreifenden automatische Umleitung wurde ein neuer Parameter, CrossSiteRedirectType, eingeführt. Dieser Parameter ist für das Cmdlet Set-OWAVirtualDirectory verfügbar und unterstützt zwei Werte, Manual und Silent. Die standortübergreifende automatische Umleitung ist standardmäßig deaktiviert (der Standardwert lautet Manual). Dies bedeutet: Wenn Sie derzeit eine manuelle Umleitung zwischen CAS an verschiedenen Active Directory-Standorten durchführen, wird diese nach der Bereitstellung von SP2 fortgesetzt.

Wenn Sie die standortübergreifende automatische Umleitung aktivieren möchten, legen Sie CrossSiteRedirectType für die virtuellen OWA-Verzeichnisse der CAS mit Internetzugriff auf Silent fest:

Set-OWAVirtualDirectory –Identity "Contoso\owa (Default Web site)" –CrossSiteRedirectType Silent

Wir haben den OWA-Verbindungsprozess aktualisiert, um die standortübergreifende automatische Umleitung zu unterstützen. Der CAS führt bei der Diensterkennung die folgenden Schritte aus:

  1. Evaluieren der Postfachversion (Exchange 2007 oder Exchange 2010).
  2. Überprüfen des Speicherorts des Postfachs.
  3. Abrufen der ExternalURL des Ziel-CAS.
  4. Abrufen des Umleitungstyps vom Quell-CAS.
    1. Wenn CrossSiteRedirectType=Manual, wird eine manuelle Umleitung ausgegeben.
    2. Wenn CrossSiteRedirectType=Silent, wird eine automatische Umleitung ausgegeben.
      1. Wenn FBAauf den Quell- und Ziel-CAS aktiviert ist, sendet der Quell-CAS ein ausgeblendetes Formular zurück an den Browser, das die Anmeldeinformationen und FBA-Einstellungen des Benutzers sowie die Umleitungs-URL enthält.
      2. Wenn FBA nicht auf den Quell- und Ziel-CAS aktiviert ist, gibt der Quell-CAS nur eine 302-Umleitung aus.

Es stimmt – die standortübergreifende automatische Umleitung kann einmaliges Anmelden (SSO) unterstützen, wenn die virtuellen OWA-Quell- und Zielverzeichnisse die formularbasierte Authentifizierung nutzen. Kunden, die OWA nur intern bereitstellen, können auch eine einmalige Anmeldung erreichen, wenn der Authentifizierungsmechanismus im virtuellen OWA-Verzeichnis die integrierte Windows-Authentifizierung ist und die OWA-Namespaces zur Sicherheitszone „Lokales Intranet“ hinzugefügt werden.

Wann ist einmaliges Anmelden nicht möglich?

Unter den folgenden Bedingungen ist einmaliges Anmelden (SSO) bei der Umleitung zwischen Active Directory-Standorten nicht möglich:

  1. Sie verwenden Standardauthentifizierung in den virtuellen OWA-Quell- und Zielverzeichnissen.
  2. Sie nutzen unterschiedliche Authentifizierungseinstellungen in den virtuellen OWA-Quell- und Zielverzeichnissen.
  3. Sie nutzen eine zweistufige Authentifizierungslösungin den virtuellen OWA-Quell- und Zielverzeichnissen.
  4. Sie nutzen eine Vorauthentifizierungslösung(wie Microsoft Threat Management Gateway 2010), die verschiedene Weblistener für die OWA-Quell- und Zielnamespaces verwendet.
  5. Der lokale CAS gibt eine temporäre Umleitung an einen anderen CAS an einem anderen Active Directory-Standort aus.

Bedenken Sie, dass in diesen Szenarien zwar kein einmaliges Anmelden möglich ist, aber dennoch eine 302-Umleitung (die wir als automatische Umleitung bezeichnen) erfolgt.

Die standortübergreifende automatische Umleitung verbessert die unbefriedigende Erfahrung des Endbenutzers, auf einen Link klicken zu müssen, um zur richtigen OWA-Infrastruktur zu gelangen, und macht u. U. die zweimalige Eingabe der Anmeldeinformationen überflüssig. Diejenigen unter Ihnen, die bisher die manuelle Umleitung von OWA verwendet haben, aktivieren hoffentlich die standortübergreifende automatische Umleitung bei der Bereitstellung von Exchange 2010 SP2!

Ross Smith IV
Principal Program Manager
Exchange Customer Experience

Es handelt sich hierbei um einen übersetzten Blogbeitrag. Sie finden den Originalartikel unter OWA Cross-Site Silent Redirection in Exchange 2010 SP2.