Conditional Access – access under control

With Conditional Access, you can easily and effectively control access to selected areas of our environment. Thanks to flexible mechanisms for building Conditional Access policies, we can quickly and effectively increase security by introducing additional requirements.

Seemingly the principle of operation and the rules used seem simple and understandable, however, in many implementations it turns out that this belief is apparent. In the reality of the internet, incorrectly implemented conditional access rules turn out to be more dangerous than their lack. The apparent sense of security resulting from the implementation of conditional access means that we incorrectly assume that some attack vectors will not be used.

How conditional access works

Azure Active Directory uses Conditional Access to make decisions about granting the user access to the resource and determining the conditions on which it is to occur.

Conditional access policies are enforced after the first authentication is completed. Therefore, conditional access should not be used as the organization’s first line of defense for scenarios such as DoS attacks.

Conditional access works on the principle of the simplest structure: if, then. The system checks for each policy whether the attempt to gain access meets the conditions of the policy, if so, runs the policy. Then, the system collects the results of running policies. Their result determines whether and on what terms the user can access the appropriate resource.

If the conditions are met, the policy is applied and actions are taken regarding access rules.

The result of the policy is blocking access or allowing access under certain conditions.

System checks Conditional access policies with each access attempt. It checks a set of conditions for each policy. If the connection attempt meets the conditions for the policy, the system runs it.

The result of all policies determines what conditions a user must meet to gain access.

Access is granted when everyone’s requirements have been met applied policies (AND logical operation).

If the result of any of the policies is Block access, the user does not access the resource.

Conditions

The conditions under which conditional access determines whether a policy is to be applied.

Mandatory conditions

1. User or group  (Users and groups)

   The policy will be applied only to selected users or users belonging to the indicated groups.

2. Cloud applications (Cloud apps)

   The policy will only be applied if you request access to the resource specified in this condition.

The policy is applied to selected users or groups trying to access the indicated resource.

Optional conditions

1. Platform / Operating system (Device platform)

   Restricting or excluding policy execution only to cases when the device generating the request operates under the control of one of the systems:

   • Android
   • iOS
   • Windows Phone
   • Windows
   • macOS

2. Location

   The policy will be applied or will not apply to requests coming from the indicated address classes.

3. Client Application

   The condition can be built for the case of browser connections and several other conditions regarding the client application.

4. Device Status

   In this case, we can only exclude from the operation of the policy for devices properly connected to the domain (Azure Hybrid AD Joined) and / or verified by Intune as complying with the defined compliance policy.

There are several other conditions, but we will tell about them another time, they are a little more complicated.

What’s next?

We already know if the user has met our conditions. Know which policies to run and can take action.

Decision!

• We already know who connected, what they want to get to and where they connect to, and which application they use ….
  
  or
  
• We know who has connected and what he wants to get to
  
  or…..

We decide:

• We’re blocking access! – we do not agree to the connection for such conditions
  
  or
  
• We agree to accessunder certain conditions:
  
  • User uses two-factor authentication
  • Connects from the device marked as complying with Intune policy
  • Connects from the Hybrid Azure AD joined device
    

How exactly does it work?

In practice it is a little more flexible and effective.

Let’s define some requirements set by the security department:

1. The administrator can connect outside the corporate network only from a registered computer and must use MFA
2. Users outside the corporate network must use MFA
3. We do not allow any logins for previously defined dangerous networks (NET_NOTRUST).

What policies will we define?

1. All connections from the NO_TRUST network are to be Blocked
   Users and groups: All users
   • Cloud apps: All cloud apps
   • Locations: Include: Any location Exclude: NET_CORPO
   • Block access
2. All users outside the korpo network must use MFA
   • Users and groups: All users
   • Cloud apps: All cloud apps
   • Locations: Include: Any location Exclude: NET_CORPO
   • Allow access provided
     require  MFA
3.  Administratorzy
   • Users and groups: Administrators
   • Cloud apps: All cloud apps
   • Locations: Include: Any location Exclude: NET_CORPO
   • Allow access provided
     • Require Hybrid Azure AD joined device

Conditional Access Policy Hierarchy

When an administrator connects to a public network, two policies apply: 2 and 3

1. Policy 2 requires the Administrator, because it belongs to All users, use MFA and then Policy 3 requires him to connect to the registered device.

1. All policies for which the connection / user meets the specified conditions are checked.

2. Each of them gives their requirements to allow access.

3. If the user meets the requirements of all policies – he gains access.

4. If even one of them prohibits access, the result of the others does not matter.