Here it is – everything you need to know about using Entra ID’s Conditional Access policies to boost your identity security posture.

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft’s cloud-based identity and access management service. It helps you manage and secure user identities, lets you synchronize legacy or on-premises identities to the cloud, and offers single sign-on (SSO) access to Infrastructure as a Service (IaaS) and Software as a Service (SaaS) applications. 

Entra ID plays a crucial role in Microsoft’s cloud architecture. It’s the only identity provider that provides direct access to popular Microsoft applications such as Microsoft 365 and Azure Cloud Services, which is why you need to properly configure your Entra ID tenant.

The consequences, otherwise, are clear. Over the past year, threat actors have exploited Entra ID misconfiguration in high-profile incidents, including the latest Microsoft breach, where the Russia-backed group Midnight Blizzard gained access to one of Microsoft’s Entra ID tenants using a password spraying attack that targeted users without MFA. After the initial breach, the group abused OAuth application permissions to access executive-level mailboxes and exfiltrate sensitive information.

Breaches like this are preventable with the proper Entra ID security controls. That’s why, in this article, we’ll take you through how to set up Entra ID’s Conditional Access policies and security configurations to ensure your identities are fully protected. 

Entra ID security defaults

Microsoft has been rolling out Entra ID security defaults for newly created tenants since October 2019. Security defaults are a set of configurations that help protect you from identity-based attacks like password spraying and phishing, which are common today.

Security defaults are designed for free-tier Entra ID tenants or those without Conditional Access features. If you pay for a P1 or P2 Entra ID license, we don’t recommend using security defaults – use Conditional Access instead. While Conditional Access policies are fully customizable, security defaults are not. 

Security defaults offer the following controls:

• Require all users to register a multi-factor authentication method 
• Require administrators to log in using multifactor authentication (MFA)
• Require all users to log in using MFA to access:
  • Azure portal
  • Microsoft Entra admin center
  • Azure PowerShell
  • Azure CLI
• Disable legacy protocol authentication

How to enable Entra ID’s security defaults

Log in to the Entra Admin Center as a security administrator or higher privileged admin. Navigate to  Identity > Overview > Properties. Select Manage security defaults and enable them.

For more information on Entra’s security defaults, see Microsoft’s official documentation.

Conditional Access

Conditional Access is a security feature provided by Entra ID to P1 and P2 premium tenants. It lets you implement policies that control access to applications and resources based on certain conditions or criteria, including user identity, device compliance, location, and more.

Conditional Access policies help prevent unauthorized users from getting hold of sensitive resources, improving your security posture. They’re highly versatile and have multiple use cases, but can be quite complicated to set up. So, as you read on, we’ll explain how each policy works and how you can leverage it. We’ll also provide some common policy examples to help. 

Why you should adopt Conditional Access

Picture this. You’re in charge of identity and access management at a tech company based in Europe. The company has 200 employees across the following departments:

• R&D (some work remotely)
• Sales (part of the group is based in the US)
• Accounting

It outsources the following services:

• Security Operation Center
• Marketing
• IT and Cloud consulting

It has a hybrid infrastructure, including

• On-premises active directory
• Legacy on-premises application
• Entra ID tenant synched with the on-premises AD
• Workload in one of the big IaaS providers
• Cloud services and SaaS apps:
  • Microsoft 365 (Email, Sharepoint, and Office)
  • Salesforce
  • GitHub 
  • SaaS application for accounting and finances

Based on this information, your task is to implement a secure authentication strategy that keeps in mind the following:

• The approach should be as permissive as possible – using strict security measures only when there’s no other solution.
• Each department should be able to operate remotely if needed.
• On-premises users should be able to access any service in the hybrid environment via single sign-on.
• Role segregation – employees should only have access to services relevant to their work.
• The principle of least privilege must be applied when providing access to applications.

Sound familiar? 

Though this may sound complicated, it’s the reality for many companies today. Employees now work remotely across the globe in different roles and with varying levels of access rights and privileges, which means that authentication security must be tighter than ever. If your administrator logs in on vacation from Zanzibar, for instance, his authentication flow must be stricter than it would be in the office.

To give employees this flexibility while addressing the diverse security requirements involved, a Conditional Access strategy is crucial. With this, you can tailor security measures to specific roles, locations, and applications, providing a robust and adaptable security framework. 

How do Conditional Access policies work?

Conditional Access is determined by policies. Administrators can design and create policies for different use cases that control who can access what and when.

Conditional Access policies are built from two sections:

1. Assignments
   • Users – who is affected by the policy?
   • Target resources – what resources are protected by the policy?
   • Conditions – under what conditions does the policy allow or deny access?

2. Access Controls
   • Grant – block or allow access. You can specify extra security measures if you decide to allow access.
   • Session – Entra ID session lifetime management.

How to set up Conditional Access policies

To create a new policy in the Entra ID portal, sign in as an administrator and navigate to Security > Conditional Access > Create new policy.

Users

Configure who is affected by the policy. You can include and exclude entities in the same policy. For example, a policy can include a specific group (such as privileged users) and exclude specific roles (Global Administrators) to provide the most granular access possible.

Target resources

Four target resource types can be protected by Conditional Access policies:

1. Cloud applications – any app that Entra ID provides access to. The policy is evaluated when a user signs into one of the apps set as a target.
2. User actions – the policy is evaluated when the user tries to register security information (MFA, password, etc.) or connect a new device to the tenant. 
3. Global Secure Access – not covered in this article. For more information, see Microsoft’s documentation.
4. Authentication context – a tag that can be applied to Protected Actions (tenant level actions), Entra ID Groups, and Sharepoint data. When you configure a policy that targets an authentication context, you need to choose at least one auth context. The policy is evaluated when either:
   1. The user executes a protected action that’s associated with the selected authentication context.
   2. The user is a member of a group that’s associated with the selected authentication context.
   3. The user tries to access a file that’s associated with the selected authentication context.

Conditions

Six conditions can be applied to a Conditional Access policy. 

1. User risk: This Entra ID security feature tags users as risky if they’re doing something suspicious. See Microsoft’s documentation for more.
2. Sign-in risk: If Entra ID tags an authentication attempt as risky, the policy is evaluated at sign-in. You can control users’ access based on the risk that Entra ID detects while they sign in.
3. Device platforms: Approve or deny authentication requests based on the operating system of the device used for login. 
4. Location: Locations are configurable objects that group lists of IP addresses, Classless Inter-Domain Routing, and geographic locations. You can approve or deny sign-ins based on the origin of the authentication request.
5. Client apps: There are two main types of client applications – modern authentication and legacy authentication clients. You can approve or deny an authentication request based on the client application used for login, which is helpful considering legacy authentication apps can leave your tenant exposed to user discovery and even brute-force attacks.
6. Filter for devices: You can apply custom device conditions to decide which devices are allowed to sign in to your tenant. See Microsoft’s documentation for more.

Available access controls

Grant

Allow or deny access to the tenant based on the configured assignments. If the policy allows access, you can apply one or more security controls as extra access requirements. These can include:

• Require multifactor authentication – MFA (any type) is required for sign-in.
• Require authentication strength – choose what MFA types (passwordless, phishing-resistant, or any type) are required for sign-in.
• Require the device to be marked as compliant – determined by your Intune compliance policy.
• Require Microsoft Entra hybrid joined device – allow access if the device is registered in Entra ID.
• Require approved client app – only allow access if the user authenticates via applications listed in Microsoft’s documentation.
• Require app protection policy – require the application used for sign-in to be protected by an Intune app protection policy. See Microsoft’s documentation for more.
• Require password change – allow access and force a password change after a successful authentication.

You can allow access if all – or at least one – of these conditions are met.

Session

These controls manage session properties such as lifetime, persistence, continuous access, and more following successful authentication.

• Use app-enforced restrictions: Establish a limited or full session based on the source device. While using this control, Entra ID passes device information to the target application. Each target application can be configured to use the incoming information from Entra to establish sessions with different capabilities. Microsoft Cloud Services, including Microsoft 365, Exchange Online, and SharePoint Online, all support this control. For example, you can configure Microsoft 365 to only allow non-limited sessions when a hybrid domain-joined device is used to log in – even by an administrative user.
• Use Conditional Access app control: Tenants with a Defender for Cloud Apps and Entra ID P1 license can redirect traffic to their cloud applications through Defender for Cloud Apps. This acts as a proxy between the user and the target application and monitors user activity within the cloud app to detect suspicious activities.
• Sign-in frequency: How much time a user has before they’re asked to re-authenticate.
• Persistent browser session: Allows the session to persist on your machine even if the browser is closed. This feature is not recommended as it exposes your sessions to unnecessary risks.
• Customize continuous access evaluation: Revoke access tokens based on critical events that occur in real-time. For example, you can continuously monitor the IP address from which a session originates and revoke the session if the IP changes (which can indicate session hijacking). This will require the user will to re-authenticate.
• Disable resilience defaults: Controls what happens if policies can’t be evaluated due to a power outage. By default, when Entra ID can’t process policies, it automatically extends the existing active session lifetime. If you choose to turn this control on, Entra ID will not extend the session’s lifetime.
• Require token protection for sign-in sessions (preview): Binds user sessions to the machine they were generated from. The feature is available for supported devices and is only relevant to Exchange Online and SharePoint. See Microsoft’s documentation for more.
• Use Global Secure Access security profile: Only relevant when the target resource of the policy is set to Global Secure Access.

Policy enforcement modes

When you finish configuring the relevant controls, you can apply one of the following operation modes:

• On – the policy is active and allows or denies access based on the configured controls.
• Off – the policy is not active.
• Report-only – the policy is not active but logs the policy evaluation results. This option is great for troubleshooting policies.

What is Conditional Access used for?

Now that you know which controls are configurable, it’s time to put them to use. Here’s how you can use Conditional Access controls to achieve your security and compliance goals.

• Blocking unauthorized access: Only grant access using a passwordless or phishing-resistant MFA method to minimize the risk of compromised user accounts.
• Location-based access: Grant or block access to the tenant based on the origin of the authentication request. You can be as granular as you want here by creating trusted and untrusted zones and applying access conditions to them. For example, you can enforce MFA for users logging in from home but relax the rule for those doing so from your headquarters.
• Compliance-based access: Grant or block access based on the device that was used for authentication. You can apply different conditions to multiple device compliance states. For example, if the device used for authentication is marked as compliant in Entra ID and is domain-joined, your controls can be less restrictive than a Zero-Trust policy.
• Session controls: Limit the session lifetime based on a directory role. By default, the Entra ID reauthentication period is set to 90 days. You can create reauthentication policies for different roles in the organization based on their sensitivity. This might involve configuring administrators to reauthenticate non-privileged users more often, for instance.
• Identity and application granularity: You can create granular, application- and entity-specific policies that deal with edge cases, such as one that only grants access to an emergency break-glass administrator under specific conditions or a policy for sensitive applications (such as Entra admin portals) that require stronger authentication controls than other cloud applications.

Configuration deep dive

You need to decide the purpose of a new policy before creating it, such as: 

1. MFA enforcement policy for non-administrative users: The policy will be context-aware, meaning that its outcome will be determined by the device or IP address used for sign-in. 
2. Zero trust policy for Global Administrator sessions: The policy will apply Zero Trust principles while authenticating an administrative user.

MFA enforcement policy for non-administrative users

Create the policy

Sign in to Entra ID as an administrator and navigate to Security > Conditional Access > Create new policy. Name the policy “MFA enforcement for non-admin users.”

Assignments

Users

You’re protecting non-administrative users in this policy. Navigate to Assignments > Users and click on the blue line that reads “0 users and groups selected”, then select Include > All users and exclude administrative roles.

Another option: You could also have created a group that contains all the administrators and excludes the users and groups. 

Target resources

As the authentication is against Entra ID cloud applications, set your target resources to Cloud apps, then select Include > All cloud apps.

Conditions 

The policy should be context-aware. Enforce MFA authentication for users who aren’t working from trusted network zones like the company headquarters, VPN subnets, or other company network segments. 

• Locations condition: Configure trusted locations (see how to do this) and select exclude all trusted locations. This means that if the user is signing in from a trusted location, they won’t be forced to authenticate using an additional factor.

• Filter for devices: The device filters are only used to enforce MFA authentication if the device is not registered in Entra. To do so, exclude devices whose TrustType is not registered or domain-joined.

Important Note: Exclude users when needed. A service account that operates without the Global Administrator role, for example, would have stopped working since it’s not excluded from the configured policy. 

Access Controls

Grant

If the assignment configurations are met, access will only be allowed while using MFA. 

To set this up, select Grant access > Require authentication strength and then pick Multifactor authentication from the dropdown box. We recommend you require stronger MFA methods like passwordless or phishing-resistant.

Session

While your main goal is to enforce MFA, make sure that a user’s sessions are time-limited once they log in. The time limit can be set as you see fit. In this example, users are required to sign in with an MFA at least once a day. Set the sign-in frequency control to periodic reauthentication every 12 hours (an entire workday).

Zero trust policy for Global Administrator sessions

Create the policy

Sign in to Entra ID as an administrator and navigate to Security > Conditional Access > Create new policy. Name the policy “Zero trust policy for administrative sessions.”

Assignments 

Users

You’re protecting administrative users in this policy. Under Assignments > Users, select the blue line that reads “0 users and groups selected”, then opt to Include the Global Administrator directory role and Exclude a break-glass administrator user:

Target Resources

This time, select the Microsoft Admin Portals. The goal is to ensure that the most sensitive admin portals will remain protected and require the user to reauthenticate more often (see session controls).

Conditions

• Sign-in risk: Allow users to sign in only if there is no risk to real-time sign-in.
   
• Device platforms: Allow the Global Administrator to log in only via a Windows machine.
  

• Client apps: Allow Global Administrators to sign in only via Browsers, Mobile apps, and desktop clients. When legacy authentication clients are configured to allow sign-in, your users might be at risk of user enumeration or brute-force attacks while ignoring MFA configurations.

Access Controls

Grant 

Only grant access if all the following controls are met:

• Require the strongest authentication strength: Phishing-resistant MFA
• Require the device to be marked as compliant
• Require a Microsoft Entra hybrid joined device

Session

• Sign-in frequency: Periodic reauthentication every 1 hour
• Customize continuous access evaluation: Strictly enforce location policies

Testing and troubleshooting

As organizations grow, so do their sign-in use cases. Each use case might require a dedicated policy. You might find yourself managing dozens of policies at this point and asking: Are there duplicated policies? Do they evaluate correctly? Is there a logical bug in the policy configuration that denies a crucial service? Are there any users that were blocked by mistake?

These are all valid concerns. Here are two methods to troubleshoot policies:

Sign-in logs

Entra ID sign-in logs provide details about which policies were evaluated during the sign-in process and their result. To view the logs, sign in to Entra ID and navigate to Monitoring > Sign-in logs. You can click on each log and switch to the Conditional Access tab to understand which policies were evaluated and see the results:

You can use search filters to answer specific questions like: “Which policies are evaluated for the user X?” or “Which policy is locking the user Y from signing in to Entra?”. 

On the sign-in logs page, click Add filters, choose Conditional Access, and apply.

By default, the new filter value will be set to None selected. Click on the new filter and select Failure. Click on a specific failed sign-in log and choose the Conditional Access tab. Select a specific policy row, then the three dots on the right side, and finally, Show details. The new page will help you understand why the result is Failure.

In the example above, you can see that the user was denied access because they were required to present an MFA method but didn’t.

What If

You can manually simulate a sign-in event to check it against your policy set.
From the Entra ID console, navigate to Security > Conditional Access > Policies. Then select What If.

In the new window, you can provide the tool with your hypothetical sign-in details:

In this example, you can see which policies will be evaluated and what the conditional access result will be if an administrative break-glass user signs in from the IP address 1.3.3.7 using a browser from a device that isn’t domain joined.

After filling in the details, select What If. A new section will show up with two tabs: Policies that will apply and Policies that will not apply.

You can see the Grant control conditions that are applied to the policy, which determine if the user will be allowed to sign in or not—the combination of sign-in logs and What If can be a powerful method for policy troubleshooting.

Take Preventative Measures to Improve Your Entra ID Security Posture 

If you’d like to learn more,

And, if you want to see if you have any Entra ID misconfigurations that can impact your environment, Rezonate can conduct a free risk assessment for you. Request your FREE risk assessment report today! Or,  request a demo to see how Entra ID misconfiguration can impact your environment.