Merge pull request #3417 from MicrosoftDocs/repo_sync_working_branch

Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/defender-docs (branch public)

Author: Ruchika-mittal01

defender-endpoint/configure-endpoints-gp.md

@@ -1,5 +1,5 @@
 ---
-title: Onboard Windows devices to Microsoft Defender for Endpoint via Group Policy
+title: Onboard Windows Servers to Microsoft Defender for Endpoint via Group Policy
 description: Use Group Policy to deploy the configuration package on Windows devices so that they are onboarded to the service.
 ms.service: defender-endpoint
 ms.author: deniseb

defender-endpoint/configure-endpoints-script.md

@@ -1,5 +1,5 @@
 ---
-title: Onboard Windows devices using a local script
+title: Onboard Windows Servers using a local script
 description: Use a local script to deploy the configuration package on devices to enable onboarding of the devices to the service.
 search.appverid: met150
 ms.service: defender-endpoint

defender-endpoint/indicator-ip-domain.md

@@ -1,6 +1,6 @@
 ---
 title: Create indicators for IPs and URLs/domains
-ms.reviewer: thdoucet
+ms.reviewer: ericlaw
 description: Create indicators for IPs and URLs/domains that define the detection, prevention, and exclusion of entities.
 ms.service: defender-endpoint
 ms.author: deniseb
@@ -15,7 +15,7 @@ ms.collection:
 ms.topic: conceptual
 ms.subservice: 
 search.appverid: met150
-ms.date: 03/04/2025
+ms.date: 04/08/2025
 ---
 
 # Create indicators for IPs and URLs/domains
@@ -31,17 +31,14 @@ ms.date: 03/04/2025
 
 By creating indicators for IPs and URLs or domains, you can now allow or block IPs, URLs, or domains based on your own threat intelligence. You can also warn users if they open a risky app. The prompt doesn't stop them from using the app; users can bypass the warning and continue to use the app if needed.
 
-To block malicious IPs/URLs (as determined by Microsoft), Defender for Endpoint can use:
+To block malicious IPs/URLs, Defender for Endpoint can use:
 
 - Windows Defender SmartScreen for Microsoft browsers
-- Network protection for non-Microsoft browsers, or calls made outside of a browser
+- Network protection for non-Microsoft browsers and non-browser processes
 
-The threat-intelligence data set to block malicious IPs/URLs is managed by Microsoft.
+The default threat-intelligence data set to block malicious IPs/URLs is managed by Microsoft.
 
-You can block malicious IPs/URLs through the settings page or by machine groups, if you deem certain groups to be more or less at risk than others.
-
-> [!NOTE]
-> Classless Inter-Domain Routing (CIDR) notation for IP addresses is not supported.
+You can block additional malicious IPs/URLs by configuring "**Custom network indicators**".
 
 ### Supported operating systems
 
@@ -62,14 +59,15 @@ You can block malicious IPs/URLs through the settings page or by machine groups,
 It's important to understand the following prerequisites before creating indicators for IPs, URLs, or domains.
 
 ### Microsoft Defender Antivirus version requirements
+Integration into Microsoft browsers is controlled by the browser's SmartScreen setting. For other browsers and applications, your organization must have:
 
-- Your organization uses [Microsoft Defender Antivirus](/defender-endpoint/microsoft-defender-antivirus-windows). Microsoft Defender Antivirus must be in active mode for non-Microsoft browsers. With Microsoft browsers, like Microsoft Edge, Microsoft Defender Antivirus can be in active or passive mode.
+- [Microsoft Defender Antivirus](/defender-endpoint/microsoft-defender-antivirus-windows) configured in active mode.
 
-- [Behavior Monitoring](/defender-endpoint/behavior-monitor) is enabled.
+- [Behavior Monitoring](/defender-endpoint/behavior-monitor) enabled.
 
-- [Cloud-based protection](/windows/security/threat-protection/microsoft-defender-antivirus/deploy-manage-report-microsoft-defender-antivirus) is turned on.
+- [Cloud-based protection](/windows/security/threat-protection/microsoft-defender-antivirus/deploy-manage-report-microsoft-defender-antivirus) turned on.
 
-- [Cloud Protection network connectivity](/defender-endpoint/configure-network-connections-microsoft-defender-antivirus) is turned on.
+- [Cloud Protection network connectivity](/defender-endpoint/configure-network-connections-microsoft-defender-antivirus).
 
 - The anti-malware client version must be `4.18.1906.x` or later. See [Monthly platform and engine versions](/defender-endpoint/microsoft-defender-antivirus-updates).
 
@@ -79,41 +77,39 @@ URL/IP allow and block requires that the Microsoft Defender for Endpoint compone
 
 ### Custom network indicators requirements
 
-To start blocking IP addresses and/or URLs, turn on "**Custom network indicators"** feature in the [Microsoft Defender portal](https://security.microsoft.com), go to **Settings** > **Endpoints** > **General** > **Advanced features**. For more information, see [Advanced features](advanced-features.md).
+To start blocking IP addresses and/or URLs, turn on the "**Custom network indicators**" feature in the [Microsoft Defender portal](https://security.microsoft.com). The feature is found in **Settings** > **Endpoints** > **General** > **Advanced features**. For more information, see [Advanced features](advanced-features.md).
 
 For support of indicators on iOS, see [Microsoft Defender for Endpoint on iOS](ios-configure-features.md#configure-custom-indicators).
 
 For support of indicators on Android, see [Microsoft Defender for Endpoint on Android](android-configure.md#configure-custom-indicators).
 
 ### Indicator list limitations
 
-Only external IPs can be added to the indicator list. Indicators can't be created for internal IPs. For web protection scenarios, we recommend using the built-in capabilities in Microsoft Edge. Microsoft Edge uses [Network Protection](network-protection.md) to inspect network traffic and allows blocks for TCP, HTTP, and HTTPS (TLS).
+Only external IPs can be added to the indicator list; indicators cannot be created for internal IPs.
 
 ### Non Microsoft Edge and Internet Explorer processes
 
 For processes other than Microsoft Edge and Internet Explorer, web protection scenarios use Network Protection for inspection and enforcement:
 
-- IP is supported for all three protocols (TCP, HTTP, and HTTPS (TLS))
+- IP addresses are supported for all three protocols (TCP, HTTP, and HTTPS (TLS))
 - Only single IP addresses are supported (no CIDR blocks or IP ranges) in custom indicators
-- Encrypted URLs (full path) can only be blocked on first party browsers (Internet Explorer or Microsoft Edge)
-- Encrypted URLs (FQDN only) can be blocked in non-Microsoft browsers (that is, other than Internet Explorer or Microsoft Edge)
-- URLs loaded via HTTP connection coalescing, such as content loaded by modern CDNs, can only be blocked on first party browsers (Internet Explorer, Microsoft Edge), unless the CDN URL itself is added to the indicator list.
-- Full URL path blocks can be applied for unencrypted URLs
+- HTTP URLs (including a full URL path) can be blocked for any browser or process
+- HTTPS fully-qualified domain names (FQDN) can be blocked in non-Microsoft browsers (indicators specifying a full URL path can only be blocked in Microsoft Edge)
+- Blocking FQDNs in non-Microsoft browsers requires that QUIC and Encrypted Client Hello be disabled in those browsers 
+- FQDNs loaded via HTTP2 connection coalescing can only be blocked in Microsoft Edge
 - If there are conflicting URL indicator policies, the longer path is applied. For example, the URL indicator policy `https://support.microsoft.com/office` takes precedence over the URL indicator policy `https://support.microsoft.com`.
-- If URL indicator policy conflicts occur, the longer path might not be applied due to redirection. In such cases, register a non-redirected URL.
 
-> [!NOTE]
-> Custom Indicators of Compromise and Web Content Filtering features are currently not supported in Application Guard sessions of Microsoft Edge. These containerized browser sessions can only enforce web threat blocks via the built-in SmartScreen protection. They can't enforce any enterprise web protection policies.
+## Network protection implementation
 
-## Network protection and the TCP three-way handshake
+In non-Microsoft Edge processes, Network Protection determines the fully qualified domain name for each HTTPS connection by examining the content of the TLS handshake that occurs after a TCP/IP handshake. This requires that the HTTPS connection use TCP/IP (not UDP/QUIC) and that the ClientHello message not be encrypted. To disable QUIC and Encrypted Client Hello in Google Chrome, see [QuicAllowed](https://chromeenterprise.google/policies/#QuicAllowed) and [EncryptedClientHelloEnabled](https://chromeenterprise.google/policies/#EncryptedClientHelloEnabled). For Mozilla Firefox, see [Disable EncryptedClientHello](https://mozilla.github.io/policy-templates/#disableencryptedclienthello) and [network.http.http3.enable](https://support.mozilla.org/ml/questions/1408003#answer-1571474).
 
-With network protection, the determination of whether to allow or block access to a site is made after the completion of the [three-way handshake via TCP/IP](/troubleshoot/windows-server/networking/three-way-handshake-via-tcpip). Thus, when a site is blocked by network protection, you might see an action type of `ConnectionSuccess` under `NetworkConnectionEvents` in the Microsoft Defender portal, even though the site was blocked. `NetworkConnectionEvents` are reported from the TCP layer, and not from network protection. After the three-way handshake has completed, access to the site is allowed or blocked by network protection.
+The determination of whether to allow or block access to a site is made after the completion of the [three-way handshake via TCP/IP](/troubleshoot/windows-server/networking/three-way-handshake-via-tcpip) and any TLS handshake. Thus, when a site is blocked by network protection, you might see an action type of `ConnectionSuccess` under `NetworkConnectionEvents` in the Microsoft Defender portal, even though the site was blocked. `NetworkConnectionEvents` are reported from the TCP layer, and not from network protection. After the three-way handshake has completed, access to the site is allowed or blocked by network protection.
 
 Here's an example of how that works:
 
 1. Suppose that a user attempts to access a website on their device. The site happens to be hosted on a dangerous domain, and it should be blocked by network protection.  
 
-2. The three-way handshake via TCP/IP commences. Before it completes, a `NetworkConnectionEvents` action is logged, and its `ActionType` is listed as `ConnectionSuccess`. However, as soon as the three-way handshake process completes, network protection blocks access to the site. All of this happens quickly. A similar process occurs with [Microsoft Defender SmartScreen](/windows/security/threat-protection/microsoft-defender-smartscreen/microsoft-defender-smartscreen-overview); it's when the three-way handshake completes that a determination is made, and access to a site is either blocked or allowed.
+2. The TCP/IP handshake commences. Before it completes, a `NetworkConnectionEvents` action is logged, and its `ActionType` is listed as `ConnectionSuccess`. However, as soon as the TCP/IP handshake process completes, network protection blocks access to the site. All of this happens quickly. A similar process occurs with [Microsoft Defender SmartScreen](/windows/security/threat-protection/microsoft-defender-smartscreen/microsoft-defender-smartscreen-overview); it's after the handshake completes that a determination is made, and access to a site is either blocked or allowed.
 
 3. In the Microsoft Defender portal, an alert is listed in the [alerts queue](alerts-queue.md). Details of that alert include both `NetworkConnectionEvents` and `AlertEvents`. You can see that the site was blocked, even though you also have a `NetworkConnectionEvents` item with the ActionType of `ConnectionSuccess`.
 
@@ -136,9 +132,9 @@ For more information, see [Govern apps discovered by Microsoft Defender for Endp
 
 ## Indicator IP URL and domain policy conflict handling order
 
-Policy conflict handling for domains/URLs/IP addresses differ from policy conflict handling for certs.
+Policy conflict handling for domains/URLs/IP addresses differ from policy conflict handling for certificates.
 
-In the case where multiple different action types are set on the same indicator (for example, **block**,  **warn**, and **allow**,  action types set for Microsoft.com), the order those action types would take effect is:
+In the case where multiple different action types are set on the same indicator (for example, three indicators for Microsoft.com with the action types **block**,  **warn**, and **allow**), the order those action types would take effect is:
 
 1. Allow
 
@@ -150,11 +146,11 @@ In the case where multiple different action types are set on the same indicator
 
 ### Defender for Cloud Apps Indicators
 
-If your organization has enabled integration between Defender for Endpoint and Defender for Cloud Apps, block indicators are created in Defender for Endpoint for all unsanctioned cloud applications. If an application is put in monitor mode, warn indicators (bypassable block) are created for the URLs associated with the application. Allow indicators can't be created for sanctioned applications at this time. Indicators created by Defender for Cloud Apps follow the same policy conflict handling described in the previous section.
+If your organization has enabled integration between Defender for Endpoint and Defender for Cloud Apps, block indicators are created in Defender for Endpoint for all unsanctioned cloud applications. If an application is put in monitor mode, warn indicators (bypassable block) are created for the URLs associated with the application. Allow indicators are not automatically created for sanctioned applications. Indicators created by Defender for Cloud Apps follow the same policy conflict handling described in the previous section.
 
 ## Policy precedence
 
-Microsoft Defender for Endpoint policy has precedence over Microsoft Defender Antivirus policy. In situations when Defender for Endpoint is set to `Allow`, but Microsoft Defender Antivirus is set to `Block`, the policy defaults to `Allow`.
+Microsoft Defender for Endpoint policy has precedence over Microsoft Defender Antivirus policy. In situations when Defender for Endpoint is set to `Allow`, but Microsoft Defender Antivirus is set to `Block`, the result is `Allow`.
 
 ### Precedence for multiple active policies
 
@@ -179,12 +175,12 @@ The result is that categories 1-4 are all blocked. This scenario is illustrated
 
    - **Indicator**: Specify the entity details and define the expiration of the indicator.
    - **Action**: Specify the action to be taken and provide a description.
-   - **Scope**: Define the scope of the machine group.
+   - **Scope**: Specify the machine group(s) which should enforce the indicator.
 
 5. Review the details in the **Summary** tab, then select **Save**.
 
 > [!IMPORTANT]
-> It can take up to 48 hours after a policy is created for a URL or IP address to be blocked on a device.
+> It can take up to 48 hours after a policy is created for a URL or IP address to be blocked on a device. In most cases, blocks will take effect in under two hours.
 
 ## Related articles