Try Nova Request Pricing
Back to blog

Exploring site collection-based session controls in SharePoint Online

May 30, 2018 by Vasil Michev

It has been almost two years since Microsoft first showcased the session controls feature at Ignite 2016. An integration between Azure AD Conditional policies and SharePoint Online, session controls allow us to configure “read-only” access to files stored in any site collection. While this feature provided a nice middle ground between allowing unrestricted access and completely blocking the user or device, it lacked some granularity as it could only be applied on the tenant level (as in any and all site collections).

Now, Microsoft has released an update for this feature, allowing us to configure session restrictions on a per site collection basis. This blog takes a look at this new functionality, and ways to configure it.

What are session controls (restrictions)?

As a reminder, the configuration of session controls can be done either via the (legacy) SharePoint Online Admin Center or the Azure AD Conditional Access blade in the Azure portal.

How can you use them?

To configure the policy, navigate to the SPO Admin center and select the Access Control tab on the left, or use the direct URL:
(https://tenant-admin.sharepoint.com/_layouts/15/online/TenantAccessPolicies.aspx).

The relevant settings can be found under the Unmanaged devices section, and the option corresponding to session controls is called Allow limited, web-only access. As the restrictions are enforced via the Conditional Access feature, which in turn relies on Modern authentication, the Apps that don’t use modern authentication, and the setting will automatically be changed to Block in order to ensure the restrictions cannot be bypassed.

Note that the new SPO Admin Center does not yet expose these settings, so you will have to switch to the old version. You can also use the Azure AD portal or SharePoint Online PowerShell to configure the restrictions. It is easier to complete the process via the SPO Admin Center, as the UI there is streamlined to fit this specific scenario, however using the Azure AD portal gives you more flexibility in terms of the conditions you can configure on the policy.

To configure the policy via PowerShell, use the following cmdlet:

Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess

No matter which way you configure the policy, the corresponding Conditional Access policies will be created and can be further customized via the Azure AD portal. Or, you can simply create a custom Conditional Access policy to enforce session restrictions by selecting the Use app enforced restrictions, access control is shown below:

For additional details and examples on how to configure session controls, refer to the official documentation here and here.

Once the policy is configured, any user that falls under its scope will have the session restrictions applied, which in the default configuration means they will not be able to download, print or sync items, however viewing and editing documents in the browser will be possible. Users will be informed about the imposed restrictions via the information bar on top of any SPO/ODFB page they access, and they will also notice that the Download and Sync buttons are absent in the UI:

Additional configurations

Apart from modifying the Conditional Access policy assignments and controls to further customize the scenarios where session controls will apply, you can also configure some SharePoint-specific settings. One of these settings is the ability to allow/prevent users from editing files in the browser, which is controlled via the -AllowEditing parameter of the Set-SPOTenant cmdlet. In addition, you can also control the file types which can be opened in the browser. This is done via the -LimitedAccessFileType parameter, which accepts three values:

  • OfficeOnlineFilesOnly – This is the most restrictive setting: it only allows standard Office file formats to be opened.
  • WebPreviewableFiles – This is the default option, which allows to work with all file types supported for preview by the browser.
  • OtherFiles – This is the least restrictive setting, allows users to download files that cannot be previewed, such as .zip or .exe files.

Lastly, the feature also enables you to specify whether the policy will apply to Guest users as well. This is done via the -ApplyAppEnforcedRestrictionsToAdHocRecipients parameter The default value is $false, meaning that the policy will not be applied to Guest users. It’s also important to understand that any files shared via the new, one-time code method are exempt from the policy.

For additional information you can refer to the Set-SPOTenant cmdlet help at docs.microsoft.com.

Configuring session controls on a specific Site collection

So far, we’ve quickly summarized the session controls feature as well as some customizations you can make to it. In its original release, the feature was applicable to the entire tenant, that is every SharePoint Online and OneDrive for Business site collection, including those belonging to Office 365 Groups and Teams. In turn, this created some issues, as configuring the feature meant potential impact of the productivity of all users.

In the beginning of May 2018, Microsoft announced that the session controls feature now can be configured on a per Site Collection basis. In order to do so, the first thing you need to do is make sure that the tenant-level configuration is set to Allow Full Access, the reason being that as with any other SPO features, the tenant-wide controls trump individual Site Collection settings. Thus, an Office 365 Group cannot have this feature configured with a more relaxed setting compared to the tenant-wide configuration. So, in order to start using the per-SC restrictions, navigate to the SPO Admin Center and make sure the setting is configured appropriately, or use the following PowerShell cmdlet:

Set-SPOTenant -ConditionalAccessPolicy AllowFullAccess

If you have previously used the feature, a Conditional Access policy will already exist in Azure AD and you are good to go. If you haven’t used session restrictions previously, you will now have to create the policy manually, as there aren’t any available by default. The important part to remember is that the Use app enforced restrictions control needs to be configured on the policy. If you need more help with creating an Azure AD Conditional Access policy, follow the steps here or here.

Once this is done, you can configure session restrictions on a per-SC basis via the Set-SPOSite cmdlet. No UI currently exists to control this feature, so you will have to use the corresponding PowerShell cmdlets, exposed in the latest version of the SPO PowerShell module.

Here’s our first example: to configure the feature for a particular Office 365 Team, you can use the following:

Set-SPOSite https://tenant.sharepoint.com/sites/Team -ConditionalAccessPolicy AllowLimitedAccess

The rest of the settings detailed in this section on additional configurations also apply, and you can use the corresponding parameters of the Set-SPOSite cmdlet to configure them. For example, to disable editing completely and to use the most restrictive setting for file preview, use the following:

Set-SPOSite https://tenant.sharepoint.com/sites/Team -AllowEditing $false -LimitedAccessFileType OfficeOnlineFilesOnly

As those values are only valid when session restrictions are being enforced, the service will notify you that you must ensure that the –ConditionalAccessPolicy parameter is set to AllowLimitedAccess and will offer to configure this setting on your behalf.

In case you need to check the currently configured policy on a particular site or report on the policies configured across all sites, you can use the Get-SPOSite cmdlet as follows:

Get-SPOSite https://tenant.sharepoint.com/sites/Team | select ConditionalAccessPolicy,AllowEditing,LimitedAccessFileType

Lastly, to revert the session restrictions use the following cmdlet:

Set-SPOSite https://tenant.sharepoint.com/sites/Team -ConditionalAccessPolicy AllowFullAccess

That’s all there is to it, now simply wait for a few minutes and go test the newly configured session restrictions. Before you ask, no, we cannot configure those on a per-site basis, the “smallest” unit is an individual Site Collection.