Conditional Access - The ultimate starter guide
Introduction
In today's world, workforce is more distributed and the security landscape keeps evolving. For IT security, identities and access management this brings some challenges along. A sign-in from a remote location, device or app may be suspect or originates from an attacker. However, we need to differentiate between legit and unauthorized access and allow the good guys and keep the bad ones out.
In this post I want to focus on the topic of identity & access management in a secure and controlled manner by using Microsoft security technologies. My aim 🎯 is:
- 💭 Explain different Entra security products and their relation
- ✅ Keep the post simple and understandable, even for someone not familiar with Microsoft Security
- 💡 Provide ideas and technical implementation guides with field notes to secure access to Entra ID
In a nutshell
- What can you protect? Identities: Users or workloads, apps (Enterprise Applications or App registrations) or with Entra IdP federated applications in authentication and authorization processes.
- How do you protect? We use signals 🚦 Signals are pieces of information that are supplied with every login. For example: Locations (geo or IP), device platform, client apps, device state/trust type and machine-learning evaluated risks.
- What is Access control? Based on the signals we control the access. The access can either be block or allow access or allow access with conditions.
- What can you do with Session control? With that, we can control the session layer and apply more granular control.
Components
- Entra ID — Microsofts identity & access management solution, a central cloud-based identity provider. All authentications to an organizations resources (such as Microsoft 365 or SaaS with federated IdPs) are evaluated against Entra ID. It verifies the authentication (is someone allowed to access) and authorization (is someone allowed to do something). Read more
- Conditional Access — Part of Entra ID and Protection is the most relevant feature to control access, based on different conditions and signals. Conditional Access is a rule-based feature to be configured by an IT admin. Every organization that has a Microsoft 365 subscription or Azure should enable Conditional Access to at least enforce MFA. Read more
- Identity Protection — Entra ID Premium Plan 2 feature to allow/block access based on signals and machine learning evaluation.
- Authentication methods — Technologies and types to proof mutli-factor authentication. Examples: Microsoft Authenticator, FIDO2 security keys and passkeys, Temporary Access Pass etc.
Read the approaches below to understand how these components play together.
Conditional Access policy capabilities
More information: Manage emergency access admin accounts
| Configuration aspect | Description |
|---|---|
| Users | Include or exclude users, groups, roles and other identities |
| Target resources | Include or exclude cloud apps which are federated with Entra as IdP |
| Network | Include or exclude network or named location |
| Conditions | Include or exclude different conditions and signals: -User risk -Sign-in risk -Insider risk -Device platforms -Locations -Client apps -Filter for devices -Auhentication flows |
| Grant | Block or allow access, or require conditions: -Require multifactor authentication -Require authentication strength -Require device to be marked as compliant -Require Microsoft Entra hybrid joined device -Require approved client app -Require app protection policy -Require password change -Require Terms of User Choose whether all or one of the selected controls |
| Session | Apply session controls to enable limited experiences within specific cloud apps -use app enforced restrictions -Use Conditional Access App Control -Sign-in frequency -Persistent browser session -Customize continuous access evaluation -Disable resilience defaults -Require token protection for sign-in sessions -Use Global Secure Access security profile |
Approaches and conditions
Those are the conditions and signals that we can work with. All of them are transmitted for each (non-)interactive sign-in request.
- Allow/block geographical locations > restrict access from different countries with Conditional Access - Named locations (IP to country resolution)
💡 Recommendation: Make a list of countries from where your organization data should be available for your employees.
- Allow/block network locations > restrict specified IP addresses or Global Secure Access trusted network locations
💡 Recommendation: Create Conditional Access named locations with your breakout and other specially treated IP ranges.
- User/sign-in risk > machine-learning evaluated signals that classify risks
💡 Recommendation: Block high user risk and medium-high sign-in risk.
- Require device trust level (Hybrid joined or marked as compliant device) > corporate-owned devices either hybrid joined or marked by Intune as compliant
💡 Recommendation: Use and enforce Intune device compliance.
Those signals should not be assumed as trusted and used to allow access, but to block access.
(As signals could be faked by a potential attacker in order to get access.)
Recommended policies
It is no secret, that Microsoft provides you with Conditional Access templates, ready to be activated with a few clicks. Those are a great starting point for every organization and should be evaluated. To make you the decision easier, I have prepared a table with some facts below.
| Policy name | Description | Impact | Security posture benefit | Technical implementation effort |
|---|---|---|---|---|
| Require multifactor authentication for admins | All admins (roles) require MFA | 🟩 Low | 🟥 High | 🟩 Low |
| Securing security info registration | Security info for MFA registration is restricted to conditions | 🟧 Medium | 🟧 Medium | 🟩 Low |
| Block legacy authentication | Blocks legacy authentication (username + password) | 🟧 Medium - 🟥 High | 🟥 High | 🟧 Medium |
| Require multifactor authentication for all users | All users must perform MFA to access services | 🟧 Medium | 🟥 High | 🟩 Low |
| Require multifactor authentication for guest access | All guests must perform MFA to access resources | 🟧 Medium | 🟧 Medium | 🟩 Low |
| Require multifactor authentication for Azure management | Portal access to Azure requires MFA | 🟩 Low | 🟥 High | 🟩 Low |
| Require multifactor authentication for risky sign-ins | Entra Identity Protection classified risky sign-ins are prompted with MFA | 🟩 Low | 🟧 Medium | 🟩 Low |
| Require password change for high-risk users | Entra Identity Protection classified risky users must change their password | 🟩 Low | 🟧 Medium | 🟩 Low |
| Require compliant or Microsoft Entra hybrid joined device for admins | Require Intune compliant or hybrid joined device for admins | 🟧 Medium | 🟧 Medium | 🟧 Medium |
| Block access for unknown or unsupported device platform | Block access for certain device OS platforms | 🟧 Medium | 🟩 Low | 🟩 Low |
| No persistent browser session | Browser access is never persistent | 🟧 Medium | 🟧 Medium | 🟩 Low |
| Require approved client apps or app protection policies | Mobile Application Management applies for apps on unmanaged devices | 🟧 Medium | 🟧 Medium | 🟥 High |
| Require compliant or Microsoft Entra hybrid joined device or multifactor authentication for all users | Require Intune compliant or hybrid join device for all users | 🟧 Medium | 🟧 Medium | 🟧 Medium |
| Use application enforced restrictions for unmanaged devices | App enforced restrictions through session controls limit experience | 🟧 Medium | 🟧 Medium | 🟥 High |
| Require phishing-resistant multifactor authentication for administrators | Admins must have phishing-resistant MFA method like FIDO2 or WHfB | 🟧 Medium | 🟧 Medium | 🟧 Medium |
| Block access for users with insider risk (Preview) | Insider risk controls | 🟧 Medium | 🟧 Medium | 🟧 Medium |
*personal classification
Additional policies
For sure there are many more additional policies that can be implemented. After you set the recommended policies live, you can start thinking about additionals. Those could be organization-specific for certain identities or apps.
Monitor
After you implement Condtitional Access policies, monitoring their impact will be crucial. Therefore you can make use of multiple features in Entra ID.
What if
If you want to get a better understanding of the impact of one or all of your policies you can use the built-in What if analyzer. You can input any signals that you want and those will be simulated and evaluated against your policies.
Sign-in logs
The first thing I always check when a user is faced by a Conditional Access sign-in failure are the sign-in logs. A sign-in blocked by Conditional Access looks like one of the following for the user:
The sign-in logs can be checked on tenant-level or individual per user. You can also filter for failed Conditional Access status.
More on Logs & Monitoring in Entra ID:
Niklas Tinner
Log Analytics Workspace
A Log Analytics Workspace is a pay-as-you-go resource hosted in Azure. It requires an Azure subscription. You can connect Entra and the Log Analytics Workspace to store your sign-in data for longer than 30 days, make individual KQL querries and use Entra workbooks.
More on Log Analytics Workspace:
Niklas Tinner
Entra monitoring workbooks
Entra monitoring workboos are great overview dashboards to get insights into various Conditional Access usage and impact data. Find them at Entra > Monitoring & health > Workbooks. Those related to Conditional Access are:
- Conditional Access insights and reporting
- Continuous access evaluation token insights
- Conditional Access Gaps and Recommendations
More...
Entra Authentication methods activity
To find out which authentication methods users are making use of for MFA, have a look at Entra > Authentication methods. Under activity and user registration details you can find all the necessary information and reports on which methods are used and registered.
Field notes 📝
Start enforcing in an organization
Conditional Access should be the heart of every identity related security in any organization that uses Microsoft 365 or Azure services. If you can start with a fresh tenant, you should start with all policies right away.
If your organization has already adopted Microsoft services, you need to get into a project with the aim to make a smooth transition and balance security and productivity to implement the policies. Get together with your security responsibles to define the upcoming changes and initiate the necessary steps. User adoption and communication becomes an important part of the process too. This is an example of steps to take on the journey to Conditional Access:
- Define the use case or security posture improvement
- Create the policy in report-only mode
- Monitor impact
- Get approval to implement policy
- Test (enable policy) with pilot users
- Get feedback, adjust or decide
- Apply policy to all
Once you have your baseline of policies, you can start to expand them to other use cases. Also stay up to date, as with every Microsoft cloud service, Conditional Access also regularly receives updates and new features. Those should be constantly evaluated and adopted, if possible.
Keep it with integrity
One more important topic is the integrity of your CA policy framework. Once the policy definition and security requirements are definied, no one should "touch"/alter the production policies without approval or justification.
With that along comes the documentation of the policies. Whether thats a tool you run or do it manually in a document or an app doesn't matter - but it should be documented!
Stay up to date
Microsoft releases new features for their cloud products, including Conditional Access. Evaluate those and your use cases and think about how to improve your security posture or making the end users life easier. Stay up to date with the Microsoft Entra Blog
powered by Oceanleaf
Niklas Tinner
Niklas Tinner