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:
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).
Comments (11)
Nice overview, but there I can’t see the Access Controls within the summary?
Good idea to split it in three parts.
I don’t go into the level of detail where we actually configure the policies in this article. But I do link to the MS Docs that show how to achieve each policy.
What are your thoughts on not requiring MFA within a trusted location? It’s much more convenient, especially if a company has a policy against workers using personal devices for work purposes. That said, would enabling a policy like this be a greater security risk?
Sure, any exception you make to your security policies opens the risk, right? But MFA is not a big deal. I actually refuse to work with customers who will not turn on MFA. Arguments like the ones you cited are so downright dumb nowadays. There are multiple ways to handle MFA, and yes a mobile device is the easiest (who cares if it is personal device?) Many don’t know, but MSFT makes it easy to allow access to corporate apps on personal mobile devices while giving full control of the apps and data to the company, while leaving the device alone (MAM). Once customers understand this, they don’t want to try to keep living like it’s 2006–they get on board with the last 15 years of development and enable BYOD with solid security behind it.
Hi Alex,
Just discovered your site and found very usefull information.
One thing I’m not sure to understand when I look at the summary graph for the Block Legacy Authentication, you have a checked [x] Mobile apps and desktops client but in the Microsoft documentation you refer it’s not checked.
Should it be checked? When I read on this it’s refer to Modern Authentication clients not Legacy authentication.
Regards,
Eric
You would NOT target (check) any modern clients. Instead you target the Legacy clients and then use the Block rather than Grant access control option.
Thanks for the great article. I love the “block unsupported platforms” rule. It completes it!
Do you have anything for session controls?
In the expanded baseline yes, as part of the Conditional Access/Best Practices guide that I publish on gumroad.
Thanks for creating these great checklists. I just purchased the bundle as it will be an excellent resource for standing up and configuring our new environment properly from the beginning. A quick question on a little bit more of an advanced CA policy — how can we prevent users from enrolling or registering more than one device? We are not allowing BYODs and instead the user will fall into one of two categories:
A. The user will receive a company issued laptop or desktop
B. The user will receive a company issued laptop and mobile phone (always an iPhone)
In another environment, we created two policies for each of these situations and then scoped it to apply to specific users.
Is there a better way to approach these situations?
Thanks for the great resources. I’m sure I’ll be purchasing the complete set soon. These are so very well written. Everyone should really be following these guides and checklists.
Thanks! You can require devices to enroll and be compliant per CA policies, then you must have your autoenrollment enabled for Windows 10, so that any device that is registered or joined to Azure AD enrolls into Intune, then last you can use enrollment restrictions within Intune to set a limit on number of devices allowed to enroll.