Exchange 2016: EAC nur im internen Netzwerk freigeben

von

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:

EAC

Das Verzeichnis ECP wird logischerweise vom IIS-Server bereitgestellt:

IIS

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:

ECP

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:

IIS

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

EAC

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:

EAC

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:

IIS Website

Nachdem die neue Website hinzugefügt wurde, müssen die Bindungen angepasst werden:

IIS Website

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"

Virtual Directory

Im IIS sieht es jetzt so aus:

IIS Konfiguration

Für ECP in der „Default Web Site“ kann EAC jetzt abgeschaltet werden:

Get-EcpVirtualDirectory "ecp (Default Web Site)" | Set-EcpVirtualDirectory -AdminEnabled:$false

EAC

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:

EAC Admin

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.

EAC Admin Port

Das funktioniert ebenfalls mit der Sophos UTM, wie hier beschrieben:

https://www.frankysweb.de/sophos-utm-9-4-waf-und-exchange-2016/

30 Gedanken zu „Exchange 2016: EAC nur im internen Netzwerk freigeben“

  1. 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.“

    Antworten

  2. 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

    Antworten

  3. 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

    Antworten

    • 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

      Antworten

      • 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.

        Antworten

  4. 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?

    Antworten

  5. 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

    Antworten

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

    Antworten

  10. 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 ;)

    Antworten

  11. @ 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

    Antworten

  12. @ 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 ;)

    Antworten

  15. 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 ..!

    Antworten

  16. 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 :-)

    Antworten

  17. 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?

    Antworten

  18. 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ß

    Antworten

  19. 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ß

    Antworten

  21. 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

    Antworten

  22. 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

    Antworten

Schreibe einen Kommentar