Microsoft has done a fantastic job with Azure and Office 365, giving us admins a suite of tools and solutions. However, there is so much in these products it can be a little confusing knowing where to start. One area of your infrastructure you really want to get correct from the start is the security!
In this post, we are going to cover the security feature of Azure AD “Condition Access”. I will go over what it is, why you should absolutely be using it and detail out the basic rules you will want to set.
- What is Conditional Access?
- Office 365 MFA vs Conditional Access
- What License Do I Need for Conditional Access?
- Where do I Configure Conditional Access?
- What Rules Should I Set?
- Troubleshooting Policies
- More
What is Conditional Access?
Conditional Access is a security feature of Azure AD. It uses signals and access policies applied to authentication attempts to either block, permit or permit with additional measures such as requiring MFA.
Signals include
- User group membership.
- Location information.
- Information about the device.
- The application being accessed.
- Real-time risk detection (P2 license required).
Office 365 MFA vs Conditional Access
Office 365 comes bundled with Multi Factor Authentication (MFA); this is referred to as user-based MFA. User-based MFA needs to be enabled for your user’s and it can easily be forgotten when setting up a user. User-based MFA is also on or off, there is little granularity in how it is applied.
Conditional access also offers MFA but allows for a set of policies to determine when MFA is best applied, or if access should be allowed at all.
As an example, with Conditional Access you could create a policy to say,
- If a user is located at a trusted location such as you head office MFA is only required to use your Finance application. But for all other applications at this site MFA is not required.
- If this user logs on from any other location, they must use MFA.
- Or travel is not part of the user’s role so, they should be blocked if they try to log on from any other country.
With conditional access if your users have an appropriate license (see below) then there is no need to enable user-based MFA.
What License Do I Need for Conditional Access?
You will need a Premium P1 or P2 plan.
P1 is bundled with the Microsoft 365 Business Premium plan and above, or the P1 or P2 licenses can be purchased separately and use with any other plan.
The P1 plan is enough to get Conditional Access, the P2 plans has some additional security features over the P1 plan, the most notable for conditional access is risk-based policies.
It is fine to mix P1 and P2 users in the same Azure AD subscription. So, you could assign a P2 license to more sensitive users such as IT and your board and a P1 to everyone else.
Where do I Configure Conditional Access?
- Logon to you Azure portal https://portal.azure.com/
- Navigate to the Azure Active Directory service
- Under Manage click Security on the left
- Under Protect click Conditional Access
What Rules Should I Set?
Of course, the exact rules you should apply will depend on our organisation’s needs. Below I will detail what I would consider a baseline set of rules for Conditional Access. Refine these as required for your needs.
Remember when building your polices. The rules are all applied!
What I mean by that is it not like a firewall where the rules are applied in order until there is a match. With Conditional Access all the rules are applied regardless of order
- If there is a policy met to block access it will be blocked even if you have a grant access policy high up.
- Equally if you have a grant access with MFA policy it will overrule a policy to grant access without MFA if both are matched.
If no polices are matched, then access will be granted without MFA.
I also like to setup a “CA-TempExcluded” group where members can be excluded from Conditional Access to help with user setups and support i.e. when your service desk is setting up a new laptop for a user and they don’t have access to the user’s MFA device. But I use a Logic App to automatically remove users from this excluded group at midnight.
You may also want to exclude a single highly controlled break glass account with an extraordinarily strong password.
Will all the below policies initially set them in the Report-only mode to confirm they work as required before setting them as On
Block High Risk Sign-in
This rule uses the risk-based capabilities of a P2 license. This rule is recommended to block access when Azure AD determines the sign-in event presents a high risk
An example of a high-risk sign-in is impossible travel. Where a user is working in one country and then there is a sign-in event from another country in a brief time window.
Assignments
- Users or workload identities:
- Include: All Users
- Exclude: A “CA-TempExcluded” group or any break glass account
- Cloud apps or actions
- Include: All Cloud Apps
- Exclude: None
- Conditions
- Sign-in Risk: Configured:Yes | High
Access controls
- Grant
- Block Access
- Session
- None
Block High-Risk Users
As with the previous rule this rule uses the risk-based capabilities of a P2 license. An example of a high-risk users is if Microsoft discovers through its partnerships with law enforcement agencies or security teams that a user’s username and password pairs have been leaked.
Assignments
- Users or workload identities:
- Include: All Users
- Exclude: A “CA-TempExcluded” group or any break glass account
- Cloud apps or actions
- Include: All Cloud Apps
- Exclude: None
- Conditions
- User Risk: Configured:Yes | High
Access controls
- Grant
- Block Access
Block Legacy Authentication
Legacy Authentications is protocols such as SMTP, POP, IMAP, and others that do not support MFA. Even if you are forcing MFA for all users if you are not blocking legacy authentication applications can be accessed without MFA over these legacy authentication methods.
There may be times when you have a genuine need to use something like SMTP for an application to send emails via Office 365. It is recommended to block legacy authentication for all users and add an exclusion for just the service user(s) to allow just the users that need legacy authentication to have it.
It is also recommended that if you are excluding certain users, you should have another Conditional Access policy to control the locations where the excluded accounts can log on from (see below).
Assignments
- Users or workload identities:
- Include: All Users
- Exclude: A “CA-TempExcluded” group, any break glass account and any services account that need legacy authentication such as SMTP.
- Cloud apps or actions
- Include: All Cloud Apps
- Exclude: None
- Conditions
- Client Apps: Legacy authentication clients “Exchange ActiveSync” and “Other Clients”
Access controls
- Grant
- Block Access
Block Guest and External Users to all Application Other than Office 365
Just in case someone misconfigures an Enterprise Application I like to have a rule to restrict Guest and External users from all applications apart from Office 365. So, they can join a Teams meeting for example but can’t use any of the other applications join to the tenant.
Assignments
- Users or workload identities:
- Include: Select users and groups | All guest and external users
- Exclude: None
- Cloud apps or actions
- Include: All Cloud Apps
- Exclude: Office 365
Access controls
- Grant
- Block Access
Block Service Accounts from Untrusted Locations
As previously mentioned, if may be required for a service account to need Legacy Authentication or you may have sensitive accounts that only need to logon from trusted locations.
I like to restrict these accounts so they ca only be used from a list of trusted locations (public ip addresses) and block their logon from anywhere else. I am then comfortable that these handful of service accounts don’t need MFA and can also use Legacy Authentication methods if required.
Assignments
- Users or workload identities:
- Include: Specific user or group | Select your services accounts
- Exclude: A “CA-TempExcluded” group, any break glass account
- Cloud apps or actions
- Include: All Cloud Apps
- Exclude: None
- Conditions
- Location
- Include: All
- Exclude: Specific location | Select your trusted location
- Location
Access controls
- Grant
- Block Access
To add your trusted locations
- Logon to Azure AD
- Security
- Under Manage select Named Locations
- Add a IP range location or Country range location at the top
Grant Access with MFA All Users
This is the main one! We want to ensure that MFA is used for all users regardless of the location and application. Now this doesn’t mean that users will be prompted to approve an MFA request every-time they breath. But they will be prompted when the user logs on from a new device, and once a month or so.
As previously mentioned, you would want to exclude background service accounts such as those that need to send emails via Office 365, but to keep tight control over these accounts by restricting where they can be used from.
Assignments
- Users or workload identities:
- Include: All Users
- Exclude: A “CA-TempExcluded” group, any break glass account
- Cloud apps or actions
- Include: All Cloud Apps
- Exclude: None
Access controls
- Grant
- Grant Access | Require Multi-factor authentication
Troubleshooting Policies
You should create any new polices in “Report-only” mode to confirm they will work as expected alongside your other polices.
But where do you see what the Report-only polices as well and the policies set to “On” are doing?
In the Sign-in logs for a user (Sign-in logs under monitoring) there are two tabs “Conditional Access” and “Report-only” here you can see the actions taken by both the polices that are set to On and those that would be applied for those that are currently set to Report-only.
A result of “Success” means that policy was applied, where a result of “Not Applied” it means the logon attempt did not meet the conditions of the police.
If no policy has the result “Success” then logon was allowed without MFA.
More
You may also be interested in my post Azure AD Defaults You Should Change or if you are not seeing all device information in the sign-in logs Azure AD – Sign-Ins Log Missing Device ID and Join type
