In a previous article, I described how Microsoft Defender for Cloud Apps (MDCA) can secure access in remote working scenarios. Although MDCA includes many features, it also comes with additional costs. For organizations that can’t (or don’t want to) pay for MDCA licenses, alternatives exist to help secure access for remote workers in the Microsoft 365 ecosystem. In this article, I explore some of the worthy features that don’t require MDCA.

Note: I will not be re-hashing the benefits of enabling MFA and switching off legacy authentication as they are already widely documented.

App Enforced Restrictions

App enforced restrictions are a trimmed down version of the MDCA app controls for use with SharePoint Online and Outlook Web Access, and they limit access to files on unmanaged devices (devices that are not Hybrid AAD joined or Intune Compliant). Corporate devices must use Microsoft Edge to be detected as ‘managed’ and bypass these restrictions.

As app enforced restrictions are implemented by Conditional Access, an Azure AD Premium P1 subscription is required. Limited access to files relies on the SharePoint Online File Viewer, and you can find the full list of supported file types is available here.

Note: For non-Office file types, depending on the file it may require download to render correctly. The documentation is not very clear on the exact scenarios supported so I recommend testing key file types.

Read More: Azure Active Directory Premium – Where to Start

SharePoint Online

To configure app enforced restrictions for SharePoint Online, navigate to the Policies section of the SharePoint Online admin center and open the Unmanaged devices page located under Access Control. In the slide-out menu (Figure 1), select the level of control desired and click save:

unmanaged devices
Figure 1: Select the level of control for unmanaged devices.

Saving the policy creates two Conditional Access policies in the tenant, both identified by the prefix [SharePoint Admin Center]. The policy names are appended with the dates they are created so if this setting is changed on different dates, multiple versions of the policies are created. The policy [SharePoint admin center]Block access from apps on unmanaged devices blocks access from client apps to SharePoint Online and the policy [SharePoint admin center]Use app-enforced Restrictions for browser access enforces the selected restrictions on browser access.

The policies are automatically enabled and scoped to all users, so make sure to add any exclusions or modifications required through the Azure AD admin center or disable the policies if you aren’t ready to deploy.

If you don’t want to enable app-enforced restrictions for all sites, they can be enabled on a per-site basis using SharePoint Online PowerShell as shown in Figure 2. When both tenant level and site level restrictions are applied, the most restrictive applies. The site-level settings can also be applied to Microsoft 365 Group-based sites using sensitivity labels.

SharePoint Online PowerShell secure access
Figure 2: Enable limited access on a per-site basis using PowerShell.

Limited web-only access will only support files that can be previewed from the browser (Supported by the SharePoint Online/OneDrive file viewer). Other files such as .exe files can’t be viewed online so they will be blocked completely. The behavior for these types of files can be configured using PowerShell with the following settings:

  • OfficeOnlineFilesOnly: Only allows users to preview Office files and blocks all others.
  • WebPreviewableFiles: This is the default setting and allows any files that can be previewed in SharePoint Online File Viewer.
  • OtherFiles: Allows any files that can be previewed in SharePoint Online File Viewer and allows any files that can’t be previewed to be downloaded.
##Configure OfficeOnlineFilesOnly
Set-SPOTenant -LimitedAccessFileType OfficeOnlineFilesOnly
##Configure WebPreviewableFiles
Set-SPOTenant -LimitedAccessFileType WebPreviewableFiles
##Configure OtherFiles
Set-SPOTenant -LimitedAccessFileType OtherFiles

When users within the scope of the Conditional Access policy sign-in to SharePoint Online, Teams, or OneDrive for Business from unmanaged devices, they will not have the option to download, print, or sync files. They will also see the banner shown in Figure 3 informing them that they are restricted in SharePoint and OneDrive:

Secure Access for Remote Workers without Microsoft Defender for Cloud Apps
Figure 3: Users are informed that they cannot download, print, or sync to this device.

Outlook Web Access

App enforced restrictions for Outlook Web Access also help to secure access and can be configured through OWA Mailbox Policies in Exchange Online where a setting in the OWA Mailbox Policy assigned to user mailboxes enforces app restrictions.

To configure the restrictions, sign into Exchange Online PowerShell and run the Set-OWAMailboxPolicy cmdlet as shown in Figure 4. If you create a new OWA mailbox policy, don’t forget to assign it to users with the Set-CASMailbox cmdlet.

Exchange Online PowerShell secure access
Figure 4: Creating and assigning a new OWA Mailbox Policy for ReadOnly access.

These are the settings currently available for the -ConditionalAccessPolicy parameter:

  • ReadOnly: Blocks downloads in OWA
  • ReadOnlyPlusAttachmentsBlocked: Downloads and viewing attachments online is blocked

A Conditional Access Policy must also be created with the Session option Use app enforced restrictions to trigger app enforced restrictions for OWA. This can be an independent policy, or you can reuse the policy created for SharePoint by adding the Exchange Online app as shown in Figure 5:

secure access cloud security
Figure 5: The SharePoint Conditional Access Policy can be reused for Exchange Online.

When users satisfy the criteria for the Conditional Access and OWA mailbox policies, they should see a warning appear letting them know that they cannot download or print attachments in OWA (Figure 6):

OWA Conditional Access
Figure 6: Downloads are blocked, and the user is informed in OWA.

Idle Session Sign-out

SharePoint Online and OneDrive support signing out users who have been idle for a set period. This can be useful for secure access when users are on unmanaged devices and can be used in any tenant with an Azure AD Premium P1 subscription. Idle session sign-out is configured in the SharePoint Admin Center under the Access control section (Figure 7) or in SharePoint Online PowerShell using the Set-SPOBrowserIdleSignOut cmdlet as shown below:

##Set TimeSpan Variables
$WarningTimeSpan = New-TimeSpan -Minutes 10
$SignOutTimeSpan = New-TimeSpan -Minutes 15
##Enabled Idle Sign Out
Set-SPOBrowserIdleSignOut -Enabled $true -WarnAfter $WarningTimeSpan -SignOutAfter $SignOutTimeSpan
cloud security
Figure 7: Configuring idle session sign-out from the SharePoint Admin Center.

The policy takes between 15 to 30 minutes to become effective and does not impact any existing sessions. When users sign into SharePoint Online after the policy is active, they will be automatically signed out if they have no activity within the defined period.

Activity is defined as a request sent to SharePoint such as a click or navigation to a new page. Viewing/scrolling on a page that is already loaded does not count as activity. When users reach the time configured for notice, they’ll see the warning shown in Figure 8:

secure access cloud security
Figure 8: Users are warned before signing out.

A drawback of this configuration is that when a user is inactive in SharePoint, they will be signed out of all Microsoft 365 apps in the browser. For example, if a user is active in OWA and Planner and has a tab open in SharePoint, they can be signed out of the other apps unexpectedly.

Persistent Browser Sessions

When a user signs into Microsoft 365 using a web browser, the stay signed in option, configured from the Company Branding page, allows the session token to persist across browser sessions. When enabled, if the user closes the browser after choosing to remain signed in, they can reopen it and continue working without reauthenticating.

On trusted devices, this can cut down on unnecessary sign-in prompts but can become a risk when used on personal or shared devices. To secure access and mitigate this risk, persistent browser sessions can be controlled via Conditional Access policies, ensuring that persistent tokens are only used in the right situations. Configuring through Conditional Access will override the setting in the Company Branding page. As this configuration requires Conditional Access, an Azure AD Premium P1 subscription is required.

To prevent persistent browser sessions on personal devices, create a new Conditional Access policy, targeting the users and devices you want to block. For example, the policy detailed in Table 1 prevents persistent sessions on uncompliant devices for all users:

Secure Access for Remote Workers without Microsoft Defender for Cloud Apps
Table 1: Conditional Access policy to block persistent sessions on uncompliant devices.

You can also create the reverse of this policy to ensure all browser sessions on compliant devices use persistent sessions.

Summary

MDCA session controls provide the granularity that some organizations definitely need for secure access. The features detailed in this article are available for any tenant with Azure AD Premium licensing and offer a more generic set of controls for tenants where MDCA licensing is not available. Before committing to purchase the enhanced licensing, it’s worth considering if the features here will satisfy your requirements.

About the Author

Sean McAvinue

Sean McAvinue is a Microsoft MVP in Office Development and has been working with Microsoft Technologies for more than 10 years. As Modern Workplace Practice Lead at Ergo Group, he helps customers with planning, deploying and maximizing the many benefits of Microsoft 365 with a focus on security and automation. With a passion for creative problem solving, he enjoys developing solutions for business requirements by leveraging new technologies or by extending the built-in functionality with automation. Blogs frequently at https://seanmcavinue.net and loves sharing and collaborating with the community. To reach out to Sean, you can find him on Twitter at @sean_mcavinue

Leave a Reply