Custom Compliance Policies: Detecting Real-World Drift with Intune

When it comes to configuring compliance policies, Intune provides settings out of the box that can be monitored for config drift, such as BitLocker enabled, minimum OS version, and Antivirus to name a few. However, if the setting (or state) you want to capture isn't included, Intune provides a way to use PowerShell to detect this information on an endpoint.

Since a PowerShell script is the detection method, this essentially provides us with an endless amount of ways to check for compliance on a Windows endpoint. In this post, we're going to take a look at what Intune Custom Compliance Policies are, how to create them, and evaluate how these policies are deployed and evaluated on the endpoint.

Prerequisites

• Microsoft Intune subscription
• A text editor (Visual Studio Code is great open-source editor)

What is a Custom Compliance Policy?

Creating a custom compliance policy in Intune requires a PowerShell detection script as well as a JSON file. Custom compliance policies can be used when the out of the box compliance settings don't satisfy the requirement.

Create a Custom Compliance Detection Script

note

Download the PowerShell detection script and JSON file used in the example below from my GitHub repo

tip

If you want to learn more about how to write your own custom compliance detection script and JSON file, Steve Weiner has a great video on this topic that you can check out here.

All the following steps are performed in the Microsoft Intune admin center.

First we need to create the PowerShell detection script and JSON file that will be used for the custom compliance policy. The PowerShell script will confirm that the EnableCertPaddingCheck registry value is set to 1, and the JSON file will define the compliance policy configuration.

1. Select Devices > Manage Devices > Compliance > Scripts > + Add > Windows 10 and later
2. Under the Basics tab, provide a name and description for the script, then click Next.
   • Name: WinVerifyTrust Signature Validation Required
3. Under Settings configure the following:
   • Detection script: If following along with the example, use the Get-WinVerifyTrustCompliance.ps1 PowerShell script from the GitHub repo linked above.
   • Run this script using the logged on credentials: No
   • Enforce script signature check: No
   • Run script in 64 bit PowerShell Host: Yes
4. Click Next > Create

Create a Custom Compliance Policy

1. Select Devices > Manage Devices > Compliance > + Create Policy

   • Platform: Windows 10 and later
   • Platform type: Windows 10/11 compliance policy

2. Click Create and configure the following:

   • Name: WinVerifyTrust Compliance Policy
   • Compliance settings: Custom compliance
   • Custom compliance: Require
   • Select your discovery script: Select the WinVerifyTrust Signature Validation Required PowerShell script

   

3. Configure the noncompliance action:

   • Actions for noncompliance: Mark device noncompliant immediately

4. Assign the appropriate group(s) to the policy and click Create.

How the IME Executes Custom Compliance Scripts

The Intune Management Extension (IME) performs all the magic behind the scenes when it comes to orchestrating the retrieval of the custom compliance detection script from Intune, running the script using the AgentExecutor, and updating the appropriate registry keys to indicate whether the device is compliant or not.

Let's see it in action.

Force the Script to Re-Evaluate

tip

If you want to use a PowerShell script to automate the steps below, take a look at the blog post written by Rudy Ooms on custom compliance policies.

To bypass the internal 8 hour timer, we're going to speed things up so we can watch what takes place when a custom compliance policy runs in real time. We can do this by performing a few steps.

From the Intune admin portal, navigate to the PowerShell script associated with the compliance policy to locate the GUID of the script. This can be found in the URL path of the script.

From the endpoint, under the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\SideCarPolicies\Scripts\Execution and the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\IntuneManagementExtension\SideCarPolicies\Scripts\Reportsregistry keys, delete any subkeys that match the GUID of the PowerShell script that is associated with the custom compliance policy that was located earlier.

note

Make sure to look under the System registry key 00000000-0000-0000-0000-000000000000 and the user registry key(s) {USER_GUID} for the PowerShell script GUID, and delete any subkeys that match the GUID of the PowerShell script.

Look at the value of the Result registry key, it will show the cached result of the last time the IME ran the custom compliance script.

Why this works

The IME caches the results of last time the custom compliance policy script ran in the registry values we just deleted. Now, if we restart the IME service, we can essentially trick the IME service in to re-running the compliance script prior to the time set by the hard coded 8-hour timer.

In this case, the last time the IME ran the custom compliance script,the JSON key WinVerifyTrustSigValEnabled that was defined when the policy was configured is set to true, which would indicate the device passed the script validation and is compliant.

Restart the IME service by running the following PowerShell one-liners.

Get-Service -DisplayName "Microsoft Intune Management Extension" | Stop-Service
Get-Service -DisplayName "Microsoft Intune Management Extension" | Start-Service

Give the IME 10-15 minutes to execute the custom compliance script. If you take a look at the IME logs, you'll notice there is quite a bit of logs being generated after restarting the IME service. So be patient with it.

Now that the cached results of the last time the custom compliance policy PowerShell script have been deleted, and after restarting the IME service, there are a few specific IME logs that are of interest to understand what is happening from start to finish when the compliance policy is executed.

IME specific logs of interest are:

• HealthScripts.log
• AgentExecutor.log

tip

IME logs are located here: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

In this first go around, the necessary EnableCertPaddingCheck registry values are set to 1, so the script should return that the device is compliant. But let's take a closer look at the IME logs to get a better idea of what's happening under the hood.