A simpler Conditional Access baseline

Some folks have written to me about the “complexity” of my Conditional Access guide and were hoping to find something a bit simpler. This surprised me, and initially I shrugged it off. But I have heard this feedback more than once now, so I decided to take this thought experiment seriously and try to simplify things a bit further.

UPDATE: I have updated this baseline with a script that you can use to create these policies, and made it available on GitHub.

I think I have come up with a good summary now, as well as a way to describe it. In this article we will consider just a handful of policies for a typical SMB who is looking to harden their tenant without having to manage so many different policies–which can seem complex when you get into having as many as 10 or 12 for example. Let’s see if we can’t cut that number in half! But first, a review: why do we need Conditional Access at all?

Modern Access Control

In the modern era, you need better access controls, and in general we are looking for stronger security. Usernames and passwords are just too flimsy these days. Attackers have many ways of obtaining passwords, and phishing is so rampant (plus it is getting harder to recognize/detect). Therefore, having another barrier beyond the traditional password is a very good idea.

So providing a second step or prompt–a.k.a. Multi-factor Authentication (MFA)–beyond the password should be your first order of business. And this second step can be an SMS text message for example, or (preferably) a code or push notification that is generated in a mobile app like the Microsoft authenticator app (and other authenticator apps work just fine–so if you already use Duo or Google authenticator or something, no sweat).

In addition to MFA, a modern application, which includes web browsers and other client applications (such as Outlook, OneDrive and so on)–these apps can communicate much more information than a legacy client login prompt (where it only asks for your username and password). For example, the modern client app will identify information about itself, and it will include some details about the specific device you are using, as well.

The cool thing about this is that you can use the device-specific information as an access control. Devices that are known can be separated from those which are not known, and that gives you the ability to quickly shrink your possible attack area from every device in the world (several billion possible endpoints) down to the relatively tiny number of devices that you enroll and support in your organization. This method has been shown to be effective at mitigating man-in-the-middle attacks such as Evilginix, which can be used by attackers to phish their way past MFA prompts.

The access controls

The access controls we can use (in the Microsoft 365 Business Premium plan) look like this:

We have a couple additional options if you move into say an E5 plan or another combo containing Azure AD Premium P2. But for the majority of SMB’s I would suggest you have plenty of capability with this list of options. The idea with a baseline set of policies is that you will create certain “rules” for how people are allowed to access the cloud apps (e.g. Office 365). So every baseline policy will be applied to All users (and yes, you can make exclusions as needed on the “Exclude” tab–it is recommended to leave at least emergency access accounts excluded from CA policies).

Bare minimum

A very easy bare minimum requires only two policies:

• Block Legacy authentication
• Require Multi-factor authentication

With those in place, you are no longer just relying on a password–plus legacy client apps that do not support a second authentication prompt are prevented from connecting entirely. This is essentially equivalent to enabling the Security defaults feature–but most organizations who are receiving help to manage and customize their Microsoft 365 environments are not going to want the Security defaults alone–they may also want to manage devices and encrypt application data, too. Therefore they must create custom Conditional Access policies, and leave the Defaults disabled (the two are mutually exclusive).

Require managed apps and devices

Now, beyond the bare minimum, I would suggest that the next policies to recommend for most SMB customers are:

• Require approved client apps for iOS and Android: This means you must use the Microsoft apps (e.g. Outlook, Office) on mobile devices to access the Office 365 services–this will give you the greatest protection and compatibility with features like DLP, email encryption, shared calendars and so on (Side note: also be sure to deploy App protection policies from Endpoint Manager, but I cannot yet recommend the access control to Require app protection policies, unfortunately).
• Require compliant device: This means every device you support needs to be enrolled with Intune/Endpoint manager (and in this policy you must include each device platform that you intend to support under Conditions). As well, you have a choice to make: it is optional to target both Browsers and Modern client apps, or just Modern client apps (leaving Browsers open for access–with MFA of course, per the bare minimum baseline policies above).
• Block unapproved device platforms: This policy will block access for any device platform that you do not intend to support, as well as platforms that are not supported or recognized by Conditional Access (such as Linux).

And that’s it–that’s the whole policy set. So five in total. That’s about as simple as I could make it.

What about location?

You can also use the Location condition to block access from certain geographies. And a common request here in the United States would be to create a named location that encompasses the U.S. (and any other approved countries where the organization might do business or travel to), and then block access from every location that is NOT the U.S./approved countries.

I think it is okay if you want to do that–knock yourself out. But also realize that if you are already requiring compliant devices, this extra policy is highly redundant, because no devices that exist in your own country or any other country will be able to access your corporate resources anyway–so the location condition isn’t really adding that much for you. The device-based approach is also friendlier to international travel (you know, once that is actually an option again). Otherwise you need to come up with a manual process to exclude folks while they globe-trot, and get them protected again once they return. As well, be aware that the location can only be determined for IPv4 addresses–at this time all IPv6 addresses are considered “unknown locations.” So yet another mark against this option.

Why not require App protection policies?

The access control called Require App protection policies has a very poor side-effect: the Teams app on mobile devices will become unusable. I can’t remember the message you get but basically the Teams app doesn’t play well with that option. Very unfortunate but until they correct that I cannot recommend the access control. However, it is not really necessary anyway, because you can deploy app protection policies for iOS and Android to All users (so there is no escaping the policy), and then with the access control called Require approved client app the end user is going to be locked into using the Microsoft apps (which are the ones being protected by the App protection policies). Therefore the access control to also require app protection on top of that is redundant and not needed.

One more high-security policy consideration

If you want to go the extra mile, and assuming you bake this approach in to your on-boarding process, you can also restrict the ability to register security information for MFA. Typically this is done from specific corporate locations. In today’s day and age, with most information workers telecommuting due to COVID, this may not be practical. But the benefit is that not just anyone out in the world can configure a second factor of authentication–you must be coming from one of the corporate offices in order to sign up for MFA.

In lieu of this policy, I would suggest that as part of your on-boarding process, you simply disable sign-in for newly provisioned user accounts until they are ready to on-board into the service, at an agreed-upon date.

In Summary

I am currently updating the Conditional Access guide, part of the Microsoft 365 Best Practices publication, and I will leave the other “optional” policies intact with about a dozen in total for your consideration. But for those who are looking to get down to brass tacks and apply the simplest baseline with a decent level of security, here it is again:

• Bare minimum for all users & all cloud apps:
  • Block legacy authentication (targeting legacy clients)
  • Require multi-factor authentication (targeting modern clients)
• Recommended for Office 365:
  • Require approved client apps for mobile devices (plus app protection policies in the Endpoint Manager/Intune portal)
  • Require compliant device (targeting every device platform you support)
  • Block unsupported device platforms (targeting every platform excluding those that you support)

And of course the optional policy to restrict security info registration.

Those policies right there really get down to the essence of Conditional Access; we can cover the gamut of access scenarios and address most security concerns for the SMB with that simple policy set. Every thing else you choose to do is icing on the cake (and probably doesn’t move the needle as far as these do).