Support Windows 10 BYOD with Microsoft Endpoint Manager and WIP-WE

Last Updated on October 4, 2022 by Oktay Sari

July 2022

IMPORTANT UPDATE: Microsoft announced the sunset for Windows Information Protection! WIP will be discontinued over time. Support for Windows Information Protection Without Enrollment will end by the end of calendar year 2022. Please read the official announcement and more on the following 2 sites:

• Announcing the sunset of Windows Information Protection (WIP)
• Support tip: End of support guidance for Windows Information Protection

If you have plans to implement WIP, I suggest you rethink your strategy accordingly. I will follow-up on this and update the WIP posts I have when more information is released by Microsoft.

1. Introduction to Windows Information Protection
2. Configuring MDM user scope and MAM user scope
3. WIP without enrollment (WIP-WE / BYOD)
4. Windows Information Protection with Enrollment
5. Windows Information Protection User Experience
6. WIP-WE User Experience – WIP Without MDM enrollment
7. Set up Azure Rights Management for WIP
8. WIP Without Enrollment Selective Wipe
9. Troubleshooting Windows Information Protection
10. Monitoring and collecting WIP audit event logs
11. WIP Learning mode
12. Support Windows 10 BYOD with Microsoft Endpoint Manager and WIP-WE

If you’ve read my previous post about Windows Information Protection Without Enrollment (WIP-WE), than you probably figured out it’s a great solution but also comes with some limitations. However, I’m a fan of WIP and in this post I want to talk a little more about how to support Windows 10 BYOD with Microsoft Endpoint Manager and WIP-WE. If you are new to WIP and want to learn more, then feel free to start with the series I wrote about Windows Information Protection.

Require device to be marked as compliant

Consider the following scenario: You have a Conditional Access policy that requires (corporate) devices to be marked compliant, before accessing Office 365 using anything else than a browser.

This means, a device has to be marked as compliant by Intune. Intune in turn forwards the device compliance status to Azure AD where Conditional Access can make decisions to grant or block access to selected resources. So devices need to be enrolled in MDM with Intune.

Block personal devices with enrollment restrictions

Now, also consider that you have a device enrollment restriction that blocks personally owned Windows 10 devices from enrolling into Intune for device management.

This setup makes sure personal devices cannot MDM enroll a Windows 10 device to Intune. Please read the official Microsoft documentation for more info and pay attention to the following:

When you block personally owned Windows devices from enrollment, Intune checks to make sure that devices are marked as corporate. Anything else (personal) will be blocked from enrolling into Intune.

Support Windows 10 BYOD with Microsoft Endpoint Manager and WIP-WE

You have also configured Windows Information Protection Without enrollment (WIP-WE) to support a BYOD scenario, but users cannot use their personal devices and the Office applications or the OneDrive client because the previous conditional access policy requires a compliant device.

In this scenario, the only way to access corporate data, would be to use the browser. A very good alternative if you don’t want to go for WIP-WE. However, if you still want to go for WIP-WE, then read along.

Conditional Access: Filters for devices (preview)

When creating Conditional Access policies, you have the ability to target (include) or exclude specific devices. We are going to use this preview functionality to target specific conditional access policies to personal devices. Please note that conditional access Filters for devices is currently in public preview and Microsoft does not recommended it for production workloads. However, it is a very powerful tool and I think (hope) this one is here to stay but don’t take my work for it yet. It is something to keep an eye on.

I have configured 2 conditional access policies that will work together to support Windows 10 BYOD with Microsoft Endpoint Manager and WIP-WE, while also making sure you have compliant corporate devices.

• CA1: DEV – W10 – COPE – Require compliant devices for apps – Exclude AAD Registered
• CA2: DEV – W10 – BYOD – Require AAD Registered devices for apps – Exclude corporate devices

DEV – W10 – COPE – Require compliant devices for apps – Exclude AAD Registered

Here’s the configuration for this policy. Pay attention to the Filters for devices (Preview) setting

Here is the Filters for devices (Preview) configuration in the portal

This conditional access policy will apply to all users on every Windows 10 device, except when the device is Azure AD registered. When you have a BYOD, that is not Azure AD registered, you cannot use the OneDrive sync desktop client to sync your files. However, you can use the browser to access OneDrive for Business.

DEV – W10 – BYOD – Require AAD Registered devices for apps – Exclude corporate devices

Here’s the conditional access policy that will support Windows 10 BYOD with Microsoft Endpoint Manager and WIP-WE.

This conditional access policy will apply to all users on every Windows 10 device, except when the device is Azure AD joined and marked as a corporate device. For example, all Windows 10 devices enrolled via Windows Autopilot are marked as corporate automatically.

To summarise, this policy uses the terms of use (TOU) feature in Azure AD, combined with conditional access policies and requires users to accept Terms of use and Azure AD Register their devices, before using desktop clients. You should know by now that WIP-WE only works, on devices that are Azure AD registered.

My Terms of Use setup

Update 13-10-2021:

You can use the What if tool to see which conditional access policies apply under selected conditions. While I was testing this on different VM’s the setup/configuration was exactly as written. But when I used the What if tool and selected more than one attribute for Filter for devices. It showed that users would have to accept the TOU on corporate devices. Not that it’s a big deal, but I was playing around and wanted this to work as I configured.

So I changed the above CA (DEV – W10 – BYOD – Require AAD Registered devices for apps – Exclude corporate devices) Filters for devices Rule syntax to device.trustType -eq “AzureAD” (this is the CA that requires users to accept the TOU). I did another run with the What if tool and this time, it showed that the policy did not apply on Azure AD joined devices. The only thing I can think of, is that it needs a little more work here and I guess that’s perhaps one of the reasons it’s still in preview.

Thx for the feedback Jan Bakker!

==================== end update ==================== 

Conditional access flow Windows 10 BYOD WIP-WE

Normally I would create a flow for just one conditional access policy but this time I tried to combine the two policies in one flow for a change. It’s a simple flow but I hope it helps clarify the decision tree and the if-then statements of conditional access assignments and access controls.

Final thoughts

By default all conditional access assignments would be ANDed. And in the examples above, one police requires a compliant device, and another requires users to accept Terms of Use and azure ad registration. The filters for devices functionality adds another dimension to conditional access policies. Above all, this feature gives you more control and freedom to work with.

When users try to access Office 365 in this example, using desktop client apps, the devices need to be marked compliant. And in case of a BYOD, the user needs to accept TOU and Azure AD register the device. As a result we can use WIP-WE to protect corporate data on these personal devices. Best of both worlds if you ask me. Below is a video showing how this all works in 10 minutes.

Things to think about

• If you target all users and have AAD Connect. Exclude the Sync user account.
• Exclude your breakglass admin accounts
• If you use VDI, you might want to use trusted locations
• Test with Windows Autopilot enrollment. All AP devices are marked as corporate once enrolled to Intune. Think about your filters

What do you think? Let me know below.