Outlook Anywhere via Citrix NetScaler (SSL-Offload)

Was ist Outlook Anywhere?

Outlook Anywhere, vormals bekannt als „RPC-over-http(s)“, ermöglicht den externen Zugriff mit dem „richtigen“ Outlook auf Exchange- ohne die Notwendigkeit eines VPN-Tunnels. Dazu wird ein SSL-Proxy von extern zugänglich bereitgestellt, der nach innen dann mit dem Exchange Client Access Server (CAS) spricht.

Aus Netzwerksicht

Outlook <–HTTPS (tcp/443)–[Firewall]–> Netscaler <–RPC*–[Firewall]–> CAS

Da das Problem mit den dynamischen Ports bei RPC damit noch nicht erschlagen wäre, sind die RPC-Verbindungen zwischen Netscaler und CAS auf eine überschaubare Anzahl von Ports (3) festgelegt. Standardmäßig sind das tcp/6001, tcp/6002 und tcp/6004, die also auf der inneren Firewall geöffnet werden müssen zwischen Proxy und CAS.

Die Verbindungspfeile sind oben bewusst so gezeichnet, dass die Verbindungen beim NetScaler terminieren und von dort neu ausgehen. Der Citrix NetScaler arbeitet mit einer Full-Proxy-Architektur, d.h. er terminiert alle Verbindungen auf der einen Seite und initiiert eigene Verbindungen auf der anderen Seite. Erst diese Arbeitsweise als „Simultan-Dolmetscher“ macht viele Funktionalitäten möglich:

• TCP-Optimierungen, die die Server entlasten und Verbindungen beschleunigen (Multiplexen von vielen Client-Verbindungen auf wenige Verbindungen zu den Backends, Maximieren von Framegröße uvm.)
• Caching und Kompression (transparent)
• Schutz vor Angriffen inklusive: Protokoll-Anomalien kommen nie bei den Backends an, da diese nur saubere Verbindungen vom Netscaler zu sehen bekommen.
• Web Application Firewall (WAF, in Platinum Edition enthalten) hat Einblick in vollständigen Layer7-Verkehr und kann auf Anomalien in HTML, JavaScript/Formularen, XML uvm. prüfen.
• Der Dolmetscher kann beim Übersetzen beliebig optimieren und verändern – gilt beim Netscaler in beide Richtungen, d.h. sowohl Request als auch Response!

Outlook Anywhere: Aktivierung

Die Funktion muss auf dem CAS zunächst aktiviert werden, entweder per PowerShell oder in der Exchange Verwaltungskonsole (Server – Clientzugriff – Outlook Anywhere aktivieren):

enable-OutlookAnywhere -Server:<ServerName> -ExternalHostName:
<ExternalHostName> -ClientAuthenticationMethod:Basic -SSLOffloading:$true

Erforderliche Informationen bei Aktivierung auf dem CAS:

Servername – der interne FQDN des CAS (sollte vom Netscaler aufgelöst werden können)
Externer Servername – der FQDN, der durch Outlook von außen angesprochen wird, unter dem also der NetScaler erreicht wird und auf den das SSL-Zertifikat ausgestellt ist
„SSL-Verschiebung“ – krude Übersetzung für SSL-Offload, wenn aktiviert, akzeptiert Exchange unverschlüsselte Verbindungen vom Proxy

Dann wird auf dem NetScaler ein SSL-Offloading (Content Switching) VServer angelegt – am Einfachsten macht man sich das mit dem passenden AppExpert Template für Outlook Web Access, das direkt einige Parameter wie Caching, Compression, sowie einen Encoding-Filter konfiguriert. Erforderlich ist hier natürlich ein valides SSL-Zertifikat, das an den VServer gebunden wird, sowie die individuellen IP-Adressen für VServer und Backends (CAS Server). Um die Sicherheit noch weiter zu erhöhen, können noch die über diesen VServer erreichbaren Pfade eingeschränkt werden.

Dazu unter AppExpert – Pattern Sets ein neues Set anlegen und (maximal) mit den folgenden Pfaden bestücken: /owa, /public, /ecp, /autodiscover, /microsoft-server-activesync, /rpc, /unifiedmessaging, /ews. Mit diesem vollständigen Set sind später alle OWA/OMA-Funktionen über diesen VServer möglich.

Das Pattern Set nun verbindlich machen, indem eine Rewrite-Policy gebunden wird: AppExpert – Applications – OWA – RedirectToHTTPS – Insert Policy – New Policy.

///

Die Policy überprüft, ob der Pfad im Request mit einem der durch das Pattern Set (Name des Sets ist Parameter der Expression) definierten zulässigen Pfade übereinstimmt. Falls nicht, trifft die Expression zu und die Policy führt die angegebene Action aus. Diese wiederum ändert dann den Pfad im Request, hier zum Beispiel auf „/owa“, so dass der Request auf die Outlook Web App zugreift.

///

Wird nun der VServer über ein Destination NAT oder das Freigeben des HTTPS-Zugriffs auf die externe Adresse des VServers zugänglich gemacht, kann schon die Konnektivität geprüft werden. Dazu gibt es einerseits ein CMDlet, um vom Exchange Server selbst aus zu testen:

Test-OutlookConnectivity -Protocol:Http -GetDefaultsFromAutoDiscover:
$true -verbose

Und andererseits eine praktische Website von Microsoft, mit der man tatsächlich auch ActiveSync, OWA, OA und SMTP von extern testen kann (mit einem Wegwerf-Postfach am Besten): https://www.testexchangeconnectivity.com Hier ist unter Umständen die Aussage irreführend, OA würde nicht funktionieren, weil die anonyme Authentifizierung für die Site im IIS aktiviert ist. Falls OWA mit Formular-Authentifizierung und OA in der selben Site betrieben werden sollen, ist dies erforderlich, was den Test stört (nicht unterstützt), die Funktion aber nicht verhindert.

Dann muss nur noch Outlook konfiguriert werden: Kontoeinstellungen – Exchange-Konto – ändern – weitere Einstellungen – Verbindung – Verbindung mit Microsoft Exchange über HTTP herstellen (check) – Exchange-Proxyeinstellungen – diese URL verwenden: externer Servername wie bei der Aktivierung angegeben – Authentifizierung: passend zur aktivierten Authentifizierungsmethode (Basic = Standardauthentifizierung).

Bei der Standardauthentifizierung werden Benutzername und Passwort beim Verbinden per IE-Dialog abgefragt – und dann ist Outlook „Verbunden mit Microsoft Exchange“.

Viel Spaß. 🙂