Azvise Azure & Azure AD, Security

What are Conditional Access Policies in Azure AD


What are Conditional Access Policies?

Conditional Access Policies (CAPs) are identity-driven policies that govern user access to resources based on certain conditions. We can summarize them as if statements that govern what will be requested, enforced or blocked. As identity has become a key focus for security efforts, it’s essential to manage it in the best way possible.

All policies “think” at the user level and are enforced after a user has completed the first form of authentication, such as entering their username and password. As such, an attacker could understand if the credentials are correct even if there are blocks dictated by CAPs that might block access based on various signals.

Conditional access policies are implemented using Azure Active Directory, which is the cloud-based identity and access management service that is part of Microsoft 365. As of right now, Azure Active Directory (or Azure AD for short) is being integrated into the newly created Entra product family.

It’s important to note that Conditional Access Policies will manage not only native Microsoft apps such as SharePoint, Teams, the Azure Portal, etc. but also all SaaS applications connected to Azure AD and all on-premises applications managed through Azure AD Application Proxy.

This can simplify the management of identities, as, for example, the user will have their MFA methods set in Azure AD, and they’ll be requested on all connected apps in Azure AD for which you have set Azure AD as the identity provider.

In most organizations, the CAPs enforce requirements such as the enforcement of MFA, the block of logins using legacy protocols and requiring a compliant device to access company resources.

It is advisable to create or make changes to CAPs only if you have a basic understatement of the service and always operate with caution since you could risk blocking access to the tenant for all users.

Please consider implementing an emergency administrator before starting with Conditional Access, and exclude it from all the policies. Read more regarding this here:

Manage emergency access accounts in Azure AD

All Conditional Access policies must grant a user access before they can access a cloud app. If one of the CAP blocks the sign-in, the request will be denied. Note that if in the same policy you both include and exclude a user, the user will be excluded.

I wrote a post on how to check which policy is blocking a user sign-in. If you are curious, you can check it out here:

How to check which Conditional Access Policy is blocking a user log-in – Azure AD

If you are creating a new policy, it can be set to “Report-only” mode first. This will allow you to use insights and reporting workbooks to evaluate the impact of the policy before you go on to apply it to everyone in the organization by turning it “On”. Alternatively, you can keep the policy inactive by setting it to “Off”. Please note that a certificate request might pop up on Macs or mobile devices if you require a check for Intune compliance in the policy, even if it’s in report mode.


Licenses and Security Defaults

As Conditional Access Policies require Azure Active Directory Premium P1, only some organizations are going to be able to use them. If you are not licensed for it, you use Security Defaults to establish a basic security baseline for your tenant. Security Defaults are now activated by default in all the newly created tenants. What Security Defaults will do is:

  1. Requiring every user to register for MFA. Once enabled, users will have 14 days to register before being required to do so.
  2. Requesting MFA for both standard users and administrators, especially when a user accesses privileged portals.
  3. Block legacy authentication protocols which can’t support MFA.


Templates and JSON

There is currently a set of recommended policies that you can deploy right away by clicking on “New policy from template” at the following link:

Conditional Access Policies | Azure AD

The templates are categorized in:

  • Secure foundation
  • Zero Trust
  • Remote work
  • Protect administrator
  • Emerging threats

While the templates are a very quick and easy way to start with CAPs, please exercise extreme caution. Even though they are created in report-only, they will not, for example, create a break glass admin and exclude it by default. If you mess up, you might end up locked out. Also note that it’s best to exclude users from CAPs using groups so that you don’t have to modify the policies constantly, which might end up in errors.

A cool new feature is the ability to implement CAPs using JSON templates. You’ll be able to export the policies you have created and be able to import them back in case anything happens.

To learn more, refer to the following documentation:

Azure AD Conditional Access documentation – Microsoft Entra | Microsoft Learn

Azvise Azure & Azure AD, Security

Add or remove a user from a Conditional Access Policy (CAP) – Azure AD


What are Conditional Access Policies?

Conditional Access Policies (CAPs) are identity-driven policies that govern user access to resources. We can summarize them as if statements that govern what will be requested, enforced or blocked.

In most organizations, the CAPs govern the enforcement of MFA, the block of logins using legacy protocols, and requiring a compliant device to access company resources.

All policies “think” at the user level.

It is advisable to make changes to CAPs only if you have a basic understatement of the service, since you could risk blocking access to the tenant for all users. In order to learn more, refer to the following documentation:


Azure AD Conditional Access documentation – Microsoft Entra | Microsoft Learn


General considerations

  • It’s a good idea to manage exclusions using Groups. This way, you won’t have to directly modify the policy every time.
  • Since many policies are scoped to include all users, you’ll have to handle exceptions with the “exclude” feature.


How to add or remove a user

  • Log in to Conditional Access – Microsoft Azure
  • Select the desired policy
  • If you intend to add a user to the policy, click on the blue link under “Users or workload identities”, then “Include,” and click the blue link under “Users and groups”.
  • Select or search for the desired user, then click “Select.”
  • If you want to exclude a user, click on the blue link under “Users or workload identities”, then “Exclude,” and click on the blue link just below “Users and groups.” The same user selection screen shown in the previous step will open. Search for and select the user, then click “Select.”

Once done, save using the “Save” button at the end of the page. If the policy is in “Report-only” or “Off“, the flow is not active.

Azvise Security

Restrict access to Azure Management apps – Azure AD

If we want to restrict access to the Azure management services for non-privileged users, we can now create a Conditional Access Policy that allows us to do so.

To create a Conditional Access Policy, we’ll need Azure Active Directory Plan 1 or higher, which is either bought standalone, or can be found most notably inside Microsoft 365 Business Premium, or the Microsoft 365 Enterprise plans (E3, E5)

On the other hand, if we just need to restrict access to Azure AD, we have the option to do so from the User Settings in the Azure AD portal:

User Settings | Azure AD

By creating the following Conditional Access Policy, we will restrict users from accessing these apps:

  • Azure portal
  • Azure Resource Manager provider
  • Classic deployment model APIs
  • Azure PowerShell
  • Azure CLI
  • Azure DevOps
  • Azure Data Factory portal
  • Azure Event Hubs
  • Azure Service Bus
  • Azure SQL Database
  • SQL Managed Instance
  • Azure Synapse
  • Visual Studio subscriptions administrator portal

First, open the following link, or go into your Conditional Access Policies:

Conditional Access Policies | Azure AD

Then, under “Users or workload identities“, select all users, and exclude the admin roles you currently use in your organization. You could also create a security group with all admin users as members and then exclude it from the policy.

Under “Cloud apps or actions”, click on “Selected apps”, then “Microsoft Azure Management“.

Finish up by selecting “Block access” under the Grant Access Controls.

From now on, all users except the admins will be blocked from accessing Azure management services.

Azvise Azure & Azure AD, Security

How to check which Conditional Access Policy is blocking a user log-in – Azure AD

General Introduction

If you have Conditional Access Policies in place to block certain log-ins, you might get that a user will contact you because their sign-in request is being blocked. Probably both you and the user don’t know which policy is making the log-in fail, since it’s not specified in the error message.

The usual error message is something along the lines of: “Your sign-in was successful, but does not meet the criteria to access this resource. For example, you might be signing in from a browser, app or location that is restricted by your admin.” and the standard error code is “BlockedByConditionalAccess” error 53003

How to solve

To get more details:

  • Click on the failed log-in request
  • Click on “Conditional Access“
  • The Policies that have as a result “Failure” and “Grant Controls” set on “Block” are the ones blocking the user.