Conditional Access – step by step configuration instructions – Part 2

Conditional access - configuration manual
Conditional Access step by step. Do you want to set up conditional access and aren’t sure how to do it right? This guide is for you.

Part 1

Where to look for the configuration panel

Network Configuration

Part 2

Configuration of the conditional access policy

Options overview

Part 3

Examples of business requirements

Jak je skonfigurować

Azure conditional access and policy configuration will be the topic of the second part of our guide. You will learn how to configure the policy, which options are required and which are optional and what they are responsible for.

Conditional Access – Creating a New Policy

After logging into the conditional access configuration panel, go to the policy view by selecting Policies (fig. 1) and then New Policy (fig. 2)

Lista polityk dostępu warunkowego Azure
fig. 1
Dostęp warunkowy Azure - dodaj nową politykę
fig. 2

The window for adding a new policy consists of 4 basic sections.

1. Namemandatory

Policy Name. It should be understandable and clearly define the purpose of the policy. An example of such a name might be: CA_POLICY_BLOCK_ALL_FROM_UNTRUST, albo: MFA_ALL_FROM_PUB

2. Assigments

Users and groups mandatory parameter. List of users and / or groups for whom the policy is to work. The policy will work ONLY for users configured here.

Cloud apps or actionsmandatory parameter. A list of applications to which the user connects and / or activities that he performs. The policy will ONLY work for connections to applications configured here.

Conditionsoptional parameter. Additional conditions restricting the policy. Details later

3. Access controls

Grantmandatory parameter. Conditions under which access will be granted .

Session optional parameter. Additional advanced settings. For basic applications are not required.

Principle of Conditional Access Policy operation

The system receives a connection. The policy checking process begins. The next steps are carried out:

Step 1: Checking the Condition – Users and groups

Test: WHO MAKES THE CONNECTION

E.g:

  • the user should be equal to j.doe@ourdomain.com
  • or (OR) the user should belong to the SALES group
  • and (AND) the user is NOT member of PRIVILEDGED group

In addition to belonging to groups, you can also use such conditions as: All guest and external users or Directory roles

Result:

TRUE: we go to the next condition
FALSE: stop, this policy will not be started for this connection

Real configuration examples can be found in the last part of our guide.

Step 2: Condition Check – Cloud apps or actions

Test: WHAT IS THE DESTINATION APPLICATION

E.g:

  • an attempt is made to connect to Microsoft PowerApps
  • or (OR) there is an attempt to connect to Office 365 SharePoint Online
  • and (AND) THERE IS NO PLACE trying to connect to Project Online

The option Register security information is available in the User actions tab – this option applies to the registration of an additional authentication mechanism for MFA. Check the paragraph: Basic Rules You Must Remember

Result:

TRUE: we go to the next condition
FALSE: stop, this policy will not be started for this connection

Real configuration examples can be found in the last part of our guide.

Step 3: Condition Check – Conditions

Test of the following 5 conditions

Important:

  • Only configured conditions are checked
  • The overall result is the product of the results of all configured conditions – if at least one condition returns FALSE, the entire test returns FALSE

If we want the policy to work for the user FOR ALL NETWORKS – do not enable the Locations condition and set Any location WE SIMPLY DO NOT enable this condition.

Same with the other conditions in the Conditions section.

The conditions in the Conditions section are used to limit the policy if they are not needed – we do not enable them!

Sign-in-risk
What levels of logging risk should the policy work for? For example, the policy is to work for connections rated as: sign-in-risk level = High or Medium

Device platforms
What operating systems should the policy work for? It is about the operating system on the device from which the user makes the current connection.

Locations
It is possible to specify the conditions for the IP address from which the connection is being made.

At this point, you can use previously defined network definitions. We discussed this in Part 1, in the paragraph: named locations

Client apps
Possibility to specify the condition for the client application used by the user. For example, the policy only works for connections from a web browser.

Device state
Determining the condition based on the device status in the AAD and its compliance with Intune policies. For example: the policy should work for all connections made from devices that do not have the status in AAD: Device Hybrid Azure AD joined

Result ( all 5 conditions, if configured ):

TRUE: we go to the next condition
FALSE: stop, this policy will not be started for this connection

Real configuration examples can be found in the last part of our guide.

sTEP 5: Restrictions – Grant

After a series of verifications, the decision came. In this step, we decide by choosing one of two options :

Block access – we do not agree to this connection and we block it.

or

Grant access – we allow connection but under certain conditions

These can be any conditions chosen from among:

  • Require multi-factor authentication
  • Require device to be marked as compliant
  • Require Hybrid Azure AD joined device
  • Require approved client app
  • Require app protection policy

Real configuration examples can be found in the last part of our guide.

And finally, we decide whether it is enough that the user meets one of the conditions selected by us or must meet all.

Basic Rules You Must Remember

How to set up a policy – procedure in a few simple steps
  1. Specify the conditions in the form (user A connects to application B) and the policy should work and configure them in the Users and groups and Cloud apps or actions sections
  2. Think about whether you expect different levels of security depending on
    • login risk
    • user’s operating system
    • the network it connects to 
    • the application he uses
    • device status
  3. Configure them in the Conditions section
  4. Specify the requirements you set for the user and configure them in the Grant section
  5. Do not touch the Session section for now
  6. Enable policy
All users and groups – Benefits And Risks

The policy will work for those users who meet the conditions set in the Users and groups section.

If you configure a policy and configure it by selecting all groups from the list (e.g. IT and Sales) – then if a new group appears, e.g. HR, the policy will not work for its members.

You must remember to update policies or make sure that the user is always assigned to a specific group. This is not a secure solution.

Choosing the option All users seems to be an interesting solution to this problem.

What is the danger of including politics for everyone?

First of all, the ability to block yourself and lose access to even the administrative panel. we will then remain in contact with Microsoft support.

In conjunction with All cloud apps, it already creates a very deadly mix.

Any suggestions?

After two theoretical parts, it’s purely practical examples. In the next, third part of our guide, I will present business issues I face in implementations and show how I think they should be configured.

Leave a Reply

Your email address will not be published. Required fields are marked *

four × four =

You May Also Like