Conditional Access Updates from Ignite

Unsurprisingly the last few days at Ignite have been a whirlwind of news and learning. From my perspective the conference has been everything I’d hoped it would be… and then some! Those of you following me on Twitter and LinkedIn will have seen an increase in spam(!) from me as I’ve tried to communicate some of the key exciting things being discussed. Whilst I’ll be doing my best to summarise those on here over the coming days and weeks, I wanted to take a moment to call out a couple of specific Conditional Access updates I felt were worthy of note.

If you follow this blog you’ll know that Identity, and Azure AD are two of my favourite topics. I’ve written about Conditional Access in particular on a number of occasions. One such post related to the built-in baseline policies that Microsoft introduced earlier this year.

In response to these additions. there’s been much debate around where and how they should be used. Microsoft have provided some clarity in recent months, implying that their use is (really) limited to smaller organisations without the skill or licensing to support manual setup. As a general rule, manual policy configuration will provide the most flexibility, but it isn’t always feasible or ideal. In response to this there are some changes planned to the way that baseline policies are applied to tenants. The world as you know it is about to change…!

Security Defaults

Microsoft want to encourage good, simple security for smaller organisations and effective use of Conditional Access for larger ones. To address this we’ve seen the introduction of Security Defaults. This is a setting which can be enabled at the tenant level to enforce good practice.

It’s also one which will replace the existing baseline Conditional Access policies in the early part of 2020!

Moving forwards this single option will enable recommended settings that were previously incorporated into some of the baseline policies. You can find this setting in the Azure AD portal under Properties, “Manage Security Defaults”:

Toggling this setting to “on” automatically enables a number of things:

• All users will need to register for Multi-Factor Authentication
• Privileged Accounts will need to perform MFA at each sign-in
• End Users will need to perform MFA once registered
• Privileged Operations will require MFA
• Legacy Authentication will be blocked

Further detail on each of these settings can be found here.

An important thing to note is that Security Defaults cannot be used in tandem with Conditional Access. Microsoft’s assumption is that you will use one or the other. Conditional Access where skills and licensing permit, and Security Defaults in other scenarios. Attempting to enable both will yield an error:

Report-Only Mode

A second (and quite excellent!) change is Report-Only mode for Conditional Access. This is something that’s been hinted at for some time, and is ironically something I stumbled across the day before Ignite in my own tenant. It’s an incredibly useful addition.

The long story short is that when enabled, Conditional Access policies will fire as if enabled, but resulting actions won’t be enforced. They will be logged though, so the potential impact of a new policy can be evaluated.

You can read more about Conditional Access Report-Only mode here on Microsoft Docs.

At face value, both of these Conditional Access updates are minor. They certainly didn’t capture headlines at Ignite in the way some other announcements did. In both cases though they’re significant, reducing administrative effort and aiding the implementation of good security practices that are perceived as either too complex, or too risky.

If you haven’t already, I’d encourage you to take a deeper look at both. As a trusted supermarket retailer here in the UK would say… every little helps!