Vor kurzen hatte ich den Aufbau einer kleinen Exchange Organisation inklusive der Einrichtung der Sophos UTM 9.4 für die Veröffentlichung der Exchange Webservices beschrieben. In den Kommentaren zu den Beiträgen wurde nach der Möglichkeit gefragt die Authentifizierung direkt an der UTM durchzuführen und nicht erst am Exchange Server. Microsoft Forefront TMG hatte diese Funktion ebenfalls. Das Feature bei der Sophos UTM dazu nennt sich „Reverse Authentication (in der deutschen Version: Umkehrauthentifizierung) “ und kann ebenfalls in Verbindung mit Exchange genutzt werden:
Umstellung Exchange 2016 für Basic Authentication
Damit die Reverse Authentication der Sophos UTM funktioniert, muss die Authentifizierungsmethode für OWA und ECP auf „Basic- Auth (Standardauthentifizierung)“ umgestellt werden. Die Art der Authentifizierung lässt sich über das EAC einstellen:
Gleiches gilt auch für /ECP:
Nachdem die Authentifizierung für beide Virtuellen Verzeichnisse umgestellt wurde, muss noch der IIS neugestartet werden (iisreset):
Weiter geht es mit der UTM
Konfiguration Sophos UTM für Reverse Authentication
Voraussetzung für die Reverse Authentication ist eine eingerichtete und funktionierende Webserver Protection (WAF). Wie die Einrichtung für Exchange 2016 funktioniert habe ich hier bereits beschrieben:
Die Konfiguration aus dem oben genannten Artikel kann nun verwendet werden und um das Feature Reverse Authentication erweitert werden.
Damit Exchange-Benutzer erfolgreich an der UTM authentifiziert werden können, muss ein Authentication Server vom Typ „Ldap“ angelegt werden:
Hinweis: Der Backend Typ muss hier „LDAP“ sein, beim Backend Typ „Active Directory (adirectory)“, funktioniert die Anmeldung an OWA nicht und es poppt immer wieder ein Anmeldefenster auf. Es können an der UTM allerdings beide Typen konfiguriert sein, sowohl Active Directory und auch LDAP.
Auch wenn der Backend Typ „LDAP“ ist, wird ein Domain Controller, oder ein Domain Controller Pool, als Server definiert. Für die Abfrage wird ein normaler Domain Benutzer und dessen Distinguished Name (BindDN) benötigt:
Der Distinguished Name lässt sich am schnellsten per Powershell anzeigen:
Get-ADUser SophosUTM | fl name,DistinguishedName
Das Feld „User attribute“ wird auf „>“ umgestellt und im Feld „Custom“ der Wert „userPrincipalname“ eingestellt. Ein Test sollte dann erfolgreich sein:
Konfiguration Sophos UTM WAF für Reverse Authentication
Um die Authentifizierung an der Sophos UTM durchzuführen, muss ein Authentication Profile angelegt werden:
Die relevanten Einstellungen können dem Screenshot entnommen werden. Als Logout URL wird der folgende Wert benutzt „/owa/logoff.owa“.
Damit das Authentication Profile angewendet wird, müssen jetzt noch zwei Site Path Routes erstellt werden, eine für OWA und eine für ECP:
Sobald die beiden Site Path Routes erstellt wurden, erscheint beim Aufruf von OWA nicht mehr das Exchange Formular für die Eingabe von Benutzernamen und Kennwort, sondern das UTM Formular:
Der Benutzername muss in diesem Fall als UPN angegeben werden:
Die Konfiguration eines Suffix im Authentication Profile scheint nicht zu funktionieren.
Hallo Zusammen, hätte das auch gegen den Hafnium Angriff geholfen? Oder wäre es per ActiveSync durchgegangen?
Hallo Franco,
durchgegangen wäre es. Der Vorteil ist jedoch, dass der Exchange Server nach Außen hin verschleiert wird, da die UTM einen Apache Server als Reverse nutzt. Der Exchange Server bzw. der IIS wird somit nicht als solcher angezeigt und taucht auch nicht als solcher in Suchmaschinen wie Shodan auf, wenn man gezielt nach Exchange Servern sucht.
Bei mir funktioniert nach der Umstellung der Abruf per iPhone nicht mehr. Hat jemand eine Lösung?
…du musst ein SitePathRouting für den Active Sync einrichten:
/Microsoft-Server-ActiveSync als Pfad nehmen ohne Reverse Authentication.
Hi Frank,
habe deine Anleitung befolgt mit einer kleinen Änderung. Meine Frage ob das jetzt ein Nachteil ist.
Exchange steht immer noch auf „Formularbasierte Authentifizierung verwenden“. Auf der Sophos habe
ich statt „userPrincipalName“ -> sAMAccountName verwendet. Nun wird der Login direkt mit den AD Username
durchgereicht.
Hallo Sebastian,
welche Einstellungen hast du verwendet, dass die Formularbasierte Authentifizierung“ funktioniert?
VG Horst
Die Änderung aus dem Technet Forum funktioniert ja prima für die Desktop Browser.
Hat schon einer was für die mobilen Browser herausgefunden?
Das man sich nicht abmelden kann ist schon irgenwie unverschämt von Microsoft.
Hallo Andre,
Es freut mich, dass es auch bei Dir funktioniert. Leider habe ich festgestellt, dass Microsoft bei jedem Update diese Datei wieder in den ursprünglichen Zustand zurücksetzt. Das nervt ein wenig.
Außerdem gilt diese Version nur für die Windows basierten Browser. Die Datei für die mobilen Browser hab ich leider noch nicht gefunden :-(.
Schönen Gruß,
Florian
Hallo Florian!
Danke für deinen Tipp!
Ich habe es auch so hinbekommen.
in der Firewall den Logoutlink ‚ /owa/auth/signout.aspx ‚ eingetragen und die .js Datei bearbeitet mit dem Inhalt von FBrandl:
$(document).ready(function(){ $(‚._ho2_2‘).click(function () { $(‚body > div:last-child ._abs_c div[role=menu] > div > div:last-child > button‘).on(‚click‘, function () { window.location.href= ‚./auth/signout.aspx‘}) }) });
so ist auch kein weiterer Login durch das Aufrufen der OWA-Oberfläche möglich.
LG
Hallo,
ich hatte das gleiche Problem mit der Basic Authentication und Exchange 2016 CU8. ich bin auf meiner Suche nach einer Lösung (Microsoft selbst bietet da grad nichts wirklich brauchbares) auf folgenden Thread im Microsoft Technet Forum gestossen:
https://social.technet.microsoft.com/Forums/windowsserver/en-US/71462d67-f05b-4d74-af63-b22f3dea35d7/exchange-2016-logoff-does-not-generate-logoff-request?forum=Exch2016GD
Nach einer kleinen Änderung läuft dieses bei mir (fast) ohne Probleme.
Wär mal interessant, wie Ihr das seht.
Schönen Gruß,
Florian
Hab das gleiche Problem das der Logoff nicht korrekt funktioniert. Er sagt nur Fenster schließen das wars. Danach kann ich mich aber wieder einloggen ohne Kennwort Eingabe. Gibt eine Lösung? Hatte das gefunden:
https://blogs.technet.microsoft.com/exchange/2015/01/12/owa-forms-based-auth-logoff-changes-in-exchange-2013-cumulative-update-8-and-good-news-for-tmg-customers/
Hallo Frank,
erst einmal vielen dank für den super Beitrag.
du schreibst, das bei dir die Authentifizierung über AD nicht funktioniert hat und du deshalb LDAP verwendet hat.
ich wollte aber das die Benutzer sich nur mit Ihrem Benutzernamen und nicht mit Ihrem UPN anmelden können.
zuerst hatte ich das gleiche Problem wie du.
Nachdem ich mich mit Benutzername an der Sophos Authentifiziert habe bekam ich eine zweites Login vom Exchange OWA.
Ich habe herausgefunden das ich mich an der Sophos, wenn ich diese auf AD Authentifizierung umstelle, nur mit dem Benutzer anmelden kann (kein UPN, kein Domäne\Benutzer).
Mein Exchange verlangt im OWA aber Domäne\Benutzer oder UBN beim Login.
Somit kann es nicht funktionieren, da die von der Sophos weitergegebenen Zugangsdaten nicht das richtige Format haben.
Um das Problem zu lösen habe ich am Exchange die Authentifizierung so umgestellt das ich mich am OWA auch nur mit Benutzername anmelden kann.
Meine verwendete Zauberformel war:
Set-OwaVirtualDirectory „owa (Default Web Site)“ -LogonFormat Username -DefaultDomain domäne.local
Danach noch den IIS neu starten:
iisreset
Vielleicht konnte ich dir mit diesem Post zur Abwechslung auch mal helfen!
mfg
Kai
Hat jemand denn mittlerweile mal eine wirkliche Lösung für den Logoff?
Weil weder intern noch extern funktioniert es, auch wenn ich die Seite schließe bin ich bei erneutem Öffnen der URL sofort wieder eingeloggt.
Hallo Sebastian,
die Benutzer müssen dann einfach über die externe URL auf OWA zugreifen und du musst sicherstellen das die URL im internen DNS nicht direkt auf den Exchange aufgelöst wird.
Hallo Frank,
danke für die schnelle Antwort.
Wie kann ich denn die internen Benutzer dazu bewegen, das sie über die UTM auf OWA zugreifen?
Gruß
Sebastian
Hallo Frank,
klasse Anleitung, ich habe die zur Absicherung des Exchange mit der UTM 9.4 umgesetzt und es funktioniert einwandfrei.
Meine Frage zu diesem Thema ist, sobald ich das Virtuelle Verzeichnis auf Standard-Authentifizierung stelle, erhalten die internen Benutzer die sich am OWA anmelden nicht mehr die gewohnte OWA Anmeldeseite.
Gibt es eine Möglichkeit das zu ändern?
Danke und Gruß
Sebastian
Hi Sebastian,
die Sophos Login Seite lässt sich austauschen:
https://www.frankysweb.de/sophos-utm-login-template-fr-exchange-2016/
Wenn interne Benutzer nicht über die WAF der UTM auf OWA zugreifen, könnte man entweder Windows Authentifizierung aktivieren, damit sich interne AD-Benutzer nicht anmelden müssen, oder aber zwei OWA Directorys anlegen, eins für die UTM mit Standard-Auth und eins für interne Benutzer mit Forms Based Auth.
Gruß, Frank
Danke für die Info :-) Ich habe jetzt anders als in deinem Tutorial nicht gegen Ldap Users sondern gegen Active Directory Users authentifiziert. Damit funktionieren auch Logins mit Vorname Nachname ohen Prä oder Suffix. Spricht da etwas Sicherheitstechnisch dagegen?
Hi Marco,
mittels AD Auth wollte es bei mir nicht klappen, daher der Weg via LDAP. Aus meiner Sicht spricht nichts gegen AD Auth, ggf. sollte nur der Benutzerkreis eingeschränkt werden.
Gruß, Frank
Hi,
danke für die immer wieder hilfreichen Anleitungen! Ich habe jetzt WAF nach deiner Anleitung eingerichtet, und wollte nun auch die Reverse Auth in Betrieb nehmen, allerdings habe ich nun das Problem der Benutzernamen.
Meine Domänenbenutzer haben alle vorname Nachname@firma.local, also mit leerzeichen. Ist aus der Vergangenheit so mitgeschleppt. Die mailadressen lauten vorname.nachname@firma.de. Nun müsste ich meinen Leuten ja beibringen sich bei OWA mit vorname nachname@firma.local anzumelden. Gibt es evtl einen eleganteren Weg das zu lösen ohne die gesamte Domänenanmeldung umzustellen? Weil ohne Reverse kann ich ja zumindest den Domänennamen mitgeben.
Gruß
Marco
Hi Marco,
es gibt die Möglichkeit ein Suffix und Präfix mitzugeben, sodass nur der Benutzername abgefragt wird. Ich habe das allerdings nicht lauffähig bekommen, mich aber auch nicht weiter damit beschäftigt.
Gruß, Frank
Hallo zusammen,
erst mal danke an Frank für die tollen Guides und die viele Arbeit die dahinter steht!
Als kleinen Beitrag dazu:
Ich habe heute eine Exchange 2010 OWA mit ReverseAuth veröffentlicht und als Abmelde URL funktioniert „/owa/auth/logoff.aspx*“ wunderbar!
Werde beim klick auf abmelden im OWA direkt ans UTM Reverse Login Template weitergeleitet.
Grüße,
Norman
Hallo Frank,
zunächst ein herzliches Danke für den tollen Blogpost und die Arbeit, die dahinter steckt! Allerdings habe ich noch eine Frage, die du mir hoffentlich beantworten kannst: kann diese Authentifizierung in Verbindung mit einem eToken verwendet werden?
Freundlich grüßt
Alex
Hi Alex,
die UTM unterstützt OATH-TOPT, es müsste also mit eTokens für 2Faktor Auth funktionieren. Getestet habe ich das allerdings nicht.
Gruß, Frank
Hallo Franky,
erstmal herzlichen Dank für die Mühe und die klasse Anleitung. Ich bin nach dieser vorgegangen, jedoch kommt nach dem Sophos Login (mit Deinem Template) allerdings nochmal der originale Anmeldeschirm vom Exchange/Outlook Web App.
Die Authentifizierung für OWA und ECP sind bei mir auf Basic.
Hast Du ne Idee?
Hallo Ulrich,
hallo Frank,
gibt es eine Lösung für das „Problem“ ?
Die Einstellungen sollten ja schon zu ändern sein, aber /ecp von außen frei zugänglich zu machen ist schon ein erhebliches Risiko.
Was kann man tun?
Danke und Gruß
Urs
Hi Urs,
Ich denke es geht um die EAC: https://www.frankysweb.de/exchange-2016-eac-nur-im-internen-netzwerk-freigeben/
Gruß, Frank
Wenn /ecp von außen gesperrt ist, kann ein Nutzer von außen auch seine Einstellungen/Optionen nicht ändern. Das sollte man dabei bedanken.
Hallo Wolfgang,
ist bei mir mit Sophos auch so – ausloggen geht nicht, man muss das Fenster schließen.
Gruß Urs
Stimmt, das tritt bei mir auch auf, werde dem noch einmal nachgehen.
Gruß, Frank
Hallo Frank
danke für die Anleitung eine Frage dazu – Funktioniert der “/owa/logoff.owa” bei Sophos? Bei KEMP hatte ich immer das „Problem“ das man das komplette Fenster schließen muss – laut Kemp ein Exchange Thema.
Danke für die Info
Grüße
Wolfgang
Hallo Franky,
tolle Anleitung !!
Eine Detailfrage dazu:
/ecp würde man von extern ungern erreichbar machen.
Wie ist das zu konfigurieren damit /ecp von intern funktioniert aber von extern nicht?
Danke und Gruß
Urs
Hi,
entweder über einen anderen Port (was allerdings etwas fummelig ist):
https://www.frankysweb.de/exchange-2016-eac-nur-im-internen-netzwerk-freigeben/
oder über eine zweite IP-Adresse.
Gruß, Frank