Exchange 2013 veröffentlichen über den Web Application Proxy in Windows Server 2012 R2

Vor ein paar Monaten habe ich einen Artikel zum Thema «Exchange – Wie weiter ohne TMG» geschrieben, in dem ich verschiedene Alternativen zu Microsofts Reverse Proxy vorstellte. Nun ist mit der Verfügbarkeit von Windows Server 2012 R2 eine weitere Möglichkeit dazugekommen: der Web Application Proxy.

Was ist der Web Application Proxy?
Der Web Application Proxy oder kurz WAP ist ein Rollendienst unter Remote Access:

Der Zweck ist, wie der Name schon andeutet, die Entgegennahme von HTTP- oder HTTPS-Verkehr, optional mit anschliessender Authentisierung des Benutzers und der Weiterleitung an einen Web-basierenden Applikationsserver wie Exchange, SharePoint oder einfach IIS.

Eine Umgebung mit WAP kann folgendermassen aussehen:

Ein paar wichtige Punkte zur Architektur:

• ADFS ist zwingend notwendig. Der WAP Server übernimmt dabei die Rolle eines ADFS Proxies, dessen Rolle es dafür nicht mehr gibt.
• Authentisierung ist optional. Sie kann entweder über ADFS mit Claims oder mit Kerberos erfolgen. Pass-through bedeutet, dass keine Authentisierung auf dem WAP erfolgt.
• Damit Kerberos verwendet werden kann, muss der WAP Domänen-Mitglied sein und Kerberos Constrained Delegation muss eingerichtet werden.
• Der WAP Server benötigt nur ein Netzwerk-Interface.
• Header-Informationen in den Netzwerkpaketen lassen sich umschreiben (rewrite). Auch SSL Offload ist möglich.

Konfiguration für OWA und OutlookAnywhere
Im Folgenden werde ich die Schritte aufzeigen, um OWA mit Pre-Authentication und OutlookAnywhere über den WAP zu veröffentlichen. Dabei verwende ich die AD-Domäne des fiktiven Unternehmens Fourth Coffee Inc. in Seattle.

Alle Server mit Ausnahme des Exchange Servers sind mit Windows Server 2012 R2 RTM aufgesetzt. Der Exchange 2013 CU2 läuft auf Windows Server 2012 RTM.

Als Erstes wird der ADFS Server installiert und konfiguriert. Ansonsten lässt sich der Wizard für die Erstellung des WAP nicht beenden. Die Konfiguration des ADFS Servers benötigt ein Zertifikat und einen öffentlich auflösbaren Namen. Ich habe mich für adfs.fourthcoffee.com entschieden.

Fourth Coffee Inc. verwendet Split-DNS, d.h. der Namensraum intern und extern ist identisch. Das Zertifikat stammt von der internen CA, die auf dem DC installiert ist. Wir brauchen für die Funktionalität des Exchange Servers ebenfalls Zertifikate (mail.fourthcoffee.com und autodiscover.fourthcoffee.com) und diese kommen dann auch auf dem WAP zum Einsatz. Alle beteiligten Server und auch der Client müssen der ausstellenden Zertifizierungsstelle vertrauen.

Als Nächstes muss ein Relying Party Trust erstellt werden. Darin ist definiert, ob der ADFS Server Claims oder Kerberos verwenden soll und welche Anforderungen für eine erfolgreiche Authentisierung erfüllt sein müssen. Hier kann zum Beispiel Multifaktor Authentisierung (MFA) angegeben oder die Claims oder Sicherheitsobjekte (User, Gruppen oder Computer) definiert werden, die Zugriff haben sollen.

Im Falle von Fourth Coffee Inc. habe ich eine AD-Gruppe erstellt, deren Mitglieder OWA von extern verwenden dürfen.

Erinnern wir uns: Für OutlookAnywhere ist diese Zugriffssteuerung nicht möglich, da keine Anmeldung des Clients (Outlook) über das Formular des ADFS-Proxies erfolgen kann. Wir werden also für dieses Protokoll Pass-Through konfigurieren müssen.

Der nächste Schritt ist die Installation und Konfiguration des WAP Servers. Während die Installation keinen Input des Administrators benötigt, muss für die Veröffentlichung die externe und interne URL angegeben werden, bei Verwendung von SSL noch das Zertifikat und ob Authentisierung nötig ist oder nicht.

Die veröffentlichten Webapplikationen lassen sich nur mit der PowerShell nachbearbeiten, nicht mit der grafischen Oberfläche.

Es wird keine Reihenfolge der Webapplikationen berücksichtigt, weshalb zum Beispiel nicht der ganze Server https://mail.fourthcoffee.com/ mit Pass-Through konfiguriert werden kann und als Ausnahme davon https://mail.fourthcoffee.com/owa mit Pre-Authentication. Alle virtuellen Verzeichnisse müssen spezifisch erfasst werden:

Damit für OWA Kerberos verwendet werden kann, muss wie oben erwähnt KCD konfiguriert werden. Dazu gehört der Service Principle Name für den Zugriff auf den Exchange Server:

Sowie die Delegationseinstellungen im Computeraccount des WAP Servers:

Da Exchange für OWA und ECP standardmässig Forms Based Authentication verwendet, muss dies auf Windows Integrated geändert werden – sonst bekommt der Benutzer doppelt Anmeldefenster, je einmal von ADFS und Exchange.

Aus der Sicht des Benutzers
Der Benutzer navigiert auf die externe URL für OWA und erhält über den ADFS-Proxy die Anmeldemaske (FBA) des ADFS Servers:

Nach Angabe von Benutzername und Passwort wird er weitergeleitet auf OWA:

Etwas unschön: Damit der Logoff funktioniert, müssen ALLE Browserfenster geschlossen werden, da der Browser die Anmeldeinformation in einem Memorycache hält:

Die Sicherheit lässt sich noch weiter erhöhen durch die Verwendung von Multi Factor Authentication. Zur Verfügung stehen Certificate-based oder Windows Azure MFA (Mobile App, Phone Call oder SMS). Dies ist allerdings ein Thema für einen separaten Artikel.

Für OutlookAnywhere erübrigen sich Erklärungen, da durch den Pass-Through das Handling der Applikation nicht ändert.

Ein Problem ist im Zusammenhang mit Outlook noch zu nennen: Outlook Apps funktionieren nicht, wenn OWA Pre-Authentication verwendet. Der Pfad für den Inhalt der Applikation ist ein Sub-Pfad von OWA, der wie oben erwähnt nicht als Ausnahme definiert werden kann. Somit ergibt sich für den Benutzer folgender Fehler:

Fazit
Web Application Proxy eröffnet neue Möglichkeiten, OWA und/oder OutlookAnywhere in unsichere Netzwerke zu veröffentlichen. Die Komplexität der Konfiguration hält sich in Grenzen und muss den Vergleich mit den Alternativen wie Loadbalancer, Reverse Proxy und Firewalls nicht scheuen.