Exchange 2016 bringt wie auch Exchange 2013 eine Weboberfläche zur Verwaltung mit (EAC), auf der die grundlegenden Tätigkeiten der Administration erledigt werden können. Allerdings bringt die einfache Administration via Webinterface auch Risiken mit.
Wer zum Beispiel Exchange 2016 und auch Exchange 2013 Server im Internet erreichbar macht, damit auf OWA, ActiveSync und Outlook Anywhere zugegriffen werden kann, hängt meistens auch die Admin Oberfläche ins Internet.
Mir wird immer etwas mulmig, wenn Administrationsoberflächen direkt aus dem Internet zugänglich sind, auch wenn starke Kennwörter vergeben werden. Wem es genauso geht, kann jetzt weiterlesen.
Hintergrund
Die EAC wird über das virtuelle Verzeichnis ECP angesprochen. Im folgenden Screenshot ist das gut zu erkennen:
Das Verzeichnis ECP wird logischerweise vom IIS-Server bereitgestellt:
Allerdings hat das ECP Verzeichnis 2 Funktionen, zum einen die EAC und zum anderen werden via ECP auch die Kontoeinstellungen für Benutzer veröffentlicht. Dies lässt sich hier erkennen:
Die Tatsache das via ECP zwei unterschiedliche Oberflächen hinter einem virtuellen Verzeichnis hängen, ist meiner Ansicht nach etwas unglücklich gelöst. Ein weiteres Verzeichnis wie etwa „Admin“ wäre meiner Meinung nach schöner, denn dann könnte man den Zugriff entsprechend an der Firewall regeln. Wer Exchange mittels NAT veröffentlicht hat, guckt dann natürlich immer noch in die Röhre.
Auch ECP am IIS-Server mittels IP-Filter einzuschränken, ist problematisch:
Mittels „IP- und Domäneneinschränkungen“ lässt sich zwar nur das interne Netzwerk erlauben, aber das deaktiviert für alle externen Benutzer die Konteneinstellungen.
Lösung
Es gibt für das ECP Verzeichnis den Parameter „AdminEnabled“, per Default steht der Patameter auf dem Wert „True“, welches die EAC einschaltet. Um also die EAC abzuschalten, kann dieser Parameter einfach auf „False“ gesetzt werden. So bleiben die Kontoeinstellungen für Benutzer erreichbar, nur eben das Admin Interface wird abgeschaltet:
Get-EcpVirtualDirectory -Server mail | Set-EcpVirtualDirectory -AdminEnabled:$false
Nachdem der Wert geändert wurde, muss der IIS neugestartet werden (iisreset). Allerdings gibt es auch hier ein Problem, denn der Parameter deaktiviert die EAC komplett. Intern, sowie extern:
Microsoft empfiehlt an dieser Stelle einen weiteren Exchange Server, im Prinzip also mindestens einen Exchange Server mit AdminEnabled=True und einen mit AdminEnabled=False. Für kleine Umgebungen, mit nur einem Exchange Server also auch keine wirkliche Lösung.
EAC Workaround
Da ich in meiner privaten Umgebungen auch nur einen Exchange Server habe, nutze ich einen kleinen Workaround. Ich habe zwei ECP Verzeichnisse auf einem Exchange Server angelegt, jeweils mit unterschiedlichen Ports. Hier die Konfiguration:
Neue Website im IIS anlegen:
Nachdem die neue Website hinzugefügt wurde, müssen die Bindungen angepasst werden:
Jetzt können per Exchange Management Shell die virtuellen Verzeichnisse angelegt werden:
New-EcpVirtualDirectory -Server mail -WebSiteName "Admin EAC" New-OwaVirtualDirectory -Server mail -WebSiteName "Admin EAC"
Im IIS sieht es jetzt so aus:
Für ECP in der „Default Web Site“ kann EAC jetzt abgeschaltet werden:
Get-EcpVirtualDirectory "ecp (Default Web Site)" | Set-EcpVirtualDirectory -AdminEnabled:$false
Der Zugriff auf EAC erfolgt nun über den konfigurierten Port der Website „Admin EAC“. Ich nutze hier Port 4444, jeder andere freie Port ist aber ebenso nutzbar:
Die Administration erfolgt jetzt über Port 4444 (Admin EAC), der Zugriff der Benutzer, egal ob intern oder extern, läuft via Port 443 (Default Web Site). Somit kann Port 443 auf den Exchange Server via NAT freigegeben werden, ohne die EAC verfügbar zu machen. Aus dem internen Netzwerk wird dann per Port 4444 administriert.
Das funktioniert ebenfalls mit der Sophos UTM, wie hier beschrieben:
https://www.frankysweb.de/sophos-utm-9-4-waf-und-exchange-2016/