In Teil 1 wurde bereits die Grundkonfiguration der Sophos XG in Verbidnung mit Exchange 2016 durchgeführt, es fehlt allerdings noch etwas Konfigurationsarbeit damit auch Outlook Anywhere, MAPIoverHTTP und die REST Api funktionieren. Wie bereits in Teil 1 erwähnt sind die Sophos Vorlagen für Geschäftsanwendungen etwas veraltet, daher muss hier manuell nachgebessert werden. Etwas irritierend ist, dass es drei Vorlagen für Exchange gibt. die Vorlage “Exchange General” behandelt die klassischen Webservices, wie OWA, EWS und ActiveSync, enthält aber auch noch völlig veraltete Pfade für OMA (Outlook Mobile Access), welches schon lange keine Verwendung mehr findet.
Wenn die drei Standard Vorlagen genutzt werden, ist es erforderlich die Exchange Webservices (OWA, EWS, ActiveSync, etc), Autodiscover und Outlook Anywhere (RPC, MAPI) von einander zu trennen. Dies bedeutet allerdings auch, dass ein SAN Zertifikat mit drei Namen (Subject Alternate Names) verwendet werden muss.
Es geht auch etwas schöner, zumindest für die aktuellen Protokolle.
Umleitung von “/” nach ”/owa”
Mit den Standard Regeln wird beim Aufruf von des Root-Folders nur eine 404-Fehlerseite angezeigt:
Normalerweise führt hier der Exchange Server den Redirect nach /owa durch. Um dies zu erreichen kann die Regel “Exchange 2016 Webservices” angepasst werden:
Im Abschnitt “Geschützte Server” kann jetzt ein neuer Pfad hinzugefügt werden:
Hier wird ein Schrägstrich “/” als Pfad eingetragen und der Exchange Server als Webserver ausgewählt. Authentifizierung bleibt leer:
Danach wird im Abschnitt “Exceptions” eine neue Ausnahme angelegt:
Als Pfad wird wieder ein Schrägstrich “/” eingetragen und “Statisches URL-Hardening” als Prüfung ausgeschlossen:
Die Firewall Regel kann jetzt gespeichert werden und schon funktioniert die Umleitung nach /owa wieder.
MAPIoverHTTP (/mapi)
MAPIoderHTTP kann ebenfalls recht einfach aktiviert werden. Es wird wieder die Regel “Exchange Webservices” editiert:
Diesmal werden im Bereich “Geschützter Server” zwei neue Pfade angelegt:
Hier werden jetzt die Pfade “/mapi” und “/MAPI” angelegt. Webserver ist wieder der Exchange Server, Authentifizierung bleibt leer:
Nachdem die beiden Pfade angelegt wurden, sieht es wie folgt in der Übersicht aus:
Zum Schluss muss noch die schon vorhandene Expeption editiert werden:
In die Liste der Pfade für die Ausnahme werden jetzt die beiden Pfade “/mapi/*” und “/MAPI/*” hinzugefügt:
Die Liste der Ausnahmen sieht nun wie folgt aus:
Hinweis: Als ich diesen Screenshot erstellt habe ist mir aufgefallen, dass ich vergessen habe die Ausnahmen für “/oma/*” und “/OMA/*” zu löschen (Blauer Kasten). Diese beiden Pfade können ersatzlos gelöscht werden. Outlook Mobile Access (OMA) wird schon lange nicht mehr verwendet und ist auf einem Exchange 2016 Server nicht mehr verfügbar.
Nachdem die Firewall Regel gespeichert wurde funktioniert MAPIoverHTTP (Das neue Outlook Anywhere).
REST API (/api)
Mit dem Stand CU4 für Exchange 2016 ist die REST-Api zwar noch nicht offiziell freigegeben, aber immerhin schon für Tests verfügbar. Die Standard Regeln berücksichtigen die neue API ebenfalls nicht, daher muss sie auf dem gleichen Weg wie MAPIoverHTTP freigegeben werden.
Hier wird wieder, wie schon bei MAPIoverHTTP, die Exchange Webservices Firewall Regel angepasst und zwei neue Pfade hinzugefügt. Diesmal “/api” und /”API”:
In die vorhandene Ausnahmeliste werden dann die Pfade “/api/*” und “/API/*” angegeben:
Jetzt sollte die Ausnahmeliste wie folgt aussehen:
Die Firewall Regel kann nun gespeichert werden und die REST-API funktioniert.
RPCoverHTTP (/rpc)
Bei dem klassischen Outlook Anywhere (RPCoverHTTP) wird es schon etwas trickreicher. Hier empfiehlt es sich vorher zu überlegen, ob dieses Protokoll noch benötigt wird, denn alle von Exchange 2016 unterstützen Outlook Versionen sprechen auch MAPIoverHTTP.
Ich würde an dieser Stelle auf RPCoverHTTP verzichten, zumindest wenn wie in meinem Fall nur zwei Hostnames zur Verfügung stehen. Der Hintergrund ist, dass die meisten Schutzmechanismen der Webserver Protection für Outlook Anywhere abgeschaltet werden müssen. Dieses gilt dann auch für die restlichen Webservices wie OWA und EWS. Wenn Outlook Anywhere, also das klassische RPCoverHTTP noch benötigt wird, empfehle ich einen dritten Hostnamen in das Zertifikat aufzunehmen (bsp. rpc.frankysweb.de) und die Exchange Konfiguration auf diesen Hostnamen anzupassen (wie auch von Sophos vorgesehen). So lässt sich eine neue Geschäftsanwendungsregel aus der Vorlage nutzen, um nur die notwendigen Schutzmechanismen für Outlook Anywhere (RPCoverHTTP) zu deaktivieren und nicht auch gleich für alle anderen Dienste.
Ich habe es trotzdem ausprobiert, ob es möglich ist mit zwei Hostnamen und zwei Firewallregeln auszukommen: Ja, geht, ist aber Kacke, denn meiner Ansicht nach deaktiviert es faktisch die Webserver Protection. Nahezu alle Features müssen deaktiviert werden. Da ich diese Konfiguration für derart unsauber halte möchte ich es auch nicht veröffentlichen. Wer unbedingt darauf besteht, kann mir eine Mail schreiben und bekommt dann ein kleines HowTo.