Exchange 2013: Sophos UTM 9.2 WAF als Reverse Proxy für Outlook Anywhere, OWA, ActiveSync und Autodiscover

Vorwort

Vor einiger Zeit hatte ich ja bereits einige Alternativen zur Forefront TMG getestet. Sophos UTM hatte ich bereits in einer älteren Version getestet. Es gibt mittlerweile aber bereits die Version 9.2 in der die Web Application Firewall (WAF) laut Sophos deutlich verbessert wurde. Ich habe mir daher die Sophos UTM nach einmal genauer angeschaut. Wer den Einsatz in Verbindung mit Exchange 2013 plant, sollte allerdings zuerst den ganzen Artikel lesen, denn nicht alles funktioniert wie erwartet. Hier also meine Erfahrungen in meiner Testumgebung:

Es handelt sich hier um meine Standard Testumgebung, 2 Exchange 2013 (CAS + MBX) Server, 1 Domain Controller, 1 Kemp Loadmaster VLM-2000 und die Sophos UTM 9.2.

Exchange und Domain Controller sind auf Server 2012 R2 installiert. Alle Systeme sind als VM installiert. Die Sophos UTM dient als Standard Gateway für die VMs und ist Mitglied des Active Directorys. Für diesen Test gibt es zusätzlich einen Windows 8.1 Client mit Outlook 2013, der nicht Mitglied des Active Directorys ist und Outlook Anywhere nutzen möchte.

Als Zugriffspunkt für Outlook Anywhere möchte ich den DNS-Namen „outlook.frankysweb.de“ verwenden, daher ist dieser Name als interner und externer Hostname konfiguriert:

Wichtig ist hier auch die Auswahl der Authentifizierungsmethode, „Aushandeln“ oder „NTLM“ habe ich mit der Sophos UTM 9.2 (9.203-3) nicht zum Laufen bekommen. Hier sollte also „Einfach“ gewählt werden. Dazu aber gleich noch etwas mehr.

Hinweis: Ich habe mich dazu entschieden nur 2 Hostnamen zu verwenden. Autodiscover.frankysweb.de für Autodiscover und outlook.frankysweb.de für Outlook Anywhere, OWA und ActiveSync. Es gibt ein paar HowTo’s die alle Dienste mittels eigenen Hostnamen und entsprechenden Regeln trennen. Wenn aber gekaufte Zertifikate verwendet werden, können viele Hostnamen schnell teuer werden.

Mit Exchange 2013 ist es Best-Practise für internen und externen Zugriffpunkt den gleichen Hostnamen zu verwenden. Bei Exchange 2010 lautete die Empfehlung noch dieses zu trennen. Ich verwende also intern, wie extern den DNS-Namen „outlook.frankysweb.de“. Intern wird der DNS-Name „outlook.frankysweb.de“ auf die IP des Loadbalancers aufgelöst. Befinden sich die Clients im Internet, wird der DNS-Name auf die externe IP-Adresse der UTM aufgelöst.

Hier befindet sich der Client extern (in meiner Testumgebung ist 192.168.10.0 das Internet)

und hier befindet sich der Client intern (192.168.200.20 ist die IP des Virtual Service des Loadbalancers)

Interne Clients verbinden sich also zum Loadbalancer, der die Verbindung dann zu einem der CAS-Server weiterreicht

Der Vollständigkeit halber noch ein Screenshot der UTM Interfaces (damit es nicht zur Verwechslung zwischen Intern und Extern kommt)

In meiner Testumgebung ist also 192.168.100.0/24 das Internet und 192.168.200.0/24 das interne Netzwerk. Mein Windows 8 Testclient im Internet ist in der Lage folgende DNS-Namen aufzulösen (beide auf die externe IP der UTM):

• outlook.frankysweb.de
• autodiscover.frankysweb.de

Mein externer Rechner soll nun also OWA und Outlook Anywhere nutzen können, bisher ist die UTM nicht konfiguriert (kein Portforward, keine WAF), daher funktioniert natürlich auch der Aufruf der URL https://outlook.frankysweb.de nicht:

Da ich die WAF nutzen möchte um OWA und Outlook Anywhere im Internet zu veröffentlichen, wird ein SSL-Zertifikat benötigt, ich verwende meine interne CA. Bei gekauften Zertifikaten müssen Autodiscover und Outlook Anywhere DNS Name auf dem Zertifikat als Subject Alternate Name stehen:

Ich finde es am einfachsten das Zertifikat an einem Windows Rechner zu erstellen und den Wizard zu nutzen. Das Zertifikat muss dann nur als PFX-Datei mit privatem Schlüssel exportiert werden und auf der UTM wieder importiert werden:

Als nächstes werden die Real Webservers angelegt

Die Einstellungen werden für beide Exchange Server durchgeführt, danach sieht es dann so aus:

Jetzt kann der Virtuelle Webserver angelegt werden, die Einstellungen sind wie folgt:

Nach dem Speichern sieht es dann so aus:

Ich habe die WAF noch nicht eingeschaltet, da ich nun zuerst noch die Ausnahmen erstelle:

In der Request Filterung gebe ich dann alle Exchange IIS Verzeichnisse in den gängigen Schreibweisen an:

/owa/*
/OWA/*
/Autodiscover/*
/Autodiscover/*
/ecp/*
/ECP/*
/ews/*
/EWS/*
/rpc/*
/RPC/*
/oab/*
/OAB/*
/Microsoft-Server-ActiveSync/*
/microsoft-server-activesync/*

Die Ausnahmen können dann auch direkt eingeschaltet werden:

Hinweis: Wer das automatische Umleiten zu OWA nutzen möchte muss hier noch das Root eintragen (Redirect von https.//outlook.frankysweb.de zu https://outlook.frankysweb.de/owa), dann sieht es so aus:

Jetzt kann auch die WAF eingeschaltet werden:

Wie schon etwas weiter oben erwähnt habe ich es nicht geschafft NTLM bzw „Aushandeln“ als Authentifizierungsmethode ans Laufen zu bekommen. Im Live Log der WAF  waren permanent HTTP 401 Fehler zu sehen. Für Outlook Anywhere lässt sich die Authentifizierung per ECP einstellen, für Autodiscover muss es per Shell erledigt werden:

Get-AutodiscoverVirtualDirectory |  Set-AutodiscoverVirtualDirectory -WindowsAuthentication $false
Get-OutlookAnywhere | Set-OutlookAnywhere -InternalClientAuthenticationMethod BASIC -ExternalClientAuthenticationMethod BASIC -IISAuthenticationMethods BASIC
Get-OabVirtualDirectory | Set-OabVirtualDirectory -WindowsAuthentication $false -BasicAuthentication $true
Get-WebServicesVirtualDirectory | Set-WebServicesVirtualDirectory -WindowsAuthentication $false -BasicAuthentication $true

Bis die Einstellungen in die Autodiscover Konfiguration übernommen werden, kann es bis zu 15 Minuten dauern. Also etwas Geduld.

Nachteile:

Die Prüfung ob der Exchange Server tatsächlich erreichbar ist, dauert für meinen Geschmack zu lange. Ich kann ohne Probleme einen Exchange Server neustarten, ohne das die UTM erkennt das der Server offline ist. Ich habe auch keine Möglichkeit gefunden, das Intervall anzupassen. Hier mal ein Screenshot, die UTM denkt der Server FWEX1 wäre noch erreichbar, der Server war zu dem Zeitpunkt aber etwas seit 3 Minuten heruntergefahren.

Leider lassen sich auch nicht die Healthcheck Dateien nutzen, es wird scheinbar nur geprüft, ob „irgendetwas“ auf Port 443 antwortet. HealthCheck wäre natürlich schöner:

Vieleicht wird da ja noch in den nächsten Versionen nach gebessert. NTLM habe ich nicht zum Laufen bekommen. Entweder funktionierte Autodiscover nicht, oder aber andere Features wie OAB Download etc. Mit der Standardauthentifizierung konnte ich keinen Fehler feststellen, allerdings lief das auch erst zuverlässig als ich intern sowie extern auf Standardauthentifizierung umgestellt hatte. Die Standardauthentifizierung hat auch zur Folge das Outlook beim Start nach Benutzer und Passwort fragt, ich finde das nicht so schön bei internen Clients. Eigentlich sollte ja „Aushandeln“ funktionieren, wenn NTLM nicht funktioniert, dann eben Standard. Leider scheint das Fallback von NTLM auf Standard in Verbindung mit der WAF auch nicht zu funktionieren.

Update 1: Zwischenzeitlich ist die Version 9.204-19 erschienen. zwar finde ich im Change Log keinen Hinweis auf NTLM, aber es kann jetzt zumindest schon mal das Time-Out für die Real Server festlegt werden.

Update 2: Bei eingeschaltetem URL-Hardening funktioniert ECP leider nicht, sobald Benutzer auf „Optionen“ klicken, wird eine Fehlermeldung angezeigt:

Ich habe das bisher nur gelöst bekommen indem ich URL-Hardening abgeschaltet habe:

Ich frage mich langsam warum ich nicht einfach einen DNAT Eintrag erstelle?! Im Hinblick auf Exchange 2013 stimmt das hier scheinbar nur bedingt:

http://www.sophos.com/de-de/products/unified/utm/tmg-replacement.aspx

Ich lasse mich aber gerne eines Besseren belehren, falls also jemand Interesse hat dieses Thema zum Laufen zu bewegen, bitte melden…

Update 3: Dank des Hinweises von Ulrich funktioniert nun auch ECP, dazu muss der Haken bei „Never change HTML during URL Hardening or Form Hardening“ in den Exceptions gesetzt sein:

Jetzt hab ich allerdings noch das Problem mit NTLM.

Sophos gibt hier ebenfalls an, dass NTLM aktuell nicht funktioniert:

http://www.sophos.com/en-us/medialibrary/PDFs/other/tmg-administrators-guide-to-sophos-utm.pdf?la=en (Seite 37)

Hat vieleicht noch jemand ein Tipp wie es zumindest möglich ist nur extern Basic Authentifizierung zu nutzen? Wie oben bereits beschrieben funktioniert es bei mir nur, wenn ich intern sowie extern auf Basic Auth. umstelle. Wobei mir gerade einfällt… mal testen… Moment

Update 4: Ein Freund hat netterweise den Kontakt zu Sophos hergestellt, sodass sich die Möglichkeit ergeben hat, ein paar offene Fragen zu klären und einen kleinen Ausblick auf die kommenden Versionen zu bekommen. Sophos hat mir auch eine Vorab-Version eines Guides für die UTM 9.2 und Exchange zur Verfügung gestellt, sodass in der Mail auf diesen referenziert wird. Sophos hat ebenfalls erlaubt die E-Mail an dieser Stelle zu veröffentlichen. Hier muss ich nun tatsächlich ein großes Lob an Sophos (und natürlich den beteiligten Personen) aussprechen, denn so eine schnelle Reaktion inkl. der detaillierten Informationen, habe ich selten erlebt. Vielen Dank an dieser Stelle. Hier nun die Mail (ohne Namen…)

Hello Frank,

My colleague asked me to look into your feedback. Unfortunately German is not my native language, so please forgive me for answering in English (and any misinterpretation of your email on my part).

With that said, I’ve taken the liberty of citing your email and answering in-line below:

Hier hab ich das erste Problem in meiner Testumgebung:

 

Prerequisites

Now, with that said, make sure your Exchange has been configured to allow Basic authentication on the relevant services (OWA, ECP, OAB, Outlook Anywhere, EWS and Autodiscover).

 

Zwar kann ich Exchange beibringen, er solle doch bitte NTLM oder Negotiate für die Authentifizierung interner Clients bereitstellen und für externe Clients Basic, aber die Erkennung ob sich ein Client intern oder Extern befindet, scheint mit zugeschalteter WAF nicht mehr zu funktionieren. Aus Exchange-Sicht sieht es meiner Nachforschung so aus, als wäre der Client intern. Daher bietet Exchange NTLM an. Was scheinbar mit der WAF nicht möglich ist.

Ich musste daher die interne, sowie die externen Authentifizierungsmöglichkeiten auf BASIC umstellen, was allerdings den Effekt hat, das Outlook beim Verbindungsaufbau und bei der Einrichtung nach Benutzernamen und Passwort fragt und die Anmeldeinformationen nicht mehr durchreicht. Das ist nicht so schön, wenn Benutzer häufig ihr Passwort ändern müssen. Es dürfte auch bekannt sein das Baisc die unsicherere Authentifizierungsmethode darstellt.

It is indeed true that it’s beneficial for your internal Exchange clients to use Integrated Windows Authentication (IWA) which negotiates between using either Kerberos or NTLM. This is not disputed for any of these services in our guide (which is a work-in-progress by the way, so please consider the version you received a preview), we only kindly request you to enable Basic Authentication as an additional means of authentication for these services (with the exception of OWA and ECP which will indeed need to be switched from Forms authentication to HTTP 401 authentication).

This setup then allows your internal client to remain using Kerberos or NTLM with the Exchange, whereas external client can use basic authentication if the UTM is configured to preform Reverse Authentication for the Exchange server.

And yes, we are quite aware that Basic Authentication is a rather insecure means of authenticating if not combined with some sort of encryptions such as SSL, which is why we are stressing the use of HTTPS in both external communication (with the clients) and internally (between UTM and Exchange).
The reason we chose to go for Basic Authentication as our default delegation method is that this is compatible with every known backend in both the Windows and Linux based webservers.

Was trage ich denn hier ein, wenn ich einen AD-Forrest mit mehreren Domains habe? Diese Konfiguration ist nicht gerade unüblich. :

 

In the next screen, select „Basic Authentication“ and click „edit“ in the left-hand bar.

Enter the default domain (either by NetBIOS name or FQDN) in the default domain name field on the popup.

 

Und das hier alte ich auch für keinen gangbaren Weg:

 

Alternative UPN domain name

The following is only necessary if the internal domain does not match the email domain AND the customer

wishes to use the users‘ email addresses instead of their internal UPN. In this example, the internal domain is

example.local and the external domainname is example.com.

 

Man kann ja nicht mal eben den UPN, der ja nun mal auch in bestehenden AD-Strukturen für diverse andere Dinge verwendet wird, ändern. Das der interne AD-Domain Name nicht mit der E-Mail Domain überein stimmt, dürfte bei sehr vielen Unternehmen der Fall sein. Gängige Praxis ist und war das Active Directory beispielsweise „firma.local“ zu nennen, während die Mail Domain auf „firma.de“ lautet. Größere Unternehmen trennen das oft auch weiter aus: europa.firma.local, asien.firma.local usw. Hier ist es also nicht möglich einen einheitlichen UPN zu konfigurieren. Nächster Punkt wäre, dass das Hinzufügen eines Suffixes, nicht automatisch eine valide E-Mail Adresse ergibt. Viele Firmen verwenden Personalnummern oder ähnliches als Benutzernamen. Der normale Benutzername wäre also in etwa P12345@europa.firma.local, die E-Mail Adresse ist dann aber doch meist vorname.nachnahme@firma.de. Hier bringt das Hinzufügen eines Suffixes also nichts.

While you are correct that AD domain management can be complex, there is no requirement to use Alternative UPNs for authentication. The reason the guide mentions this is that, for small environments (where the internal domain is firma.local and the external is firma.de) it could be beneficial to add an alternative UPN as it looks a lot neater.

Should you however wish to authenticate using just username and password or UPN and password you are more than welcome to. The UTM will not reject p12345@europa.firma.local as a valid username as long as it is set to perform LDAP authentication based on UPN (such as described in the guide)

Können Sie mir erklären, warum später noch Site-Path Routing eingesetzt wird?

Yes I can, we configure site-path routing because we want to enable different authentication profiles for different paths. This allows one to use UTM based HTTP 401 based authentication for services such as EWS, Autodiscover and Outlook Anywhere, while enabling the use of our UTM forms authentication for functionalities such as OWA and ECP.

Schön wäre es auch wenn Sie in den kommenden Versionen, vielleicht eine Möglichkeit schaffen würden, das konfiguriert werden kann, wann ein Server als offline angesehen wird. Hintergrund ist in Bezug auf Exchange die healthcheck.htm die für jeden Webservice generiert wird und dadurch der Status der Dienste und nicht nur des IIS geprüft werden kann. Wäre ein nettes Feature. Vielleicht könnte man dann auch direkt eine kleine konfigurierbare Loadbalancing Funktion einfügen um ggf. Leistungsstärkere Server mit mehr Benutzern zu versorgen als schwächere.

This is indeed a legitimate issue and we are looking into using more accurate healthchecks.

Unequal load sharing however is a whole different concern, as this would require a rather extensive knowledge of the protocol and the metrics involved in either the administrator (who will have to know the approximate number of sessions a server can handle) or the UTM (who would need to estimate the amount of sessions per server based on either a template or some severely complicated calculation based on response times or something).

Long story short: We assume both backend to have roughly equal performance for the sake of keeping it simple.

Zum TMG Administrators Guide hätte ich noch folgende Anmerkungen: Die TMG Implementierungen die ich betreut habe, hatten alle nur den einen Zweck: Exchange und SharePoint im Internet zu veröffentlichen. Die ganzen anderen Funktionen habe ich nur sehr sehr selten im Einsatz gesehen. Das übliche Design war dann doch eher: Frontfirewall -> DMZ -> Forefront TMG -> Firewall/oder internes Netzwerk. TMG hat in den meisten Fällen (soweit ich das beurteilen kann) häufig nur den Proxy gespielt, um die Dienste im Internet zu veröffentlichen. Und hier hätten wir dann ein paar Punkte die vielen sauer aufstoßen:

 

NTLM and Kerberos delegation

Sophos UTM does not support NTLM or Kerberos Constrained Delegation modes of authentication.

 

Das ist sehr schade denn NTLM ist die Standardauthentifizierung bei Exchange 2013. Und Kerberos wäre natürlich noch ein Bonbon.

We are indeed quite aware that a lot of TMGs have been deployed in the fashion you’ve described, which is why our main focus of development in regards to TMG replacement has been in our WAF. This has led to the significant improvements already seen in our 9.2 and it will translate into more TMG-like features being added in future releases.

With that said, we currently do not support NTLM and Kerberos constrained delegation for backend authentication, as our primary focus has been on compatibility with multiple different backends, which precludes the use of NTLM (which is a proprietary Microsoft protocol). With that said, expect Kerberos Constrained Delegation to be added in an upcoming release.

Und das hier war leider die einzige Möglichkeit zu verhindern das ein Benutzer seine zig privaten Geräte via Outlook Anywhere mit dem Firmenpostfach synchronisiert. Man möchte ja ungerne die Datenhoheit verlieren. Ich möchte also nicht, dass alle Firmenmails auf einem privaten unverschlüsseltem Laptop liegen:

 

Microsoft UTM  has the ability to add X.509 client certificate checks to any Web Listener, allowing only those users that have a valid certificate to access the resource or post their authentication details to TMG.

Sophos UTM does not currently have this functionality.

We have started development on X509 client certificates as additional authentication scheme (similar to our OTP functionality) for the next major UTM release. This is a very crucial feature for us as many governments require some sort of certificate based authentication in order for UTM to be a viable option, so expect to see it in our product soon.

Schön wäre natürlich auch die Anzahl der Namen auf dem Zertifikat möglichst gering zu halten. Wildcard Zertifikat sind sehr teuer und haben den großen Nachteil das im Falle einer Kompromitierung alle Geräte/Dienste etc mit einem neuen Zertifikat ausgestattet werden müssen. In Ihrem neuen Howto werden ja zumindest nur noch 3 Namen verwendet, allerdings bieten viele Zertifikatsanbieter günstige Zertifikate mit 2 Namen (meist autodiscover.domain.tld und whatever.domain.tld) zu recht günstigen Preisen an.

The guide configures outlook anywhere on an alternative hostname as we’ve had some reports of false positives (traffic dropped for looking illegitimate even though it isn’t) when combining ECP and Outlook Anywhere in the same firewall profile. While we have yet to consistently reproduce these effects in our testing, we’ve decided to recommend using different profiles until we’re sure these issue do not occur when combining said features.

Was mir jetzt persönlich nicht ganz klar ist, weil mir da das KnowHow in der Funktionsweise der WAF fehlt sind die Ausnahmen. Erst Einschalten und dann per Ausnahme wieder abschalten? Kann ich es da nicht gleich abschalten?

This is due to the way our WebAdmin configuration works. The firewall profile URL hardening assumes that we know all the exact paths and documents that can potentially exist in the backend server. This is of course impossible in an Exchange environment (due to the type of URLs and HTTP messages being used) so we need to create some exceptions to allow the UTM to filter based on a path (for example we want to block “/” but allow “/owa”) but disable blocking the URLs below these virtual directories needed to make Exchange works.

While I understand that this can be a bit cumbersome, we think it is better than the alternative (allowing everything below a certain virtual directory by default). We are a talking about a security product, after all.

Mir fehlt auch folgendes Feature, welches mit TMG einfach umzusetzen war: Im Active Directory gab es 3 Gruppen (Allow_ActiveSync, Allow_OutlookAnywhere und Allow_OWA) um den Zugriff besser steuern zu können. Benutzergruppen bekommen Zugriff auf OWA, aber nicht auf Outlook Anywhere etc. Und wenn Outlook Anywhere erlaubt ist, dann nur mit dem passenden Client-Zertifikat auf dem Firmennotebook.

The first part of your configuration is quite simple to mimic using a UTM, simply make sure that the reverse authentication profiles being used for the specific services do not contain the groups you wish to disallow access to a specific resource (for example, only add “Allow_OWA” to the reverse authentication profile for the “/owa/” site path rule).

The certificate authentication however, as mentioned before, will be added soon.

I hope this has helped shed some light on the guide, our product and why we chose to do things in a specific way.

Please feel free to publish this response on your blog and reach out to us with any future questions.

Mit diesen Informationen und vieleicht auch noch der ein oder anderen Mail, kommt hier sicherlich eine gute Lösung heraus. Updates gibt es dann hier.