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):
Now they will see the following prompt:
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.
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!
Updated Jul 01, 2019
Version 2.0
