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/.

SettingDescription
AllowedTlsAuthenticationEndpoints
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.
ConfiguredTLSAuthenticationNetworkName
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 https://internaladdress.corp.petervanderwoude.nl 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.

26 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?).

    Reply
    • 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

      Reply
  2. Hi Peter,

    I am a little bit confused about this note in you text:

    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.

    I’ve configured the URI https://nls.ssc.local as an AllowedTlsAuthenticationEndpoints. What value do I need to configure in my VPN profile for Trusted Network Detection suffix?

    And how does this relate to the ConfiguredTLSAuthenticationNetworkName setting?

    Reply
  3. Hi Peter, can you give advice how i can to set up a better firewall management – Switching between Guest and Domain/Private?advice and tips will be appreciated

    Reply
  4. doesn’t work for me 🙁
    I set it up with one internal server which also has a cert from our internal CA which is in trusted root certs of the device.
    If I
    Invoke-WebRequest -Uri https://server.fqdn.tld -Method get -UseBasicParsing -MaximumRedirection 0
    I get a 200 in return. Profile remains public.
    I also added a second server which is internal but has an actual publicly valid certificate. If I Invoke-Webrequest, I get a 302 but it is resolvable (which is said to be the criteria). But the profile remains public.
    Latest Win11 (22H2, 2023-09 Update)
    Any ideas?

    Reply
      • “funny” thing… I’m still on this problem, followed a new rabbit hole and came back here again.

        In the meantime, I got also different answers to my problem.
        Some say, switching to domain profile only works, if the device is actually domain joined. Others say, this is the solution for entra only devices.
        So who is right?
        And even IF this is only working for actually domain joined devices, what is the solution to detect a private network then? Well.. this was the question I followed this time to get here.

        My device are Entra only/autopiloted

        To your question: yes, both are only available on the internal network. The names aren’t even resolved on public DNS

        Maybe something I’m getting wrong: What does “When any of the URLs can be resolved over HTTPS” mean? It’s resolved over DNS but accessible over HTTPS. Or does this feature actually require DNS over HTTPS resolution?
        Then this might be my next rabbit hole, as network team said, they enabled DoH, but it pretty much looks like it’s not working…

        Reply
      • it works now. I tried several different internal servers some of them even share the very same wildcard cert. all returned http 200.
        One of them works, all others don’t
        I have no idea why…

        Reply
  5. Our testing suggests the functionality is bugged. When switching between cable and wifi for instance, we sometimes see Get-NetConnectionProfile reporting “DomainAuthenticated” whilst the Windows Firewall is using “Public Profile”. This has been the case from Win 10.0.19042 up to 10.0.22631.2428.

    Reply
    • can absolutely confirm this
      Powershell says “DomainAuthenticated”
      Firewall is in public profile (it really is, Ports are closed. It’s not a visual glitch)
      Windows 11 22H2 GUI says private profile
      Reboot -> everything is fine

      (this might be one of the reasons why I thought it isn’t working at all)

      Reply
  6. Very helpful post thank you. Do you know how often the devices query’s the website to validate that it’s connected to a trusted network? As I journey down the cloud only join want to make sure I size the web server resource to support the hits. Is this one of those things that a minimal spec’d server (or multi servers for redundancy)could support thousands of devices?

    Reply
  7. I tried using it on a windows pro machine w/ a user logged in with business premium license hoping it might still work but it seems it is in fact limited to enterprise.

    Anyone know of another solution for business premium licenses?

    Reply

Leave a Comment

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