Conditional Access (CA) is front and center of any attempt to secure Microsoft 365. If you’ve spent any time securing your tenant and Entra resources, you’ll know what Conditional Access is by now, so we’ll assume at least a level 200 understanding, skip the introduction, and instead dive into the most common mistakes I see when helping folks out with it.
These aren’t listed in any particular order, and the devil’s in the details, so make sure you read the full post instead of just skimming the bullet points! There are also way more than five mistakes you can make with Conditional Access, but let’s start with these.
Table of Contents
- Exclusions and access gaps aren’t minimized with additional policies
- Location based policies don’t consider VPNs
- No or poor break glass/emergency access account setup
- Unprotected Conditional Access groups
- No architectural framework leads to gaps and complex management
Exclusions and access gaps aren’t minimized with additional policies
A bit like the “death and taxes” joke, exclusions are inevitable at some point for any Conditional Access administrator. Putting aside the egregious exclusions to require MFA for users who kick and scream loudly about it, you’ll have legitimate scenarios that just don’t work with an exclusion. But consider this rule for CA policy design: all exclusions should have a supplementary policy to minimize that exclusion.
“Huh?”
Let’s explore this with an example.
You’ve got a CA policy which requires administrators can only authenticate on a compliant device. Great fundamental policy everyone should look at, because it provides some protection against Adversary in the Middle (AiTM) phishing attacks, and from administrators’ privileged access on unmanaged devices.
But, what if your admins in scope of this policy need to authenticate to a device that cannot be compliant? There’s a few scenarios that might happen: Windows Server access is the easy example.
So you add an exclusion: John Doe’s admin account doesn’t need added a compliant device so that he can sign in to a Windows Server to activate app X.
Depending on how the rest of your CA policies are enabled, this exposes you to some risks:
- Will I remember to remove the exclusion?
- Could the admin now log into their personal (unmanaged, unmonitored, potentially insecure) devices?
It’s scenarios like this we want a follow up policy to minimize the risk.
In our example, what could a follow up policy look like, and how could we design and manage it?
Firstly, we know the admin won’t need the exclusion for long. Therefore, rather than exclude the admin directly, let’s exclude a Privileged Identity Management (PIM) protected group, previously known as a privileged access group (now called PIM for Groups). This allows us to (a) have an approval process and (b) have a time restriction for automatic removal of the exclusion.
So far so good. We’ve minimized the risk of forgetting to remove the exclusion. But what about the risk of logging into devices we don’t want them to?
This is where the follow up policy comes into play. We target the policy at the excluded group, then make additional requirements. For example, now that you don’t need a compliant device, you do need to authenticate from the public IP of our data centre. You could even use something like Authentication Methods to require certificate based auth. Or both.
Point being, we keep narrowing and narrowing and narrowing the scope of allowable activity. First, the user could authenticate on any unmanaged device. Then, we limited it to two hours. Then, we limited it only to our known IPs. We could go further, all depending on what other CA policies permit or don’t.
Other examples I often see and how you would potentially minimize them:
- Web apps on unmanaged Windows and macOS will be allowed, routed through Defender for Cloud Apps’ reverse proxy to block downloads. This is a great setup because you can stop data exfiltration while accommodating BYOD. But… do you really need to allow all your users BYOD web app access? Do you need to allow them access to all cloud apps this way? Consider implementing multiple policies that combine to only allow the users who need BYOD access, and only to the apps they need, such as Office 365, but maybe not your admin portals. Consider further using access packages and entitlement management for time-bound and request-only BYOD access, for scenarios such as temporary access while the corporate device is fixed.
- Guest access is allowed in the tenant. Nothing wrong with this and each tenant is different, but consider targeting policies to your guests with explicit blocks on apps they’ll never need; or flipping it on its head and blocking all apps except their known-required apps. Even consider different rules for different personas of guest – does a guest who only access SharePoint sites really need theoretical permission to all cloud apps?
Also consider that every time you use Include conditions, you’re de-facto excluding all other conditions. For example, if you set up MFA for all users but only include the Windows device platform, you are excluding MFA for all users on all other platforms. It’s for this reason it’s critical that as soon as you refine the scope of a policy, either by include or exclusion, there are additional policies targeting those gaps.
Location based policies don’t consider VPNs
Some folks scoff away the idea of using country-based named locations in Conditional Access policies. I get why, because it’s not rocket science to bypass it. But I still encourage their use. They tackle the low hanging fruit, call upon adversaries to (albeit slightly) increase the cost of attack, and protect you from those no-brainer scenarios. Really, after they’re breached, do you want to be the person answering the CEO’s question of “… and why didn’t we block access from countries we don’t have staff?”. If you’re going down this route, you’ll usually create a named location of where you do business and block all authentication except from that location. If you don’t do remote work and/or have a public IP/range, even better.
Back to country-based authentication. Two obvious bypasses are spinning up a VM/VPS in the allowed region, or using an anonymous IP address from a consumer VPN (ExpressVPN, if you’re reading, hit me up for that sponsorship deal).
While Entra ID Protection (previously Azure AD Identity Protection) has anonymous IP address detection calculated in real-time, these only feed into the risk score and we cannot specifically select them: there’s no CA option for blocking anonymous IP addresses, it’s just abstracted into the risk score which makes it a bit black-box and unpredictable. Entra ID Protection also wouldn’t have a specific detection for using a VPS.
There’s one option that can help. It’s not perfect, but let’s check it out: Microsoft Defender for Cloud (MDA) access policies.
MDA integrates with Conditional Access via a capability called Conditional Access App Control. Essentially, we use the Session settings in Conditional Access to hand over the session to MDA, which has its own policy engine, driven by access policies, and powered by a reverse proxy.
In the two policy examples below, we can explicitly block any IPs that MDA recognizes as anonymous, cloud providers, brute force, or otherwise unwanted.
Now when the user authentications from (in the example below) an Azure virtual machine or anonymous VPN, they’re blocked (presuming MDA recognizes the IP as such, which it’s pretty good at).
No or poor break glass/emergency access account setup
Emergency access accounts are fundamental to Conditional Access, but it’s surprising how many tenants don’t set them up.
Look at it like this: in 30 seconds or less, Conditional Access give you the power to lock every single user our of your tenant, including you and all other admins. The reality is, configuring Conditional Access is a high-risk activity that should only be done by folks adequately trained in it… who aren’t in a rush and make mistakes.
Thinking about emergency access, you have a few design choices:
- One or more accounts excluded from all CA policies, usually via an Entra group. The accounts are Global Admins (so they can reverse any lock-outs) and given super duper passwords, and you may even want to split those passwords out physically so that one half of a password is kept by user A/site A; and the other half by user B/site B. The logic here is if we’re not requiring strong authentication, we want physical hurdles in the way. This is the most common way of managing emergency access. You can supplement it by having a script that confirms the emergency access accounts are always applied to your CA policies, in case you forget or they’re removed.
- If you still (understandably) want emergency access accounts to require strong authentication, you could exclude them from all CA policies except one policy specifically for them that requires FIDO2. Why FIDO2? Why not Azure MFA? There are service dependencies in Azure authentication and, depending on the type of risk you want to protect against, if the Azure MFA service goes down, you won’t get SMS or Authenticator app MFA, but FIDO2 should still work, based on the linked Microsoft documentation. Just make sure those FIDO2 keys are available and tested.
- Instead of using standard accounts, use service principles and API access. The service principle has API permission to reverse any lock-outs, either specifically to edit CA policies, or other permissions such as managing group access to then exclude from Conditional Access. The advantage here is you can do it passwordless and minimize standing global admins. The negative is in the heat of the moment, depending on skills and general fumbling around, this may not be the fastest way.
I don’t believe any of these are the right way and others are the wrong way. They cater to different risk models and acceptance levels. But please, whatever you do, have an emergency access plan, test it, and set up auditing for when it’s used.
Unprotected Conditional Access groups
For #4 on this list I was torn between a few things, but this is one I’ve been exploring the most lately.
Conditional Access is going to be responsible for a lot of your security controls. By scoping its policies to different groups, you control things such as who needs MFA, what the strength of that MFA should be, the devices a user can authenticate from, the allowed locations… you get the picture. Important stuff.
Now consider who can manage these policies. Folks with the Security Administrator and Conditional Access Administrator role are obvious. But really, we’re talking about Groups Administrator too, right? This role can lead to a lot of problems because it’s not considered a privileged role, but in your tenant it might be the keys to managing privileged access, security exceptions, or other significant attack paths.
Groups Administrator isn’t privileged for good reason: there’s another role called Privileged Role Administrator which is meant to be the keys to managing privileged access, such as adding users to a group with Global Admin rights. So why am I calling out Groups Administrator? Because, by default, your Entra groups aren’t privileged. You need to make them role assignable at the time of creation.
When a group is role assignable, you can give it Entra admin roles, but you don’t need to. Just being role assignable means I need privileged access beyond Group Administrator to manage it: Global Admin or Privileged Role Administrator. So, if you’re managing access to sensitive resources with Conditional Access, you might want to consider this option. It does have draw backs: it’s got to be static, so it doesn’t scale well, but that’s by design.
You can also consider an additional guardrail: the new restricted management admin units function can be applied to groups, blocking potentially even privileged administrators from tampering with the groups. However, it’s not resistant to a global admin deleting the admin unit, so think of this as more of a tool to protect you from accidents.
No architectural framework leads to gaps and complex management
You’ve just got Entra, and you know you need to start enforcing MFA, blocking unauthorized devices, and a bunch of other stuff. You head into the Conditional Access policies page, and start creating policies or using Microsoft’s own policy templates. Before long, your list of policies starts to look like this.
At first, this is fine. But scale it out over a few thousand users, a few hundred apps, and several years. Invariably, this leads to inconsistent policy application, gaps, and a really really difficult to manage Conditional Access system. In short, it’s the lack of up front architecture and design is usually the root cause of all the previous common mistakes.
Point being: you need a design. I’m a huge fan – borderline Oblivion adoring fan style – of Claus Jespersen’s Conditional Access for Zero Trust framework. With a focus on understanding personas and their access to resources, couple with a smart naming convention and granular options, it makes long-term management of Conditional Access simpler to manage, troubleshoot, and scale.
—————————————————–
This is the first in a series of blogs on Microsoft 365 security mistakes I commonly see in the field. Coming up will be similar posts for Microsoft Defender for Endpoint/Cloud Apps/Office 365/Identity, Exchange Online Protection, Privileged Identity Management, and more. If there’s a specific product or service you want me to cover, hit me up on LinkedIn or Twitter/X.
