Conditional Access policies now apply to all client applications by default
Published Aug 11 2020 09:00 AM 37K Views

Howdy folks,

When it comes to securing your organization, nothing is more effective than enabling multi-factor authentication (MFA) for your users. Whether using traditional methods like phone or token codes, or modern passwordless methods like the Authenticator, Windows Hello, or FIDO, MFA reduces the probability of account compromise by more than 99.9%. As part of adopting MFA, you should block legacy authentication endpoints that can’t support MFA. Legacy authentication protocols like POP, SMTP, IMAP, and MAPI can’t enforce MFA, making them preferred entry points for adversaries attacking your organization.


Organizations use Azure AD Conditional Access to enforce Zero-Trust Least-Privileged Access policies. Conditional Access allows you to determine access based on explicitly verified signals collected during the user’s sign-in, such as the client app, device health, session risk, or IP address. This is the best mechanism to block legacy authentication, but a recent analysis showed fewer than 16% of organizations with Conditional Access have policies that apply to sign-ins using legacy authentication protocols.

To help organizations more easily achieve a secure Zero Trust posture, we’re announcing 2 updates to help customers block legacy authentication:

  1. New Conditional Access policies will apply to legacy authentication clients by default.
  2. The client apps condition, including improvements to the client apps admin experience, is now in General Availability.

Daniel Wood, a program manager on the Conditional Access team, has written a blog to explain how these changes can help secure your organization. As always, please share your feedback below or reach out to intelligentaccesspm@microsoft.com with any questions.

Best regards,

Alex Simons (@Alex_A_Simons)

Corporate Vice President of Program Management

Microsoft Identity Division

 

-------

Hi everyone,

 

Today, I’m excited to announce we’re taking a big step forward in helping to make organizations more secure by changing the default Conditional Access configuration for new policies to apply to all client apps—including legacy authentication clients.

 

We’ve simplified the admin experience to make it easier for admins to create policies targeting modern authentication clients and legacy authentication clients. By default, all new Conditional Access policies will apply to all client app types when the client apps condition is not configured. Sign-ins from legacy authentication clients don’t support MFA and don’t pass device state information to Azure AD, so they will be blocked by Conditional Access grant controls, such as requiring MFA or compliant devices. If you have accounts which must use legacy authentication, you can grant them policy exceptions to keep them from being blocked.

 

If you want to create a Conditional Access policy that only targets legacy authentication clients, switch the client apps Configure toggle to Yes and deselect Browser and Mobile apps and desktop clients, leaving Exchange ActiveSync and Other clients selected.

 

clientapp1.jpg

 

And for those of you who manage your policies using the Microsoft Graph API, we’ve simplified the client apps schema with the release of the new Conditional Access API in v1.0 to match the new UX. Here’s an example of the new default configuration for the client apps condition when you create a new policy using the API.

 

clieantapp4.png

 

What about my existing Conditional Access policies?

If you have existing Conditional Access policies, they will continue to apply to the same client apps with no change. However, if you view an existing policy, we’ve made it easier to see which client apps are selected by removing the Configure Yes/No toggle. Existing policies where the client apps condition was not configured now look like this:

 

clientapp2.jpg

 

Understanding client app usage in your organization

Before creating a new policy, it’s good to understand who’s using legacy authentication in your organization. To see which client apps and protocols are being used in your organization during sign-in, simply navigate to the Sign-ins page and filter the results by client app type.

 

client app 3.jpg

 

Share your feedback!

We hope that these changes make it easier for admins to secure their organizations by blocking legacy authentication. As always, please share your feedback below or reach out to

daniel.wood@microsoft.com with any questions.

 

Thanks,

Daniel Wood (@Daniel_E_Wood)

Program Manager

Microsoft Identity Division

14 Comments

Cool, now if you can get them to apply to client credentials flow as well... :)

Copper Contributor

Great stuff. It is also going to be great if we can manage Azure AD Powershell with conditional 

access.

Brass Contributor

Nice work!

Copper Contributor

I’m wondering how using Conditional Access to block legacy connections is supposed to impact Azure AD Identity Protection and the generic AAD Signins log. 

We have CA rules in place to block Legacy Auth (e.g. IMAP) and yet we still see opportunistic IMAP login attempts that show up as “Risky” in Identity Protection. They also appear in the Azure Signins log and seem to fail because the accounts are locked, not because CA has stopped them.

 

Is the problem that CA needs a successful authentication before it gets involved? Or does this sound crazy and I’ve probably done something wrong?

Brass Contributor

WOW!

Copper Contributor

Until unauthorized access installs AAD Request Verification Service -PROD | Permissions, enterprise app. Your application can acquire a token to call a Web API hosted in your App Service or Function app on behalf of itself (not on behalf of a user). This scenario is useful for non-interactive daemon applications that perform tasks without a logged in user. It uses the standard OAuth 2.0 client credentials grant.   Be careful this is how the system is being compromised.   So be careful 

Steel Contributor

I'm still waiting and keeping tabs on legacy auth because of the Surface Hubs using legacy auth. Hope to have that resolved soon. 

Steel Contributor

Thanks for that. It would be great if CA policies blocked after username too.

Cool, that will save time! 

Brass Contributor

Prefect ,thank you 

Bronze Contributor

"If you have accounts which must use legacy authentication, you can grant them policy exceptions to keep them from being blocked."

It should be noted that in June of 2021 Microsoft will block legacy authentication - so don't get too comfortable with the exceptions.

Copper Contributor

So any new conditional access policy with selection "All cloud Apps" would support MFA for Legacy Authentications clients. ? would they now be prompted for MFA using IMAP, POP, SMTP? If so is this applicable the current existing rules as well

Iron Contributor

@mongie105 You need to use Authentication policy via Exchange powreshell. Check out this article explains how to block legacy auth before CA rules come into play because they won’t if you still allow basic auth for POP, IMAP and other legacy protocols. 

 

This will effect older apps and clients  that use basic auth like Outlook 2013 when not set to modern auth. 

https://docs.microsoft.com/en-us/exchang/clients-and-mobile-in-exchange-online/disable-basic-authent...


 

 

 

 

Copper Contributor

Hi Alex,

 

great news! Is a condition to skip for trusted locations in active sync now supported? Because it works perfectly but officially it’s unsupported.

 

regards,

Andreas

Version history
Last update:
‎Aug 13 2020 09:26 AM
Updated by: