In this post I will be discussing on how to Block access to Office 365 access when Windows is not patched. The purpose of this post is to implement a solution so as if any Windows 10 workstation device is not patched for last couple of months (let’s say 6 months), device should not be able to access Office 365 or we can say let’s block the access to Office 365 applications such as word, excel, PowerPoint etc.
- Why we require this policy to block Office 365 client apps ?
- Settings required to restrict access to Office 365 client apps for Windows 10 / Windows 11 devices
- Create Compliance Policy to define to define minimum Operating System
- Create Conditional Access policy to block Access to O365 Client Apps
- Evaluate access to Office 365
Why we require this policy to block Office 365 client apps ?
Nowadays for any organization, the biggest threat is not have the systems patched. It might seems pretty good when we have 90-95% compliance rate in terms of patches report. We feel like a huge success and can boast it within the organization, but what about remaining percentage ? There are likely chances that nobody is looking into missing numbers and those systems will become vulnerable and will keep to stay on same OS version (patch version) as the big numbers looks good. This initiative of blocking Office 365 application will force not only users but Admins who are managing the patches to take action because if one of the major service is impacted, then eventually users will contact service desk and the case will pointed to correct direction to take the action whether in terms of resolving the issue related to why patching is not happening and to troubleshoot it or rebuilding the Operating system if team is not able to resolve Windows update issue.
Settings required to restrict access to Office 365 client apps for Windows 10 / Windows 11 devices
At a very high level if we wanted to implement the solution for restricting Office 365 access through Office 365 client apps and Office 365 cloud app, we need a combination of Compliance Policy and Conditional Access Policy, both will work together to achieve the solution, we must configure following:
- Compliance Policy: We will create compliance policy to define specific valid operating system builds in “Major.Minor.build.revision” format so as to mark them as compliant / non-compliant. More on this later.
- Conditional Access: We will create Conditional access policy to grant access to Office 365 client apps only when system is compliant.
Create Compliance Policy to define to define minimum Operating System
We will begin with creating Compliance policy in MEM admin center (Intune portal). Before creating this policy let’s decide when would you like to mark your system as non-compliant, may be 3 months or 6 months ? Your organization has to take the decision on when to mark the system as non-compliant if they haven’t been patched for last couple of months.
Login to Microsoft Endpoint Manager admin center and navigate to Home > Device > Windows > Compliance policies. Click on Create Policy, select Platform as Windows 10 and later with Profile type selected as “Windows 10/11 compliance policy” and click Create.
On Windows 10/11 compliance policy blade while Basics selected, specify Name such as “Check Windows 10 version” and click Next.
On Compliance settings, you will see various options to define Compliance settings such as:
- Custom Compliance
- Device Health
- Device Properties
- Configuration Manager Compliance
- System Security
- Microsoft Defender for Endpoint
We are interested in Device Properties, click to expand it.
We will see various options, starting with:
Operating System Version
Minimum OS version
Maximum OS version
Minimum OS version for mobile devices
Maximum OS version for mobile devices
I am not going to use any of this options as this might be only useful for one kind of OS build such as 1909, 2004, 20H1, 20H2 etc. You cannot successfully define the combination of minimum OS version for each Operating system with above mentioned settings if you have more than one type of Windows 10 operating system in your environment, and I am sure this will be the case for every organization. But there is a way to handle this scenario by using Valid operating system builds
How to define Valid operating system builds
Under Valid operating system builds we can define multiple operating systems with minimum OS version and maximum OS version. Let’s understand what values we can put in. We have 3 columns as Description, Minimum OS version, Maximum OS version.
For Description, you can use something like “Windows 10 20H2” or “Windows 10 20H2 – patches Sept’21 onwards”.
“Minimum OS version” and “Maximum OS version” values relies on OS build versions which is in a specific format such as major.minor.build.revision. You can get this value on any Windows 10 workstation by opening command prompt and typing “Ver”. I ran on of my system and got following value:
Microsoft Windows [Version 10.0.19044.1415]
- major is 10
- minor is 0
- build is 19044
- revision is 1415
major.minor ie. 10.0 will remain same for entire Windows 10 OS. Build is specific to feature update released every year, 19044 build version is actually 21H2 version. While revision is latest patch applied for specific build version ie. 1415, revision will keep on upgrading with every patch released and applied to that specific feature update.
For list of all available build versions can be checked through Windows 10 release history, this page will help you defining patch revision version for specific month to be used for compliance purpose.
Another way to get Windows 10 build version is run the command “Winver” under Windows + R. We will get value:
Version 21H2 (OS Build 19044.1415)
Upon checking the Windows 10 release history, I can get the information of Build version to be used for each month and can pick the minimum value based upon that.
For 21H2, I can see 3 build versions available as this is released recently at the time when this blog was written:
As this is the latest OS build recently released, I don’t have old that to be used such as 3 months or 6 months to be used as reference to mark as Non-compliant. Hence, for the sake of demonstration I am going to use:
- Minimum OS version: 10.0.19044.2000
- Maximum OS version: 10.0.19044.3000
Taking reference for Windows 10 release history, I am defining Min. and Max. OS version for other Windows 10 OS as well.
- Windows 10 20H2 : 10.0.19042.1288 : 10.0.19042.3000
- Windows 10 1909: 10.0.18363.1801 : 10.0.18363.3000
Note: I have used revision as 3000, there is no revision released for 3000, just for the sake of compensating all future versions, I am using an upper max. value.
Once the values are defined under Compliance settings > Valid operating system builds, click Next.
On Actions for noncompliance page, specify the sequence of actions on noncompliance devices. We will use the setting Mark device noncompliant when Schedule (days after noncompliance) as 7 days. Hence giving extra 7 days of time for system to get patched rather than getting it non-compliant immediately when the systems are built out of the box using task sequence OS build / AutoPilot.
On Scope tags click Next. On Assignments page, assign the policy to existing group. Click Next.
Verify the all the settings under Review + create page and click Create.
Create Conditional Access policy to block Access to O365 Client Apps
As we have already deployed Compliance Policy for Windows 10 devices which will take some time to evaluate on workstations to mark them as compliant / non-compliant. We need to create Conditional Access policy to block the O365 client apps when device is marked as non-compliant.
On Microsoft endpoint Manager admin center portal, navigate to Home > Devices > Conditional Access and click on New policy > Create new policy.
This can also be accessed through Azure Portal > Azure AD Conditional Access.
Provide name to the policy such as “Block O365 client apps – Windows 10”.
Under Assignments > Users or workload identities, specify “All users” or for testing purpose specify existing Users and groups.
Under Cloud apps or actions, either we can specify All cloud apps or specific Office 365 out of list of all cloud apps mentioned.
Note: This setting will block access to Office 365 using cloud ie. Through browser. Users won’t be able to access Office apps through any browser.
Under Conditions, select Client apps, select Configure as “Yes”. If you go with “No”, then by default policies will be applied for all existing settings as define below.
- Modern authentication clients
- Mobile apps and desktop clients
- Legacy authentication clients
- Exchange ActiveSync clients
- Other clients
For this demo “Mobile apps and desktop clients” is the one we are looking for which includes all Office desktop and phone applications. But for the sake of additional security, I am selecting all.
Under Access controls > Grant, select Grant Access when Require device to be marked as compliant.
Enable policy by changing from Report-only to On (Report-only is a good option to test your policy first in production environment, for demonstration purpose I am going with On), click on Create.
Note: Conditional Access Policies does not have feature with assignment, hence once it is created, it will be applied based upon the settings we have specified. Hence make sure to thoroughly test the settings using Report-only settings, and better to use break glass accounts to prepare yourself in the event if whole organization / accounts are getting locked because of wrong settings specified.
Evaluate access to Office 365
We are done with the settings, when user receives the policy and marked as Non-compliant. We can verify the results by launching existing Word App. We will see the error:
Get access to this resource
This device does not meet your organization’s compliance requirements. Open your organization’s device management portal to take action.
Clicking on More details can show you the App name as Microsoft Office.
When we try accessing Office portal using https://office.com, we again got error. And while expanding the More details info, this time the app name was OfficeHome because we also blocked Cloud apps.
For Troubleshooting Conditional Access issues, you need to go to Azure portal > Conditional Access > Sign-in logs.
Defining Conditional Access policies along with Compliant policies is not too difficult but be ready with the consequences if not correctly implemented. Always check / verify before implementing. The implementation should be done in report-only form for few days / weeks to verify the results. Once you see the policies are correctly applying, then only mark Conditional Access policy as On from report-only.