In a previous article, we discussed how a conditional access policy blocking basic authentication prevents Outlook clients (leveraging RPC over HTTP) from reconfiguring after a mailbox migration to Exchange Online. This is due to RPC over HTTP not supporting modern authentication. On the other hand, Outlook clients leveraging MAPI over HTTP would reconfigure without incident. This is due to MAPI over HTTP supporting modern (and basic) authentication.
This article explores how security defaults, which Microsoft has been enabling on all new tenants to block basic auth, could also prevent Outlook clients (leveraging RPC over HTTP) from reconfiguring after migration to Exchange Online.
How to check if Security Defaults are enabled (modern authentication is enforced)
To determine if security defaults are enabled in your tenant.
Log into the Microsoft 365 Admin Center. From the left pane expand Settings and select Org Settings. From the Services tab, select Modern Authentication. The Modern Authentication pop-out will identify if security defaults have been enabled.
The screenshot below shows the message that security defaults are enabled, indicating that modern authentication is required and basic auth connections are blocked.
If security defaults have not been enabled in your tenant, the modern authentication pop-out will have configurable options. The screenshot below shows that modern authentication has been enabled (but it is not enforced). We can also see which protocols permit clients to use basic auth. Based on the selections in the screenshots, Outlook clients are still permitted to use basic auth (via either RPC over HTTP or MAPI over HTTP).
Tip: While not the focus of this article, I highly recommend working towards disabling basic auth on as many protocols as you can before the October 1st, 2022 deadline. This not only improves your security posture prior to October but also gets you prepared for the retiring of basic auth.
Workaround: Disable security defaults temporarily (not recommended)
One possible workaround, which will temporarily lower the security posture of your tenant (and is not recommended), is to disable the security defaults in the tenant.
This workaround may be necessary if:
- Your mailboxes are hosted on Exchange 2010, which does not support MAPI over HTTP. Exchange 2010 only supports RPC over HTTP. This means all Outlook clients, regardless of version, are using RPC over HTTP, and by extension, will try to make an initial connection to Exchange Online with basic auth and fail.
- Your mailboxes are hosted on Exchange 2013 and newer, and you have not enabled MAPI over HTTP. This means all Outlook clients, regardless of version, are using RPC over HTTP. For this scenario I highly recommend switching all mailboxes to MAPI over HTTP before migrating to Exchange Online. This is significantly better than reducing the security posture of your tenant.
Should you want to disable the security defaults in your tenant log, into the Azure Portal (portal.azure.com). Select Azure Active Directory. From the left navigation, select Properties.
Click the link Manage Security Defaults. From the Enable Security Defaults pop-out, toggle the Enable Security Defaults setting to No. Click the Save button.
Once you have migrated all mailboxes, repeat these steps but select Yes. Once saved security defaults will be enabled and basic authentication will be blocked.
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.
Unfortunately, I have never had any luck with this solution. Nevertheless, I am posting it here in case it works for you.
Solution: Enable MAPI over HTTP before migration (recommended)
If your mailboxes are hosted on Exchange 2013 and newer the best solution is to enable MAPI over HTTP a few weeks before your mailbox migrations to Exchange Online. MAPI over HTTP supports modern authentication, which means its initial connection to Exchange Online uses modern authentication, allowing for Outlook profile reconfiguration.
MAPI over HTTP can be enabled either globally or at a per-mailbox level.
To determine if MAPI over HTTP is enabled globally, run the following command. A value of true indicates MAPI over HTTP is globally enabled. A value of false indicates MAPI over HTTP is disabled.
C:\> Get-OrganizationConfig | Format-List MapiHttpEnabled
By default, all mailboxes are configured with a MAPI over HTTP value of null. A value of null means the mailbox is following the global setting identified in Get-OrganizationConfig. However, it is possible to set the mailbox itself to a value of either true (enabled) or false (disabled). Mailbox level settings supersede the global setting.
To determine which mailboxes have a setting other than null run the following command.
C:\> Get-CASMailbox -ResultSize Unlimited | Where-Object {$_.MapiHttpEnabled -ne $null}Any mailbox with a MapiHttpEnabled value of false is still leveraging RPC over HTTP. In addition, any mailbox with a MapiHttpEnabled value of null and a global value of false is also operating under RPC over HTTP.
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.
- If this column shows HTTP, you are using MAPI over HTTP, and Outlook should reconfigure itself correctly after migrating 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, the next step is to enable it. There are some prerequisites to configure MAPI over HTTP, such as:
- Configuring a namespace on the MAPI virtual directory
- The namespace used for MAPI is listed 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. Enabling per mailbox is a great way to pilot MAPI over HTTP before rolling it out to the entire organization.
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.
Tip: You can use Log Parser Studio to monitor the logs for RPC over HTTP connections to Exchange.
With the Outlook profile reconfigured for MAPI over HTTP, we can successfully migrate our mailbox to Exchange Online with the security defaults 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
This helped a lot, thanks