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:

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:

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:

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:

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:

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

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“:

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“:

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

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:

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:

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

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

Get-OrganizationConfig | fl MapiHttpEnabled

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

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:

Mit dem folgenden Befehl lasen sich externe Verbindungen wieder aktivieren:

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

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
}