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:
The fact that there are two different interfaces behind one virtual directory via ECP is, in my opinion, a somewhat unfortunate solution. Another directory such as "Admin" would be better in my opinion, because then you could control access at the firewall accordingly. Of course, anyone who has published Exchange using NAT will still be left out in the cold.
Restricting ECP on the IIS server using IP filters is also problematic:
Using "IP and domain restrictions", only the internal network can be allowed, but this deactivates the account settings for all external users.
Solution
There is the parameter "AdminEnabled" for the ECP directory, by default the parameter is set to the value "True", which switches the EAC on. To disable the EAC, this parameter can simply be set to "False". In this way, the account settings remain accessible for users, only the admin interface is switched off:
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:
EAC can now be switched off for ECP in the "Default Web Site":
Get-EcpVirtualDirectory "ecp (Default Web Site)" | Set-EcpVirtualDirectory -AdminEnabled:$false
EAC is now accessed via the configured port of the "Admin EAC" website. I use port 4444 here, but any other free port can also be used:
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/
Hatte die ganzen Jahre die von Franky oben beschriebnene Lösung am laufen.
Heute habe ich das Update Exchange2016-KB5030524-x64-de und CVE-2023-21709.ps1 eingespielt. Seit dem kommt beim Umschalten nach der Anmeldung auf den anderen SSL Port „Der eingegebene Benutzername oder das Kennwort ist ungültig. Wiederholen Sie die Eingabe, und versuchen Sie es noch mal.“
Habe auch das gleich Problem und keine Lösung.
N’abend zusammen. Auch nach 4,5 Jahren funktioniert die Anleitung noch ;-) aber leider mit einer Einschränkung: Wenn ich https://meinserver:4444/ecp aufrufe, werde ich zur Anmeldung an https://meinserver/owa/auth/logon.aspx?url=https%3a%2f%2flocalhost%2fecp%2f&reason=0 weitergeleitet. Leider sind die Auth-URL und die Rücksprung-URL ohne die Port-Nummer, so dass ich nach Eingabe der Credentials wieder im alten https://meinserver/ecp lande mit deaktiverten Admin-Features. Ich kann nach erfolgtern Anmeldung dann zwar die Adresse manuell auf https://meinserver:4443/ecp setzen und bin weiterhin angemeldet, aber schön geht anders. Hat jemand eine Idee, wie man sich von der Anmeldeseite korrekt weiterleiten lassen kann bzw. direkt auf die richtige A. Sämtliche Authentifizerungs-Einstellungen im IIS habe ich schon durch. Die haben keinen Einfluss auf das Verhalten. Sowohl für die Site als auch die virtuellen Verzeichnisse.
Gruß
Ben
Genau dasselbe Verhalten zeigt sich bei uns auch.
Hat jemand hierfür schon eine Lösung gefunden?
Hallo zusammen,
mittlerweile lässt sich ab Exchange 2016 ECP nur für den externen Zugriff sperren mittels IIS IP-Filter.
Genauer gesagt mit dem IIS Feature „IP- und Domäneneinschränkungen“ lässt sich nur das interne Netzwerk für ECP Zugriff erlauben.
Externe Clients/Benutzer können dann trotzdem noch auf ihre Kontoeinstellungen über OWA zugreifen, da sich die URL geändert hat: https://mail.domain.com/owa/#path=/options/mail
Anleitung:
„Installation von IP und Domäneneinschränkungen für IIS über den Server Manager.
Dann im IIS unter Default Website ECP auswählen und dort auf
Einschränkungen für IP Adressen und Domänen.
Dort wird ein neuer Zulassungseintrag erstellt, der alle lokalen Subnetze beinhaltet (Netzwerkadresse eintragen und im zweiten Feld 255.255.255.0).
Außerdem dann noch rechts im Menü unter „Featureeinstellungen bearbeiten“ Zugriff für nicht angegebene Clients auf
Verweigern setzen und Deny Action Type auf Not found.
Neustart des IIS anschließend“
Viele Grüße
Hallo Tobias,
vielen Dank für den guten Hinweis!
Gut, dass ich bei den älteren Artikeln immer auch die Kommentare lese..
:)
Hallo,
Danke für den Tipp! Funktionier einwandfrei.
Viele Grüße, Stefan
Hallo, das wäre eigentlich die einfachste Lösung! Habe alles so konfiguriert inkl. IIS-Neustart, aber der Zugriff auf EAC von beliebiger Quell-IP ist immer noch möglich, obwohl nur internes Netz erlaubt. was mache ich falsch?
MfG
Heiner
Daran habe ich mich auch gerade wund gesucht.
Grund ist das ich davor einen Proxy eingesetzt habe (SOPHOS UTM nach Frankys Anleitung).
Ich habe dann für den Proxy eine Verweigern Regel gesetzt.
Ich habe das gleiche Problem mit eine Sophos XG..
Wo hast du das verweigert?
und wie?
Top, läuft super :-)
Ist diese von Microsoft empfohlene Zwei-Server-Lösung mit einmal AdminEnabled True und einmal False auch mit einer Zwei-Knoten DAG (Exchange 2016 und Server2016) realisierbar, wenn nur einer der Knoten aus dem Internet erreichbar ist? Oder werden an den zweiten Server bestimmte Anforderungen gestellt?
Moin moin,
wir haben mit Exchange 2016 dasselbe Problem wie Patrick am 25. Mai 2016 um 15:28. Es werden in der EAC-Kopie keine OUs angezeigt, in der Default-Webseite hingegen schon. Bin ein wenig frustriert, da die Google-Suche von den „mehr als 500 OUs anzeigen“ zugespammt wird. Gibt es hier einen Ansatz?
Viele Grüße
Sven
Hab jetzt doch hinbekommen. Der Wer ist wie folgt:
1) In der ems das ecp Verzeichnis löschen (Remove -EcpVirtualDirectory -Identity ‚mail-server\ecp (Default Web Site)‘
2) iisreset
3) New-EcpVirtualDirectory -Server mail-server -ExternalURL https://mail-server/ecp -InternalURL https://mail-server/ecp
4) iisreset
Fertig.
Viele Grüße
Steve
Hey Frank,
ich bin deiner Anleitung leider auch erfolglos gefolgt. Seltsamerweise konnte ich mich immer noch sowohl extern als auch intern anmelden. Nun habe ich allerdings ein ganz anderes Problem. Ich habe alle Einstellungen wieder Rückgängig gemacht und alle extra gesetzten Einträge entfernt (Admin EAC website gelöscht, Virutall Directorys entfernt, die Anmeldungen als admin auf der Default Web Site auf „true“ gesetzt).
Jetzt kann ich mich nicht mehr im EAC anmelden. Ich komme ganz regulär auf die EAC login Maske, aber nach Eingabe von user / pw passiert nichts. iisreset und sogar Server Neustart wurden durchgeführt, allerdings ohne Erfolg. Ich weiß gerade aktuell leider nicht weiter und hoffe du kannst mir helfen.
Viele Grüße
Steve
Die von Thomas Lating beschriebene Lösung habe ich seit ca. 10 Monaten im Einsatz – läuft einwandfrei!
https://social.technet.microsoft.com/Forums/ie/de-DE/eacfa100-ef12-41e1-875e-aacb033eb023/exchange-server-2013-zugriff-auf-ecp-von-extern-verbieten?forum=exchange_serverde
fyi :)
@ Frank, evtl. solltest du diesen Workaround mal aktualisieren. Der Zählt ja auch für Exchange 2016 glaub ich ;)
Habe gerade nochmal alles in Gedanken durchgedacht. Ich bin da einen kleinen anderen Weg gegangen, da ich das Problem immer noch hatte. Ich habe eine zweite IP auf dem Server angegeben und für diese einen DNS Eintrag gemacht auf dem DC. Danach die ECP Website „kopiert“ über die Shell. Weitere Infos liefert dir Google garantiert zu dieser Art Workaround. Frank hatte ja auch auf meine Frage nicht geantwortet. So musste ich mir einen anderen Weg suchen ;)
@ Thomas,
danke für die Rückmeldung. Schön, dass es funktioniert.
Für mein Verständnis. Kannst du etwas genauer sagen, was Du gemacht hast?
Vermutung: Wenn ich die Verwaltungskonsole (EAC) mit dem IE 11 öffne, dann habe ich
eine Zertifikatswarnung. Das sowohl vor als auch nach „Franks Workaround“.
Grüße
@ Martin
Ich habe das doch noch hinbekommen. Es lag bei mir an den Zertifikaten. Habe über unsere „interne“ CA eins generiert für die Verwaltungs Website. Danach ist alles im grünen Bereich ;)
Diese Verhaltensweise kann ich leider bestätigen.
Hat jemand eine Lösung?
Ich habe auch das Problem wie Christian. Wie kann man diesen Fehler beheben?
Hat wunderbar geklappt. Vielen Dank. Nur ein kleines Problem gibt es.
Wenn ich auf Empfänger im Admin Center klicke, wird ganz rechts im Fenster ein Preview vom ersten User angezeigt.
So soll es auch sein.
Aber sobald ich einen anderen User klicke, erscheint nur “ Bitte warten Sie …“ und das bis das Fenster nichts mehr anzeigt.
Das ganze passiert nicht nur bei den Empfängern, sondern bei allen anderen Menüpunkten auch.
Sobald ich auf „ecp (default Web Site)“ den AdminEnabled:$true setze, funktioniert wieder alles ..!
Hallo Frank,
Super, genau das habe ich gesucht. Hat perfekt funktioniert. Wieder einmal ein Beitrag von dir, der mir super geholfen hat.
Danke und Gruß aus dem Sauerland von nebenan :-)
Hallo Franky,
danke für die Anleitung.
Bei unserem Exchange werden wir über Port 4444 ebenfalls wieder auf die Default Web Site auf „ECP“ umgeleitet.
Jemand eine Idee wo das Problem ist?
Hallo Franky,
meine vorangegangene Frage hat sich erledigt…
Allerdings: Sobald wir bspw. einen neuen Verteiler über ECP anlegen wollen, bekommen wir keine Auflösung der Organisationseinheiten. Über die Defaultwebsite funktioniert es ohne Probleme, fällt dir dazu etwas ein? Ansonsten finde ich das dieser Workaround eine wunderbare Lösung darstellt.
Danke und Gruß
Hallo Franky,
ich habe dasselbe Problem wie Steffen und werde aus deiner Antwort leider nicht ganz schlau. Ich habe deine Anleitung soweit Schritt für Schritt eingehalten, werde aber ebenfalls immer auf die Default Web Site weitergeleitet und lande somit in der beschränkten ECP Umgebung. Könntest du bitte etwas konkreter sagen, was du mit deiner Antwort meintest?
Danke und Gruß
Hi Franky,
so gehts auch, meiner Meinung nach die schönere Variante da keine Ports gedreht werden müssen:
http://anexinetisg.blogspot.de/2014/06/disable-external-access-of-exchange.html
Wichtig !!
Damit die 2te IP Adresse nicht im DNS registriert wird und somit Autodiscover auf ein falsches Zertifikat läuft, muss die IP wie folgt gesetzt werden:
netsh interface ipv4 add address Ethernet 192.168.0.2 255.255.255.0 skipassource=true
Gruß
Marco
Ich dachte ich hätte den Fehler gefunden und für die neuen Virtual-Directory’s auch eine URL eingetragen und zwar identisch zur normalen nur mit dem Port 4444 in der URL. Gebe ich aber die 4444 URL ein springt der Browser auf die folgende URL
Irgendwas passt hier noch nicht so ganz? Idee?
Steffen
Hi Steffen,
richtig, der Port ist in den Umleitungen leider hardcoded, du musst den Port manuell angeben. Nicht schön, funktioniert aber.
Gruß, Frank
Servus,
ist eigentlich genau die Lösung, die ich suche! Allerdings bekomme ich nach der Umstellung auch mit Port 4444 Aufruf immer nur die Konto-Seite des Admins statt den EAC???
Was könnte hier falsch laufen?
Gruß, Steffen