Summary
Limiting access to Microsoft 365 and Azure can be achieved using Azure Conditional Access Policies. These Policies can be defined using a variety of conditions ranging from Azure AD group membership or Azure Risk Indicators to public IP Addresses. Policies can also be defined to take action or just report on events that meet the policy's criteria. Actions taken can be to deny access or force access to use different methods of authentication.
Systems Involved
Departments that use the system
Prerequisites
You must be a member of the Security Administrator or Global Administrator role in Azure AD to edit this Policies
A Security Reader can view the overall policy, but will not have the access to drill into some of the criteria.
To check to see if you are Eligible to activate this role for yourself or already assigned this role permanently - refer to this Article
Overview
To Access Conditional Access Polices, log into the Azure Portal and type in "conditional" in the search bar
Click on Azure AD Conditional Access
As of 7/12/2022, we have three active Conditional Policies. One of them mimics a classic "firewall" where we can block a malicious IP address from trying to access our Azure/M365 tenant. Another one mimics a next generation "firewall" that blocks by geo-location. Both of these policies leverage Named Locations, which you should see on left navigation menu under Manage (highlighted above). Let's review Named Locations briefly by clicking into it.
Named Locations
We currently only have three Named Locations that are in use:
NIC has our public IPv4 ranges that we will always trust and can leverage for including/excluding in our policies. We currently use the NIC Named location in our Block High Risk User and Sign-ins Policy to exclude the NIC campus from that policy.
NIC Blocked Countries lists any country that have been listed as source location of a security event that we do not expect user traffic from.
Blocked IP Ranges lists any IP addresses/networks that repeatedly showed up in a high risk sign-in attempts. We can update this Named Location with any IP addresses that we determined should be blocked due to malicious activity.
To update a Named Location, just click on it and the Named Location edit window will appear on the right side of the browser. Click on the + sign to add a new IP address or network (in CIDR notation).
Click on Add and Save to update the Named Location
Now that we know how to manipulate Named Locations, let's go back to the Policies
Policies
Since we were looking at Block IP Ranges, click on the Block O365 Access From Blocked IP Ranges
You can see that we apply this policy to ALL users except for Specific Users for 1 particular App and requires 2 conditions to trigger the Block Access.
Users and Groups
When you click on Users and Groups, a dialog window appears on the right with the Include option.
For this policy, we are including ALL users. However, we do add a few users to Exclude just to avoid locking ourselves out of the system. If you click on the work Exclude, that list will be presented.
In this case, the policy will never apply itself to the users above (partial list) regardless of any other condition
Cloud Apps or Actions
For now, we will just focus on Cloud Applications. This policy act on Office 365 access, though the list of applications that show up in the right window is extensive. Also, you can type an application into the field to see if it can leverage this policy (like Box or Canvas). Further testing needs to be done for third party applications, but we definitely can leverage this for Microsoft products.
Conditions
Here we get to leverage our Named Locations and Risk levels to determine if the Policy is applied or not. Since this policy is all about blocking IP addresses from accessing Office 365, it has two Conditions defined
Device platforms include Windows, Mac OS, iOS, Android, etc. In this case, we do not want ANY type of device accessing Office 365. Also, the location is our familiar Blocked IP Ranges Named Location
Access Controls
For now, we can just focus on the Grant aspect of this condition. For this Block IP policy, well - we just want to Block access. However, if you can see that Granting access has quite a bit of granularity that the device / user can meet for this Policy to take effect.
Enable Policy
Finally, we can choose to Enable/Disable this policy. If we want to see how well our policy identifies an event before taking action, we can always set the policy to Report-Only.
Auditing Policy Changes
Policy adds and changes are tracked in Azure Active Directory under Audit Logs