Enforce MFA for SharePoint Online Sites with Conditional Access Policies

Securing Confidential SharePoint Online Data

SharePoint Online sites hold some very confidential information. Now that SharePoint Online supports sensitivity labels, you can protect individual documents with encryption to stop their contents leaking. Other features, like regarding newly uploaded documents sensitive by default to stop them being shared externally until Data Loss Prevention (DLP) processing completes, help too, as do normal DLP policies.

All of this is good, but a compromised account can still access sites and download information. And the quickest way to being compromised is for an account not to use multi-factor authentication (MFA). Microsoft says that MFA blocks 99.9% of account compromise accounts. According to a Microsoft session at the RSA Conference 2020, in January 2020 only 11% of enterprise Office 365 accounts were enabled for MFA. This is a real problem.

Conditional Access Policy for SharePoint Online

To encourage people to use MFA to secure confidential documents and increase the overall security posture of SharePoint Online, tenants can deploy Azure Active Directory conditional access (CA) policies to enforce MFA for specific sites. The technology is available in preview now with general availability slated for later this summer.

The CA policy controls user access to data with MFA and can be assigned to all users in the tenant or selected accounts. Figure 1 shows the general structure of such a policy and the configuration for actions, how access is granted, and the users coming within scope of the policy. You can also see that the policy requires users to accept a terms of use document.

Image 1 Expand
Figure 1: A conditional access policy to enforce MFA access for SharePoint Online sites (image credit: Tony Redmond)

In terms of enforcing MFA, the new option for CA policies is to control “accessing secured app data,” which is where SharePoint Online comes in. This can be combined with the other controls available in CA policies, such as setting a sign-in frequency to make sure that users can’t leave sessions open for long periods.

The levels referred to in the policy (Level 1, Level 2, and Level 3) are placeholders for now. In the final version, they might be called “Low security”, “medium security”, and “high security” or something similar.

Securing a Site

After configuring a CA policy, you need to assign it to a site (all types of sites are supported). For now, this must be done with PowerShell as no GUI exists in the SharePoint Online admin center for this purpose. You’ll need to download the latest version of the SharePoint Online PowerShell module (version 16.0.19927.0 at a minimum) to be able to run the necessary commands.

After installing the updated module, you can select a site to secure with MFA and run the Set-SPOSite cmdlet to link the CA policy with the site. For example:


This command tells SharePoint Online that the CA policy with the tag “urn:microsoft:req1” applies to the site. Think of the tag as the way to connect the site with the CA policy. As noted above, when generally available, the tag might be called something different to make it clearer and to indicate its purpose. The same CA policy can be assigned to multiple sites, but only one CA policy can be assigned to a site.

Once the CA policy for MFA is attached to a site, future attempts to access the site are assessed by Azure Active Directory against the CA policy settings (and any other CA policies which apply). Users whose accounts are secured by MFA meet the criteria for access set in the CA policy and can proceed as normal.

Those whose accounts do not use MFA see an Azure Active Directory sign-in screen telling them that the organization needs more information to keep their account secure, which is a polite way to tell the user to set up MFA (the appearance of the sign-in screen shown in Figure 2 uses custom branding).

Image 2 Expand
Figure 2: Accounts not protected by MFA are blocked (image credit: Tony Redmond)

Licensing

Conditional access policies of this type require Azure Active Directory Premium license. In this case, you’ll need AAD Premium for anyone who needs to access a site secured by the MFA policy. Microsoft sources tell me that this shouldn’t be a problem as most enterprise tenants have these licenses. This assertion can’t be confirmed independently, so it’s something to check for your tenant. In addition, users are likely to need Office 365 E5 or Microsoft 365 E5 compliance licenses. However, Microsoft has yet to confirm this.

Some Limitations

Increased security often incurs some limitations on functionality. If you apply a CA policy with MFA to a site, the following applies:

  • The OneDrive sync client can’t synchronize document libraries from the site.
  • Only the online apps can be used to open Office files (Word, Excel, PowerPoint).
  • Teams can’t load files from the site into its Files channel tab. You can only access files through the SharePoint browser interface.
  • OWA can’t add attachments to messages from document libraries in the site.
  • Workflows don’t work in the site.

Microsoft is working on these limitations and might be able to relieve some in the future.

Mix and Match Policies

Conditional access policies can be combined to allow different levels of access to a site. For instance, you could require some users to use both MFA and a managed device, while others are allowed in based on MFA alone. And others might be allowed access without MFA because of their position in the company (not recommended, but possible). A lot of flexibility exists, as does the chance to confuse people and block access. Take your time and figure out what access you need and how it should be controlled, and you’ll probably find a conditional access condition to suit.

BECOME A PETRI MEMBER:

Don't have a login but want to join the conversation? Sign up for a Petri Account

Register