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.
Vielen Dank für den guten Artikel. Da ich noch auf Stand 9.2 war, habe ich meine einstellungen angepasst. Funktioniert bis auf NTLM alles am PC Client und Connectivity Checker, jedoch kann ich auf Mobile Devices über Active Sync nicht die Inhalte von Unterordner sehen. Diese sind leer und werden unter Android mit „Keine Verbindung“ gekennzeichnet.
Hat wer die Lösung für mich?
Hallo Franky
Vielen herzlichen Dank für die detaillierten und dadurch äusserst hilfreichen Informationen. Sie haben mir einen grossen Dienst erwiesen.
Beste Grüsse aus der Schweiz, Adrian
@Andre: Nein, beim Exchange 2013 funktioniert die Weiterleitung out-of-the-box. Im IIS habe ich beim mir auch keine Weiterleitungen gefunden. Das wird wohl irgendwie anders realisiert.
@Andre: Funktioniert denn die automatische Umleitung in deinem internen Netz? Ohne über die WAF zu gehen?
@Thomas: Danke für dein Feedback. Nein, intern funktioniert automatische „redirection“ auch nicht. Ich habe meine 2 Exchange CAS Server „standardmässig“ installiert und einzig via PowerShell CAS-Array gebildet.
Ich weiss, dass es die Möglichkeit gäbe im IIS auf den 2 CAS Servern jeweils auf „Default Web Site“ ein HTTP Redirect einzuschalten wie in folgendem Link beschrieben: http://www.briandesmond.com/exchange/redirecting-owa-urls-in-exchange-2010/
Ich habe nicht gerade ein Exchange 2013 vor mir und weiss nicht mehr wie es dort standardmässig ist. Musstest du in IIS zuerst manuell eine Umleitung einrichten?
Hallo Frank
Erstmals vielen Dank für den super Artikel. Ich bin auch daran unsere TMG’s und UAG’s abzulösen.
Ich verwende für meine ersten Tests UTM 9.3 (mit Reverse Authentication / Site Path Routing ).
Ich habe noch Exchange 2010 im Einsatz.
Ich habe folgende UTM 9.2 Dokumentation als Basis verwendet.
https://sophserv.sophos.com/repo_kb/120454/file/Exchange%20WAF%20How%20to%209%202.pdf
Dann hatte dein beschriebenes ecp Problem mit Fehler 412 wo ich die Lösung auf dieser Seite fand!
Nun habe ich noch das Problem dass ich von nicht automatisch auf umgeleitet werde. Ich möchte kein Redirection auf den CAS Servern im IIS machen! Du schreibst, dass man unter „Exceptions“ zusätzlich zu den owa – OWA – ecp….. Pfaden auch „/“ eintragen muss damit es funktioniert, doch bei mir leider ohne Erfolg. Hast du mir einen Tip was man das sonst noch machen muss, oder funktioniert das ev. mit Exchange 2010 nicht?
Grüsse aus der Schweiz
André
Hallo Frank,
vielen Dank auch von mir für den ausführlichen Artikel!
Hast Du in der beschriebenen Konfiguration eventuell auch schon einmal die zertifikatsbasierte Authentifizierung am Exchange (wahlweise auch an der UTM) beim ActiveSync hinbekommen?
Bei mir will es einfach ohne DNAT-Regel nicht funktionieren. Leider kann ich die Mobilgeräte nach Vorgabe nur per Zertifikat anbinden. Idealerweise würde die Prüfung des Zertifikats schon an der UTM stattfinden (wie beim TMG) – aber die kann das wohl nicht…
Viele Grüße,
Carsten
Brauchst Du nicht runterladen, einfach das „normale“ Software Appliance ISO installieren. Da sind VMWare Tools mit drin (genau wie auch für HyperV und Xen).
Wo kann man den „VMWare virtual appliance“ runterladen? Dann müsste ich nicht extra eine virtuelle Maschine bereitstellen. Ist die VM Aplliance auch kostenlos?
Servus,
mit AutoDiscover klappt es bei mir mit der 9.210 noch immer nicht. Hab das heute einen ganzen Tag in allen Variationen getestet (mit Exchange 2013 CU6). Soll es denn wirklich funktionieren? Die NTML Zeile im Changelog des Up2Date 9.210 ist ja nicht wirklich aussagekräftig, bezieht diese sich wirklich auf die WAF?
viele Grüße
der Janosch
Hallo,
habe auch gerade das Update auf 9.210 installiert. Aber leider auch noch keine Zeit gehabt, NTLM zu testen. Wie kann man das am Besten testen?
Gr
Hallo zusammen,
erst mal ein großes Lob für diesen Artikel. Ich habe mich mit dem Thema ziemlich intensiv beschäftigt. Die Sophos UTM ist mittlerweile mein absoluter Schwerpunkt. Das wichtigste, das Firewall Profil, fehlt leider in diesem Artikel.
Es gibt mehrere Varianten einen Exchange über das Firewall Profil abzusichern. Der von Sophos dokumentierte Weg ist der Weg des geringsten Wiederstandes. Ich habe die Beta Phase der 9.2 von Anfang bis Ende mitgemacht. Von daher weiß ich genau welche Möglichkeiten hier bestehen.
Ich persönlich ziehe es vor den sichersten Weg zu gehen. Das habe ich auch schon beim TMG so gehalten. Maßgeblich für die Sicherheit ist hier auch das „Rigid Filtering“, auf deutsch „strenge Filterung“. Man sollte aber auch beachten, wenn man diese Funktionalität nutzt, sollte man sich mit der Sophos UTM auch auskennen. Wenn ich Zeit habe werde ich mal ein Beispiel hier posten.
Ein einfaches Natten ist die unsicherste Methode. Angriffe finden heute auf dem Anwendungslayer statt und dafür kann man sich nunmal nur mit einer WAF schützen.
Etwas zu dem NTLM Problem. NTLM funktioniert nur für RPC over HTTPs. Das liegt daran das im Firewall Profil für Outlook Anywhere das Häkchen „pass Outlook Anywhere“ angehakt werden muss. Das bedeutet letztendlich nichts anderes, als dass der Datenverkehr ungefiltert durch die UTM durchgelassen wird. Das ist aber auch bei anderen alternativen Lösungen der Fall.
Von daher macht es auf jeden Fall Sinn für die anderen Dienste ein extra Firewall Profil zu erstellen und dann natürlich auch mehrere virtuelle Webserver zu erstellen.
Das wichtigste zum Schluß. Ab der Version 9.210 soll NTLM Paththrough funktionieren. Ich hatte bis jetzt noch keine Zeit das zu testen. Wenn jemand damit schon Erfahrungen gemacht hat kann er das hier ja posten. Eine Vorauthentifizierung auf der UTM funktioniert aber leider immer noch nicht mit NTLM.
vg
mod
Servus,
eine hässliche Variante bei zwei CAS-Servern wären natürlich 2 DNATs und darauf dann Round-Robin DNS. *duck-und-weg*
viele Grüsse
der Janosch
Hallo,
jetzt habe ich auch mal einen Client testen können.
Grundsätzlich funktioniert der Zugriff mit OA und NTLM, wenn mal die Serverkonfiguration manuell vornimmt. Per Autodiscover funktioniert es mit NTLM nicht.
Ebenso sehe ich bei mir, über OA, keine Öffentlichen Ordner. Das mag aber vielleicht mit einer internen Fehlkonfiguration zusammenhängen.
Gruß
Matthias
Hallo,
vielen Dank für den Guide, hat mir sehr weitergeholfen. Jedoch habe ich 2 Anmerkungen:
1.) Die Ausnahme mit /Microsoft-Server-ActiveSync/* wird keinen Erfolg bringen. Es sollte mit der Einstellung kein Smartphone den Exchange erreichen können. /Microsoft-Server-ActiveSync* brachte bei mir den Erfolg.
2.) Entweder habe ich es übersehen, oder das Firewall-Profil wurde nicht dokumentiert. Da dies an sich das A und O ist, sollte das nachgeholt werden.
Hi Ralf,
danke für die schnelle Rückmeldung.
Bisher habe ich es nur über den Remote Connectivity Analyzer von MS getestet. Einen Client knüpfe ich mir heute mal vor, vielleicht klappt es ja dann. Man kann ja nie wissen.
Gruß
Matthias
Schade, ein nachträgliches Editieren meines Beitrages wäre schön gewesen. Hab erst zu spät gemerkt, wieviele Fehler da drin sind :). Man möge es mir nachsehen.
Ralf
Hi Matthias,
habe nochmal geschaut. Ich nutze die Funktionalität vom meinem Arbeitsnotebook, um auf meinen privaten Mailserver per Anywhere zuzugreifen. Dahe rbin ich nicht in der Domäne. DIe EInstellungen auf Exchangesete habe ich geprüft. Steht alles auf NTLM. Ichs ehe auch im Outlookprofil unter Proxyeinstellungen, dass er diese Einstellungen korrekt gesetzt hat
(Proxyautheinstellungen = NTLM)
Bei Notebookneustart werde ich einmalig nach Benutzername/Passwort gefragt. Schliesse ich dann Outlook und öffne es wieder, erfolgt keine Passwortabfrage mehr bis zu nächsten Rechnerneustart. Ich konnte es allerdings noch nicht extern mit Domänenrechner testen aus zeitlichen Gründen.
Rein von der Konfig her muss ich aber davon ausgehen, dass es funktioniert, weil ich keine Aushandlung, sondern explizit NTLM eingestellt habe.
Gruß,
Ralf
Hallo Frank,
wirklich eine sehr hilfreiche Anleitung. Leider funktioniert es bei mir auch nur ohne NTLM.
@Ralf
Auch mit dem neusten Update auf UTM Version 9.206-35 klappt es bei mir mit NTLM nicht. Hast Du noch Einstellungen angepasst?
Gruß
Matthias
Hi Frank,
Danke für deine anschauliche Erklärung zur Einrichtung der Reverseproxyfunktionalität für einen Exchange 2013. Ich hab mir das mal von deiner Anleitung abgeleitet und verwende ein kostenloses StartSSL Zertifikat (Singlename) auf der Sophos aka Astaro. Intern nutze ich ein SAN Zert von der eigenen CA.
Auch ich habe mich an die Umsetzung internal=external URL gehalten (intern mit PinPoint Zone) und bei mir ist für Anywhere in wie extern NTLM gesetzt. Meine Sophos hat FW Stand
Firmware version: 9.206-35
Pattern version: 66845
und ich konnte sowohl Active Sync, OWA als auch Anywhere von extern problemlos nutzten.
Natürlich werde ich, weil ich Outlook extern von einem Nicht Domänencomputer testweise eingerichtet hatte beim Start nach Benutzername/Passwort gefragt. Das werde ich nochmal gegenprüfen, wenn ich ein passendes Gerät habe. Aber grundsätzlich sieht es bisher gut aus. Redirekt -> /owa geht auch…insgesamt hat Astaro/Sophos die Reverseproxyfunktionalität nun scheinbar ganz gut implementiert bekommen. Gruß, Ralf
Hi Frank,
vielen Dank für den ausführlichen Bericht und die Mühe! So wie es aussieht, kann ich mir die Tests dann erst mal sparen. Ich verwende intern und extern nur noch NTLM für Outlook Anywhere, denn sobald Basic-Auth (auch nur bei externer OA-Konfiguration bei EX 2013) ins Spiel kommt, provoziert man das Anmelde-Popup Phänomen in diversen Szenarien. Verliert Outlook die Verbindung zu Exchange auf Grund eines kurzen Timeouts, dies kan eine Netzwerkstörung sein, ein Schwenk der aktiven Datenbank oder auch die Herausnahme eines CAS-Servers, probiert Outlook seine vordefinierten Verbindungsmöglichkeiten durch – darunter ist dann auch eben externes OA mit Basic-Auth.
Dies irritiert die Benutzer schon sehr, schlimm wird es, wenn sie dann anfangen die PWs an ihren W7-Clients für die Basic-Anmeldung zu speichern und eine PW-Policy im Spiel ist., dann ist der Ärger erst Recht vorprogrammiert.
Solange OA komplett auf NTLM konfiguriert ist, gehen eigentlich alle Szenarien im Betrieb, bei Wartung oder auch Ausfällen einzelner Knoten, relativ glatt mit kurzen Aussetzern und Reconnects – aber eben ohne Anmelde-Popups. Auch in großen Umgebungen mit Usern im Online-Modus gibt es da bisher keine Schwierigkeiten.
Hi, I will try in english…sorry my german in bad in writing :-)
The above works! – thanks for that. But the internal users, sitting before the UTM, they use NTLM, when I switch the virtual directories to basic, they start getting password prompts when manually downloading the OAB or starting outlook.
I use split-dns, having the same hostname internally and externally.
How can we solve this? – or can it be solved at all until Sophos makes NTLM pass through, or do I have to use different hostnames for internal and external Outlook Anywhere?
Regards Martin :-)
Es scheint ja auch ein Problem mit EWS und MacOS zu geben.. Weiß man da schon genaueres?
Hast Du meinen Ausgabe von Get-OutlookAnywhere mal versucht bei Dir zu setzen?
Also die -IISAuthenticationMethods auf alle drei Modi zu stellen?
Den 412 Fehler bekommst du weg, wenn Du in der Exception unter Advanced den Haken bei „Never change HTML during URL Hardening or Form Hardening“ setzt.
Hallo Ulrich, vielen Dank für den Tipp. Habe es direkt mit aufgenommen. Gruß, Frank
PS: Den OAB Download kannst du direkt aus Outlook heraus testen -> Senden/empfangen -> Senden-Empfangen-Gruppen -> Adressbuch herunterladen. Hast du einmal getestet, wie es mit der Einrichtung eines neues Profils ausschaut?
ah.. nicht bist zum Ende gelesen.. Hatte das FW Profil weiter oben erwartet. :-)
Hallo Frank,
wieder einmal eine gute Anleitung.
Du verschweigst aber dein Firewall Profil „Exchange Services“ für die WAF.
Beim Exchange 2013 habe ich die Authentifizierung für Outlook Anywhere umgestellt:
Get-OutlookAnywhere liefert nun:
ExternalClientAuthenticationMethod : Ntlm
InternalClientAuthenticationMethod : Ntlm
IISAuthenticationMethods : {Basic, Ntlm, Negotiate}
Wie kann man den OAB Download testen? Fehlermeldungen erscheinen bei mir nicht.
Grüße,
Uli
Hi Frank,
wir stellen jetzt auch gerade auf die UTM von TMG um. Grob geht ertmal alles.
Wir haben noch exchange 2003. Offen ist:
– OWA login seite mit passwort Änedrungsmöglichkeit
– Verschiedene Logins , mal mit Domäne , mal nur username
Hast Du ein Form Template für die UTM für OWA?
Gruß
Frank
Sehr schöner Beitrag! Bleibt nur die Frage nach dem Best Practice internal und external URL gleich zu halten. Das erfordert ja z.B. Split-DNS. Ist das keine fiese Fehlerquelle? Ich habe sowas immer versucht zu vermeiden. Wie löst du das in der Praxis? Split-DNS oder DNS Views?
Internal und External URL gleich zu halten ist kein Muss. Bei Exchange 2010 war es noch Best Practise Interne und Externe URL unterschiedlich zu konfigurieren. Je nach Umgebung würde ich dieses Konzept auch beibehalten.
Gruß, Frank
Hi Ihr,
also ich hab meinen Front-End-Server auch via DNAT, nur 443, direkt im Internet stehen und bis jetzt ist nichts passiert. Auch weiß ich von 3 Exchange-Provider das deren Frontend-Kisten auch nicht durch irgendwelches WAFs gesichert sind. Das einizige was ich gemacht habe ist den Frontend-Server in ein eigenens „DMZ“-Netz zu legen.
Grüße Michael
Hallo,
bei einem DNAT Eintrag hast du aber das Problem das nur eine Destination IP angeben kannst. Bei einem einzelnen CAS Server geht das noch, bei mehreren wird es schwierig. Dort kommen dann wieder Loadbalancer ins Spiel, die aber teilweise schon Funktionen einer Application Firewall mitbringen. Warum also diese nicht nutzen? Ich persönlich würde mich immer gegen einen NAT Eintrag in das private LAN entscheiden. Gerade bei einem Dienst an dem viele Komponenten beteiligt sind (Windows Server, IIS, .NET, Exchange) habe ich doch Unbehagen, diesen per NAT im Internet verfügbar zu machen. Einen CAS-Server in eine DMZ zu hängen und zwischen CAS und Mailbox Role eine Firewall zu haben, könnte dir einen Spass mit dem MS-Support bescheren ;-) Das ist aber nur meine Meinung.
Gruß, Frank
Ich bin mal echt gespannt! Erst mal vielen Dank für die Mühe das mal auseinander zu reißen. Ich finde es extrem frech das Sophos so krank Marketing bewirbt um den TMG zu ersetzen. Vielleicht bei Kunden die das als Default-Gateway hatten aber ganz ehrlich? Wofür haben Kunden überhaupt TMG gekauft? Weil sie alle Exchange Webdienste perfekt absichern wollten.