Secure your Microsoft 365 tenant with Conditional Access

Secure your Microsoft 365 tenant with Conditional Access

Conditional Access

Today the security perimeter of a company extends beyond an organisations network.  With Bring your own device (BYOD), people working remote & accessing folders and documents with sensitive information from anywhere we have moved to a user & device-centric security perimeter.

Conditional access is at its core an if-then framework that lets you evaluate signals from users and their devices and based on these signals decide what should happen. Some examples:

  • If a user logs in from an unknown location to the company = enforce multifactor authentication (MFA)
  • If a user logs in from an unmanaged device = block access
  • If a user is considered in risk of being compromised = allow access but require a password change

And the list can go on...

Security defaults

Tenants created after October 22, 2019 may have a feature called Security Defaults already enabled for them from the start. This was so your users would be protected from day one and would not require you to configure any Conditional Access policies of your own.

You would also not need to purchase any licenses as all tenants are entitled to basic multifactor authentication via Security Defaults

These default settings will:

  • Require all users and admins to register for MFA
  • Challenge users with MFA if they show up with a new device or are logging into a new application as well as for critical roles and tasks
  • Disable legacy authentication
  • Protect admins by enforcing MFA every time they login

This is great in a "take security off my hands" kind of way and ensure some basic protection for you. However most organisations may require more granular control and this is where Conditional Access comes in. This is a feature that requires an Azure Active Directory Premium 1 license (P1)

Emergency accounts

Before you implement your very first policy control you should implement at least two emergency access accounts. Exclude one of the accounts from phone-based multifactor authentication and one from all conditional access policies.

If you misconfigure a policy and accidentally lock yourself or your users out of the tenant, these accounts are crucial for getting back in.

You should always monitor these accounts closely so I will personally (also following MS recommendations) create the following resources:

  • Obtain the object IDs of the user accounts
  • Create a log analytics workspace where I send SigninLogs
  • Create an alert that will fire every time the return is more than 1 record for this KQL query
// Search for multiple Object IDs (UserIds)
SigninLogs
| project UserId 
| where UserId == "<Object ID of BTG Account 1>" or UserId == "Object ID of BTG Account 2"

Have an action group that notifies the correct people if these accounts get accessed.

Implement conditional access polices

Which policies you should apply depends a lot on your company requirements. I have implemented everything from MFA everywhere for everyone, MFA but only when signing in from a location that is not stored in named locations in CA & MFA only when from unmanaged devices, the list goes on.

Today Microsoft makes it easy for you by building certain templates that you can straight up copy and implement for yourself with minor adjustments.

  • Login to the Azure Portal
  • Search for Azure AD Conditional Access
  • Select New policy from template (Preview)

Here you can browse all templates and implement them in report-only mode. Some policies I like to implement are:

  • Require multifactor authentication for all users & admins
  • Require multifactor authentication for Azure management (Access to Azure Portal)
  • Block legacy authentication
  • Require password change for high-risk users (Requires P2)
  • Require multifactor authentication for risky sign-ins (Requires P2)

For your use case you can consider these, browse the other templates I have not mentioned and make adjustments to fit your need. It is very important that you exclude your break the glass (emergency accounts) and implement report-only mode for the policies.

When you are satisfied with your policies you should go to Insights and reporting in the left pane. The first time it will ask you to configure this so you need to send Signinlogs and Auditlogs to a log analytics workspace.

Once configured you can select which policy you want to view, time range & what impact it would have had if the policy was activated. You can play around in the different views and filters.

Analyse this insight with your customer or team to make further adjustments to the policies before activating the policy. Usually you would activate the policies in report-only mode, send the logs to a log analytics workspace, wait for some duration to gather data & then analyse the results.

References

What is Conditional Access in Azure Active Directory? - Microsoft Entra
Learn how Conditional Access is at the heart of the new identity-driven control plane.
Plan an Azure Active Directory Conditional Access deployment - Microsoft Entra
Learn how to design Conditional Access policies and effectively deploy in your organization.
Manage emergency access admin accounts - Azure AD - Microsoft Entra
This article describes how to use emergency access accounts to help prevent being inadvertently locked out of your Azure Active Directory (Azure AD) organization.

About the author

About me
If you have landed on my page you will have already understood my passion for tech, but obviously there is more to life than that. Here I will try and outline a few of my other hobbies. Strength training I am a person who loves to move around and challenge