New Baseline Conditional Access Policies in Azure AD

Back to Blog

New Baseline Conditional Access Policies in Azure AD

Remember over a year ago when the first Baseline Conditional Access policy dropped? It was simple enough and most definitely a good move, but of course, most people still aren’t using it. I have heard some nightmarish statistic–something like less than 2 percent of admin accounts in Azure AD are protected by MFA. Puke! Hopefully these baselines see better adoption in the months to come.

Anyway, now we have three brand new, additional baseline polices available. It’s like a mid-year Christmas!

There are now four baseline policies available:

  • Require MFA for admins (this was the original policy)
  • End user protection
  • Block legacy authentication
  • Require MFA for Service Management

To start, look at Block legacy authentication; this is something that has been sorely needed for a long time. Of course, in Exchange Online it is also possible to create authentication policies which disable basic auth, and I have been recommending that for a long time.  But now, blocking legacy protocols can be accomplished across all Microsoft 365 services with this one policy. Note that you may have service accounts in your environment that require basic auth, but as with all policies this one allows you to exclude selected users. 

I think that Exchange Online authentication policies are still relevant though, since you can turn off basic authentication at a more granular level—for each individual service/protocol. For example maybe you need to exclude a handful of users from this policy. But then, let’s say you find out that you only need to leave EWS open for them, so then why not disable IMAP, POP, SMTP and others?  You can do that with an EXO auth policy, but not with this conditional access policy.

Check out the End user protection policy. This one blows my mind a little actually; it is leveraging “risk-based” conditional access, which is a technology normally accessible only via an Azure AD Premium P2 subscription.

Really cool to see that Microsoft felt strongly enough about identity protection to include this premium feature as a baseline policy. Kudos, Microsoft. As another surprising bonus, if any evidence of leaked credentials surfaces on the dark web, Microsoft will also block sign-in and force the user to perform a password reset using their second factor.

The other cool thing I want to point out here is that SO MANY businesses still gawk at the idea of MFA. Why? Because they think it’s annoying. I just want to slap these customers sometimes. WAKE UP! Do you not realize the era we live in? MFA is non-negotiable in my mind. But this is one way to make the transition easier for end-users. They will need to register for MFA within 14 days of their first login attempt after applying this policy, but moving forward they would only be challenged for that second factor under “risky” conditions (e.g. unknown or infrequent location, etc.). 

Now I generally just turn on MFA straight up for users across the board. In some circumstances where Azure AD Premium is available to the customer, they may decide to exclude known/trusted locations such as their corporate offices, and maybe trusted devices. But, good to have a low-impact entry point here as well (and at no additional cost).  Even if you are enforcing MFA for all user sign-ins, the extra protection against leaked credentials is huge, so I would still recommend enabling this one.

The last policy isn’t really that cool. It’s just requiring MFA whenever certain services are accessed that rely on the Azure Resource Manager API. I just think this is redundant if you are already enforcing MFA more widely anyway (as you should be).

Thumbs up though to MS. Now if we could just force the issue somehow… Sigh. I guess there is always ransomware and the other threats out there–eventually those who aren’t adopting a better baseline will get hit hard, and realize it’s time to transform their thinking about security in the cloud. Don’t let that be you. They are making it easier and easier to adopt a better security posture these days–go check out these policies to get started.

Comments (11)

  • David Brooker Reply

    I am hoping to turn on MFA in its “easygoing – only challenge in risky logins” mode using the newly/ free of charge additional charge “End User Protection” baseline policy highlighted in your article. However I am a little puzzled as to how it interacts with the Multi-Factor authentication settings in the Active Users part of the Office 365 Admin Center?

    Turning on the End User Protection baseline policy in Azure Admin doesn’t appear to turn on MFA for an Office 365 user in the Office 365 Admin Center. Does MFA have to be turned on in both locations or only one? Might turning it on in both locations lead to one overriding the other with the result that users are endlessly being challenged for a login even when at their normal desks?

    Or is turning MFA on in the Office 365 Admin Center turning MFA on for the whole system and then the settings in Azure Admin are setting the “sensitivity” levels of the MFA setup?

    Microsoft’s own documentation doesn’t seem to cover this part of setting up MFA.

    June 3, 2019 at 6:38 am
    • Alex Reply

      It isn’t very clear I am afraid, however let’s say that you never went and “enabled” MFA for any particular user via the admin center. Then, instead you create a conditional access policy that requires MFA for an app, say SharePoint. Then the experience will be, the users will need to perform MFA when accessing SharePoint–that is the requirement in the CA policy. The controls in the admin center are “per user, enforce MFA,” whereas in CA it is “under such and such conditions, enforce MFA for the specified users and cloud apps”

      June 3, 2019 at 11:36 am
  • Matthew Brooker Reply

    Does that imply that the two places to set up MFA (Office 365 Admin & Azure Conditional Access) are “cumulative” i.e. if set up in both then if any of the conditions in either are met then an MFA challenge would kick in?
    That would intimate that the best approach in my scenario where I an trying to introduce a “light touch” form of MFA which only presents a challenge when a “risky login” is present is to leave MFA Off on a per user basis in Office 365 Admin and turn it on the “End User Protection” in Azure CA only.

    This approach would appear to give the most granular control whereas if turning it on from within the Office 365 admin centre is a “one size fits all / blunt instrument” way of introducing MFA.

    June 3, 2019 at 11:58 am
    • Alex Reply

      Right. I do typically enable everyone in the admin center, but because I use named/trusted locations and so forth, it does reduce frequency of the prompts for users. That of course requires Azure AD Premium. But just turning on the policy as you mentioned would probably be the lightest touch method. It will require the users to register for MFA within 14 days of enabling the policy, then it will challenge on risky sign-ins (also gives you that other protection with the compromised credentials/force password reset).

      June 5, 2019 at 11:11 am
  • David Brooker Reply

    Just a warning to anybody implementing the “Block Legacy Authentication” baseline policy. On a Windows 2012 Essentials server running the Azure AD integration tool i.e. not AD Connect. Implementing this baseline policy breaks the communication between the 2012 Essentials Server and Azure AD.
    Not a big problem and in my case I setup a separate admin level account which I excluded from the baseline policy and all was restored.

    June 5, 2019 at 9:39 am
  • Ken Reply

    With a recent change to the preloaded conditional access baseline policies, you cannot exclude users anymore.

    Have you figure out how to exclude service accounts with the new recent change?

    June 27, 2019 at 5:27 pm
    • Alex Reply

      True, I noticed this today. It appears that you can no longer exclude for End user protection and Block legacy authentication. However, the MFA policies still allow you to define exclusions. You should create custom policy to replace the block legacy auth–just use the condition Client apps > Other apps. Then Block access. That would allow you to have exceptions. As for End user protection–we can just wait and hope they put this back to the way it was initially, or otherwise further improve it. That’s part of the risk when using anything in preview–it could change on a dime, and without notice.

      June 27, 2019 at 8:39 pm
  • Ken Reply

    I was wondering if you know how to recreate the policy as a custom policy.

    I have it set as:
    Assignment: all users excluding the service accounts
    All Cloud Apps
    Conditions: Risky sign-ins (Medium and High).
    Access Controls: Grant w/ MFA.

    Would these settings work to replace the End user protection policy?

    June 28, 2019 at 10:12 am
    • Alex Reply

      It won’t 100 percent replace it, no. The baseline policy also will block sign-in and make a user change their password if their credentials are leaked. You would want to look at the Identity Protection features in AAD P2 to get similar to this.

      June 28, 2019 at 12:18 pm
  • sankarasubramanian parameswaran Reply

    how we can disable the MFASetup from the external

    September 26, 2019 at 5:25 am
    • Alex Reply

      You can’t. Baseline policies need some more work in my opinion. We need the ability to have exceptions, including guest accounts.

      September 27, 2019 at 1:40 pm

Leave a Reply

Back to Blog

Helping IT Consultants Succeed in the Microsoft Cloud

Have a Question? Contact me today.