RPC/HTTP & Block Legacy Auth may prevent Outlook reconfiguration after migrating to Exchange Online

I have had a few projects now where one of the security requirements for Office 365 was to implement a conditional access policy that blocked legacy authentication (also known as basic auth). What this block does is enforce modern authentication for all clients. Any clients not using modern authentication will be denied access to all Office 365 resources.

In each of these projects, these security policies were enforced prior to moving any mailboxes to Exchange Online. In each case we ran into the same two symptoms:

• The Outlook client (which supported modern authentication) failed to reconfigure after a mailbox migration to Exchange Online
• Any on-premises users with permissions to a migrated mailbox were now getting a continuous basic authentication prompt

How the conditional access policy was configured

In all cases, the conditional access policy was scoped to all users and all cloud apps.

Conditions scoped under Client Apps were set to include Mobile apps and desktop clients with a subitem of Other clients. No other conditions were set. The access control was to Block access.

Note: “Other clients” includes clients that use basic/legacy authentication, and do not support modern authentication. Reference: Conditional Access: Conditions

After we migrated a mailbox and Outlook failed to reconfigure (continuous legacy auth prompts) we could see the failure under Azure AD Sign-Ins. Oddly our Outlook client (Office ProPlus) which supported modern authentication was being blocked due to legacy authentication.

Workaround: Disable the policy or add an exclusion

Two possible workarounds include:

• Disabling the policy until after the migration
• Adding users to an exclusion list prior to migration

Both of these workarounds are essentially doing the same thing. They are allowing Outlook clients time to reconfigure themselves after a mailbox migration to an Exchange Online mailbox. In both instances, you are weakening the security of your Office 365 tenant, so I can’t recommend either approach. But I can state that both options do work.

Note: As of October 13th, 2020, these workarounds will not be an option as Microsoft plans to block all legacy authentication in Office 365.

Workaround: Add a registry key

One solution Microsoft provided was to add a registry key to Outlook, which would force it to use modern authentication for autodiscover.

https://docs.microsoft.com/en-us/exchange/troubleshoot/client-connectivity/outlook-prompt-password-modern-authentication-enabled

Unfortunately, this solution did not work for us. However, I am posting it here in case it works for you.

• In our first environment, where the source was Exchange 2010, our Office ProPlus clients lost their ability to connect to their on-premises mailbox.
• In the second environment, where the source was Exchange 2013, nothing happened at all. Migrating a mailbox to Office 365 still had the same reconfiguration issue.

Solution: Enable MAPI over HTTP before migration

While examining the Exchange 2013 environment we noticed MAPI over HTTP was disabled for all users. This is an issue because RPC over HTTP does not support modern authentication. This means that an Outlook client configured for RPC over HTTP will initially try to connect to Office 365 using legacy auth, which will fail as the conditional access policy is blocking it.

Under normal operation, an Outlook client connecting with RPC over HTTP and legacy auth to Office 365 would be instructed to reconfigure itself for MAPI over HTTP and modern auth.

We confirmed the state of MAPI over HTTP globally by running the following command. A result of false indicates MAPI over HTTP is not enabled at a global level.

 C:\> Get-OrganizationConfig | Format-List MapiHttpEnabled

MapiHttpEnabled : False

It is also possible to enable MAPI over HTTP on a per-mailbox level. By default, all mailboxes are configured with MAPI over HTTP set to a null value. So, we checked for any mailbox where MAPI over HTTP was set to either true (enable) or false (disabled) with the following command.

 C:\> Get-CASMailbox -ResultSize Unlimited | Where-Object {$_.MapiHttpEnabled -ne $null}

No results were returned so we know all mailboxes were still configured in their null state. Another way to check would be to reverse the -ne operator to an -eq operator to list all mailboxes configured in a null state. If you wish to export a list of mailboxes and their MapiHttpEnabled state, you could run a command such as this.

 C:\> Get-CASMailbox -ResultSize Unlimited | Select DisplayName, MapiHttpEnabled | Export-CSV -Path C:\Users\<user>\Desktop\MapiHttpEnabled.csv -NoTypeInformation

With MAPI over HTTP set to null for all users and false at a global level this confirmed all Outlook clients were still operating under RPC over HTTP (aka Outlook Anywhere).

We can further confirm this by checking the connection status of an Outlook client.

• If the protocol column reports RPC/HTTP you are still using RPC over HTTP (a.k.a. Outlook Anywhere).
• If this column shows HTTP, then you are using MAPI over HTTP, and Outlook should reconfigure itself correctly after migration to Exchange Online.

Tip: You can get to this dialog by holding down CTRL + right-clicking on the Outlook icon in the system tray. From the context menu select Connection Status.

If MAPI over HTTP is not enabled, then the next step is to get it enabled. There are definitely some prerequisites to configure MAPI over HTTP, such as:

• Configuring a namespace on the MAPI virtual directory
• The namespace used for MAPI is included on the SSL certificate
• MAPI/HTTP is configured on your load balancer

For a full list of server and client requirements, check this article from Microsoft.

Once all prerequisites are met you can enable MAPI over HTTP at either a global or mailbox level. Note, that the mailbox setting overrides the global setting.

To enable MAPI over HTTP globally run the following command.

 C:\> Set-OrganizationConfig -MapiHttpEnabled $true

To enable an individual mailbox for MAPI over HTTP run the following command.

 C:\> Set-CASMailbox -Identity Leela -MapiHttpEnabled $true

It may take some time for the MAPI over HTTP change to propagate. Depending on the versions of Exchange and Outlook in your environment you may see a prompt to restart Outlook. Otherwise, MAPI over HTTP will update automatically the next time Outlook restarts, without any nag messages.

If you check the Connection Status once more we should now see a protocol of HTTP.

With the Outlook profile reconfigured for MAPI over HTTP, we can successfully migrate our mailbox to Exchange Online with a legacy auth block in place.

Once the mailbox has been migrated and Outlook reconfigures itself successfully the connection status Authn column should now show the status of Bearer. Bearer indicates the Outlook client is using modern authentication.

Have you seen this issue before? What did you do to fix it? Drop a comment below or join the conversation on Twitter @SuperTekBoy