Exchange Online - Modern Authentication and Conditional Access Updates

Published 04-01-2019 06:56 AM 40.9K Views

We’re constantly improving the security of Office 365 products and services. Modern Authentication and Conditional Access are two of the best ways of ensuring that your clients can take advantage of authentication features like multi-factor authentication (MFA), third-party SAML identity providers, and are implementing automated access control decisions for accessing your cloud apps based on conditions. Firstly, here’s some news about Modern Authentication. As you might already know, all new Office 365 tenants created on or after August 1, 2017 have Modern Authentication enabled by default in Exchange Online for all clients. Today, we’re announcing that Modern Authentication will soon be enabled for the Windows Outlook client and Skype for Business client in all managed (non-federated) tenants that were created before to August 1, 2017. Those tenants already have Modern Authentication enabled for Outlook mobile, Outlook for Mac and Outlook on the Web, so there are no changes to any of those clients.

What does it mean to be a ‘managed tenant’?

If you use Password Hash Sync, Pass-Through Authentication, or you create, manage and authenticate your user identities directly in the cloud, your tenant is considered a ‘managed tenant’ – and this change affects you. If your still create, manage and authenticate your identities in your on-premises Active Directory, and you use ADFS or some other 3rd party iDP to authenticate your users – your tenant will not be affected by this change.

Will my user experience be different?

This change affects the dialog users will see when requesting their credentials. They used to see the following prompt (the exact dialog depends upon the OS of the client, but this should be similar enough to help you identify it): MApost1 Now they will see the following prompt: MApost2

How does this change authentication?

From the user’s perspective, it’s just a dialog change. From a security perspective, the client is now using OAuth (not Basic Auth) to authenticate.

What’s better about that? Why do I care?

Switching to Modern Authentication (even if it’s used just for username and password) is more secure than using Basic Auth. Modern Authentication is not subject to credential capture and re-use, credentials are not stored on the client device, it ensures users re-authenticate when something about their connection or state changes, and it makes adding MFA simple.

What do I need to do as an Admin?

Nothing. Nothing at all, well except perhaps one thing: help your users understand that this new dialog means their connection to Office 365 is even more secure than it was before. Feel free to take the credit for that; tell them you changed it to increase their security; we don’t mind. The next thing to do is to start thinking about enabling MFA and Conditional Access, to make those connections even more secure. Here’s a great place to start finding out more. Speaking of Conditional Access, that leads us to the next thing we wanted to announce: we’re making some changes there too, specifically related to Exchange ActiveSync (EAS).

We’re making a change to ensure that EAS connections will be evaluated against previously unsupported conditions within Conditional Access (CA).

As you might know, many conditions that are available in CA policies have not been supported for EAS. These include country, named locations, sign-in risk, and device platform. Currently, if you include any of these conditions in a policy that targets EAS, that condition is always enforced. For example, a policy to require a compliant device outside of the corporate network would always apply (independent of the user’s location). The below shows how the admin would enable the client app condition used to target CA policy to EAS clients. MApost3 The change we have made ensures that CA policy applied to EAS correctly honors previously configured conditions. You may see some cases where EAS may begin to work where it was previously blocked. So, if you have CA policies today that block EAS traffic because a condition is not supported, we advise you inspect and remove any of the unsupported conditions from policy. For example, suppose you previously configured the following policy: “Block all EAS traffic from French Guyana”. Today all EAS traffic is blocked. If you are relying on a rule like that to block all EAS traffic, you need to re-think your strategy. With the change we are making, only the EAS traffic from French Guyana will be blocked. We’re sure that you find this behavior more logical, but we wanted to make sure you were aware of the change. So, it’s worth checking your existing CA policies to make sure you don’t have rules that might be affected by this change. Other than this, we don’t expect any other change in behavior: EAS clients should still receive quarantine email when they don’t meet the CA policy requirements; otherwise they will get email access just as they do today. We really do treat the security of our service and the protection of your data as our primary concern. Please leave any comments or feedback, and thanks for reading! The Exchange Team
Not applicable
Is this an aprils fool or is this announcement just be done at an unfortunate date?
Not applicable
Oh it's for real, just unfortunate timing, but we wanted to get the message out asap.
Not applicable
Greg, how do we not know that your comment isn't also part of the April Fool's gag?
Not applicable
Does the EAS change go into effect immediately? Or is it rolling out? What's the time frame?
Not applicable
It's slowly rolling out now.
Not applicable
The EAS change has started rolling out and we've sent Message Center posts to all tenants we believe might see an impact based on their existing policies. So check Message Center.
Not applicable
What indicators will we have to know this change has rolled out to our tenant?
Not applicable
We’ve had a ton of issues with needing to reinstall Office or reconnect users to Azure Ad based on a recent change to modern authentication. What changed in the last six weeks to make this change as seamless as you’re saying it will be?
Not applicable
Hi StuBeck,

We saw an issue when we turned on Modern Auth for an older tenant where a very small set of users received a login prompt which was caused by the account logged into Office ProPlus (via the File > Office Account tab). It was only a few users but we just had to remove their creds from Credential Manager and have them log back in. Then the prompts were resolved.

Not applicable
Did you raise a support incident for the issues? You should if not, we're not aware of anything in particular that might explain the issues you describe.
Not applicable
Will on premises mailboxes in hybrid environments be able to take advantage of this?
Not applicable
This doesn't apply to on-premises mailboxes, only this in Exchange Online.
Not applicable
Is it only for Office 365 installs of Outlook or will Outlook 2016 MSI versions also be able to utilise this?
Not applicable
Outlook 2016 MSI/Perpetual supports MA, so it will work for that client too.
Not applicable
Out tenant has approx 30 different domains associated with it. Some of the domains are Managed (Password Hash sync or Cloud Only identities which authenticate directly in the cloud) and others are Federated and authenticate against an on-premise AD using ADFS. So - we have a foot in each will this change affect us?
Not applicable
If you have multiple domains, some managed, some federated, we'll treat your tenant as federated. No changes will take place at this time.
Not applicable
What does this mean for Outlook 2010 clients which while still possibly not supported still work with O365?
Not applicable
There's no impact to Outlook 2010, as it can't trigger the Modern Auth flow.
Not applicable
In order for the update for EAS in Conditional Access does the tenant have to be managed or does this change take affect into a federated environment as well?
Not applicable
The EAS change will happen for all tenants, managed auth or federated.
Not applicable
How do I opt out, prevent or delay this change from happening? I do not want modern authentication enabled on my tenant.
Not applicable
We have multi factor authentication enabled and app passwords deployed to about 500 devices (Outlook 2016 and iOS mail). Enabling modern authentication for the tenant is going break all of our devices. I need a way to roll this out gradually without disrupting our users.
Not applicable
So this means all users will suffer the awful "Use this account everywhere on your device" additional prompt when they log in. Can we supress this and set it to Never?
Not applicable
My tech support rep says that EAS conditional policies that check against device compliance are not supported.

For example, a policy that blocks was except on compliant devices. Is this true and will this change with this rollout?

Not applicable
What is the timeframe for rolling out the modern auth. change to older tenants?

We would like to be able to enable this feature our self, and not just out of the blue by Microsoft.

So I need to know how much time we got before this feature is rolled out?

Not applicable

We have a managed O365 tenant created before Aug2017, with MFA already enabled on many users, with app passwords on Windows Outlook 2016.


Please i need an answer, if this change will affect these users or not. Will Outlook client pop up this prompt that will ask for users' real passwords the time that Microsoft will roll out this change?



New Contributor

Any update on this change (Modern Authentication) ? Our tenant has not recieved the change yet - and I'm wondering whether I need to enable it myself or just wait a bit and let it happen.


I encourage all to utilize the M365 Message Center to monitor for change. If its not been communicated via the message center then its likely still under dev.
Some additional unsolicited guidance: MS has a great tool for the M365 Roadmap
Have fun!!



We create and manage our users at our on-prem AD but it is synced up to O365 and we use Azure MFA.

Are we going to get the Modern Authentication for "Outlook for Office 365 MSO"?

How is this going to affect users with MFA already enabled with an App Password for Outlook?

Thank you!



There is a demand by our leadership that we enable MFA for the outlook 2016 Fat Client.  We already do this for OWA and ECP by redirecting to on prem ADFS to our internal IDP.  

1. We are 100% on prem.  0 hybrid.  Yes there are plans, but during the scope of this demand.

2. I ensured that all my VD are setup of Modern Auth.  OAUTH is available.

3.  Setting RPC does not allow for OAUTH???

4. I have validated the OAUTH cert Get-ExchangeCertificate (Get-AuthConfig).CurrentCertificateThumbprint

5. I have configured exchange online [PS] C:\Windows\system32>Get-PartnerApplication "Exchange Online"

and enabled is set to $TRUE

6.  The organizationconfig for oauth2 is set to $TRUE

7.  We are only going to allow 2016 and block older versions.   ADAL support is on by default.



1. When I set MFA for OWA and ECP there was an ADFS issuer that I pointed exchange two.  Where is this for MAPI.  

2. How do I redirect authentication for MAPI

3.  I know AAD and HYBRID scenarios this can be done.  Can a 100% ON PREM  accomplish this.

@jsdao - that's a lot of q's. Let me try and answer them;


OAuth won't work with RPC/HTTP - only MAPI/HTTP.


You HAVE to be Hybrid with O365 for Hybrid Modern Auth to work. It will not work direct against on-prem ADFS in the same OWA does. 


Your 3 questions;

1. It's not done the same way. It's done by enabling an Auth Server at the Org level, and setting it to the default Auth provider. 

2. By doing step #1. 

3. No. It cannot. 

New Contributor

I'm not sure what changed, but recently I've had a couple of users that once sync'd to the cloud via hybrid config, the modern authentication doesn't work. Most of the users in my environment have no issues at all, but in the last week, I've had two new users created that once migrated to exchange online via hybrid, they no longer use the modern authentication. When trying to configure their mailboxes, they are being prompted with the basic authentication and that obviously will not work. I have done everything I can to try to figure this out and nothing works except to leave them on my local exchange server until this issue is resolved. 

@Chris Varner - that's odd Chris. We did have one new issue we're seeing - could this be it? 

New Contributor

@Greg Taylor - EXCHANGE I don't think so because I just deleted the Outlook profile, tried to recreate it, and it started prompting for credentials using the Basic Authentication screen. I know it is going to fail at that point. Also, there is only one other user that has this issue. It isn't affecting everyone like it is affecting these two users. The current Exchange Online incident that just came out today sounds very similar to what I am experiencing with these two accounts, but these users don't have multiple accounts. This is issue is really mind blowing because it isn't affecting everyone the same. I can log into this same PC with a different E1 licensed user and Outlook works fine, so why it is happening for these 2 users is beyond me. If I migrate her back to the On-Prem server, it works fine. 

Ok, then there are likely some reg keys under HKCU causing this. What version of Outlook is this? 


Check for ExcludeExplicit0365Endpoint and make sure it's 0. Also check the client is using MAPI/HTTP and EnableADAL is set to 1 if this is Outlook 2013, or not set to 0 regardless of version. 

New Contributor

OK, Here are the Current Registry settings I have in place. Let me add that these were only added because of these two users that are having this issue. Before them, everything worked fine.


This issue is happening with Outlook 2016.


All are DWORD values. 

HKCU\Software\Microsoft\Office\16.0\Common\Identity\EnableADAL is set to "1"

HKCU\Software\Microsoft\Exchange\MapiHttpDisabled is set to "0"

HKCU\Software\Microsoft\Exchange\AlwaysUseMSOAuthForAutoDiscover is set to "1"


I will add ExcludeExplicit0365Endpoint and see if that makes a difference.

New Contributor

OK with all of the above registry settings applied to the user, it still doesn't work and AutoDiscover has stopped working. After putting in all of the users information manually, it still wont connect. Any other user on the PC works fine.

Set ExcludeExplicit0365Endpoint back to 0. or remove it. Get AutoD working properly. 


If those users can configure a profile on a different machine then clearly it's something in the registry local to the machines they have causing it. If they can't create a profile on a different machine, it's the user account in some way. 


Opening a support case might be a better way of continuing to figure out what's going on. 

New Contributor

OK, I have used this same user on another computer and it doesn't work there either. But it does work for the other E1 licensed users on that machine. 


How do I open a support case?

Occasional Visitor
There's an issue I'm having with this that I'd like to pass on to the developers, but I'm having a hard time finding a way to report it so I'm giving this a try in case someone sees it. We use group policy to have Outlook 2016 autoconfigure the first time it's launched, connecting people to accounts hosted on Office 365. Under the old system you'd see the Outlook loading splash, then the old login prompt would appear at the top of the screen, the user would fill it out and click OK, and then everything would continue and be fine. With the new system the modern auth login appears centered in the screen *behind* the loading splash. The password field is hidden and everything lines up so perfectly that many users don't realize it's a separate window they have to click on to bring to the foreground and log in. We just get people saying Outlook isn't loading. It looks like this: Outlook needs to be updated to either force the login window to appear above the loading splash, or to position it at the top of the screen so the password field is visible and it's more obvious to users what's happening. Already tried submitting this to the Outlook UserVoice (mod said post to TechNet) posted it to TechNet, contacted (chat said open a O365 ticket) and opened an O365 ticket (guy said post to UserVoice. Alas.)
Occasional Contributor

@Greg Taylor - EXCHANGE and @The_Exchange_Team is there any guidance available for implementing Cloud Azure MFA today for OWA for Exchange Server 2016 on-premise? We're using AADC with pass-through authentication (no ADFS). The majority of existing documentation points to Azure MFA server, which is no longer supported for new deployments.

Version history
Last update:
‎Jul 01 2019 04:36 PM
Updated by: