Ex2013 CAS -Proxy und Redirect

Auf der Seite Ex2013 CAS - Client Access habe ich die verschiedenen Aspekte der CAS-Rolle beschrieben und dass der Exchange 2013 CAS "eigentlich" nur ein Reverse Proxy ist und die Anfragen der Clients direkt zum richtigen Backend Server weiter leitet. Der Exchange 2013 Backend ist wieder für das Rendern der OWA-Seiten etc. zuständig. Diese Seite beschreibt, wie diese Koexistenz mit "Legacy Versionen" aussieht, also Exchange 2010 und Exchange 2007 Servern als Backend. Im Rahmen einer Exchange 2013 Einführung ist es nämlich einer der ersten Schritte, die bisherigen URLs auf den neuen Exchange 2013 Server umzustellen.

Beachten Sie dazu auch CASProxy mit Exchange 2007, CAS Proxy 2010 und CAS Proxy2016

Der Exchange 2013 CAS kann bei Kenntnis des Anwender dann die Daten zum passenden "Next-Hop" weitergeben. Und das passiert entweder als Reverse Proxy, d.h. der Exchange Server stellt seinerseits die Anfrage an den dahinter liegenden Server oder der Exchange 2013 CAS schickt den Client über einen "HTTP-Redirect" zum einem anderen Zugangspunkt. Diese Technik ist aber nicht neu, sondern schon von Exchange 2007 und 2010 bekannt:

Da ein Exchange 2010 oder 2007 Server keine Zugriffe auf einen Exchange 2013 Server durchführen kann, ist einer der ersten Schritte bei einer Migration und Koexistenz die primären URLs auf Exchange 2013-Server zu leiten. Das betrifft alle URLs (OWA, ActiveSync, RPC, EWS etc.) und natürlich auch Autodiscover.

CAS2103 zum "Next Hop"

Ich habe mir selbst aus verschiedenen Quellen eine Tabelle aufgebaut, in der ich die wesentlichen Aspekte der CAS-Proxy Funktion von Exchange 2013 zusammen gefasst habe.

Diese Liste ist eine Momentaufnahme zum RTM-Zeitpunkt. Updates von Exchange können das Verhalten verbessern bzw. verändern.

Die Proxy Funktion ist ne URL getrennt zu betrachten. Relevant für die Version ist der Postfachserver, auf dem das Postfach des Anwenders liegt. Zudem ist zu unterscheiden, ob in der AD-Site mit dem Postfachserver auch ein CAS-Server mit konfigurierter "ExternalURL" ist. Zumindest mit Exchange 2010 ist dies das Kriterium den Client per HTTP-Redirect auf den Exchange 2010 CAS zu schicken.

URL
Ex2013

  • Ex2010
Ex2007

OWA
  • Proxy zum Ex2013 MB
  • Ohne External URL
    Proxy zum Ex2010 CAS
  • Mit ExternalURL
    Redirect zur ExternalURL des Exchange 2010 CAS in der AD-Site des Postfachservers
  • Redirect auf Exchange 2007 External URL
    (Legacy Namespace)

ECP
  • Proxy zum Ex2013 MB
  • Ohne External URL
    Proxy zum Ex2010 CAS
  • Mit ExternalURL
    Redirect zur ExternalURL des Exchange 2010 CAS in der AD-Site des Postfachservers
  • ECP gibt es nicht auf Exchange 2007

POP
  • Proxy zum Ex2013 MB
  • Proxy zum Ex2010 CAS
  • Proxy zum Ex2007 CAS

IMAP
  • Proxy zum Ex2013 MB
  • Proxy zum Ex2010 CAS
  • Proxy zum Ex2007 CAS

ActiveSync
  • Proxy zum Ex2013 MB
  • Proxy zum Ex2010 CAS
  • Proxy zum Ex2007 CAS

Autodiscover
  • Proxy zum Ex2013 MB
  • Proxy zum Ex2013 MB
    Der Ex2013 liefert die passende Antwort
  • Proxy zum Ex2013 MB und von dort dann zum Exchange 2007 CAS

RPC
  • Proxy zum Ex2013 MB
  • Proxy zum Ex2010 CAS
  • Proxy zum Ex2007 CAS

EWS
  • Proxy zum Ex2013 MB
  • Proxy zum Ex2010 CAS
  • Autodiscover Anfrage um die Ex2007 EWS ExternalURL zu bekommen (Legacy)

Sie können gut sehen, das die Anfragen zum Exchange 2010 Postfach als Proxy weiter gegeben werden. Nur wenn der Exchange 2010 noch eine "external URL" hat, wird der Client umgeleitet. Die Unterstützung für Exchange 2007 ist für OWA und EWS reduziert. Der Client wird über die LegacyURL zum Exchange 2007 CAS umgeleitet. Aber für ActiveSync, RPC, POP und IMAP gibt es keine Umleitung. Hier bedient der Ex2013 CAS auch den Ex2007 CAS als Reverse Proxy

Wer eine sehr genaue Information der Funktion im Jahr 2013 sucht, sollte sich den TechEd-Vortrag von Greg Taylor auf der TechEd 2013 anschauen:

TechEd 2013: Microsoft Exchange Server 2013 Client Access Server Role
MP4 http://video.ch9.ms/ch9/d71c/2cead341-a1d0-4d1b-8be9-1d03df5bd71c/OUC-B313_mid.mp4 

TechEd 2013: Microsoft Exchange Server 2013 Client Access Server Role
PPTX: http://video.ch9.ms/sessions/teched/na/2013/OUC-B313.pptx

Auch die PowerPoint-Dateien sind gut zu sehen, da Sie die Funktion mit Animationen beschreiben. Interessant sind auch folgende Links:

Client Redirection

Schon Exchange 2010 hat Zugriff von Clients auf andere Server weiter gereicht (Proxy) oder den Client zu einem besseren Zugangspunkt gesendet. Das macht auch Exchange 2013 nicht viel anders und das hat zwei wesentliche Gründe:

  • Optimierter Zugang
    Stellen Sie sich vor, sie haben Exchange Server in verschiedenen Kontinenten mit eigenen Internet-Zugängen. Dann wäre es ja wünschenswert, wenn ein Anwender zum "besten" Zugang geleitet wird
  • Funktionseinschränken
    Der zweite Grund ist, dass der Exchange 2013 CAS nur ein "Proxy" ist aber diverse Funktionen nicht mehr selbst abwickelt, was in Exchange 2010 und insbesondere in Exchange 2007 anders war. Wer eine neuere Exchange-Version einsetzt, muss sowieso alle Clients mit einer CAL versorgt haben und daher ist es eher unwahrscheinlich, dass eine Firma lange einen "Mischbetrieb" aufrecht erhält. Es macht aber für Microsoft kaum sinn, in ein neues Produkt extra Code einzubauen und weiter zu pflegen, der nur eine Kompatibilität mit einer vorherigen Version sicherstellen soll. für solche Dienst ist es daher besser, die Clients direkt auf den "alten Server" zu lenken. der die Funktion weiter betreibt.

Ex2013 CAS zu CAS Proxy ohne MOMT

Die Umleitung eines Clients zu einem "besseren Externen Zugangspunkt" war in Exchange 2010 und 2007 noch besonders wichtig, damit z.B. die Outlook Clients einen CAS-Zugang in der Nähe ihres Postfachservers genutzt haben. Grund war hier z.B. MOMT (MAPI on the Middle Tier), bei dem ein Outlook per RPC/HTTP mit dem CAS gesprochen hat, der dann daraus eine MAPI-Verbindung (RPC) zum Postfachserver gemacht hat.

Bei der Konstellation ist es ungeschickt, wenn ein Anwender einen CAS Server im "falschen" Standort nutzt und daher RPC über das hausinterne LAN zum anderen Standort geht. Gleiches gilt auch für OWA, weswegen Exchange 2010 in dem Fall geprüft hat, ob ein CAS-Server in der AD-Site des Postfachservers eine "ExternalURL" hat und leitet den Anwender dorthin weiter.

Exchange 2013 macht dies aber nicht mehr, da hier alle Client Zugriffe über HTTPS oder IMAP/POP laufen und die Umsetzung auf "MAPI", wenn man davon überhaupt noch sprechen kann, auf dem Postfach Server erfolgt. Es ist nicht mehr so schädlich, wenn ein Client beim falschen CAS ankommt., der dann die Anfrage als Reverse Proxy zum richtigen Server über das gleichen Protokoll weiter gibt. Es kann sogar gewollt sein, dass z.B. ein Client in einem Kontinent einen lokalen CAS-Server nutzt (Geo-DNS), der dann über das firmeneigene gesicherte WAN zum Postfachserver in einem anderen Kontinent weiter gegeben wird.

InternalURL, ExternalURL und FQDN

Aus diesem Grund ist es wichtig, dass die aktuellen als auch die neuen Server korrekt bezüglich der und "ExternalURL" konfiguriert sind, denn diese Information nutzen auch die Exchange 2013 CAS-Server, um zu ermitteln, ob und wie ein CAS-Server aus dem Internet erreichbar ist.

Der Wert für "InternetURL" ist ebenfalls wichtig, da dieser an die Clients per Autodiscover weiter gegeben wird und zumindest für interne Clients wichtig ist. Allerdings ist der Wert nicht für die interne Exchange 2013 Proxy-Funktion erforderlich. für die Zugriffe auf andere interne Exchange Server der Organisation nutzt Exchange 2013 immer den FQDN des Zielservers und generiert daraus die URLs. Dies wirkt sich auf folgende Dinge aus:

  • Zertifikate
    Wenn der Exchange 2013 per HTTPS auf den nächsten Server zugreift, muss im Zertifikat auch der FQDN-Servername enthalten sein. Bei größeren Firmen mit einer internen CA ist das weniger ein Problem, aber wenn Sie intern öffentliche Zertifikate einsetzen, sind das zusätzliche Namen (=Kosten). Kniffliger wird es aber, weil viele CAs keine "privaten Namen" mehr signieren, z.B.: "ex01.firma.local".
  • IIS-Bindungen
    Der FQDN des Servers verweist normal auf die primäre IP-Adresse des Servers. Das Sxchange Setup macht alles richtig aber es gibt Administratoren, die in den IIS-Bindungen die Konfiguration ändern. Das kann die Funktion nachhaltig stören.
  • Virtuelle Verzeichnisse
    Früher konnte man mehrere virtuelle Exchange-Verzeichnisse anlegen. Das geht schon länger nicht mehr und sie sollten sich hüten, die angelegten Verzeichnisse umzuschreiben.
  • Proxy
    Der Exchange CAS Server muss die anderen Exchange Server per HTTPS direkt erreichen. Probleme machen hier Zwangsproxies, WAN-Optimierer oder einfach eine falsche Proxy-Konfiguration des Exchange Servers per WPAD
  • Loadbalancer
    Wenn der Exchange 2013 Server nicht auf die konfigurierte "InternalURL" geht, die gerne mal auf einen Loadbalancer verweist, dann wissen Sie nun auch, dass der CASProxy ihren Loadbalancer umgeht und eigene Strategien zur Verfügbarkeit verfolgt. Eventuell müssen Sie ihr Vorgehen beim Patchen auch erweitern, da ein CAS-Server, der im Loadbalancer auf "pause" gestellt ist, von anderen CAS-Servern weiter angesprochen wird.
  • Firewall und IP-Routing
    Gerade größere Firmen haben ihre CAS und Mailbox-Server vor den Clients abgeschottet und stellen einen Loadbalancer "davor". Wenn die neuen Exchange CAS-Server wir die bestehenden Server quasi "von Hinten" kommen, sollte alles funktionieren. Wenn der Zugriff aber z.B. aus anderen Subnetzen oder Standorten erfolgt, könnte es erforderlich werden über Portfreigaben und IP-Routing zu sprechen.
  • Kerberos
    Der Wechsel auf den FQDN hat natürlich den Vorteil, dass der anfragende CAS-Server sich per Kerberos am anderen Server anmelden kann.

Es ist also weiterhin "wichtig", dass sowohl die in Exchange konfigurierten InternalURLs und ExternalURLs ebenso stimmig sind, wie die Erreichbarkeit des internen FQDN.

Legacy URL und Legay NameSpace

Mit Exchange 2013 ist zumindest schon mal der Betrieb eines Exchange 2003 Servers nicht mehr möglich. für den Zugriff auf dieses Server musste früher noch eine "LegacyURL" in Exchange 2010 hinterlegt werden. Exchange 2010 konnte keine OWA-Anfragen zu einem Exchange 2007 oder 2003 Server als Proxy weitergeben und hat damit den Anwender auf den alten Server umgeleitet. Exchange 2003 kannte aber noch gar nicht die Technik mit "InternalURL" und "ExternalURL" und so konnte der Exchange 2010 Server gar nicht wissen, wie die URL für den Zugriff auf Exchange 2003 lautet. Daher diese zusätzliche Konfiguration.

Mit Exchange 2013 muss zwar keine zusätzliche URL mehr als "LegacyURL" definiert werden aber Exchange 2013 kann zwar Exchange 2010 OWA-Zugriffe als Reverse Proxy unterstützen aber kein Exchange 2007. Entsprechend ist es auch hier wichtig, dass die Exchange 2007 Server weiterhin per OWA erreichbar sind. Schaltet man aber nun bei einer Migration den bislang genutzten DNS-Namen auf die Exchange 2013 Server um, müssen die Exchange 2007 Server unter einem anderen Namen erreichbar sein, der dann auch in dem Feld "ExternalURL" dieser Exchange 2007 Server gepflegt wird.

Es gibt keinen offiziellen Weg, wie man einen Exchange 2007 Server hinter einem Exchange 2013 CAS verbergen kann. Es gibt aber natürlich gerade für kleine Firmen während der Migration die Möglichkeit, darauf zu verzichten um den Aufwand für ein eigenes Zertifikat, eigene IP-Adresse, DNS-Name und Internet-Veröffentlichung zu sparen. Denkbar ist z.B. die zügige priorisierte Migration der OWA-User auf Exchange 2013, damit diese weiter arbeiten können.

Wer heute ein "Webportal" vorgeschaltet hat, kann natürlich auch hier z.B. ausgehend vom HomeMDB des Benutzers oder einer Gruppenzugehörigkeit den Zugriff das vorher authentifizierten Anwenders gleich auf den richtigen Server weiter leiten.

Authentifizierung

Auch die Authentifizierung ist ein wichtiger Aspekt beim Exchange 2013 CAS Proxy, da sich der Server gegen den Backend Server natürlich authentifizieren muss. Das kann er aber nicht als "Benutzer", denn in den seltensten Fällen wird der CAS-Server die Anmeldedaten des Benutzers bekommen haben. Dies wäre nur mit "Basic" oder "Impersonation" möglich aber nicht beim Einsatz von NTLM oder Kerberos durch den Client.

Das ist aber auch gar nicht erforderlich, da sich die Exchange Server in einer Organisation quasi "vertrauen. Daher erfolgt die Authentifizierung gegen den Backend Server, was durchaus auch ein Exchange 2010 CAS sein kann, immer mit dem Servernamen. Im IIS-Log eines Exchange 2010 Servers ist dies gut zu sehen

2013-06-09 07:32:32 192.168.100.8 POST /ews/exchange.asmx - 443 - 192.168.100.32 ExchangeInternalEwsClient-EwsStoreDataProvider+(ExchangeServicesClient/15.00.0620.000) 401 0 0 0
2013-06-09 07:32:32 192.168.100.8 POST /ews/exchange.asmx - 443 MSXFAQ\NAWEX13$ 192.168.100.32 ExchangeInternalEwsClient-EwsStoreDataProvider+(ExchangeServicesClient/15.00.0620.000) 200 0 0 156
2013-06-09 07:32:32 192.168.100.8 POST /ews/exchange.asmx - 443 - 192.168.100.32 ExchangeInternalEwsClient-EwsStoreDataProvider+(ExchangeServicesClient/15.00.0620.000) 401 0 0 0
2013-06-09 07:32:32 192.168.100.8 POST /ews/exchange.asmx - 443 MSXFAQ\NAWEX13$ 192.168.100.32 ExchangeInternalEwsClient-EwsStoreDataProvider+(ExchangeServicesClient/15.00.0620.000) 200 0 0 93

Dennoch sollten Sie die Grundlagen können, mit denen sich ein Anwender an dem Exchange 2013 CAS Server anmelden kann, aber auch vorher am Backend Server (2007/2010) anmelden konnte. Das ist insbesondere bei Migrationen wichtig, bei denen die Anmeldung an den bisherigen Servern geändert wurde und nun die Anmeldung über den Exchange 2013 Server verhindert.

Häufiger Fall ist, dass Outlook Anywhere nur per "BasicAuth" freigegeben wurde. Mit dem umzug der URL von Exchange 2010/2007 auf den Exchange 2013 kann sich der neue CAS-Server dann nicht am Backend Server anmelden. Schauen wir uns die Verfahren einfach mal an:

  • Formbased
    Es ist nicht schädlich, wenn der Exchange 2010 z.B. Formbased Anmeldung aktiv hat, da der Ex2013 als Proxy per NTLM daran vorbei geht. Der Exchange 2010 erkennt, dass es sich nicht um einen "Browser" handelt. Allerdings muss NTLM aktiv sein.
  • NTLM aktiv
    Auf dem OWA-Verzeichnis muss NTLM aktiv sein. per Default ist dies NICHT aktiv. Die Fehlermeldung in Exchange 2013 OWA ist ein "Something went wrong" und wenig aussagekräftig.
Get-ecpVirtualDirectory -Server ex2010server | ?
   Set-EcpVirtualDirectory -WindowsAuthentication:$true

Get-OWAVirtualDirectory -Server ex2010server | ?
   Set-OWAVirtualDirectory -WindowsAuthentication:$true
  • Outlook Anywhere
    OA muss auf Exchange 2010 aktiv sein, das der Ex2013 einen Proxy auf den Ex2010 CAS macht. Der ExternalHostname von Exchange 2010 OA sollte auf den Ex2013 verweisen. Bei Exchange 2007 musste man dies noch als Rolle des Windows 2003 Betriebssystems manuell installieren.

Sollte der Zugriff über Exchange 2013 nicht funktionieren, dann ist ein Blick in die IISLogs des Exchange 2013 und die CAS-Logs des Exchange 2013 hilfreich. Hier wird sehr gut protokolliert, warum der Zugriff fehlgeschlagen ist.

Weitere Links