Protect Unmanaged PC Access | CA Scenarios for Success (2 of 4)

We are back today for part two of our four part series on conditional access scenarios for success. Today, we will discuss how to restrict unmanaged PCs from accessing corporate resources. We often hear that organizations want to empower their employees to be productive, even on their personal PCs- but that they need to do so in a way that prevents users from leaking their corporate data. We find that most want to enable full resource access (such as through thick clients) only from corporate PCs where they have the capability to wipe/manage that data. However, they still need to provide some access from personal PCs- which we can accomplish by enabling browser-only access with MFA enforced for personal PCs, providing a more limited (yet still protected) experience. Today, we are going to focus on implementing this for SharePoint Online and Exchange Online, since we see most organizations focused first on protecting mail and files, but you can extend these policies to other corporate resources as well.

 

This scenario enables personal, unmanaged devices (non domain-joined) to access their corporate resources through the browser only with MFA controls, while allowing only domain-joined (corporate) devices to access corporate data using thick clients. Additionally, we can use SharePoint session controls to enforce restrictions for browser access on personal PCs, preventing users from downloading/printing/syncing their files.

Scenario Requirements

This scenario is simple to fulfill- all it requires is setting up two conditional access policies, enabling SharePoint session controls, and configuring Hybrid Azure AD Join for your domain-joined devices. Let's dive a little deeper into these requirements before we begin setting up the CA policies!

• Two Conditional Access policies
  • 1st Policy: scoped to EXO/SPO/etc., that targets Client Apps and requires devices be Domain Joined to access. This policy will prevent non-domain joined devices from accessing ExO/SPO through thick clients.
  • 2nd Policy: scoped to EXO/SPO/etc., that targets the Browser, excludes Trusted Networks, and requires MFA and Session Controls to access. This policy will allow browser-only access to ExO/SPO for personal devices and will force them to complete a MFA prompt before being granted access. For SPO, additional controls will be in place to prevent downloading/printing/syncing.
  • For Conditional Access policies to take effect, you also need to ensure the targeted users have Azure AD Premium licenses assigned.
• Access control restrictions enabled in SPO (required for Session Controls to work)
  • In the SharePoint admin center under "access control" we will "allow limited, web-only access" for unmanaged devices
  • NOTE: When you enable these access controls in the SharePoint admin center it automatically creates two conditional access policies in Azure AD that by default apply to all users. You have two options: you can either modify the auto-created policies to target the specific security groups you want to receive this policy and add ExO as a targeted cloud app. Or, you can delete the auto-created policies and follow the configuration steps below to create them.
• Hybrid Azure AD Joined Devices
  • In order for conditional access to consider a device "Hybrid Azure AD joined", it must be a Windows device that is joined to an on-premises AD and registered to Azure AD using Hybrid Azure AD Join. Follow the straightforward instructions in this doc to get Hybrid Azure AD Join configured for your devices.

Configuration Steps

To configure the two conditional access policies, simply follow the configuration outlined in the screenshots below.

 

Policy 1- Enabling thick client access for only domain joined devices (effectively blocking thick client access for personal, non domain-joined devices)

Policy 2- Enforces MFA to access ExO/SPO through the browser on personal PCs, with additional session controls for SPO.

End User Experience

Let's take a look at how these policies impact the end user experience.

When we try to access the Teams client on an unmanaged device (which honors CA policies targeted to SPO), end users will be blocked and notified that they need to be domain joined.

On that same unmanaged devices, if we try to access OneDrive through the browser we will see this limited experience enforced by the SharePoint Online session controls. The banner on the top of the page notifies the end user that they can't download/print/sync using this unmanaged device. This enables your end users to stay productive by accessing and editing documents, while preventing that corporate data from leaking to this unmanaged device.

In Review

Scenario Goal: Allow only Domain Joined devices to access corporate data using thick clients, but restrict unmanaged device access to the browser with MFA

Scenario Scope: Windows PCs

Recommended when…

• You want to enable remote access to web resources on personal PCs
• You only want full resource access from corporate PCs
• You want a strong, yet flexible, security posture for Windows PCs

 

In the next post of this series, we will shift our focus to protecting corporate data on mobile devices. Have more questions about protecting unmanaged PC access? Have you tried out these conditional access scenarios? Let us know in the comments below!

 

-Sarah and Josh

Comments

• Anonymous
  July 05, 2018
  Great articles. However, I can't get Teams to behave! Based on your policy above to block thick client access, I attempted to include Teams as targeted Cloud App. I launch Teams on an unmanaged/none Azure AD joined PC and enter id and password. You then get the window saying "You can't get there from here" (Good), but if you close out that window you then get prompted to sign in again and it performs a browser based auth (shows as Chrome in the logs) and successfully logs you in (Bad) with full thick client access. Something in Teams authentication is bypassing this control. Any idea?
  • Anonymous
    July 09, 2018
    Hi Simon, we tried replicating this and didn't observe the same behavior you are seeing (it successfully blocked for us). If this issue persists it may be worth opening a ticket with support.