Outlook Anywhere nur für bestimmte Benutzer erlauben

Gleich mehrere Leser dieses Blogs haben sich einen Artikel zum Thema „Outlook Anywhere nur für bestimmte Benutzer“ gewünscht. Die Anforderung dabei ist immer recht ähnlich: Nur ausgewählte Benutzer sollen sich aus dem Internet per Outlook Anywhere zum Exchange Server verbinden dürfen, alle anderen Benutzer sollen diese Möglichkeit nicht haben. Es geht also darum, dass Benutzer nur auf Exchange und ihr Postfach zugreifen dürfen, wenn diese mit dem internen Netzwerk verbunden sind. Eine Verbindung via Outlook Anywhere soll nicht möglich sein, es sei denn dem Benutzer wurde dies explizit erlaubt. Hintergrund dieser Anforderung ist oft, dass der unkontrollierte Abfluss von Daten eingeschränkt werden soll, denn in der Standardeinstellung kann jeder Benutzer irgendeinen Rechner mit Outlook via Outlook Anywhere mit Exchange verbinden und somit auch auf sein Postfach zugreifen. Die Mails der Firma landen somit möglicherweise auch auf den privaten PCs der Mitarbeiter. Es ist also nachvollziehbar, dass man dies etwas einschränken möchte.

Um es schon einmal vorwegzunehmen: Ja, man kann es einschränken, aber dazu muss dieser Artikel etwas weiter ausholen…

Outlook Anywhere vs. MAPIoverHTTP

Seit Exchange Server 2013 unterstützt Exchange zwei Protokolle für die Verbindung aus dem Internet. Das schon sehr alte Protokoll nennt sich „Outlook Anywhere“ bzw. „RPCoverHTTPs“. RPCoverHTPPs gibt es schon (ich mag mich irren) seit Exchange 2003 und ist auch immer noch in den aktuellen Exchange Server Versionen enthalten und aktiviert. Das neuere Protokoll „MAPIoverHTTPs“ gibt es seit Exchange Server 2013, in den aktuellen Exchange Versionen ist MAPIoverHTTP ebenfalls in der Standardeinstellung aktiviert. Outlook kann also mit zwei verschiedenen Protokollen eine Verbindung zu Exchange herstellen, entweder per MAPIoverHTTP oder per RPCoverHTTP. Beide Protokolle nutzen als Grundlage HTTPs, sind in der Standardeinstellung auf Exchange Servern aktiviert und werden vom IIS auf dem Exchange Server ausgeliefert:

IIS Manager

Im Screenshot wird es deutlich, RPCoverHTTP und MAPIoverHTTP, sowie weitere Protokolle wie ActiveSync und EWS, als auch OWA werden per HTTPs (Port 443) vom IIS ausgeliefert. Sobald also der Exchange Server via Port 443 aus dem Internet erreichbar ist, sind auch gleich alle Protokolle aus dem Internet erreichbar. Kurz gesagt: Folgt ihr den gängigen Exchange Konfigurationsanleitungen (wie auch auf meinem Blog) und veröffentlicht Exchange per HTTPs (beispielsweise per Port Forward) im Internet, sind alle Exchange Protokolle durch den Benutzer nutzbar. Ein Benutzer kann also auf seinem privaten PC einfach Outlook installieren und problemlos eine Verbindung zum Exchange Sever herstellen und auf seine Postfächer zugreifen. Für ActiveSync und OWA lässt sich die Verwendung mit entsprechenden Richtlinien ganz gut steuern, auch der Zugriff auf das Exchange Admin Center (auch das wird per HTTPs veröffentlicht) lässt sich der Zugriff steuern, bei RPCoverHTTPs (Outlook Anywhere) und MAPIoverHTTP wird es etwas komplizierter…

Outlook: Interner und externer Zugriff

Outlook erhält seine Konfiguration bekanntlich via Autodiscover, Autodiscover übergibt für die Exchange Protokolle auch eine „Interne URL“ sowie eine „Externe URL“. Diese URLs lasen sich für jedes Exchange Protokoll konfigurieren, hier mal ein Beispiel für MAPIoverHTTP:

Outlook Anywhere / MAPIoverHTTP

Eigentlich entspricht es der Best Practise die interne und externe URL für alle Protokolle gleich zu halten (wie im Screenshot zu sehen), dies führt allerdings dazu, dass Exchange nicht mehr feststellen kann, ob ein sich ein Outlook Client intern oder extern (im Internet) befindet.

Leider habe ich keine Doku gefunden, anhand welcher Merkmale ein Exchange Server bestimmt, ob sich ein Client intern oder extern befindet. Anhand meiner Tests vermute ich, dass Exchange die Unterscheidung zwischen „Internes Outlook“ und „Externes Outlook im Internet“ per SCP und SNI durchführt. Meinen Tests nach spielt es keine Rolle, ob ein Outlook Client Mitglied des Active Directory ist, sondern nur ob der Client den Exchange Server anhand den Autodiscover SCP Eintrags finden kann. Dies ist üblicherweise im internen Netz der Fall, denn hier kann der Client die Domain Controller erreichen. Externe Clients können (ohne VPN) die Domain Controller und die interne URL nicht erreichen und nutzen daher die konfigurierte externe URL. Per SNI (Server Name Indication) stellt Exchange dann vermutlich fest, dass sich der Client extern befindet.

Problem: Outlook Anywhere Fallback

Wie bereits erwähnt, kann Outlook RPCoverHTTP (Outlook Anywhere) und MAPIoverHTTP für die Verbindung zu Exchange nutzen. An dieser Stelle kommt es nun zu einem Problem: Für das Protokoll MAPIoverHTTP lässt sich konfigurieren, ob auf ein Postfach von einem Externen Client zugegriffen werden darf. Man könnte also einfach einstellen, dass nur bestimmte Benutzer via MAPIoverHTTP aus dem Internet auf ihr Postfach zugreifen dürfen. Leider ist es aber nicht ganz so einfach, denn Outlook versucht eine Verbindung via RPCoverHTTP herzustellen, wenn keine MAPIoverHTTP Verbindung hergestellt werden kann. Wird also der externe Zugriff via MAPIoverHTTP auf ein Postfach blockiert, nutzt Outlook einfach RPCoverHTTP als Alternative und stellt die Verbindung her. Anders als bei MAPIoverHTTP lassen sich externe RPCoverHTTP Verbindungen aber nicht blockieren, es gibt diese Einstellung schlicht nicht. RPCoverHTTP muss daher abgeschaltet werden, damit externe Verbindungen blockiert und nicht durch ein Fallback trotzdem genutzt werden können.

HowTo: Externe MAPIoverHTTP Verbindungen blockieren

Damit Outlook Verbindungen aus dem Internet via MAPIoverHTTP eingeschränkt werden können, muss einiges an der Exchange Konfiguration verändert werden. Im wesentlichen müssen in den meisten Umgebungen die folgenden Punkte geändert werden:

  • Trennung zwischen internen und externen Namensraum
  • Neues Zertifikat welches den internen und den externen Namen enthält
  • Anpassung öffentliches DNS
  • Deaktivierung Outlook Anywhere (RPCoverHTTP)

Anhand der folgenden Umgebung beschreibe ich die nötigen Änderungen im Detail:

Exchange Lab

Intern gibt es einen Exchange 2019 Server und einen Domain Controller. Outlook Clients nutzen aktuell den DNS Namen „outlook.frankysweblab.de“ sowohl für den internen, als auch für den externen Zugriff. Hier mal ein Beispiel der der Konfigurierten URLs für das /mapi Verzeichnis:

MAPIoverHTTP

Im Screenshot ist zu sehen, dass für Exchange ein Namensraum konfiguriert wurde (interne und externe URL sind gleich). Dies ist für alle virtuellen Verzeichnisse nach diesem Schema konfiguriert und entspricht auch der Best Practise. Im internen DNS gibt es den 2 HOST-A Einträge welche auf die interne Exchange IP verweisen:

Internes DNS

Im öffentlichen DNS gibt es ebenfalls die HOST-A Einträge, hier aber mit der öffentlichen IP:

Öffentliches DNS

Der Zugriff aus dem Internet erfolgt via Port-Forward am Router.

Neues Zertifikat konfigurieren

Damit es später nicht zur Zertifikatswarnungen kommt, sollte zunächst das Zertifikat ausgetauscht werden. Es ist erforderlich, dass der neue zukünftige Name für externe Verbindungen im Zertifikat vorhanden ist. Aktuell verfügt das Zertifikat nur über die DNS-Namen „outlook.frankysweblab.de“ und „autodiscover.frankysweblab.de“:

Zertifikat

Dieses Zertifikat muss nun mit ausgetauscht werden, damit auch der neue Name für externe Zugriffe enthalten ist. Ich verwende für externe Zugriffe den DNS-Namen „outlook-ext.frankysweblab.de“:

Zertifikat

Wenn für Exchange ein Wildcard Zertifikat verwendet wird, sind keine Änderungen am Zertifikat erforderlich. Das neue Zertifikat wird an alle Exchange Dienste gebunden:

Exchange Dienste

Exchange URLs anpassen

Nach dem Wechsel des Zertifikats können die Exchange URLs angepasst werden. Für alle Protokolle wird nun die neue externe URL konfiguriert. Hier als Beispiel das /owa und /mapi Verzeichnis:

Externe URLs
Externe URLs

Nachdem die URLs für alle Protokolle (mit Ausnahme von /PowerShell und /Autodiscover) geändert wurde, sollte mindestens 2 Stunden gewartet werden. Autodiscover wird in dieser Zeit die neuen URLs an die Clients verteilen.

Öffentliches DNS anpassen

Im öffentlichen DNS muss nun der alte Eintrag entfernt und durch den neuen Eintrag ersetzt werden. In meinem Fall wird also „outlook.frankysweblab.de“ durch „outlook-ext.frankysweblab.de“ ersetzt:

öffentliches DNS

Am internen DNS sind keine Änderungen erforderlich. Auch hier bietet es sich wieder an, ein bisschen Zeit ins Land ziehen zu lassen, je nachdem wie die TTL eingestellt ist.

Verbindungen testen

Nach den Änderungen können die Verbindungen getestet werden. Interne sowie externe Clients sollten nach wie vor eine Verbindung mit Exchange herstellen können. Interne Clients nutzen weiterhin die für interne Verbindungen konfigurierte URL:

interne Outlook VerbindungOutlook Anywhere

Ein externer Client (in diesem Fall eine Azure VM) stellt die Verbindung zu Exchange mit der externen URL her:

externe Outlook VerbindungOutlook Anywhere

Am Exchange Server sollte auch kontrolliert werden, ob MAPIoverHTTP aktiviert ist, dies kann mit folgendem Befehl überprüft werden:

Get-OrganizationConfig | fl MapiHttpEnabled
MAPIoverHTTP Einstellung

Externen Zugriff auf Postfächer konfigurieren

In der Standardeinstellung blockiert Exchange keine externen Verbindungen. Der externe Zugriff auf Postfächer kann mit dem Befehl „Set-CASMailbox“ deaktiviert werden:

Get-CASMailbox MAILBOXNAME| Set-CASMailbox -MAPIBlockOutlookRpcHttp:$true -MAPIBlockOutlookExternalConnectivity:$true
Zugriff abschalten

Dieser Befehl schaltet den externen Zugriff via MAPIoverHTTP für das Postfach ab und deaktiviert RCPoverHTTP. Somit kann Outlook ein Fallback mehr auf RPCoberHTTP durchführen, wenn keine MAPIoverHTTP Verbindung aufgebaut werden kann. Das Deaktivieren des externen Zugriffs trennt bereits bestehende Verbindungen nicht sofort. Bei meinen Tests konnte Outlook nach ca. 5 Minuten keine Verbindung mehr von extern mit Exchange herstellen.

Im Verbindungsstatus eines externen Outlooks sieht es nun wie folgt aus (hier wird wieder die interne URL angezeigt), eine Verbindung kann nicht mehr hergestellt werden:

Zugriff abschaltenOutlook Anywhere

Mit dem folgenden Befehl lasen sich externe Verbindungen wieder aktivieren:

Get-CASMailbox <MAILBOXALIAS> | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$false -MAPIBlockOutlookExternalConnectivity:$false
Zugriff einschalten

Auch das Aktivieren benötigt wieder etwas Zeit, bei meinem Tests wieder etwa 5 Minuten.

Der folgende Befehl kann verwendet werden um den externen Zugriff für alle Postfächer abzuschalten:

Get-CASMailbox -ResultSize Unlimited | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$true -MAPIBlockOutlookExternalConnectivity:$true

Mit diesem Befehl lässt sich der externe Zugriff für alle Postfächer wieder aktivieren:

Get-CASMailbox -ResultSize Unlimited | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$false -MAPIBlockOutlookExternalConnectivity:$false

Wie bereist erwähnt, ist in der Standardeinstellung der Zugriff nicht beschränkt, dies betrifft also auch neue Postfächer. Wenn der Zugriff nur für bestimmte Benutzer möglich sein soll, für alle anderen aber Benutzer nicht, könnte ein kleines Script genutzt werden, welches zyklisch ausgeführt wird. Das Script könnte beispielsweise den Zugriff für alle Benutzer abschalten, mit Ausnahme der Benutzer die einer bestimmten Gruppe angehören:

$AllowExternalAccessGroup = "AllowExternalAccess"
$AllMailboxes = Get-Mailbox -resultsize unlimited | select alias
$AllowExternalAccess = Get-DistributionGroup $AllowExternalAccessGroup | Get-DistributionGroupMember | select alias
$DisableExternalAccess = Compare-Object -ReferenceObject $AllMailboxes -DifferenceObject $AllowExternalAccess -Property Alias | where {$_.SideIndicator -eq "<="} | select alias
foreach ($Mailbox in $DisableExternalAccess) {
Set-CASMailbox $Mailbox.Alias -MAPIBlockOutlookRpcHttp:$true -MAPIBlockOutlookExternalConnectivity:$true
}

11 Gedanken zu „Outlook Anywhere nur für bestimmte Benutzer erlauben“

  1. Irgendwelche Vorschläge wie man den Usecase mit Exo umsetzen kann?

    Gibt über die die exo-powershell einen Befehl, der ist aber deprecated und läuft nächstes Jahr aus :(

    Antworten
  2. Genau, so machen wir es auch bei einem Kunden, hier aber mit der Sophos und Umkehrauthentifizierung. Obwohl Mapi zukünftig der bessere Weg sein sollte. Hier gibt es aber eine Besonderheit, dass man Exchange klar machen muss, wie die Auth extern verläuft und dort ist verschl. Basic Auth. erforderlich. Und hier muss man zwingend auf eine dedizierte externe oder interne URL setzen.

    Und noch ein Hinweis, laut meines Wissens ist es nicht möglich, ein Wildcard Zert. an die Dienste POP3 und IMAP zu binden, die Zuweisung gibt keinen Fehler zurück aber mittels get Befehl sieht man, dass unter Services dies dann fehlt. Franky, bitte ggf. nochmal prüfen und Artikel korrigieren, außer ich liege falsch. Genauso gibt es einen Bug, wenn man ein Zert., 2 DAG Membern zuweisen will, kein Fehler in der Powershell, aber einer bekommt nicht das Zert. Es müssen definitiv 2 dedizierte Zert. sein und keine Kopie.

    Antworten
    • Auch in einer dag sind zwei Zertifikate nicht notwendig. Seitens Ms wird sogar irgendwo explizit erwähnt, dass es dasselbe Zertifikat sein muss. Wenn man einer dag hat, hat man üblicherweise auch einen loadbalancer davor, so dass die Zertifikate auf den Servern aber eigentlich irrelevant sind, wenn der loadbalancer auf Layer 7 arbeitet.

      Antworten
    • Das mit der DAG würde ich auch das erste mal hören. Wie Norbert schon richtig schreibt: Es ist empfohlen das gleiche Zertifikat zu verwenden.
      Wo es nicht automatisch gesetzt wird ist auf das Backend – das musst du manuell nachholen.

      Antworten
      • Aber das Backend läuft auch problemfrei mit dem selfsigned Zertifikat der Installation. Da muss man nicht unbedingt das „Frontend“-Zert verwenden.

        Antworten
      • Ich habe es zumindest 2x erlebt, dass die Kopie des Zert. vom anderen Knoten, nicht beim 2. gebunden wurde. Aber ich habe nur das Ergebnis gesehen, nicht kontrolliert, ob es 2x vergessen wurde. Aber ich nehme meine Aussage gern zurück. Bisher musste ich mich nur immer um die Reparatur kümmern und hier war die Lösung ein eigenes Zert. Weil das andere, trotz aller Namen im Zert. mit SANs nicht fkt. Aber wie gesagt, dann nehme ich meine Aussage lieber zurück, bevor ich doch was falsches sage ;) Halte mich in Zukunft zurück.

        Antworten
  3. Gut zu wissen, dass das auch so mit Bordmitteln funktioniert. Alternativ kann man die Zugriffssteuerung auch mit dem KEMP mit aktiviertem ESP auf Basis von AD-Sicherheitsgruppen realisieren.

    Antworten
    • Wir setzen gerade neu den Kemp bei uns ein und leider funktioniert das mit den AD-Sicherheitsgruppen nur wenn man die Formularbasierte Authentifizierung hinterlegt, wie bei OWA zum Beispiel.
      Bei EAS und Outlook Anywhere funktioniert es leider nicht, da wir dort die Basisauthentifizierung, bzw. „Delegate to Server“ hinterlegen mussten. Früher beim TMG hatte dies funktioniert.

      Wenn es trotzdem mit dem Kemp funktionieren sollte, wäre ich über eine Idee was wir ändern müssen sehr dankbar.

      Antworten

Schreibe einen Kommentar