Deploying Conditional Access to further secure your Microsoft 365 Identities

What is Conditional Access?

Conditional Access is a feature of Azure Active Directory that allows organisations to require specific conditions to be met before granting access to their Microsoft 365 environment. Conditional Access is enforced using policies that evaluate user sign-in attempts. Each sign-in attempt has signals that can be used to determine what controls should be enforced to grant or block access.

By using Conditional Access, you can strengthen the security of your Microsoft 365 identities and minimise the effects of a variety of threats, such as brute force and phishing attacks. It also establishes the “verify explicitly” principle of Zero Trust, making it a fundamental tool when adopting a Zero Trust security approach.

Configuration aspects

Conditional Access policies are built using assignments and access controls. Assignments are used to define the scope of which users, applications, devices, and locations the policy should apply to. Access controls are used to determine if a user’s access should be allowed, blocked, or limited.

Assignments

‘Assignments’ are split into three areas: users, cloud apps or actions, and conditions.

‘Users’ is where you can choose which individual or groups of users should be included or excluded from the policy. Microsoft also provides the option to select pre-defined groups of users such as guests or users with an administrator role.

Cloud apps or actions provide three options that focus on the scoping of the policy to a specific application, a user action, or the context in which the user is authenticating.

• Cloud apps allow you to select the application you want the policy to apply to. You have the option to select “all cloud apps,” which will include all applications, or you can select individual applications to be included. Some apps, such as Office 365, bundle applications together to provide an easier way to include many related applications.
• User actions allows you to select tasks that users may be required to action. Currently, two options are available: register security information and register or join devices.
• Authentication context allows you to scope a policy at a more granular level by targeting specific actions within an application. For example, you can use this to limit the level of access users have to SharePoint sites from unmanaged devices or require additional authentication when accessing sites classified as more sensitive.

Conditions allow you to determine what additional signals should be evaluated. These are the following:

• User risk
• Sign-in risk
• Device platforms
• Locations
• Client apps
• Filter for devices

Access controls

Access controls are split into two areas: grant and session.

The grant section enables you to determine if access is granted or blocked.

• Granting access requires you to configure a control that can be used to verify the if user’s sign-in is more secure. The options currently available are the following:
  • Require multifactor authentication
  • Require authentication strength (currently in preview)
  • Require device to be marked as compliant
  • Require Hybrid Azure AD joined device
  • Require approved client app
  • Require app protection policy
  • Require password change
  • Require acceptance of terms of use
  • You can select multiple grant controls, and you have the option to require one or all of the selected controls.

• Choosing to block access will prevent a user from signing in. You’re likely to choose this option when explicitly looking to prevent access. A common use case would be blocking access when a user attempts to sign in using legacy authentication.

Session allows you to limit a user’s access when within an application. This can be the type of actions a user can perform within an application, such as downloading or syncing content, or the frequency in which a user must reauthenticate and whether they can remain signed in when they exit a browsing session.

Conditional Access use cases

Conditional Access can be used in a number of different ways to protect your organisation. Some of the common use cases are listed below:

Enforcing multifactor authentication prompts

You can use conditional access to enforce MFA (multifactor authentication) when users sign in to Azure and Microsoft 365 services. One of the benefits of using conditional access to enforce MFA is that you can be far more granular with the scope in which MFA is triggered. For example, you could only require MFA when users sign in from an unmanaged device. MFA fatigue can occur when users are asked for MFA too frequently. MFA fatigue attacks involve attackers using social engineering to deceive users into approving MFA prompts. Limiting the scope for MFA by factoring in additional conditions such as unmanaged devices helps reduce MFA fatigue.

Blocking access using legacy authentication

Legacy authentication is a less secure authentication protocol used to authenticate with Microsoft 365 and has been superseded by modern authentication. The problem with leaving legacy authentication enabled is that it allows users to authenticate against Microsoft 365 without the additional security benefits that modern authentication enforces, for example supporting MFA. By using conditional access, you can block clients that use legacy authentication thus forcing users to use modern authentication.

Intelogy Tip

We advise examining your sign-in log activity to see how frequently legacy authentication is used before blocking it. You can filter the Azure AD sign-in logs to review sign-in attempts that have used legacy authentication and then determine whether these are genuine scenarios that call for exceptions, for example, a scan to email requirement. You may also notice a lot of users are still using legacy authentication. If that is the case, additional change management may be required to support them in the transition to modern authentication.

Allowing access only from devices managed by Microsoft Intune

Conditional access is also commonly used to grant access only to users attempting to sign in from a device managed by Microsoft Intune. This can greatly reduce your attack surface, as malicious sign-in attempts will most commonly occur from unmanaged devices. You can use this in combination with other policies that require additional authentication when a user attempts to enroll a device with Microsoft Intune.

Intelogy Tip

For anyone reading this who doesn’t have their devices enrolled in Microsoft Intune and they are joined to an on-premises Active Directory, you do have the ability to allow access only from Hybrid Azure AD joined devices. Hybrid Azure AD joining your devices can typically be done a lot quicker than an implementation of Microsoft Intune, and a lot of organisations will use this as a quick way to secure their environment whilst they transition to Microsoft Intune.

Requiring approved client apps for mobile device access

Another common use case is requiring that approved client apps be used on mobile devices. By using approved client apps, you’re able to enforce app protection policies (part of Microsoft Intune) that allow you to manage your corporate data better on both managed and unmanaged devices. App protection policies enable you to control how users can interact with your corporate data and provide the ability to perform a selective wipe that targets the corporate data without impacting the user’s personal data. This can be especially useful when implementing a ‘Bring Your Own Device’ mobile device strategy.

How to set up Conditional Access policies

Creating a Conditional Access policy can be done via the security section within the Azure Active Directory admin center or via the protect & secure option in the Microsoft Entra Admin Center. The example below demonstrates this via the Azure Active Directory Admin Center.

1. To create a new policy, click New policy.

2. You will then be able to populate the assignments and access controls for your policy. You will need to provide a name for the policy. This should be something descriptive, allowing you and other administrators to easily identify what the policy does.

3. Users: The users and groups included in or excluded from the policy can be selected here.

4. Cloud apps or actions: Here you can select the cloud applications, user actions, or authentication contexts.

5. Conditions: Additional conditions such as risk, device details, and location can be included or excluded here.

6. Grant: Using the Grant section, you will determine if access is granted or blocked, and if granted, what additional measures are required.

7. Session: The Session section can be used to determine if any limitations should be enforced once a user has signed in.

8. Enable policy: Enable policy is the last section, and it is used to determine if the policy is on, off, or report-only. More details on this section follow below.

Enabling a policy

Once you have populated your policy’s requirements, you will be able to choose from three options that determine how the policy will affect users once you create it. Those three options are Report-only, On, and Off.

Setting a policy to On will enforce the policy for the selected assignments and will begin to impact users the next time they’re required to reauthenticate.
Setting a policy to Off means that it will not be enforced.

Using Report-only allows you to evaluate the effectiveness of a policy before you enforce it for users. You can review the impact of policies in report-only mode by reviewing assigned users’ sign-in logs. For each sign-in log, there will be a “report-only” tab, which allows you to see the hypothetical result of a report-only policy. This can be an important tool in determining how the policy will impact users as well as an essential tool for troubleshooting.

Policy templates

Currently in preview is the ability to create a new policy from a template. Policy templates can be a great starting point when your organisation is new to Conditional Access. They focus on key scenarios that help reduce threats across the five security objectives below:

• Secure foundation: Focuses on policy templates that provide a foundational level of protection for authentication.
• Zero Trust: Focuses on policy templates that help to enforce the “verify explicitly” Zero Trust principle.
• Remote work: Focuses on policy templates that help protect remote users.
• Protect administrator: Focuses on policy templates that help to protect users with privileged administrator roles.
• Emerging threats: Provides a single policy template that helps to protect users with privileged administrator roles by enforcing phishing-resistant multifactor authentication.

Our thoughts on Conditional Access

Conditional Access is an essential tool for organisations to maintain secure access to their Microsoft 365 environment. It provides granular controls that allow you to strike a balance between security and productivity. If not deployed correctly, it can be a hindrance to your organisation, however with the proper planning and use of features like report-only mode you can ensure your deployment will be a success. Using conditional access has proven highly valuable for the organisations we have worked with and has allowed them to keep a productive workforce while still fulfilling their security requirements. We feel that Conditional Access is going to be a key part of all organisations’ security posture when using Microsoft 365, and it is something that we highly recommend adopting in your organisation.

For more information on the deployment and benefits of Conditional Access, please see the documentation provided by Microsoft here.

If you need help with your Conditional Access deployment, please don’t hesitate to get in touch.