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: Internal and external access
Outlook receives its configuration 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:
It is actually best practice to keep the internal and external URL the same for all protocols (as shown in the screenshot), but this means that Exchange can no longer determine whether an Outlook client is internal or external (on the Internet).
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
As already mentioned, Outlook can use RPCoverHTTP (Outlook Anywhere) and MAPIoverHTTP to connect to Exchange. This is where a problem arises: For the MAPIoverHTTP protocol, it is possible to configure whether a mailbox may be accessed from an external client. You could therefore simply configure that only certain users are allowed to access their mailbox from the Internet via MAPIoverHTTP. Unfortunately, however, it is not quite that simple, because Outlook attempts to establish a connection via RPCoverHTTP if no MAPIoverHTTP connection can be established. So if external access to a mailbox via MAPIoverHTTP is blocked, Outlook simply uses RPCoverHTTP as an alternative and establishes the connection. Unlike MAPIoverHTTP, however, external RPCoverHTTP connections cannot be blocked; this setting simply does not exist. RPCoverHTTP must therefore be switched off so that external connections can be blocked and not used anyway via a fallback.
HowTo: Block external MAPIoverHTTP connections
In order to restrict Outlook connections from the Internet via MAPIoverHTTP, some changes must be made to the Exchange configuration. Essentially, the following points must be changed in most environments:
- Separation between internal and external namespace
- New certificate which contains the internal and external name
- Customization of public DNS
- Deactivation Outlook Anywhere (RPCoverHTTP)
I will describe the necessary changes in detail using the following environment:
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:
The screenshot shows that a namespace has been configured for Exchange (internal and external URLs are the same). This is configured for all virtual directories according to this scheme and also corresponds to best practice. In the internal DNS there are 2 HOST-A entries which point to the internal Exchange IP:
There are also HOST-A entries in the public DNS, but here with the public IP:
Access from the Internet is via port forward on the router.
Configure new certificate
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“:
If a wildcard certificate is used for Exchange, no changes to the certificate are required. The new certificate is bound to all Exchange services:
Customize Exchange URLs
After changing the certificate, the Exchange URLs can be adjusted. The new external URL is now configured for all protocols. Here is an example of the /owa and /mapi directory:
After the URLs for all protocols (with the exception of /PowerShell and /Autodiscover) have been changed, you should wait at least 2 hours. Autodiscover will distribute the new URLs to the clients during this time.
Customize public DNS
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:
No changes need to be made to the internal DNS. Again, it is advisable to allow a little time to pass, depending on how the TTL is set.
Test connections
After the changes, the connections can be tested. Internal and external clients should still be able to connect to Exchange. Internal clients continue to use the URL configured for internal connections:
An external client (in this case an Azure VM) establishes the connection to Exchange with the external URL:
You should also check whether MAPIoverHTTP is activated on the Exchange Server; this can be checked with the following command:
Get-OrganizationConfig | fl MapiHttpEnabled
Configure external access to mailboxes
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
This command disables external access via MAPIoverHTTP for the mailbox and deactivates RCPoverHTTP. Outlook can therefore perform a fallback to RPCoberHTTP if no MAPIoverHTTP connection can be established. Deactivating external access does not immediately disconnect existing connections. In my tests, Outlook was no longer able to establish an external connection to Exchange after approx. 5 minutes.
The connection status of an external Outlook now looks as follows (the internal URL is displayed here again), a connection can no longer be established:
The following command can be used to reactivate external connections:
Get-CASMailbox | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$false -MAPIBlockOutlookExternalConnectivity:$false
Activation also takes some time, about 5 minutes in my tests.
The following command can be used to disable external access for all mailboxes:
Get-CASMailbox -ResultSize Unlimited | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$true -MAPIBlockOutlookExternalConnectivity:$true
This command can be used to reactivate external access for all mailboxes:
Get-CASMailbox -ResultSize Unlimited | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$false -MAPIBlockOutlookExternalConnectivity:$false
As already mentioned, access is not restricted in the default setting, so this also applies to new mailboxes. If access should only be possible for certain users, but not for all other users, a small script could be used which is executed cyclically. The script could, for example, disable access for all users, with the exception of users who belong to a specific group:
$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
}