Why do we need to deal with unmanaged devices and what are my options to consider? As we all know, times are changing and employees are not working the same way they were doing some years ago. Employees are not always on the corporate network anymore, they are working with data in the cloud, are working from home, or even from personal (unmanaged) devices. If employees work from unmanaged devices we cannot expect those devices to be secure since we have no control over them. So how do we deal with those unmanaged devices accessing our corporate data on online services such as SharePoint Online, Microsoft Teams, Exchange Online and OneDrive? When dealing with this question there are multiple options to consider.
Some bad options are;
Some better options are;
In this blog I will guide you through the steps on how to use Conditional Access Policies to configure limited web-only access for unmanaged devices.
Lets start off with some basic licensing requirements;
Since all of these are included in the Microsoft 365 Business Premium subscription and above most companies won’t have to worry about licensing.
Besides licensing lets make sure you’re corporate devices are being managed by Microsoft Intune, you can verify this by following these steps;
Lastly lets search for Azure AD registered devices that are being managed by Microsoft Intune.
Some companies choose to actively manage corporate devices that are “Azure AD Registered” devices. Based on my experience though, most of the time, these devices should not have been on this list. They are either “Personal” devices that were accidentally or intentionally enrolled in Microsoft Intune by the user or they are “Corporate” devices that have been improperly installed and configured by IT personnel.
If you encounter any personal devices in this list that are “Intune Managed”, you should stop the enrollment. If you decide to ignore them, understand that the Conditional Access policies might not apply to them.
If you want to prevent these personal devices becoming Microsoft Intune managed in the first place you should implement “Enrollment Restrictions”.
Follow these steps to configure them (if not skip them);
As an optional step, If you wish to test the policy or limit its scope to a specific set of users, click on the “Create Restriction” button to create a custom policy. Also, consider blocking device platforms that you are not actively managing at the moment. If you don’t do this you’ll run the risk of unwanted devices being managed by Microsoft Intune.
Take note that after configuring the enrollment restriction policy, administrators will need to use one of the following authorized methods to be able to enroll corporate devices;
Users trying to enroll their personal device will see the following error message;
Before implementing the Conditional Access policies, it is important to know that Microsoft 365 can only determine if a device is compliant (with device compliance policies), if the sign-in happens from a managed browser. If a user works with the Microsoft Edge browser (must be signed-in), Microsoft 365 can see that you are working from a compliant device. But what if the user works with any other browser? Now Microsoft 365 cannot check device compliance unless… You install the “Windows Accounts” extension for Google Chrome or enable Single Sign On for Mozilla Firefox. Peter van der Woude wrote a great blog about how to install the “Windows Accounts” extension in Google Chrome. (link)
A last thing before we start, we should determine whether the policies should apply to both guest and member accounts. Even if you decide not to apply the policies to guests, you should not skip this step.
It’s important to note that guests in SharePoint and OneDrive do NOT automatically receive an (Azure AD B2B) guest account when someone shares a file, folder, or site with them. As Conditional Access policies can only be enforced on guests with an Azure AD B2B guest account, you should consider making this change to your environment.
SharePoint and OneDrive integration with Azure AD B2B to the rescue!
Simply download and connect to the SharePoint Online Management Shell and use the following cmdlet;
Set-SPOTenant -EnableAzureADB2BIntegration $true |
Going forward, an Azure AD B2B account will be automatically created for guests accessing SharePoint and OneDrive links. Users won’t have to reshare anything, unless a sharing link is used that was created by a user who no longer exists. By making this change not only will you be able to enforce Conditional Access policies on these guests, but they will also no longer require a Microsoft account. (read more about the integration here)
Making this change becomes especially important if you plan on excluding guests from the Conditional Access policies. Implementing this change will ensure guests are not affected and can be properly excluded. It may sound strange but it is necessary due to the fact that guests with SharePoint/OneDrive links can’t have Conditional Access policies applied to them. As a result, they will be impacted by the policy due to the pre-configuration that we are performing in the next step.
Follow these steps to pre-configure SharePoint Online (also OneDrive and MS Teams) to be able to handle app-enforced restrictions within Conditional Access Policies;
Optional: If you prefer doing this with PowerShell (outcome is the same), you can use below cmdlet and parameter.
Set-SPOTenant -ConditionalAccessPolicy AllowLimitedAccess |
The result of making this change are two Conditional Access policies being created which we can find inside Microsoft Entra Admin Center.
The reason why we are disabling the policies is to prevent it from affecting our users as we want to make some changes to the policies first. Do not try to create the “Use app-enforced restrictions for browser access” policy manually without changing the setting within the SharePoint Admin Center, because the policy won’t take effect. Also do not delete the Conditional Access policies or else you’ll have to recreate them by flipping the switch off and on again within the SharePoint Admin Center.
In my opinion Microsoft is making these steps unnecessarily complex but for now we will have to deal with it.
Follow these steps to pre-configure Exchange Online to be able to handle app-enforced restrictions within Conditional Access Policies;
Get-OwaMailBoxPolicy | select-object ConditionalAccess* |
Set-OwaMailBoxPolicy -Identity OwaMailboxPolicy-Default -ConditionalAccessPolicy ReadOnly |
By turning the feature on we can now move on to configuring the Conditional Access Policies.
First let me explain what these policies actually do before we configure them.
Now that you know what the policies do lets configure them by following these steps;
Please note that these are my recommendations, they may not fit your company precisely so add exclusions or make other necessary changes if that fits your company policies better.
Name | Change the policy name to something that fits your company’s naming convention. |
Users | Select a group of users that you want to test the policy out on before you turn the policy on company-wide. Exclude any users that you don’t want to be impacted, for example certain user groups or service-accounts. |
Cloud apps or actions | Add Exchange Online to the selected apps, now both SharePoint Online and Exchange Online should be selected. |
Conditions | Mobile Apps and Desktop clients should stay selected. Exclude any device platforms and/or locations that you don’t want to get impacted by this policy. For example iOS and Android if you aren’t managing mobile phones yet with Microsoft Intune, or exclude a specific IP-address for users working from an RDS server with Microsoft Office. |
Grant | U can leave both “Require Hybrid Azure AD joined device” and “Require device to be marked as compliant” option selected or choose either one of the two. For example you could have only the “Require device to be marked as compliant” option selected, this way non-compliant managed devices would have the same experience as unmanaged devices. |
Session | (no changes) |
Name | Change the policy name to something that fits your company’s naming convention. |
Users | Select a group of users that you want to test the policy out on before you turn the policy on company-wide. Exclude any users that you don’t want to be impacted, for example make a decision if you want to include guests. |
Cloud apps or actions | Add Exchange Online to the selected apps, now both SharePoint Online and Exchange Online should be selected. |
Conditions | (no changes) |
Grant | (no changes) |
Session | (no changes) |
Now prepare to turn on the policy. I would strongly recommend to test the policies, and also scope them to pilot users first before implementing them company wide. This way you can make the necessary changes that fit your company.
To conclude this blog, let me give you some visual examples of what the user experiences are like on the web after implementing the “Use-app-enforced restrictions for browser access” Conditional Access policy.
OneDrive Web – No download, print or sync options
MS Teams Web – There is no download option anymore
Excel Web – Cannot download, print or sync options
SharePoint Online – No download, print or sync options
Exchange Online – No downloading or printing attachments
Cannot Sign-in to the OneDrive Desktop Client
Cannot Sign-in to Microsoft Office Desktop apps (including MS Teams)
Your email address will not be published. Required fields are marked *
2 Comments