Like Exchange 2013, Exchange 2016 comes with a web interface for administration (EAC), which can be used to carry out basic administration tasks. However, simple administration via the web interface also entails risks.
For example, if you make Exchange 2016 and Exchange 2013 servers accessible on the Internet so that OWA, ActiveSync and Outlook Anywhere can be accessed, the admin interface is usually also connected to the Internet.
I always feel a little queasy when administration interfaces are accessible directly from the Internet, even if strong passwords are assigned. If you feel the same way, you can read on now.
Background
The EAC is accessed via the ECP virtual directory. This can be clearly seen in the following screenshot:
The ECP directory is logically provided by the IIS server:
However, the ECP directory has 2 functions, on the one hand the EAC and on the other hand the account settings for users are also published via ECP. This can be seen here:
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.
Restricting ECP on the IIS server using IP filters is also problematic:
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.
Solution
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
After the value has been changed, the IIS must be restarted (iisreset). However, there is also a problem here, as the parameter completely deactivates the EAC. Both internally and externally:
Microsoft recommends an additional Exchange Server at this point, in principle at least one Exchange Server with AdminEnabled=True and one with AdminEnabled=False. For small environments with only one Exchange Server, this is not really a solution.
EAC Workaround
As I only have one Exchange server in my private environment, I use a small workaround. I have created two ECP directories on an Exchange server, each with different ports. Here is the configuration:
Create a new website in the IIS:
After the new website has been added, the bindings must be adjusted:
The virtual directories can now be created using the Exchange Management Shell:
New-EcpVirtualDirectory -Server mail -WebSiteName "Admin EAC" New-OwaVirtualDirectory -Server mail -WebSiteName "Admin EAC"
It now looks like this in the IIS:
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:
Administration now takes place via port 4444 (Admin EAC), user access, whether internal or external, runs via port 443 (default web site). Port 443 can therefore be released on the Exchange server via NAT without making the EAC available. Administration from the internal network is then carried out via port 4444.
This also works with Sophos UTM, as described here:
https://www.frankysweb.de/sophos-utm-9-4-waf-und-exchange-2016/