Allow Outlook Anywhere only for certain users

Several readers of this blog have requested an article on the subject of "Outlook Anywhere for certain users only". The requirement is always quite similar: Only selected users should be allowed to connect to the Exchange server from the Internet via Outlook Anywhere, all other users should not have this option. In other words, users should only be able to access Exchange and their mailbox if they are connected to the internal network. A connection via Outlook Anywhere should not be possible unless the user has been explicitly allowed to do so. The background to this requirement is often that the uncontrolled outflow of data should be restricted, because in the default setting, any user can connect any computer with Outlook to Exchange via Outlook Anywhere and thus also access their mailbox. The company's emails may therefore also end up on the employees' private PCs. It is therefore understandable that you want to restrict this somewhat.

Let's get this out of the way first: Yes, you can narrow it down, but this article has to go a bit further...

Outlook Anywhere vs. MAPIoverHTTP

Since Exchange Server 2013, Exchange has supported two protocols for connecting from the internet. The very old protocol is called "Outlook Anywhere" or "RPCoverHTTPs". RPCoverHTPPs has been around (I may be wrong) since Exchange 2003 and is still included and activated in the current Exchange Server versions. The newer protocol "MAPIoverHTTPs" has been available since Exchange Server 2013, and MAPIoverHTTP is also activated by default in the current Exchange versions. Outlook can therefore establish a connection to Exchange using two different protocols, either via MAPIoverHTTP or via RPCoverHTTP. Both protocols use HTTPs as a basis, are activated by default on Exchange servers and are delivered by IIS on the Exchange server:

The screenshot clearly shows that RPCoverHTTP and MAPIoverHTTP, as well as other protocols such as ActiveSync and EWS, as well as OWA are delivered by IIS via HTTPs (port 443). As soon as the Exchange Server is accessible from the Internet via port 443, all protocols are also accessible from the Internet. In short: If you follow the standard Exchange configuration instructions (as on my blog) and publish Exchange via HTTPs (e.g. via Port Forward) on the Internet, all Exchange protocols can be used by the user. This means that a user can simply install Outlook on their private PC and easily connect to the Exchange server and access their mailboxes. The use of ActiveSync and OWA can be controlled quite well with appropriate guidelines, and access to the Exchange Admin Center (which is also published via HTTPs) can also be controlled; with RPCoverHTTPs (Outlook Anywhere) and MAPIoverHTTP it becomes somewhat more complicated...

Outlook: Internal and external access

Outlook receives its configuration via AutodiscoverAutodiscover also passes an "Internal URL" and an "External URL" for the Exchange protocols. These URLs can be configured for each Exchange protocol, here is an example for 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).

Unfortunately, I have not found any documentation on which characteristics an Exchange server uses to determine whether a client is internal or external. Based on my tests, I suspect that Exchange uses SCP and SNI to differentiate between "Internal Outlook" and "External Outlook on the Internet". According to my tests, it does not matter whether an Outlook client is a member of the Active Directory, but only whether the client can find the Exchange server using the Autodiscover SCP entry. This is usually the case in the internal network, because here the client can reach the domain controller. External clients (without VPN) cannot reach the domain controller and the internal URL and therefore use the configured external URL. Exchange then presumably uses SNI (Server Name Indication) to determine that the client is located externally.

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:

Internally, there is an Exchange 2019 server and a domain controller. Outlook clients currently use the DNS name "outlook.frankysweblab.de" for both internal and external access. Here is an example of the configured URLs for the /mapi directory:

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

To avoid certificate warnings later, the certificate should first be replaced. It is necessary that the new future name for external connections is present in the certificate. Currently, the certificate only has the DNS names "outlook.frankysweblab.de" and "autodiscover.frankysweblab.de":

This certificate must now also be replaced so that the new name for external access is also included. I use the DNS name "outlook-ext.frankysweblab.de" for external access:

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

The old entry must now be removed from the public DNS and replaced with the new entry. In my case, "outlook.frankysweblab.de" is replaced by "outlook-ext.frankysweblab.de":

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

By default, Exchange does not block external connections. External access to mailboxes can be blocked with the "Set-CASMailbox" can be deactivated:

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
}