Using Conditional Access Policies to Allow Access to Office 365 – Petri.com

Organizations adopting Microsoft’s cloud services need to keep their employees safe, especially when employees need to access these cloud services while being outside of the organization’s network. In this guide, we’ll explain how organizations can set up Conditional Access policies to restrict how their users can access Office 365 and other Microsoft services.

Table of Contents

What are Microsoft’s Conditional Access policies?

As more and more employees now want to be able to work remotely and on any device chosen, security has become a crucial topic for all organizations. Over the past few years, it has become critical for an organization to figure out how to secure employees working both in the office and remotely.

The security challenges of migrating to Microsoft’s cloud services

Many organizations migrate to cloud services such as Microsoft 365 to provide better management and support. Cloud services bring many benefits to an organization, though they often add complexity from a security perspective.

Microsoft 365 does provide excellent tools to assist organizations in migrating their data to the cloud,  all while securing access to the company’s information. The key to using these tools is to know where they are, have a valid license, and learn how to use them for monitoring purposes.

In a Microsoft 365 environment, Azure Active Directory (Azure AD) is the core authentication component that provides core access control to the tenant and all available services. Microsoft 365 does not utilize anonymous access, which minimizes the process for accessing these services no matter the device. 

As part of the Azure Active Directory service, Microsoft provides the ability to control access based on conditions. Conditional Access policies, as they are known, combine different signals to determine if access to an application or service should be granted or denied.

These policies, at their core, are simple if-then statements. For example, if a user wants to gain access to Microsoft Teams, we can require them to meet the condition of being in the office to be granted access to the app.

Conditional Access policies serve as a protection layer executing at the point of authentication to control access to Microsoft 365. You can enforce these policies for internal employees and external guest users. You can also create policies targeting specific users, groups, devices, or other signals available to Azure Active Directory.

Standard Conditional Access Policy Signals

The most common signals used by Conditional Access policies are:

  • User or group memberships
  • IP address location
  • Type of device
  • Connecting application
  • Real-time risk detection

Common Conditional Access Decisions

The most common access decisions used by Conditional Access policies are:

  • Block access
  • Grant access
  • Grant access plus force multi-factor authentication
  • Grant access plus ensure the device is compliant
  • Grant access plus ensure the device is Hybrid Azure AD joined
  • Grant access plus require an approved client app
  • Grant access plus use an app protection policy

Conditional Access Policy Licensing

To utilize Conditional Access-based policies, your organization needs to have one of the following licenses:

If you are an educational or government organization, you must use the equivalent “A” or “G” license.

Core Conditional Access Basic Policies

When Microsoft first enabled Conditional Access policies within Azure Active Directory (Azure AD), they deployed a few basic policies. Over time, these policies were replaced with what’s now called security defaults, but the company also provided templates for manually creating policies as an alternative. 

Security defaults

Microsoft’s goal with security defaults is to deliver a basic level of enabled security at no extra cost to the organization.

Security defaults is a set of basic identity security mechanisms recommended by Microsoft

The security defaults include the following settings:

  • Require all users to register for Azure AD Multi-Factor Authentication.
  • Require administrators to do multi-factor authentication.
  • Require users to do multi-factor authentication when necessary.
  • Block legacy authentication protocols.
  • Protect privileged activities such as access to the Azure portal.

Security defaults are for organizations who want to increase their security posture but don’t know how or where to start. They’re for organizations using the free tier of Azure Active Directory (Azure AD) licensing. 

If an organization has more complex security requirements, security defaults will not be enough and it’s recommended to use Conditional Access policies instead.

Conditional Access policy templates

Conditional Access templates provide an easy method for deploying policies that match Microsoft‘s recommendations. There are currently 14 policy templates split into different policies that you can assign to either user identities or devices.

Microsoft provides 14 conditional access policies templates

The full list of Conditional Access policy templates includes:

  • Require multi-factor authentication for admins.
  • Securing Security info registration.
  • Block legacy authentication.
  • Require multi-factor authentication for all users.
  • Require multi-factor authentication for guest access.
  • Require multi-factor authentication for Azure management.
  • Require multi-factor authentication for risky sign-in.
  • Require password change for high-risk users.
  • Require compliant, or hybrid Azure AD joined device for admins.
  • Block access for unknown or unsupported device platform.
  • No persistent browser session.
  • Require approved client apps or app protection.
  • Require compliant or hybrid Azure AD joined device or multi-factor authentication for all users.
  • Use application enforced restrictions for unmanaged devices.

You’re not required to use any of these templates, but they serve as a starting point for quick and easy deployment. These policies can also be modified or even added to organizational-specific ones.

Examples of Conditional Access Policies

You can find below three common examples of Conditional Access policies you can use to restrict access to Microsoft 365.

Example 1: Block access from all locations except for a trusted location

Here are the different settings we’ll be using to set up this Conditional Access policy:

  • Included users: All guest and external users
  • Excluded users: Current administration user
  • Cloud Apps or actions: All apps
  • Conditions: Include any location and exclude all trusted locations
  • Access controls: Block access
Conditional Access policy for blocking access from all locations except a trusted location

Example 2: Block sign-ins for users attempting to use legacy authentication protocols

Here are the different settings we’ll be using to block sign-ins from legacy authentication protocols:

  • Included users: All users
  • Excluded users: Current administration user
  • Cloud Apps or actions: All apps
  • Conditions: Exchange ActiveSync Client and Other clients
  • Access controls: Block access
Our Conditional Access policy will block sign-ins from legacy authentication protocols

Example 3: Require multi-factor authentication for all guest users accessing company resources

Here are the different settings we’ll be using to require MFA authentication for all guest users accessing company resources:

  • Included users: All guest and external users
  • Excluded users: Current administration user
  • Cloud Apps or actions: All apps
  • Conditions: None
  • Access controls: Grant access requiring multi-factor authentication
Our Conditional Access policy will require MFA authentication for all guest users accessing company resources

These basic examples show the configuration properties available when creating Conditional Access policies. They provide deep granularity to ensure policies require the correct identities for specific workloads.

Configuration properties available for Conditional Access policies

When choosing the users or groups to assign to a policy, you can either choose “all users,” select “All guest and external users,” “Directory roles,” or specific users or groups.

You can choose to apply a policy to different user groups

The Cloud apps or action property allows you to select all apps or specific ones for your Conditional Access policy. You can also choose specific user actions such as registering security details or authentication context provided by another service such as SharePoint Online. 

The cloud apps or action property allows you to select all apps or specific ones

The condition property allows you to check the user or sign-in risk level, the device platform used for the connection, the location the request is coming from, and whether it is a modern or legacy authentication request. You can also use filters to select specific devices within the directory. 

The condition property lets you use filters to select specific devices within the directory.

The other properties of Conditional Access policies include options to restrict user sessions. As an example, it’s possible to force users to re-authenticate after a specific amount of time.

it’s possible to force users to reauthenticate after a specific amount of time.

Conclusion

Conditional Access policies determine the conditions for accessing Microsoft apps and services within an organization. If Microsoft’s security defaults may work well as a starting point for most organizations, many of them may need to create custom policies that better fit their security needs.

Personally, I think every organization should use Conditional Access policies to generate protection rules executed at the point of authentication to control who can enter the tenant. Once someone makes it into the tenant, only permissions may or may not restrict what they can do

If you have not started using Conditional Access policies yet, you can go through Microsoft’s documentation to plan a conditional access deployment and check out the current templates provided by the company to get started.


Total
0
Shares
Leave a Reply

Your email address will not be published. Required fields are marked *

Previous Post

Changes to the Labour Code – remote work – JD Supra

Next Post

Has Remote Working Changed B2B Purchasing Forever? – Realbusiness

Related Posts