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.
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.
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:
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.
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:
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.
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:
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):
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
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:
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:
You can also create the reverse of this policy to ensure all browser sessions on compliant devices use persistent sessions.
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.