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 and their security.
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:
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:
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:
Policies can be targeted to specific users and groups. These aregiving administrators in our organization greater control over access to applications and data.
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.
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 for security, 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 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.
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:
Let’s now see how a conditional access policy works in Azure AD.
All Conditional Access policies are applied in two phases:
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.
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:
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.
Many of today’s organizations have common access problems. It 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:
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.