WebView2 and Defender firewall rules

[dmills488]

Our enterprise endpoints are completely locked down using Defender Firewall Intune policy. No traffic is allowed out unless explicitly specified in policy.

We need to allow C:\Program Files (x86)\Microsoft\EdgeWebView\Application\112.0.1722.58\msedgewebview2.exe out to external destinations.

However, the filepath of the executable changes whenever WebView2 is upgraded.
Defender Firewall policy does not support wildcards.

How can we allow WebView2 out in our Defender Intune policy?

[Danielx64]

Just a shot in the dark, is it possible to whitelist anything that is signed by Microsoft?

[Danielx64]

Other option is to bundle your own version of webview2 with the app you are creating.

[dmills488]

Whitelisting anything signed by Microsoft is not an option. It needs to be limited to just WebView2, even that is opening up more than we would really like.

We are using third party applications (Cisco AnyConnect, Zscaler Client Connector, etc) that use WebView2 as an embedded browser to do SAML authentication with Azure. Firewall logs show the "native/pre-installed" WebView2 making the calls out to Azure.

In previous versions of these apps, where the legacy IE11 embedded browser was being used, we would see the call coming from the actual third party application. It doesn't seem like this is the case now with WebView2 and any of the third party vendors we've seen.

[Danielx64]

Ahhh right, this is going to be a fun one. From a developer side of things, there is an option to bundle a fixed version of webview2 (https://learn.microsoft.com/en-us/microsoft-edge/webview2/concepts/distribution#the-fixed-version-runtime-distribution-mode), only issue is getting vendors to create, test and release a package to address this edge case.

[Danielx64]

@novac42 is someone going to answer this one for the OP?

[srwei]

@dmills488 There are two things you can try.
The first is to utilize WDAC tagging and create a policy to include an attribute for the wv2.exe, then it can be read from Firewall to allow traffic. I believe WDAC tagging allows for the use of wildcards if it's in the beginning or end of the path, so you could set the path as *\msedgewebview2.exe. Here are some documents on how to achieve this: https://techcommunity.microsoft.com/t5/intune-customer-success/new-settings-in-microsoft-intune-to-enhance-windows-defender/ba-p/3803857
https://learn.microsoft.com/en-us/windows/security/threat-protection/windows-defender-application-control/appidtagging/windows-defender-application-control-appid-tagging-guide

Otherwise, like @Danielx64 mentioned, there is an option to use our Fixed Version.

[rookieerror]

@dmills488 did you ever manage to sort this issue? having the same problem at the moment with ZScaler and Defender

[Matchew218]

@dmills488 @rookieerror did you ever find a solution? Im in the same situation trying to migrate to SAML auth. I have another way which is to use the default browser but this comes with its own challenges as I have to add a firewall rule to allow chrome out on all firewall profiles but this means if a user drops onto the secure client mgmt tunnel it allows them to browse the internet freely. We enforce always on vpn and Windows firewall to block everything unless connected to the vpn/domain profile.

Embedded browser would be perfect for this, if it wasnt for the issue with the webview2 not having a static path. I tried to download the runtime and see if that would install to a fixed path but cisco secure client always calls the one in the version folder.

[rookieerror]

@dmills488 @rookieerror did you ever find a solution? Im in the same situation trying to migrate to SAML auth. I have another way which is to use the default browser but this comes with its own challenges as I have to add a firewall rule to allow chrome out on all firewall profiles but this means if a user drops onto the secure client mgmt tunnel it allows them to browse the internet freely. We enforce always on vpn and Windows firewall to block everything unless connected to the vpn/domain profile.

Embedded browser would be perfect for this, if it wasnt for the issue with the webview2 not having a static path. I tried to download the runtime and see if that would install to a fixed path but cisco secure client always calls the one in the version folder.

I ended up creating an Intune remediation script which checks for the version of WebView2 installed and then creates a firewall rule using that version number in the path

[Matchew218]

@rookieerror how does it work if the user has no access to intune unless connected to the vpn? Assuming your clients always have access to intune.
Are you willing to share the script?

Kind regards
M

[rookieerror]

Script was something like this:

$directoryPath = "C:\Program Files (x86)\Microsoft\EdgeWebView\Application"

$subfolders = Get-ChildItem -Path $directoryPath -Directory

$pattern = '^\d+.\d+.\d+.\d+$'
$matchingSubfolders = $subfolders | Where-Object { $_.Name -match $pattern }

$highestVersionFolder = $matchingSubfolders | Sort-Object { [version]$_.Name } -Descending | Select-Object -First 1

$newDirectoryPath = "$directoryPath$($highestVersionFolder.Name)"

$exePath = "$newDirectoryPath\MSEdgeWebView2.exe"

$displayName = "Allow MSEdgeWebView2 Outbound - Version $($highestVersionFolder.Name)"

New-NetFirewallRule -DisplayName $displayName -Direction Outbound -Program $exePath -PolicyStore MDM -Profile Any -Action Allow

"Firewall rule created with display name: '$displayName' to allow $exePath in outbound direction."

[Matchew218]

@rookieerror top work, thank you