Automatically switching the Windows Firewall profile on Azure AD joined devices

This new year starts with short blog post about another nice configuration addition to Windows. Starting with the latest release of Windows 11, it’s now possible to make the Windows Firewall aware of the location of the device. That maybe sounds a bit more than what it actually is. The idea is that it enables Windows to check if it’s on a domain connected network, based on the accessibility of one or more URLs. When one of the URLs is available, Windows will switch the Windows Firewall profile to domain. When none of the URLs are available, Windows will work how it always worked and in general simply rely on the public profile. That behavior enables IT administrators to configure specific firewall exclusions, only when domain connected. Something that can be useful for specific apps that still have an on-premises presence. This post will start with a short introduction about the new settings that are available for this configuration, followed with the steps to actually configure those settings. This post will end with showing the behavior after applying the configuration.

Note: With the latest December updates to Windows 10 and Windows 11, this functionality should be available for all versions of Windows. This functionality does require the Enterprise edition of Windows.

Introducing the Network List Manager configuration options

The intelligence to make the Windows Firewall aware of the location of the device is available within the NetworkListManager node in the Policy CSP. That node contains the settings to configure URLs of TLS authentication endpoints. When Windows can resolve those URLs over HTTPS, the network will be considered as authenticated. That will make sure that the Windows Firewall profile will switch to the domain profile. The table below provides an overview of the new settings in the Policy CSP and how those settings should be used. The root node for all the mentioned settings is ./Device/Vendor/MSFT/Policy/Config/NetworkListManager/.

Value: A string with one or more TLS endpoints.
This policy setting controls the list of URLs to endpoints that are only accessible within the corporate network. Multiple URLs can be separated by using the unicode character 0xF000. When any of the URLs can be resolved over HTTPS, the network will be considered authenticated.
Value: A string with a name.
This policy setting controls the string that is to be used to name the authenticated network. That network is authenticated against one of the endpoints that are listed in AllowedTlsAuthenticationEndpoints setting.

When looking at a bit more details about the TLS authentication endpoint, there are a few important things to keep in mind. The endpoint must not have any authentication checks (no login, or MFA), the endpoint must be an internal address (not accessible outside the corporate network), the client device must trust the server certificate (trusted root certificate), and the certificate shouldn’t be a public certificate.

Note: When the network name setting is used for the trusted network detection in an Always On VPN profile, the name must be the DNS suffix that is configured in the TrustedNetworkDetection attribute.

Configuring the Network List Manager configuration options

When looking at the actual configuration of these new settings in the Policy CSP, and using Microsoft Intune for the configuration, the configuration is actually pretty straight forward. In the future it will probably even become easier. For now, the configuration will still rely on using a custom device configuration profile. The following nine steps walk through the creation of that custom device configuration profile, with the settings to configure the TLS authentication endpoints. That endpoint should only be available within the corporate network, and the certificate should be trusted by the client.

  1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices Windows > Configuration profiles
  2. On the Windows | Configuration profiles blade, click Create profile
  3. On the Create a profile blade, provide the following information and click Create
  • Platform: Select Windows 10 and later as the platform for the configuration profile
  • Profile type: Select Templates as the profile type for the configuration profile
  • Template name: Select Custom as the template name for the configuration profile
  1. On the Basics page, specify a valid Name and optionaly a Description and click Next
  2. On the Configuration settings page (see Figure 1), click Add to add rows for the following custom settings and click Next
  • OMA-URI setting 1 – This setting is used to configure the different TLS endpoints for the authenticated network
    • Name: Provide a name for the OMA-URI setting to distinguish it from other similar settings
    • Description: (Optional) Provide a description for the OMA-URI setting to further differentiate settings
    • OMA-URI: Specify ./Device/Vendor/MSFT/Policy/Config/NetworkListManager/AllowedTlsAuthenticationEndpoints
    • Data type: Select String as data type for the configuration of the value of the setting
    • Value: Specify as value to configure an internal endpoint
  • OMA-URI setting 2 – This setting is used to set a name for the authenticated network
    • Name (1): Provide a name for the OMA-URI setting to distinguish it from other similar settings
    • Description: (Optional) Provide a description for the OMA-URI setting to further differentiate settings
    • OMA-URI (2): Specify ./Device/Vendor/MSFT/Policy/Config/NetworkListManager/ConfiguredTLSAuthenticationNetworkName 
    • Data type (3): Select String as data type for the configuration of the value of the setting
    • Value (4): Specify Intern as value to set a name for the internal authenticated network

Note: Make sure to adjust the URL to a TLS authentication endpoint that exists on your corporate network.

  1. On the Scope tags page, configure the required scope tags click Next
  2. On the Assignments page, configure the required assignment and click Next
  3. On the Applicability rules page, configure the required applicability rules and click Next
  4. On the Review + create page, verify the configuration and click Create

Note: At some point in time these settings might become directly available within Microsoft Intune.

Experiencing the Windows Firewall profile switch

Once the configuration is applied, it’s actually quite simple to experience the behavior of the Windows Firewall switching the active profile. Simply get a Windows device, turn it on, and connect it to the corporate network. Below in Figure 2 is an overview of a Windows device that can check the availability of the specified URL (see Name and NetworkCategory), and switched the active profile of the Windows Firewall to Domain network.

Note: For the expected behavior it’s important that the certificate used on the TLS authentication endpoint is trusted on the Windows device. That can be achieved by distributing the root certificate, by using Microsoft Intune.

More information

For more information about configuring the Network List Manager policies, refer to the following docs.

8 thoughts on “Automatically switching the Windows Firewall profile on Azure AD joined devices”

  1. Happy to finally see a blog post on this feature but it’s missing the part I was questioning – do I just setup a basic IIS site with a cert for the endpoint or is there another way (easier?).

    • I had tested it during February and it indeed worked in Windows 10 with 2023-02 CU.

      On 31/3/23, Microsoft revised their requirements for “Policy CSP – NetworkListManager”:
      ✔️ Windows 10, version 2009 [10.0.19042] and later

      So, it is official. It will work in Windows 10 2009 and later


Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.