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.
We wrote about it
We wrote about it- How conditional access works
- Conditional Access Policy Hierarchy
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)
The window for adding a new policy consists of 4 basic sections.
1. Name – mandatory
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 actions – mandatory 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.
Conditions – optional parameter. Additional conditions restricting the policy. Details later
3. Access controls
Grant – mandatory parameter. Conditions under which access will be granted .
Session – optional parameter. Additional advanced settings. For basic applications are not required.
Important
ImportantConditional access works AFTER VERIFICATION of the login and password, so it has data on what groups the user belongs to and what administrative roles he has been assigned.
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.
Important
Step 1 and Step 2 – MUST HAVE DEFINED TERMS
These can be All users or All cloud apps conditions but must be set.
Step 3 is OPTIONAL, we don’t need to configure it.
It gives us the opportunity to build different policies for the same user groups and applications based on additional parameters
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.
Ok, the conditions are ready
Ok, the conditions are readyAt the moment, based on our conditions:
- user and groups to which it belongs (it’s in the configuration section: Users and groups)
- target application to which it tries to connect (it’s in the section: Cloud apps and actions)
- optional additional restrictions (in the Conditions section)
System can decide if the policy should be run.
IF NO: this will end the process
IF YES: we are going to Step 4
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
- 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
- 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
- Configure them in the Conditions section
- Specify the requirements you set for the user and configure them in the Grant section
- Do not touch the Session section for now
- 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?
Remember
- First check the policy on a small group of people and then turn it on for a larger group.
- Create an account or Emergency_Access group that will be excluded from Conditional Access. Let them be accounts not used on a daily basis, intended for use only in exceptional situations.
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.
External Links
External LinksWhat is Conditional Access? – Microsoft Documentation
https://docs.microsoft.com/en-us/azure/active-directory/conditional-access/overview