diff --git a/windows/deployment/deploy-enterprise-licenses.md b/windows/deployment/deploy-enterprise-licenses.md index 7542124117..c02e0390cd 100644 --- a/windows/deployment/deploy-enterprise-licenses.md +++ b/windows/deployment/deploy-enterprise-licenses.md @@ -177,7 +177,7 @@ Once Windows Setup finishes, the user is automatically signed in and the device Open the **Accounts** > **Access work or school** pane in the **Settings** app by selecting the following link: > [!div class="nextstepaction"] -> [Activation](ms-settings:workplace) +> [Access work or school](ms-settings:workplace) or @@ -359,6 +359,8 @@ A device is healthy when both the subscription and activation are active. If the slmgr /dlv ``` +For more information on **Slmgr**, see [Slmgr.vbs options for obtaining volume activation information](/windows-server/get-started/activation-slmgr-vbs-options). + ## Troubleshoot the user experience In some instances, users might experience problems with activation of the Windows Enterprise E3 or E5 subscription. The most common problems that users might experience are the following issues: @@ -482,10 +484,6 @@ Use the following guides to verify each one of these requirements: For more information, see [Assigning licenses to users](#assigning-licenses-to-users). -### Delay in the activation of Enterprise license of Windows - -There might be a delay in the activation of the Enterprise license in Windows. This delay is by design. Windows uses a built-in cache when determining upgrade eligibility. This behavior includes processing responses that indicate that the device isn't eligible for an upgrade. It can take up to four days after a qualifying purchase before the upgrade eligibility is enabled and the cache expires. - ## Known issues - If a device isn't able to connect to Windows Update, it can lose activation status or be blocked from upgrading to Windows Enterprise. Make sure that Windows Update isn't blocked on the device: @@ -520,6 +518,10 @@ There might be a delay in the activation of the Enterprise license in Windows. T > > Make sure to first check the group policy of **Do not connect to any Windows Update Internet locations**. If the policy is **Enabled**, then this registry key will eventually be reset back to `1` even after it's manually set to `0` via `reg.exe`. Setting the policy of **Do not connect to any Windows Update Internet locations** to **Disabled** or **Not Configured** will make sure the registry value remains as `0`. +- Delay in the activation of Enterprise license of Windows. + + There might be a delay in the activation of the Enterprise license in Windows. This delay is by design. Windows uses a built-in cache when determining upgrade eligibility. This behavior includes processing responses that indicate that the device isn't eligible for an upgrade. It can take up to four days after a qualifying purchase before the upgrade eligibility is enabled and the cache expires. + ## Virtual Desktop Access (VDA) Subscriptions to Windows Enterprise are also available for virtualized clients. Enterprise E3 and E5 are available for Virtual Desktop Access (VDA) in Azure or in another qualified multitenant host. diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md index d67d35f75a..dd113afcfc 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-device-registration-overview.md @@ -1,7 +1,7 @@ --- title: Device registration overview -description: This article provides an overview on how to register devices in Autopatch -ms.date: 07/25/2023 +description: This article provides an overview on how to register devices in Autopatch. +ms.date: 02/15/2024 ms.service: windows-client ms.subservice: itpro-updates ms.topic: conceptual @@ -25,7 +25,7 @@ The overall device registration process is as follows: :::image type="content" source="../media/windows-autopatch-device-registration-overview.png" alt-text="Overview of the device registration process" lightbox="../media/windows-autopatch-device-registration-overview.png"::: -1. IT admin reviews [Windows Autopatch device registration prerequisites](windows-autopatch-register-devices.md#prerequisites-for-device-registration) prior to register devices with Windows Autopatch. +1. IT admin reviews [Windows Autopatch device registration prerequisites](windows-autopatch-register-devices.md#prerequisites-for-device-registration) before registering devices with Windows Autopatch. 2. IT admin identifies devices to be managed by Windows Autopatch through either adding device-based Microsoft Entra groups as part of the [Custom Autopatch group](../deploy/windows-autopatch-groups-overview.md) or the [Default Autopatch group](../deploy/windows-autopatch-groups-overview.md). 3. Windows Autopatch then: 1. Performs device readiness prior registration (prerequisite checks). @@ -47,8 +47,8 @@ See the following detailed workflow diagram. The diagram covers the Windows Auto | ----- | ----- | | **Step 1: Identify devices** | IT admin identifies devices to be managed by the Windows Autopatch service. | | **Step 2: Add devices** | IT admin adds devices through Direct membership or nests other Microsoft Entra ID assigned or dynamic groups into the **Windows Autopatch Device Registration** Microsoft Entra ID assigned group when using adding existing device-based Microsoft Entra groups while [creating](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#create-a-custom-autopatch-group)/[editing](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) Custom Autopatch groups, or [editing](../deploy/windows-autopatch-groups-manage-autopatch-groups.md#edit-the-default-or-a-custom-autopatch-group) the Default Autopatch group | -| **Step 3: Discover devices** | The Windows Autopatch Discover Devices function discovers devices (hourly) that were previously added by the IT admin into the **Windows Autopatch Device Registration** Microsoft Entra ID assigned group or from Microsoft Entra groups used with Autopatch groups in **step #2**. The Microsoft Entra device ID is used by Windows Autopatch to query device attributes in both Microsoft Intune and Microsoft Entra ID when registering devices into its service.
  1. Once devices are discovered from the Microsoft Entra group, the same function gathers additional device attributes and saves it into its memory during the discovery operation. The following device attributes are gathered from Microsoft Entra ID in this step:
    1. **AzureADDeviceID**
    2. **OperatingSystem**
    3. **DisplayName (Device name)**
    4. **AccountEnabled**
    5. **RegistrationDateTime**
    6. **ApproximateLastSignInDateTime**
  2. In this same step, the Windows Autopatch discover devices function calls another function, the device prerequisite check function. The device prerequisite check function evaluates software-based device-level prerequisites to comply with Windows Autopatch device readiness requirements prior to registration.
| -| **Step 4: Check prerequisites** | The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:
  1. **Serial number, model, and manufacturer.**
    1. Checks if the serial number already exists in the Windows Autopatch's managed device database.
  2. **If the device is Intune-managed or not.**
    1. Windows Autopatch looks to see **if the Microsoft Entra device ID has an Intune device ID associated with it**.
      1. If **yes**, it means this device is enrolled into Intune.
      2. If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.
    2. **If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name and other attributes. When this happens, the Windows Autopatch service uses the Microsoft Entra device attributes gathered and saved to its memory in **step 3a**.
      1. Once it has the device attributes gathered from Microsoft Entra ID in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not registered** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn't enrolled into Intune.
      2. A common reason is when the Microsoft Entra device ID is stale, it doesn't have an Intune device ID associated with it anymore. To remediate, [clean up any stale Microsoft Entra device records from your tenant](windows-autopatch-register-devices.md#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).
    3. **If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.
  3. **If the device is a Windows device or not.**
    1. Windows Autopatch looks to see if the device is a Windows and corporate-owned device.
      1. **If yes**, it means this device can be registered with the service because it's a Windows corporate-owned device.
      2. **If not**, it means the device is a non-Windows device, or it's a Windows device but it's a personal device.
  4. **Windows Autopatch checks the Windows SKU family**. The SKU must be either:
    1. **Enterprise**
    2. **Pro**
    3. **Pro Workstation**
  5. **If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:
    1. **Only managed by Intune.**
      1. If the device is only managed by Intune, the device is marked as Passed all prerequisites.
    2. **Co-managed by both Configuration Manager and Intune.**
      1. If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state. The required co-management workloads evaluated in this step are:
        1. **Windows Updates Policies**
        2. **Device Configuration**
        3. **Office Click to Run**
      2. If Windows Autopatch determines that one of these workloads isn't enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not registered** tab.
| +| **Step 3: Discover devices** | The Windows Autopatch Discover Devices function discovers devices (hourly) that were previously added by the IT admin into the **Windows Autopatch Device Registration** Microsoft Entra ID assigned group or from Microsoft Entra groups used with Autopatch groups in **step #2**. The Microsoft Entra device ID is used by Windows Autopatch to query device attributes in both Microsoft Intune and Microsoft Entra ID when registering devices into its service.
  1. Once devices are discovered from the Microsoft Entra group, the same function gathers additional device attributes and saves it into its memory during the discovery operation. The following device attributes are gathered from Microsoft Entra ID in this step:
    1. **AzureADDeviceID**
    2. **OperatingSystem**
    3. **DisplayName (Device name)**
    4. **AccountEnabled**
    5. **RegistrationDateTime**
    6. **ApproximateLastSignInDateTime**
  2. In this same step, the Windows Autopatch discover devices function calls another function, the device prerequisite check function. The device prerequisite check function evaluates software-based device-level prerequisites to comply with Windows Autopatch device readiness requirements before registration.
| +| **Step 4: Check prerequisites** | The Windows Autopatch prerequisite function makes an Intune Graph API call to sequentially validate device readiness attributes required for the registration process. For detailed information, see the [Detailed prerequisite check workflow diagram](#detailed-prerequisite-check-workflow-diagram) section. The service checks the following device readiness attributes, and/or prerequisites:
  1. **If the device is Intune-managed or not.**
    1. Windows Autopatch looks to see **if the Microsoft Entra device ID has an Intune device ID associated with it**.
      1. If **yes**, it means this device is enrolled into Intune.
      2. If **not**, it means the device isn't enrolled into Intune, hence it can't be managed by the Windows Autopatch service.
    2. **If the device is not managed by Intune**, the Windows Autopatch service can't gather device attributes such as operating system version, Intune enrollment date, device name and other attributes. When this happens, the Windows Autopatch service uses the Microsoft Entra device attributes gathered and saved to its memory in **step 3a**.
      1. Once it has the device attributes gathered from Microsoft Entra ID in **step 3a**, the device is flagged with the **Prerequisite failed** status, then added to the **Not registered** tab so the IT admin can review the reason(s) the device wasn't registered into Windows Autopatch. The IT admin will remediate these devices. In this case, the IT admin should check why the device wasn't enrolled into Intune.
      2. A common reason is when the Microsoft Entra device ID is stale, it doesn't have an Intune device ID associated with it anymore. To remediate, [clean up any stale Microsoft Entra device records from your tenant](windows-autopatch-register-devices.md#clean-up-dual-state-of-hybrid-azure-ad-joined-and-azure-registered-devices-in-your-azure-ad-tenant).
    3. **If the device is managed by Intune**, the Windows Autopatch prerequisite check function continues to the next prerequisite check, which evaluates whether the device has checked into Intune in the last 28 days.
  2. **If the device is a Windows device or not.**
    1. Windows Autopatch looks to see if the device is a Windows and corporate-owned device.
      1. **If yes**, it means this device can be registered with the service because it's a Windows corporate-owned device.
      2. **If not**, it means the device is a non-Windows device, or it's a Windows device but it's a personal device.
  3. **Windows Autopatch checks the Windows SKU family**. The SKU must be either:
    1. **Enterprise**
    2. **Pro**
    3. **Pro Workstation**
  4. **If the device meets the operating system requirements**, Windows Autopatch checks whether the device is either:
    1. **Only managed by Intune.**
      1. If the device is only managed by Intune, the device is marked as Passed all prerequisites.
    2. **Co-managed by both Configuration Manager and Intune.**
      1. If the device is co-managed by both Configuration Manager and Intune, an additional prerequisite check is evaluated to determine if the device satisfies the co-management-enabled workloads required by Windows Autopatch to manage devices in a co-managed state. The required co-management workloads evaluated in this step are:
        1. **Windows Updates Policies**
        2. **Device Configuration**
        3. **Office Click to Run**
      2. If Windows Autopatch determines that one of these workloads isn't enabled on the device, the service marks the device as **Prerequisite failed** and moves the device to the **Not registered** tab.
| | **Step 5: Calculate deployment ring assignment** | Once the device passes all prerequisites described in **step #4**, Windows Autopatch starts its deployment ring assignment calculation. The following logic is used to calculate the Windows Autopatch deployment ring assignment:
  1. If the Windows Autopatch tenant's existing managed device size is **≤ 200**, the deployment ring assignment is **First (5%)**, **Fast (15%)**, remaining devices go to the **Broad ring (80%)**.
  2. If the Windows Autopatch tenant's existing managed device size is **>200**, the deployment ring assignment will be **First (1%)**, **Fast (9%)**, remaining devices go to the **Broad ring (90%)**.
| | **Step 6: Assign devices to a deployment ring group** | Once the deployment ring calculation is done, Windows Autopatch assigns devices to two deployment ring sets, the first one being the service-based deployment ring set represented by the following Microsoft Entra groups:
  1. **Modern Workplace Devices-Windows Autopatch-First**
    1. The Windows Autopatch device registration process doesn't automatically assign devices to the Test ring represented by the Microsoft Entra group (**Modern Workplace Devices-Windows Autopatch-Test**). It's important that you assign devices to the Test ring to validate the update deployments before the updates are deployed to a broader population of devices.
  2. **Modern Workplace Devices-Windows Autopatch-Fast**
  3. **Modern Workplace Devices-Windows Autopatch-Broad**
    4. Then the second deployment ring set, the software updates-based deployment ring set represented by the following Microsoft Entra groups:
| | **Step 7: Assign devices to a Microsoft Entra group** | Windows Autopatch also assigns devices to the following Microsoft Entra groups when certain conditions apply:
  1. **Modern Workplace Devices - All**
    1. This group has all devices managed by Windows Autopatch.
  2. **Modern Workplace Devices - Virtual Machine**
    1. This group has all **virtual devices** managed by Windows Autopatch.
    | diff --git a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md index 43bc24d8c2..27c2f9f084 100644 --- a/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md +++ b/windows/deployment/windows-autopatch/deploy/windows-autopatch-register-devices.md @@ -1,7 +1,7 @@ --- title: Register your devices -description: This article details how to register devices in Autopatch -ms.date: 07/25/2023 +description: This article details how to register devices in Autopatch. +ms.date: 02/15/2024 ms.service: windows-client ms.subservice: itpro-updates ms.topic: how-to @@ -83,7 +83,7 @@ To be eligible for Windows Autopatch management, devices must meet a minimum set - Devices must have Serial Number, Model and Manufacturer. > [!NOTE] -> Windows Autopatch doesn't support device emulators that don't generate the serial number, model and manufacturer information. Devices that use a non-supported device emulator fail the **Intune or Cloud-Attached** prerequisite check. Additionally, devices with duplicated serial numbers will fail to register with Windows Autopatch. +> Windows Autopatch doesn't support device emulators that don't generate the serial number, model and manufacturer information. Devices that use a non-supported device emulator fail the **Intune or Cloud-Attached** prerequisite check. > [!IMPORTANT] > Windows Autopatch supports registering [Windows 10 Long-Term Servicing Channel (LTSC)](/windows/whats-new/ltsc/) devices that are being currently serviced by the [Windows LTSC](/windows/release-health/release-information). The service only supports managing the [Windows quality updates](../operate/windows-autopatch-windows-quality-update-overview.md) workload for devices currently serviced by the LTSC. Windows Update for Business service and Windows Autopatch don't offer Windows feature updates for devices that are part of the LTSC. You must either use [LTSC media](https://www.microsoft.com/evalcenter/evaluate-windows-10-enterprise) or the [Configuration Manager Operating System Deployment capabilities to perform an in-place upgrade](/windows/deployment/deploy-windows-cm/upgrade-to-windows-10-with-configuration-manager) for Windows devices that are part of the LTSC. diff --git a/windows/security/operating-system-security/network-security/windows-firewall/dynamic-keywords.md b/windows/security/operating-system-security/network-security/windows-firewall/dynamic-keywords.md new file mode 100644 index 0000000000..275f7adfa9 --- /dev/null +++ b/windows/security/operating-system-security/network-security/windows-firewall/dynamic-keywords.md @@ -0,0 +1,222 @@ +--- +title: Windows Firewall dynamic keywords +description: Learn about Windows Firewall dynamic keywords and how to configure it using Windows PowerShell. +ms.topic: how-to +ms.date: 01/16/2024 +--- + +# Windows Firewall dynamic keywords + +> [!IMPORTANT] +>This article describes features or settings that are in preview. The content is subject to change and may have dependencies on other features or services in preview. + +Windows Firewall includes a functionality called *dynamic keywords*, which simplifies the configuration and management of Windows Firewall. + +With dynamic keywords, you can define a set of IP address ranges, fully qualified domain names (FQDNs), and **autoresolution** options, to which one or more Firewall rules can refer. + +## Configure dynamic keywords + +To configure dynamic keywords, you can use: + +- [Firewall CSP][CSP-1], which can be used with a Mobile Device Management (MDM) solution like Microsoft Intune +- Windows PowerShell + +> [!TIP] +> Microsoft Intune offers a simplified management experience called *reusable settings groups*. For more information, see [Add reusable settings groups to profiles for Firewall rules][MEM-1]. + +This article describes how to configure dynamic keywords using Windows PowerShell. + +## Dynamic keywords and Fully Qualified Domain Names (FQDN) + +Dynamic keywords can be configured by defining a set of IP address ranges or FQDNs. Here are important things to consider when using FQDNs: + +- FQDN support is for reducing the overhead of managing IP rules where IP addresses are dynamic and change frequently +- FQDNs aren't a replacement for IP addresses in all scenarios. IP addresses should be used when possible, for security and performance reasons + - FQDN rules can affect performance on the endpoint, caused by DNS latency and other factors + - FQDN isn't a secure DNS service. The FQDN resolution uses the default DNS configuration of the endpoint +- An FQDN rule requires a DNS query to happen for that FQDN to be resolved to an IP address. Traffic to IP addresses must generate a DNS query for FQDN rules + - Limitations include: websites accessed via proxy, secure DNS services, certain VPN tunnel configurations, cached IPs on the endpoint +- While Partially Qualified Domain Names (PQDNs) are allowed, FQDNs are preferred. Wildcards `*` are supported for hosts, for example `*.contoso.com` + +Two examples of FQDN rules are: + +- Block all outbound and inbound by default and allow specific outbound traffic +- Block all inbound by default and block some specific outbound traffic + +> [!NOTE] +> Inbound FQDN rules aren't natively supported. However, it's possible to use *pre-hydration* scripts to generate inbound IP entries for the rules. + +> [!CAUTION] +> The default configuration of *Blocked for Outbound* rules can be considered for certain highly secure environments. However, the *Inbound* rule configuration should never be changed in a way that allows traffic by default. + +In high security environments, an inventory of all apps should be maintained. Records should include whether an app requires network connectivity. Administrators should create new rules specific to each app that needs network connectivity, and push those rules centrally, using a device management solution. + +### Functions and known limitations + +The Windows Firewall FQDN feature uses the Network Protection external callout driver, to inspect DNS responses where the DNS query matches FQDN rules. Some important functions and limitations of the feature are: + +- The Network Protection component doesn't periodically execute DNS queries. It requires an application to execute a DNS query +- Windows Firewall flushes all stored resolved IP addresses on device restart +- Network protection doesn't synchronously inspect the DNS response, as it doesn't hold the UDP packet during inspection. The result is a potential condition where an application, after receiving the DNS response, attempts to connect, but gets blocked if it's faster than the firewall rule update + - Generally, applications have retry logic for an initial failed connection and as a result the issue is transparent to the end user + - On occasion a component might not have retry logic on initial connection fail. Which is solved in two ways: + - The user can hit *refresh* in the application they're using, and it should connect successfully + - Administrators can use the *prehydration* scripts tactfully, where this condition is occurring in their environment + +### FQDN Feature requirements + +The following are requirements for the FQDN feature: + +- Microsoft Defender Antivirus must be turned on and running platform version `4.18.2209.7` or later. + - To verify, open [Windows Security](windowsdefender://) and select **Settings** > **About** +- Network Protection must be in *block* or *audit* mode. For more information, see [Check if network protection is enabled][M365-1]. +- DNS over HTTPS (DoH) must be disabled. To configure your preferred browser, you can use the following settings: + - [Microsoft Edge][EDGE-1] + - [Chrome][HTTP-1] + - [Firefox][HTTP-2] +- The device's default DNS resolution settings apply. This feature doesn't provide DNS security or functionality changes + > [!TIP] + > You can also download the ADMX file from there, follow the directions, and configure it via gpedit.msc for local testing. + +## Manage dynamic keywords with Windows PowerShell + +This section provides some examples how to manage dynamic keywords using Windows PowerShell. A few important things to consider when using dynamic keywords are: + +- All dynamic keyword objects must have a unique identifier (GUID) to represent them +- A firewall rule can use dynamic keywords instead of explicitly defining IP addresses for its conditions +- A firewall rule can use both dynamic keywords and statically defined address ranges +- A dynamic keyword object can be reused across multiple firewall rules +- If a firewall rule doesn't have any configured remote addresses, then the rule isn't enforced. For example, if a rule is configured with only `AutoResolve` objects that aren't yet resolved +- If a rule uses multiple dynamic keywords, then the rule is enforced for all addresses that are *currently* resolved. The rule is enforced even if there are unresolved objects. When a dynamic keyword address is updated, all associated rule objects have their remote addresses updated +- Windows doesn't enforce any dependencies between a rule and a dynamic keyword address, and either object can be created first. A rule can reference dynamic keyword IDs that don't yet exist, in which case the rule isn't enforced +- You can delete a dynamic keyword address, even if it's in use by a firewall rule + +### Allow Outbound + +Here's an example script to allow an FQDN from PowerShell. Replace the `$fqdn` variable value with the FQDN you wish to block (line #1): + +```PowerShell +$fqdn = 'contoso.com' +$id = '{' + (new-guid).ToString() + '}' +New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true +New-NetFirewallRule -DisplayName "allow $fqdn" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id +``` + +Dynamic keyword addresses can be created with the `AutoResolve` parameter set to `$true` or `$false`. If `AutoResolve` is set to `$true`, then Windows attempts to resolve the keyword to an IP address. + +### Block Outbound + +Here's an example script to block an FQDN from PowerShell. Replace the `$fqdn` variable value with the FQDN you wish to block (line #1): + +```PowerShell +$fqdn = 'contoso.com' +$id = '{' + (new-guid).ToString() + '}' +New-NetFirewallDynamicKeywordAddress -id $id -Keyword $fqdn -AutoResolve $true +New-NetFirewallRule -DisplayName "block $fqdn" -Action Block -Direction Outbound -RemoteDynamicKeywordAddresses $id +``` + +### Display Auto resolve rules and associated resolved IP addresses + +This example shows how to display all dynamic keyword addresses that have the `AutoResolve` parameter set to `$true` and the associated resolved IP addresses. + +```PowerShell +Get-NetFirewallDynamicKeywordAddress -AllAutoResolve +``` + +> [!NOTE] +> IP addresses will not populate until DNS query is observed. + +### Hydrate FQDN rules + +The following sample scripts read the current Windows Firewall configuration, extract FQDN-based rules, and perform DNS resolution on each domain. The result is that the IP addresses for those rules get "prehydrated." + +```PowerShell +Get-NetFirewallDynamicKeywordAddress -AllAutoResolve |` +ForEach-Object { + if(!$_.Keyword.Contains("*")) { + Write-Host "Getting" $_.Keyword + resolve-dnsname -Name $_.Keyword -DNSOnly | out-null + } +} +``` + +A similar script can be used to perform DNS resolution using `nslookup.exe`: + +```PowerShell +Get-NetFirewallDynamicKeywordAddress -AllAutoResolve |` +ForEach-Object { + if(!$_.Keyword.Contains("*")) { + Write-Host "Getting" $_.Keyword + nslookup $_.Keyword + } +} +``` + +If using `nslookup.exe`, you must create an outbound firewall rule when using the *block all outbound* posture. Here's the command to create the outbound rule for `nslookup.exe`: + +```PowerShell +$appName = 'nslookup' +$appPath = 'C:\Windows\System32\nslookup.exe' +New-NetFirewallRule -DisplayName "allow $appName" -Program $appPath -Action Allow -Direction Outbound -Protocol UDP -RemotePort 53 +``` + +### Block all outbound and allow some FQDNs + +In the next example, a list of applications is parsed for FQDN evaluation. The FQDNs listed in the scripts were observed when inspecting traffic on the first launch of Microsoft Edge. + +> [!IMPORTANT] +> This is not a complete list nor a recommendation. It's an example of how an application should be evaluated to ensure proper connectivity and function. + +To learn more about Microsoft Edge requirements for Internet connectivity, see [allowlist for Microsoft Edge endpoints][EDGE-4]. + +```PowerShell +$domains = @( + '*.microsoft.com', + '*.msftconnecttest.com', + 'assets.msn.com', + 'client.wns.windows.com', + 'config.edge.skype.com', + 'ctldl.windowsupdate.com', + 'dns.msftncsi.com', + 'login.live.com', + 'ntp.msn.com' +) + +foreach ($domain in $domains) { + $id = '{' + (New-Guid).ToString() + '}' + New-NetFirewallDynamicKeywordAddress -Id $id -Keyword $domain -AutoResolve $true + New-NetFirewallRule -DisplayName "allow $domain" -Action Allow -Direction Outbound -RemoteDynamicKeywordAddresses $id +} +``` + +For more information about the PowerShell cmdlets used to manage dynamic keywords, see: + +- [Get-NetFirewallDynamicKeywordAddress][PS-1] +- [New-NetFirewallDynamicKeywordAddress][PS-2] +- [Remove-NetFirewallDynamicKeywordAddress][PS-3] +- [Update-NetFirewallDynamicKeywordAddress][PS-4] + +For information about the API structure, see [Firewall dynamic keywords][WIN-1]. + + + +[CSP-1]: /windows/client-management/mdm/firewall-csp + +[EDGE-1]: /deployedge/microsoft-edge-policies#control-the-mode-of-dns-over-https +[EDGE-2]: /deployedge/microsoft-edge-policies#builtindnsclientenabled +[EDGE-3]: /deployedge/configure-microsoft-edge +[EDGE-4]: /deployedge/microsoft-edge-security-endpoints + +[HTTP-1]: https://chromeenterprise.google/policies?policy=DnsOverHttpsMode +[HTTP-2]: https://support.mozilla.org/kb/firefox-dns-over-https + +[M365-1]: /microsoft-365/security/defender-endpoint/enable-network-protection#check-if-network-protection-is-enabled + +[MEM-1]: /mem/intune/protect/endpoint-security-firewall-policy#add-reusable-settings-groups-to-profiles-for-firewall-rules + +[PS-1]: /powershell/module/netsecurity/get-netfirewalldynamickeywordaddress +[PS-2]: /powershell/module/netsecurity/new-netfirewalldynamickeywordaddress +[PS-3]: /powershell/module/netsecurity/remove-netfirewalldynamickeywordaddress +[PS-4]: /powershell/module/netsecurity/update-netfirewalldynamickeywordaddress + +[WIN-1]: /windows/win32/ics/firewall-dynamic-keywords diff --git a/windows/security/operating-system-security/network-security/windows-firewall/toc.yml b/windows/security/operating-system-security/network-security/windows-firewall/toc.yml index b566dce388..f856de3ef6 100644 --- a/windows/security/operating-system-security/network-security/windows-firewall/toc.yml +++ b/windows/security/operating-system-security/network-security/windows-firewall/toc.yml @@ -13,6 +13,8 @@ items: href: configure.md - name: Configure with command line tools href: configure-with-command-line.md + - name: Dynamic keywords + href: dynamic-keywords.md - name: Hyper-V firewall href: hyper-v-firewall.md - name: Troubleshoot