A screenshot showing the available baseline Conditional Access policies enabled

I’ve been particularly busy these last couple of weeks and struggled to find time to post on here. I do have several things saved up that I’m keen to get posted though… this being the first in a series of planned entries. For now, the Identity theme continues πŸ™‚ I wrote about the Security Registration updates in Conditional Access a while back. Since then Microsoft have further improved CA - adding some new baseline policies that can benefit all environments.

I was keen to provide some commentary around these changes, hopefully encouraging you to take a look and enable them within your own tenants. Others have covered this already, so I’m a little late to the party. In my opinion though, you can’t shout loudly enough about some of these new security oriented additions.

So here goes…

A bit about Conditional Access…

Conditional Access is one of those fantastic features in Azure AD that almost single-handedly justifies the purchase of Premium licensing. For the uninitiated, it allows us to control authentication behaviour based on a selection of things:

An overview of the Conditional Access flow and capability

At a base level, we can use Conditional Access to approve, block, or limit sessions based on different criteria. For Azure AD P1 these attributes are based on static conditions such as who / what / where. Azure AD P2 extends this to include risk-based policies – a component of Identity Protection. These advanced policies use automated intelligence to classify the risk of an authentication request; enforcing dynamic controls based on the result. As an example, a request from an anonymous IP address on an unknown device can trigger a high-risk condition; blocking access or mandating MFA before the request is allowed. Clever stuff.

So What’s New?

Conditional Access policies are a powerful weapon in ensuring your organisation’s security, but they can be unwieldy and confusing. What’s good? What should you be enabling? What’s best practice? Baseline policies are Microsoft’s way of highlighting the answers to some of these questions, the first of which was the “Require MFA for Admins” policy introduced last year. These have been added to in the last few weeks with a handful of new (Preview) additions:

  • End User Protection
  • Block Legacy Authentication
  • Require MFA for Service Management

End User Protection (Preview)

The End User Protection entry takes some of the complexity out of configuring a (friendly) policy for MFA; drawing on some of the more advanced risk-based capabilities of Azure AD P2. In simple terms this policy invokes MFA where the user session is deemed to be a potential risk. It also ensures compromised accounts (where credentials have been detected via Microsoft’s leaked credential service) are proactively blocked. In this latter case access isn’t reinstated until the user resets their password via self-service password reset, or an administrator clears the risk alert by assigning a new (temporary) password.

I really like this addition. Aside from lending access to some of the more premium capabilities of P2, it simplifies the creation and maintenance of Conditional Access policies relating to MFA. Many policies I’ve seen errr on the side of caution, triggering unnecessary prompts for users that lead to irritation. At the opposite end of the scale, lots of organisations don’t leverage MFA enough to secure authentication. Why not let Microsoft do the work for you?!

As with most policies, you should exclude break-glass accounts to ensure access in case of any MFA / CA related outage (no references to recent events!).

Block Legacy Authentication (Preview)

The Block Legacy Authentication policy does exactly what it says on the tin. It’s no secret that most bad sign-in attempts come via legacy authentication requests. Given that this method provides no support for MFA it’s hardly surprising, but does mean that even with an MFA policy you are exposed to risk if legacy protocols are enabled.

The recommendation for some time now has been to disable these using existing Conditional Access controls. This new policy makes it that bit easier to do so πŸ™‚ There are some prerequisites to be aware of though:

  • Review Azure AD sign-in logs to understand the potential impact see here for a guide).
  • If there’s evidence of legacy authentication in use, ensure your directory is enabled for modern authentication.
  • Verify that connecting clients (Office, Mobile Apps / Devices etc.) in addition to Office 365 services are modern authentication enabled.

Once you’ve satisfied those requirements and confirmed that legacy authentication isn’t (widely) used, enable this policy to automatically block legacy authentication requests. Job done! πŸ™‚

Require MFA for Service Management (Preview)

Last, but not least, we have the new “require MFA for service management” policy. This isn’t quite as obvious as the previous two in title, but is a useful and sensible policy to enable - irrespective of whether you extensively use services homed in the world of Azure.

An increasing number of organisations are turning to Azure to deliver services back to the organisation. Interaction takes many forms ranging from simple portal based activity, to programmatic integration via Azure PowerShell or the Azure CLI. In all cases the default sign-in experience is devoid of MFA - leaving your environment exposed to a variety of potential attacks.

This policy enforces MFA for all attempts to sign-in to these services - administrative or otherwise. For this reason, again ensure that break-glass or Service Accounts / Principals are excluded where you need emergency or programmatic access that can’t respond to MFA challenges.


These are excellent new baselines for what remains one of my favourite features of Azure AD. Whilst Conditional Access is fairly intuitive, it’s not easy for everyone to grasp, or to get “right”. Microsoft’s decision to start including these best practices out of the box is going to do wonders for the security of those organisations who want to “set and forget” - without the worry of whether they’ve adopted the multitude of options in the right way.

Here’s hoping for more of these as time goes by, and (dare I say it) automatic enablement as they mature…

Do heed the / my warnings around exclusions, and prerequisites if you haven’t done so already… That aside, enjoy spending 5 minutes turning these on to get yourselves (and your organisations) into a better place!