It is not unlikely that some of your users still use Windows 7 on their home computers. Or any other outdated operating system (heaven forbid). Despite the warnings, news articles, and endless coffee chit chats about this subject, they still have the – “if it ain’t broke, don’t fix it” – mindset, and will eventually use it to access work resources as well.
With the use of Conditional Access you can block specific operating systems, but you cannot specify a specific version, like Windows XP or Windows 7. This is possible with Intune Compliance policies, but they will not apply to unmanaged clients, the scope of today’s blog post.
Bring in Cloud App Security
First, we’ll need to route the application to Cloud App Security using Conditional Access. In this example, I use Office365 as the selected app, and Windows 10 as the selected device platform, but you can adjust this to your own situation.
+ Create a new policy
Users and groups: Select the user. Start with a test user!
Cloud apps or actions: Select Office 365
Conditions:
Select Device state (Preview), All device state, and exclude Device Hybrid Azure AD joined and Device marked as compliant.
Select Device platforms: Windows
Session: Use Conditional Access App Control, Use custom policies
With this action we route all traffic, coming from unmanaged devices, to Cloud App Security.
Access policy
Next, create an access policy in Cloud App Security and define the policy like the example below.
This is the beauty of Cloud App Security. To test this out, you can only apply the policy to one user and/or app. In this case, we select User agent tag -> equals -> Outdated operating system.
Take note: I could not find any official documentation in this, but I read a post on the tech community website that states the following: outdated = current version –2.
If you want to be more specific, you can also block the exact version based on the user agent string.
User experience
When a user with an outdated operating system tries to access one of the resources, the session is blocked.
In the Cloud App Security portal, an alert is created.
Wrap up
One thing I have to point out here: user agents can be easily spoofed. This is not something Microsoft or Cloud App security can change for you, but it’s important to keep in mind when you design your Conditional Access and MCAS policies. Do not just configure policies for the clients that you support, but also create a safety net for the clients that are not specified or not supported. Do not just focus on the most common devices and browsers.
In this blog post, I showed you the powerful capabilities of Cloud App Security. Please check out my other blogs about this product.
Check out the Microsoft documentation if you want to learn more:
Protect with Microsoft Cloud App Security Conditional Access App Control | Microsoft Docs
Create Cloud App Security access policies to allow and block access | Microsoft Docs
Stay safe!
Pingback: Food for thought - Bring Your Own Disaster. - JanBakker.tech
with being new to cloud app security this is something that im looking to review, but when testing this procedure, there is something missing on my point of view that is not mentioned as a pre-req or otherwise known. I need to add an App to Conditional Access App Control otherwise it will not allow me to make any Access Policy as per your description.
Do you have any blogs or details/info about this?
It came by itself once i started using it. But i face another problem.
The User agent tag is empty on the test user, so no matter what i do, the user is never blocked.