When it comes to manage access to resources in infrastructure, there are two main questions we usually ask.
- “Who” is the user and “What” resources?
- Is it allow or deny access?
Answers to above questions are enough to define the base rules. But depending on the tools and technologies that can use to manage the access, we will have additional questions which will help us define accurate rules. As an example, Sales manager walks up to the IT department and says “Peter need to access “Sales” folder in the file server”. So, based on the statement, we know the user is “Peter” and resources is “Sales” folder in the “File Server”. Also, we know the user “Peter” needs to “Allow” access to the folder. However, since we are going to use NTFS permission, we know that we can make the permissions more accurate than that. When sales manager says “Allow” peter to access “Sales” folder he didn’t define it as “Read & Write” or “Read Only”. He didn’t also define if he need same permission to all the sub folders in the “Sales” folder. Based on answer to those, we can define more granular level rules.
Access control to resource in an infrastructure happens in many different levels with many different tools and technologies. The first level of control happens in the network perimeter level. Using firewall rules, we can handle “in” and “out” network traffic to/from company infrastructure. If user pass that level, then it will verify the access based in users and groups. After that it comes to applications and other resources. But problem we have as engineers is to manage all these separately. Let’s go back to our previous example. In there we only consider about NTFS permission. If “Peter” is a remote worker and he connect to internal network using Remote desktop services, first we need to define firewall rules to allow his connection. Then if multi-factor authentication required for remote workers, I need to configure and defines rules in there. Also, when user logs in, he will not have same permission he has in company workstation. So, those session host permissions need to be adjusted too. So, as we can see even its sounds simple, we have to deal with many different systems and rules which cannot combine in to “one”.
So far, we looked in to on-premises scenarios. When it comes to cloud, the operation model is different. We cannot apply the same tools and technologies we used to manage access in on-premises. Microsoft Azure’s answer for simplifying access management to workloads is “Conditional Access”. This allow manage access to applications based on “Conditions”. When it comes to public cloud mostly we allowing access to applications from networks we do not trust. There for, using “Conditions” we can define policies for users which they need to comply, in order to get access to the applications.
In Condition Access Policy, there are two main section.
Assignments – This is where we can define conditions applying to user environment such as users and groups, applications, device platform, login locations etc.
Access Control – This is to control access for the users and groups when they comply with the conditions specified in the “assignments” section. it can be either allow access or deny access.
Let’s see what conditions we can applies using conditional access policies.
Assignments
Under the assignment section there are three main options which can use to define conditions.
1) Users and Groups
2) Cloud apps
3) Conditions
User and Groups
Under the user and groups option we can define the users and groups targeted by the condition access policy.
We can select define target as “All” or selected number of users and groups.
We also can explicitly select groups and exclude individuals from it.
Cloud Apps
Under the cloud app option we can select the applications which is targeted for the policy. these applications can be Azure apps or on-premises applications which is published via Azure Active Directory using Azure App Proxy. Similar to users and groups, we also can explicitly allow access to a large group and exclude specific entities.
Condition
Using options under this category we can specify the conditions related to user’s login environment. This category has 4 sub-categories.
1) Sign-in risk
2) Device Platforms
3) Locations
4) Client Apps
It is not required to use all these sub-categories for each and every policy. By default, all these are in disabled mode.
Sign-in risk
Azure Active Directory monitor user login in behavior based on six types of risk events. These events are explained in details on https://docs.microsoft.com/en-us/azure/active-directory/active-directory-reporting-risk-events#risk-level . As an example, I am usually login to azure from IP addresses belongs to Canada. I log in to azure at 8am from Toronto. After 5 minutes, its detects a login from Germany. In typical scenario, it’s not possible unless I use a remote login. From Azure point of view, it will detect as malicious activity and will rate as “Medium” risk event. In this sub-category, we can define what level of sign-in-risks need to consider.
Note – If you need enable the policy, you need to first click on “Yes” under configure option.
Device Platforms
Device platforms are categorized based on the operating systems. it can be,
• Android
• iOS
• Windows Phone
• Windows
We also can explicitly allow all and then exclude specific platforms.
Locations
Locations are defined based on IP addresses. If it’s only for “trusted” IP addresses, make sure to define trusted IP addresses using the given option.
Client Apps
Client apps are the form that users access the apps. It can be using web, mobile apps or desktop clients. Exchange ActiveSync is available when Exchange Online is the only cloud app selected.
Access Controls
There are two categories which can use to add the access control conditions to the policies.
1) Grant
2) Session
Grant
In this category, we can specify the allow or deny access. Under the allow access, we can add further conditions such as,
• Require multi-factor authentication
• Require device to be marked as compliant
• Require domain joined device
MFA
Multi-factor authentication is additional layer of security to confirm the authenticity of the login attempt. Even policy set to allow access, using this option we still can force user to use MFA. This is allowed to use Azure MFA or on-premises MFA solution (via ADFS).
Compliant
Using Microsoft Intune, we can define rules to categorize the user devices are compliant or not according to company standards. if this option is used, only the devices which is compliant will consider.
Domain Joined
If this option is used, it will only consider connection from Azure Active Directory domain joined devices.
Once you define the options, it can either force to use all the options or only to consider “one” of the selected.
Sessions
This is still on preview mode. This is basically to provide additional information about session to the cloud app so it can confirm authenticity of the session. Not every cloud app supports this option yet.
Demo
By now we know what are the conditions we can use to define a condition access policy. Let’s see how we can configure a policy with a real-world example. Before we start, we need to look in to prerequisites for the task. In order to setup condition access policies we need following.
1. Valid Azure Active Directory Premium Subscription
2. Azure Administrator Account to create policies
In my demo, I have a user called “Berngard Saller”. He is allowed to access an on-premises application which is published using Azure Application Proxy (http://www.rebeladmin.com/2017/06/azure-active-directory-application-proxy-part-02/).
