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/
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