Windows configuration profile fails even if the OS settings are enabled

[harrisonravazzolo]

Fleet version: 4.68, also testing in dogfood

Web browser and operating system: Chrome, latest

---

💥  Actual behavior

Windows configuration profile fails to verify even if the settings are on the device.

• Full error message from Fleet: The MDM protocol returned a success but the setting couldn't be verified by osquery.
  • In Fleet we have profile_verifier.go here. My understanding is that the verification relies on rawProfileResultsSyncML which comes from the mdm_bridge extension. We suspect the mdm_bridge extension likely queries WMI/CIM classes.

Configuration profile (CSP) is here:

<Replace>
    <Item>
        <Meta>
            <Format xmlns="syncml:metinf">chr</Format>
        </Meta>
        <Target>
            <LocURI>./Device/Vendor/MSFT/Policy/Config/DeviceHealthMonitoring/ConfigDeviceHealthMonitoringScope</LocURI>
        </Target>
        <Data><![CDATA[HealthMonitoring,BootPerformance,WindowsUpdates]]></Data>
    </Item>
</Replace>

This affects verification of any CSP policy that doesn't populate WMI classes, leading to false negatives where policies are correctly applied but Fleet reports them as failed.

Other profiles I have tested this same behavior on are passcode and PinnedStart Items. I can provide some examples if needed.

Why is this a problem?

• WMI is slow as a snail or not supported/used across all CSP domains. I gathered a few bits from the interwebs - Some CSPs have full WMI provider support, others only write to registry, and some have partial WMI coverage.

Supporting Evidence:

• If we take a CSP for DeviceHealthMonitoring for example - see here for docu we deploy through Fleet and it is sent to the device successfully. This can be verified in Powershell with a command that looks at the management database (WMI)

Get-CimInstance -Namespace "root\cimv2\mdm\dmmap" -ClassName "MDM_Policy_Result01_DeviceHealthMonitoring02" | 
    Select-Object ConfigDeviceHealthMonitoringScope

which returns returns nothing. The CSP node is there but there is no values assigned to it.

However, if we use the registry which is the authoritative source for CSP policy data, we see the expected values from the CSP, the command to query the reg:

Get-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\DeviceHealthMonitoring" -ErrorAction SilentlyContinue

🧑‍💻  Steps to reproduce

Add this DeviceHealth profile to Fleet:

<Replace>
    <Item>
        <Meta>
            <Format xmlns="syncml:metinf">chr</Format>
        </Meta>
        <Target>
            <LocURI>./Device/Vendor/MSFT/Policy/Config/DeviceHealthMonitoring/ConfigDeviceHealthMonitoringScope</LocURI>
        </Target>
        <Data><![CDATA[HealthMonitoring,BootPerformance,WindowsUpdates]]></Data>
    </Item>
</Replace>

🕯️ More info (optional)

@TsekNet: We may want to do what https://github.com/okieselbach/SyncMLViewer does and look at the etw trace for the syncml response instead of relying on the mdm_bridge extension? Or update the extension?

• That app seems to get the response immediately vs. I've noticed Fleet can take hours(?) before timing out.
• Can use something like https://github.com/0xrawsec/golang-etw to get the ETW event handler then parse the event payload to extract SyncML XML, then process/verify as needed.

🛠️ To fix

Fix Fleet's Windows configuration profile verification to handle verification of any configuration profiles that don't populate WMI classes.

[TsekNet]

We may want to do what https://github.com/okieselbach/SyncMLViewer does and look at the etw trace for the syncml response instead of relying on the mdm_bridge extension? Or update the extension?

That app seems to get the response immediately vs. I've noticed Fleet can take hours(?) before timing out.

Can use something like https://github.com/0xrawsec/golang-etw to get the ETW event handler then parse the event payload to extract SyncML XML, then process/verify as needed.