Microsoft Defender Network Protection – Not Enabling via Intune – Troubleshooting & Fix

When configuring Defender for Endpoint (MDE) customer recently, I ran into a problem when trying to enable network protection.  Network protection is a feature of MDE and Microsoft Defender Antivirus (MDAV) that takes the filtering capabilities of SmartScreen and applies them to all network traffic.  It is a prerequisite for things such as MDE’s web content filtering and URL/domain indicators of compromise.

This blog details the specific problem I had enabling it with Intune (Microsoft Endpoint Manager), and general troubleshooting steps to follow that will help for that problem and hopefully others you may experience.

The problem

Configuring network protection should be super straight forward.  In your antivirus endpoint security profile, you simply choose yes against turn on network protection.

Info: Until about a year ago, all configuration of Microsoft Defender was done using an endpoint protection Intune device configuration profile.  This was a type of configuration profile that covered Antivirus, Firewall, BitLocker, etc.  Microsoft since then introduced endpoint security – a blade within the Microsoft Endpoint Manager admin center that intends to simplify and improve management of all security related profiles.  This isn’t always foolproof, and there are reasons you may want to stick with device configuration profiles, which I’ll be blogging about soon.  For what it’s worth, this blog applies to both, as I tried both and had the same problem (and fix).

However, on my devices, even after syncing to Intune, network protection just didn’t enable.

Troubleshooting network protection

On the device, a few ways to check network protection are…

• In a third-party browser, visit the SmartScreen test website.  Why third party?  Because SmartScreen is built into Edge.  Network protection is about extending that to the general network.  In the screenshot below, I can tell network protection isn’t doing it’s job because I see the page render and not a failure to load.

• In PowerShell, Get-MpPreference returns MDAV settings.  In this case, EnableNetworkProtection returns a value of 0.  The MEM setting configured earlier should have set it to 1.

• In the MDMDiagReport (Settings > Accounts > Access work or school > [your account] > Info > Create report), you can find out information on configuration service providers (CSPs) set up in Intune.  This means you can search for many Intune settings and see what has been applied.  In my case, EnableNetworkProtection was under the area for unmanaged policies.

Strangely, in Intune, the policy clearly shows success:

At the moment, my guess is this to some kind of bug in configuration profiles and endpoint security profiles.  I will get in touch with Intune support to confirm.  Why do I think it’s a bug?  Because when I apply the fix, all I’m doing is bypassing the profiles and turning it on directly…

The fix

Fundamentally, when we are updating endpoint security profiles, we are just working with a user interface to set up OMA-URIs.  Without getting into too much detail, these are the underlying settings an MDM configures, exposed by the OS to a tool like Intune.

When the MDM’s UI doesn’t let us change these, even if they exist in the OS, we can, in Intune at least, create a custom configuration profile.  In it, we point directly to the OMA-URI and say how we want to configure it.

The OMA-URI for network protection is ./Vendor/MSFT/Policy/Config/Defender/EnableNetworkProtection.  When you configure this as an Integer of value 1, you enable it.  Value 0 disables it. To create a this in Intune, when adding a configuration profile, choose custom, then add a row configured as below.  You don’t need a description, but make sure the OMA-URI is exactly as just stated and the value is 1.

Immediately after the client synced, the value changed to 1 in Get-MpPreference.

When the test website is attempted in a third-party browser (Firefox in my example), it now presents an error code SSL_ERROR_NO_CYPHER_OVERLAP.

Finally, EnableNetworkProtection is now showing as a managed policy in MDMDiagReport (but note it only shows the default value of 0, and the actual value column is not populated – I am not sure why this is the behaviour.  Tamper protection?)