Exchange 2013: Externen Zugriff auf das Exchange Admin Center (EAC) beschränken
Seit die MMC-basierte Konsole in Exchange 2013 durch das webbasierte Exchange Admin Center ersetzt wurde, besteht das potenzielle Risiko, dass jeder auf die EAC zugreifen kann. Denn diese ist nur durch Benutzername und Passwort geschützt. Mögliche Lösungswege werden in diesem Beitrag aufgezeigt.
In Exchange 2013 wurde die MMC-basierte Konsole der Vorgänger durch ein Web-basiertes Verwaltungstool ersetzt: das Exchange Admin Center oder EAC. Dies ist sicher begrüssenswert, da das Management von jedem Client ohne Installation eines Tools erfolgen kann und dieses dann auch nicht bei jedem CU ebenfalls aktualisiert werden muss. Allerdings ergibt sich auch ein Problem.
Das Problem
Das EAC ist ein Teil des Exchange Control Panels (ECP), auf das jeder Benutzer mit Mailbox Zugriff hat, und es wird auch über die gleiche URL aufgerufen. Wenn nun Outlook Web App (OWA) und ECP ins Internet veröffentlicht werden, ist auch EAC verfügbar. Interne Verwaltungswerkzeuge, die nur über Benutzername/Passwort geschützt öffentlich erreichbar sind, stellen da natürlich ein Risiko dar.
Mögliche Lösungen
Im Internet finden sich verschiedenen Lösungsansätze. Hier ein paar Beispiele und deren Vor-/Nachteile:
- Nur OWA veröffentlichen
Obschon dies funktioniert, ist die Funktionalität für den Benutzer arg eingeschränkt. Er kann zum Beispiel den Abwesenheitsassistenten nicht nutzen. - EAC im virtuellen Verzeichnis des ECP deaktivieren
Auch diese Diese Methode funktioniert prinzipiell, aber dafür ist EAC auch intern nicht mehr verfügbar und die Administration muss vollständig über die Exchange Management Shell erfolgen. - Ein zusätzliches virtuelles Verzeichnis mit eigener, extern unveröffentlichter IP-Adresse für ECP erstellen und im Default-Verzeichnis EAC deaktivieren
Der Vorteil dieses Vorgehens ist, dass keine Einschränkungen für Benutzer oder Administratoren entstehen. Dafür ist der Setup ein wenig kompliziert, was die Fehleranfälligkeit erhöht.
 |
Microsoft Exchange TrainingsFür mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse. |
Für mehr Informationen zu Exchange 2013 und 2016 besuchen Sie einen der folgenden Kurse.
Die elegante Lösung
Bei der ADFS-basierten Authentisierung kann sehr einfach zwischen intern und extern unterschieden werden: Kommt die Anfrage über den Web Application Proxy, ist sie extern, trifft sie hingegen direkt auf den ADFS Server, ist sie intern.
In ADFS kann auch die Zugehörigkeit zu einer Sicherheitsgruppe verwendet werden, um ein Berechtigungstoken auszustellen oder eben nicht.
Eine Kombination aus beiden Bedingungen lässt den Zugriff auf ECP von intern für alle zu und von extern für alle ausser für die Exchange-Administratoren.
Die Konfigurationsschritte
Gehen wir davon aus, dass folgende Komponenten schon installiert sind und funktionieren:
- Active Directory
- Certificate Services
- Exchange 2013 ab SP1 (Voraussetzung für native ADFS Authentisierung)
- Active Directory Federation Services
- Web Application Proxy
-
- Relying Party Trust für OWA und ECP einrichten
- OWA und ECP vDir auf ADFS Authentication umstellen
Die Schritte 1 und 2 habe ich bereits in meinem letzten Artikel beschrieben: Exchange 2013: OWA mit Zertifikat-basierter Authentifizierung
- OWA und ECP auf WAP veröffentlichen
- Issuance Authorization Rules für WAP konfigurieren
Issuance Authorization Rules können das Ausstellen von Token an Bedingungen knüpfen und werden entweder pro Relying Party Trust in den Claims Rules festgelegt oder wie in der Beispielkonfiguration für alle Anforderungen, die vom WAP eintreffen, konfiguriert:
- Eine neue Regel hinzufügen
Achtung! Standardmässig wird eine Regel erstellt, die allen Benutzern den Zugriff ermöglicht. Diese muss entfernt werden:
Die neue Regel erhält einen Namen und die Bedingungen in der Claims Rule Language:
Die SID für die auszuschliessende(n) Gruppe(n) lässt sich einfach per PowerShell feststellen und kopieren:
Das Resultat
Der externe Zugriff auf OWA oder ECP endet für einen Exchange Administrator folgendermassen:
Intern hingegen wird der gleiche Benutzer zugelassen:
Der Test User 01 kann sich hingegen auch extern erfolgreich anmelden:
Fazit
Neben den vielseitigen Authentisierungsmöglichkeiten bietet WAP auch einen eleganten Weg, den Zugriff auf EAC auf das interne Netz zu beschränken.