How to fix the FUNDAMENTAL flaw in Conditional Access (Part 3 – miscellaneous tips)

In part 1 I wrote about the fundamental flaw in Conditional Access and part 2 walked through my way to address it using a block-by-default setup. This post will be slightly different as I want to share some miscellaneous tips & tricks and experiences regarding Conditional Access. I hope you will find it useful.

1. Verify your break-glass account!

While there are more guardrails today than a few years ago, it is still possible to lock yourself out of your own tenant either by configuration error or due to technical issues in Entra. So follow Microsoft’s advice: Create a break-glass account, protect it with a physical FIDO2 key, exclude from all Conditional Access policies and test it regularly. Also, make sure it is monitored and triggers an alarm when it logs in!

2. “What if” is amazing!

Although it was briefly introduced in part 2, the “What if” tool truly deserves more attention. This powerful feature allows you to determine which Conditional Access policies will apply under various scenarios. It’s an invaluable resource for both troubleshooting and designing policies. I highly recommend using this tool actively. Whenever you find yourself wondering, “What happens if I change this setting?”, the “What if” tool can likely provide the answer. Investing time in exploring the “What if” tool is definitely time well spent.

3. Always backup/export your Conditional Access policies

I often compare Conditional Access policies to the firewall rules in a traditional corporate network. These policies are absolutely vital for maintaining IT security, and access to them must be controlled meticulously. Given their importance, it’s not only crucial to ensure you have a reliable backup of these policies, but you also must make sure you can restore them as well! Test your restore capability and document it well in case of emergency.

Check if your backup solution or vendor supports backing up Conditional Access policies. If not, you should at least export the policies to files and back them up securely. These files need to be protected with the same level of security as direct access to Conditional Access. If you need to export these rules, here’s a sample script to help you with that task.

# Export Conditional Access Policies to JSON

# Check if module is installed
if (-not (Get-Module -Name Microsoft.Graph.Identity.SignIns)) {
    Install-Module -Name Microsoft.Graph.Identity.SignIns -Scope CurrentUser
}
Connect-MgGraph -Scopes Policy.Read.All

# Set export directoty, create if it doesn't exist
$savepath = "C:\Export\ConditionalAccessPolicies"
if (-not (Test-Path $savepath)) {
    New-Item -Path $savepath -ItemType Directory
}

# Get all Conditional Access Policies
$policies = Get-MgIdentityConditionalAccessPolicy

# Loop through each policy and export to .json file
foreach ($policy in $policies) {
    $fileName = $savepath+"\$($policy.DisplayName).json"
    $policy | ConvertTo-Json -Depth 100 | Out-File -FilePath $fileName
}
Disconnect-MgGraph

4. Safeguard your policies! Set up monitoring and alerts! 🚨

Once again, let’s compare Conditional Access policies to the firewall rules in a traditional corporate network. Any unauthorized changes to these policies should be treated as potential indicators of malicious activity. Fortunately, you now have completed step 2 😉, and you have a backup or export of these policies. The next crucial step is to ensure you are alerted to any and all changes in your Conditional Access policies. Setting up these alerts will help you quickly identify and respond to any suspicious modifications, thereby maintaining the integrity and security of your IT environment.

In my experience, the most straightforward method for monitoring you Conditional Access policies is to send them to a Security Information and Event Management (SIEM) solution. SIEM solutions are designed to collect, analyze, and report on security data from across your IT environment. If you don’t have a SIEM solution in place, I suggest using Azure Log Analytics. Azure Log Analytics is a cost-effective, pay-as-you-go service that can analyze your logs and help you set up alerts based on specific conditions. For example, an SMS notification every time the audit log catches anything related to Conditional Access.

This easy setup will send me text message every time any changes are made related to Conditional Access.

While this solution may seem simple, it is highly effective. If someone adds, removes, or changes your Conditional Access policies, it is crucial to be alerted immediately!

5. Some of my (and your) favorite settings

While writing this blog post I went on LinkedIn for some inspiration and asked what your favorite Conditional Access settings are. The response was way bigger than what I anticipated, so thank you everyone! It’s impossible to go through all your comments and suggestion in one post, it is simply too much at once. So I am going to do some of my personal favorites and some from LinkedIn this time. But just because I don’t mention a particular setting now, doesn’t mean I don’t think it’s good. And if your comment on LinkedIn isn’t mentioned, please don’t think I didn’t read or appreciate it, I really do. ❤️

Based on feedback, it’s important to highlight the flexibility of Conditional Access. Many people overlook this when considering my advice and suggestions. For example Sign-in frequency mentioned below. You don’t have to set the same time period for all users, they can be different for almost any circumstance you want. Users, admins, guests can all have different settings, and they can vary based on factors such a risk, client type, network location etc.

Also: All my comments/suggestions below are completely generic, and is not meant as advice for your environment.

So in no particular order:

Block legacy protocols

This is incredibly important as old authentication methods (like SMTP, IMAP etc) will bypass any MFA requirement since they don’t support it! This is like locking the front door of your house for security, but then leaving the back windows wide open, making it easy for someone to get in. Depending on your technical debt, this setting can be disruptive, so make sure you test thoroughly before implementation. This is configured by putting “Exchange ActiveSync clients” and “other clients” in a block policy:

Sign-in frequency

I see many customers misunderstand this setting, and think of it as “Don’t ask for MFA again for X time”. But Sign-in frequency sets how long you can access resources before you are asked to authenticate again. The default here is 90 days 😱 which is way too long in my opinion. As a starting point I would suggest for users to match their working hours (8 hour workday = re-authenticate after 8 hours). Admins should have much shorter (1 hour perhaps), depending on the role and which tier of privileges. Again, don’t focus on my values here, they are just examples. Be aware that this setting works slightly differently depending on the device is Entra registered/unknown vs Entra joined/hybrid joined.

Persistent browser session

This is one of my personal favorites! Persistent browser session can be very scary so this should absolutely be disabled for all privileged accounts, and I would consider it for user accounts as well. Imagine you have a persistent session enabled and you’re logged into an admin portal as an administrator. If you close your web browser, you can simply reopen it and navigate back to the admin portal without facing any MFA challenge—you’ll still be logged in! I always recommend “Never persistent”.

Various client requirements

This is a BIG topic with many variables and it depends very heavily on your existing technical environment, but you should strive to always set clients as a requirement to access resources as much as possible. A common recommendation is to require compliant devices in order to access resources in the cloud. This not only requires Microsoft Intune but also that you set up a proper compliance profile. You can use this in many different ways, but I normally suggest restricting desktop apps for compliant/managed devices, so unmanaged devices can only use webapps (and should be blocked from downloading files). If you don’t have devices in Intune, then use hybrid joined devices if that’s applicable. If not then take a close look at device filtering (located under Conditions) and see if you can use this to identify clients within your organization. This is a very flexible expression builder to include or exclude devices from you policy.

Secure your service accounts

Service accounts can’t use MFA and I see many places that people opt in for an IP address filter. The downside is that everything from that IP can then log in using that service account. Want a better filter? Use the device filter from the point above to filter login to specific devices, using their Device ID or particular values in an extentionattribute. This however requires your device to be Entra registered/Entra joined/Entra hybrid joined. In particular, service accounts can be restricted to only log in from specific device and not whitelisting the entire IP address. Below is a straightforward yet effective filter. The specified user is blocked from logging in from any device except the one with the specific DeviceID.

Secure MFA registration

An account is particularly vulnerable for hijacking before their first MFA method is set, so this is a critical part of your user provisioning. Under “User actions” in Conditional Access you have a setting meant to secure MFA registration.

If an MFA method is registered, then Entra ID will out-of-the-box always ask for MFA to register another method. Use this to your advantage and pre-register either a Temporary Access Pass or a FIDO2 key. You can use a phone number as well, but I’m hesitant to recommend it because it’s such an insecure method. In addition use either IP filter or a device filter. For example you must log in from a hybrid joined device or Intune compliant device in order to register MFA methods on your account.

IP address/Country filters

Most important of all: You should never exclude IP addresses from MFA requirement and you shouldn’t rely solely on an IP filter for your security. You can however enhance your Conditional Access policies by using IP filters to block IP addresses or countries from which you know you won’t be logging in. For instance, if your organization is based solely in Norway and rarely travels abroad for work, it makes sense to restrict logins from other countries. However, this filter should be used in addition to other policies, such as requiring MFA and compliant devices, rather than replacing them. But keep in mind that you need a plan for when the need to login from other countries arrives, but luckily we have a blog post on how to fix that in a secure manner.

Authentication Context (thank you Mariusz Wolski and Felix Brand)

This honestly should be a separate blog post, but I was compelled to include it here as well. In Entra ID, you can define one or several ‘Authentication Contexts’. These contexts are available to be used in other apps in Entra, including 3rd party, provided the app supports them. The purpose is to enable trigger-based Conditional Access policies that activate only under specific conditions. A common example in my experience is Privileged Identity Management (PIM), where you can use Authentication Context to trigger new Conditional Access policies when activating a privileged role. These additional policies can include stronger MFA methods like FIDO2, requiring a compliant device, or enforcing another sign-in frequency and never persisting sessions. All of which will be automatically enforced when you activate your role.

On that note: When you activate a privileged role, it is recommended to set sign-in frequency to “every time”. It ensures verification of your identity at activation and fairly often while the role is active, reducing the risk of token theft and session hijacking. It should be combined with never persistent sessions. It is a real danger of MFA fatigue and depending on your workload you can receive a large amount of prompts. So you should test well before deployment and use this primarily on highly privileged roles.

Block Device code flow (thank you Erik Radix and Alexander Tuvström)

Device code is an authentication method where you navigate to a link and enter a code. It’s primarily used for devices with limited or no keyboard or web browser functionality, making it difficult or impossible to enter a username and password directly. With the device code flow, you obtain a code on the device you want to log into and complete the authentication on another device. While this method is convenient, it also poses significant phishing risks. I found an excellent blog post about it, which I highly recommend checking out.

Once again, security is much easier when you know the organization, so if your organization does not need device code flow on a large scale it is recommended to block it for everyone, and open up for any exceptions if you need them.

Thank you everyone!

This was my 3rd and last part of this series. I hope you found it useful. Conditional Access is a central and crucial part of your identity security, and establishing good Conditional Access policies should have a very high priority.

Writing this series was incredibly fun and inspirational to me, so I will write more posts about Conditional Access in the near future. But first I will enjoy some time off and enjoy Christmas with my family. 🎄

🥳Merry Christmas, happy new year and I’ll see you all in 2025! Take care!🥳