Today’s modern security perimeter extends beyond an organization’s network to include both user and device identity, as access to the organization can occur from many different places and in many different ways.
For this reason, today we are going to talk about Azure Conditional Access, the tool that allows you to manage access according to the organization’s policies.
What is conditional access?
We could define conditional access as the tool that gathers the necessary signals to make decisions and apply the policies established by the organization. And this Azure AD conditional access is at the heart of the new identity-based control plane.
Stated most simply, conditional access directives are if-then statements; this means that if a user wants to access a resource, they must complete an action.
For example, if a payroll manager wants to access our organization’s payroll application, they need to use multi-factor authentication to access it. Another example, one of our workers wants to access the system from a trusted IP, such as the IP of the company offices, in this case, conditional access can allow not to use of multi-factor authentication since the device/user is being connected from a registered and trusted IP.
When setting up Conditional Access, administrators face two main goals:
- Empower users to be productive anywhere, anytime
- Protect organization resources
That is, the administrators of our organization using Conditional Access, can facilitate access in certain conditions or limit it in others, adapting to the necessary security of each situation so that our workers and users have the required access with a balance between comfort and security.
Next, we can see the operating scheme of Conditional Access:
What are the most common access conditions?
If we talk about the most common conditions that can be taken into account when deciding the access of a user or device in our organization, we could include the following:
Membership in a user or group
Policies can be targeted to specific users and groups, giving administrators in our organization greater control over access to applications and data.
IP location information
Organization administrators can create trusted IP address ranges that can be used when making policy decisions.
They can also specify that traffic from IP address ranges of entire countries or regions is blocked or allowed.
Users in our organization with devices on specific platforms or marked with a specific status can use them when applying Conditional Access policies.
Filters can be used for different devices, to target policies to specific devices, such as privileged access devices.
Users trying to access specific apps can trigger different Conditional Access policies.
Real-time and calculated risk detection
Signal integration with Azure AD Identity Protection enables Conditional Access policies to identify dangerous sign-in behavior.
Faced with a problem of this type, the established policies can force users to change their password, use multi-factor authentication to reduce their level of risk, or block access until an administrator carries out a manual action, making sure that there is no error. risk to the organization.
Microsoft Defender for Cloud Apps
Microsoft Defender enables our administrators to maintain real-time monitoring and control of user application access and sessions, increasing visibility and control over access and activities within our organization’s Cloud environment.
What are common Conditional Access decisions?
The most restrictive decision is the user or device access to the applications or data of our organization is blocked.
The least restrictive decision to apply, but this decision may require one or more of the following options:
- Require multi-factor authentication (MFA)
- Require device to be marked as compatible
- Require a hybrid Azure AD joined device
- Require approved client application
- Require an app protection policy (Currently in preview)
How does a Conditional Access policy work?
Let’s now see how a conditional access policy works in Azure AD.
All Conditional Access policies are applied in two phases:
Phase 1: Gathering session details
During the first phase of the policy, session details such as network location and device identity are collected, which will be required for policy evaluation.
Phase 1 of policy evaluation occurs for all policies that are enabled, as well as for policies that are informational only.
Phase 2: Compliance
During this phase 2, the session details collected in phase 1 are used to identify requirements that have not been met.
If there is a policy that is set to block access, the app will stop here and the user will be blocked.
If there is no lockout policy, but all requirements for access have not yet been met, the user will be prompted to complete further control requirements in the following order, until the policy is met:
- Multi-factor authentication
- Device marked as compatible
- Hybrid Azure AD joined device
- Approved Client Applications
- Application protection policy
- Change of password
- Custom controls
Once the user or device has passed all controls, session controls (those enforced by the application, enforced by Microsoft Defender for Cloud Apps, and token lifetime control) are applied.
Like phase 1, this phase 2 policy evaluation is performed for all enabled policies.
Some examples of commonly applied directives
Many of today’s organizations have common access problems that could be easily solved by using Conditional Access.
Next, we will put some examples in which the use of Conditional Access will be useful for our organization:
- Require multi-factor authentication for users with administrative roles
- Require multi-factor authentication for Azure management tasks
- Block logins for users who attempt to use outdated authentication protocols.
- Require trusted locations for Azure AD Multi-Factor Authentication registration
- Block or grant access from specific locations
- Block dangerous login behavior
- Require organization-managed devices for specific apps
If you want to know more about creating Conditional Access policies and their possibilities, you can continue reading about the step-by-step process here.
Daniel Morales Fitó – Cloud Engineer at Itequia