Blocking BYOD based on unsupported OS versions

Last Updated on June 20, 2022 by Oktay Sari

A couple of days ago, a colleague asked me if it was possible to Block BYOD based on unsupported OS versions from accessing Microsoft 365 resources like Exchange Online or SharePoint Online and Teams, when using the desktop apps on unmanaged devices with older OS versions.  In this scenario, BYOD’s are not allowed to MDM enroll to Intune.

Let’s have a look at what options we have when it comes to Blocking BYOD based on unsupported OS versions with MEM/Intune and conditional access. We all know Microsoft Endpoint Manager can block devices from enrolling to Intune based on minimum OS versions right? We also have the option to use compliance policies and require a minimum OS version from there. Combined with a conditional access policy, managed devices with older OS versions can be blocked from accessing Microsoft 365 resources. However, these options are generally used for company owned devices.

You can off course enroll BYOD devices to Intune and make use of these options, but then again, who wants to enroll personal devices to MEM? I know I’m not a fan of having full access to BYOD. Imagine yourself in a situation where you have to explain why 15 years of personal files, photo’s and baby video’s have been wiped because someone did not pay attention…

First a disclaimer; This post is a proof of concept that might need some finetuning here and there. It’s a very   creative use of conditional access policies where things can go south very easily. I strongly suggest you test this in your test tenant and NOT in production. 
It’s an idea I’d like to share with you all and find out what you think of it. Perhaps you have a very   good use case for this. I invite you to share your thought below.

Never did I know, that this was going to be a never ending story… Although…it seamed like this. Buckle up because it’s a long read. If you want to skip all the research and jump right to the configuration that works, then go ahead. However, If you want to know more about my journey and things I did wrong then read along.

Block unsupported OS versions with MEM

Blocking BYOD based on unsupported OS can be achieved with MEM. Some of the options you have to block unsupported OS versions are described below.

• For Windows 10 or Windows 11 devices that are Intune managed we can use Compliance policies combined with Conditional access to block unsupported OS versions with MEM.
• For Android devices (managed and unmanaged) we can use Conditional launch and block unsupported OS versions
• For iOS and iPad devices (managed and unmanaged) we can also use Conditional launch

* Both for Android and iOS/iPad you can even go deeper and require a minimum app version as well.

Looking at the above we can see that when it comes to unmanaged (personal) Windows devices, we seem to be out of luck. Or not?

What’s the use case?

What’s the use case for blocking BYOD based on unsupported OS versions? Well, there are a couple of use cases I an think of;

1. Device registration in Azure AD is optional. No WIP (Windows Information Protection) policies in place.
2. Device cannot register in your Azure AD tenant. Without Azure AD registration devices cannot be targeted with WIP-WE (Windows Information Protection Without Enrollment) policies.
3. Device can register with Azure AD and can be targeted with WIP-WE policies.

In all three cases, you are requiring users to have a Windows OS version that is up to date.

Note: I’m not a fan of BYOD accessing corporate data, without having some form of data protection in place. Your first (and perhaps even only) option to consider is restricted web access to Microsoft 365 services from unmanaged devices. If you have the required licenses you could also go for Microsoft Defender for Cloud Apps. If that is not an option. At the very lease, consider Windows Information Protection.

If I was to go ahead with this in a production tenant, than option 3 would be a good use case. With option 3, you allow users to use the Office 365 desktop apps while protecting documents that are downloaded or synced to the device, with Windows Information Protection. At the same time, although these are personal devices, you require the OS to be updated. But remember, this is a concept and fun thing to play with and learn from in your test tenant.

Conditional access filter for devices to the rescue

With conditional access filter for devices, we can include or exclude specific devices. I was thinking that perhaps the device attribute operatingSystemVersion could help with this challenge.

I want the policy to apply, when a device is NOT Azure AD joined or registered and NOT on a certain OS build. Please keep in mind thought, that depending on what the device status is, the policies will or will not apply.

Here’s a quote from Microsoft “The filter for devices condition in Conditional Access evaluates policy based on device attributes of a registered device in Azure AD and hence it is important to understand under what circumstances the policy is applied or not applied”

Have a look at the policy behavior with filter for devices table to better understand this. At first I was only interested in policy behavior on devices that are unregistered.

Based on the information we now have, It seems I have to create a Conditional access policy with a filter set to Include devices and use negative operators for the filter to apply on unregistered devices. Still with me?

Note: I’ve tried many different configurations but was not able to create a working set of policies while trying to target (include) unmanaged devices. But keep reading to see how I solved this.

Block unsupported OS versions with conditional access policies

Here’s an example of my first conditional access policy. Let’s start with (what I thought to be ) a good configurations..

The good thing (I thought) was, that the operatingSystemVersion attribute works with the -NotIn operator (according to the documentation). Why is this good? You don’t have to consider every revision… The latest build for Windows 10 21H2 is 19044.1620. Windows 10 OS build numbers are structured as follows; major.minor.build.rev – 10.0.19044.1620. Have a look at the Windows 10 release information if you want to know more. So I’ve configured the following Conditional Access policy

I thought this policy would block all Windows devices that are not on build 19044.xxx or 22000.xxx and where the device is NOT Azure AD joined. All negative operators.

Looking at the sign-in logs I noticed, that whenever a user tried to sign-in to (for example) Microsoft Teams, on a device that was not Azure AD registered or Azure AD joined, the Join Type was empty. So I was still thinking that this should work… Seems like I can read every device attribute.

Blocking unsupported OS versions with Conditional Access filter for devices

For a while, blocking BYOD based on unsupported OS versions with Conditional Access filter for devices is not working like I want it to. Some of the rule syntaxes I’ve tried:

• device.operatingSystemVersion -notIn [“10.0.19044″,”10.0.22000”] -and device.trustType -ne “AzureAD”
• device.operatingSystemVersion -notIn [“10.0.19044”] -and device.trustType -ne “AzureAD”
• device.operatingSystemVersion -notIn [“10.0.19044″,”10.0.22000”] -or device.trustType -ne “AzureAD”
• device.operatingSystemVersion -notIn [“10.0.19044”] -or device.operatingSystemVersion -notIn [“10.0.22000”]
• device.operatingSystemVersion -notIn [“10.0.19044”] -or device.operatingSystemVersion -notIn [“10.0.22000”] -and device.trustType -ne “AzureAD”
• device.operatingSystemVersion -notIn [“10.0.19044″,”10.0.22000”]

After many more attempts my head was spinning like crazy. I got very confused with all combinations. I’ve tried ORs and ANDs, all ORs and all ANDs. Perhaps the syntax is no good and I tried to manually edit the syntax but to no avail.

The day after, I was brainstorming with Niels about this issue, and we tried some other combinations without any luck. Niels is a blogger himself and has some great content.

I concluded that Conditional Access filter for devices did not work for me when using the -NotIn operator. Better yet, Whenever I tried to combine a negative operator with OR/AND multiple OS builds, it would not work.

I almost gave up, but decided to leave it for a couple of days and start over.

Update: Perhaps I had a logic error in my filter, which is why it only worked partially sometimes. A reader pointed me in the right direction so perhaps this will keep you from making the same mistake I did. You must use “and” to combine multiple “not equal” conditions, or else the expression is always going to be true.

Requirements for BYOD devices

Are you still reading and with me? OK…Let’s continue. First things first. Back to the drawing board. What I’m trying to achieve is this:

1. Block BYOD (personal devices) from enrolling to Intune/Microsoft Endpoint Manager
2. Unmanaged devices should be able to use the browser (restricted) to access Microsoft 365
3. Block all unmanaged or unregistered devices from accessing Microsoft 365 resources using the desktop client apps.
4. Require Azure AD registered BYOD to have updated Windows versions
5. Require users to accept Terms of Use on BYOD
6. BYOD should be targeted with WIP-WE policies

Note: Be very careful with Conditional access policies when set to Block access! Obviously you can get   yourself in a situation where you’re locked out your own tenant. Always work with pilot groups and if       possible, in a test tenant. Be even more careful when targeting All Apps!

Conditional Access filter for devices and BYOD

I started over from scratch and configured a couple of Conditional access policies to meet my requirements. The first problem (Block BYOD devices from enrolling to Intune) can be solved with enrollment restrictions and I’m not going to discuss that here. The requirement to target devices with WIP-WE is covered in many other posts I’ve written in the past. Here are the other conditional access policies I configured:

1. DEV – Windows – COFM – Require Compliant Device (exclude browser/registered)
2. DEV – Windows – BYOD – Block All exclude AAD joined or workplace joined
3. DEV – Windows – BYOD – Accept TOU v1
4. DEV – Windows – BYOD – Block OSVersions

1 – Windows – COFM – Require Compliant Device (exclude browser/registered)

The first Conditional Access policy is targeting all users (exclude break glass accounts) and the Office 365 cloud app on Windows devices. It requires Intune devices to be compliant but excludes browsers and Azure AD registered devices.

2 – Windows – BYOD – Block All exclude AAD joined or workplace joined

The second Conditional Access policy is targeting all users (exclude break glass accounts) and the Office 365 cloud app on Windows devices. It blocks all devices that are NOT Azure AD registered or Azure AD joined but at the same time excludes browser access.

Another good thing that policy 2 accomplishes, is that it will block users on BYOD, when they choose the “No, sign in to this app only” option.

When you have configured Windows Information Protection policies targeting unmanaged devices (WIP-WE) this option is a No Go. When users do click on “No, sign in to this app only” the device will not register in Azure AD, but will have access to data. Maurice Daly wrote a great post on that one, so make sure you read it.

3 – Windows – BYOD – Accept TOU v1

The third Conditional Access policy is targeting all users (exclude break glass accounts) and the Office 365 cloud app on Windows devices. It requires users to accept terms of use on all devices that are NOT Azure AD joined.

4 – Windows – BYOD – Block OSVersions

The fourth Conditional Access policy is targeting all users (exclude break glass accounts) and the Office 365 cloud app on Windows devices. It Blocks access except when working on a Azure AD joined device, or on a device with a certain OS build.

Note: You will have to update the rule syntax for this policy and include all OS builds you want to allow. Any future update should be added as soon as possible, because users could be working on OS build 19043 but after updating to 19044 they will have no access according to the above policy.

Summary (this far)

The combination of Conditional access policies described in this post will require users to register their BYOD with your Azure AD tenant, accept Terms of Use, and to have an OS build that is allowed to access Microsoft 365 resources using the desktop client applications. Blocking BYOD based on unsupported OS versions seems to work! If for whatever reason, they cannot register their device, they will be restricted to browser access only. And of course, make sure you have restricted web/browser access for unmanaged devices to SharePoint Online and OneDrive to be a little more secure.

You will have to think of some sort of onboard process to help users when they are allowed to work on personal devices. Create manuals or video’s for users to follow while self servicing and registering their devices. There are also other considerations, like contractors who want to work on their corporate issued devices. Most of the time their devices will be managed by another company with their own configurations and restrictions.

Communication is key if you want to apply this successfully without driving your users mad!

User experience

One other thing to consider is the end-user experience. When users are blocked by your conditional access policy because they have an outdated OS version or try to work on unregistered devices, they’ll only see an error message that’s very vague at the least..

And of course they will call your support team when they see an error blocking them from working on their personal device. When you troubleshoot these issues and look at the sign-in logs, depending on the policies you have, you might see a lot of failures.

Correct user workflow

On bring your own devices, users should follow the next steps to successfully sign-in and work with client apps like Microsoft Teams;

1. Update to a supported OS build
2. Azure AD Register a device (settings –> add work or school account)
3. Download and install Microsoft Teams client app
4. Start Microsoft Teams and sign-in
5. Accept the terms of use

Wrapping it up

Here’s a video showing you the configuration in Microsoft Endpoint Manager and Azure. I’ll also show you the user experience on different devices I used while testing. Hope you like it.

Conclusion

Based on the information provided by the Microsoft docs, I was focused on creating a Conditional access policy with a filter set to Include devices and use negative operators. Because only then the policy should apply on unregistered devices. This only seems to work when using no more than 1 device attribute. When combining multiple attributes or for example stacking the attribute device.operatingSystemVersion to include multiple OS builds, it does not work as expected.

The only conditional access policy that did work as documented, was DEV – Windows – BYOD – Accept TOU v1 where I Include filtered devices with a rule syntax device.trustType -ne “AzureAD”. This policy targets every device that is NOT azure AD joined.

I ended up creating multiple conditional access policies, blocking or allowing access, including and excluding filtered devices, to achieve something that seemed very simple at first.

I’m planning to contact Microsoft support about this and see if I can have them confirm this behavior.

What do you think? Is there a use case for this or is it all mumbo jumbo? I invite you to share your thoughts below.