Merge branch 'main' into docs-editor/activate-sensor-1761481794

Author: aditisrivastava07

defender-for-cloud-apps/create-snapshot-cloud-discovery-reports.md

@@ -1,7 +1,7 @@
 ---
 title: Create snapshot cloud discovery reports
 description: This article provides information about how to upload logs manually to create a snapshot report of your cloud discovery apps.
-ms.date: 01/29/2023
+ms.date: 10/20/2025
 ms.topic: how-to
 ms.reviewer: Mravela
 ---
@@ -61,6 +61,7 @@ To create a snapshot report:
 
 Cloud discovery uses the data in your traffic logs. The more detailed your log, the better visibility you get. Cloud discovery requires web-traffic data with the following attributes:
 
+
 - Date of the transaction
 - Source IP
 - Source user - highly recommended
@@ -77,9 +78,10 @@ Therefore, these attributes won't be shown in cloud discovery data for these log
 To successfully generate a cloud discovery report, your traffic logs must meet the following conditions:
 
 1. [Data source is supported](set-up-cloud-discovery.md#supported-firewalls-and-proxies).
-2. Log format matches the expected standard format (format checked upon upload by the Log tool).
-3. Events aren't more than 90 days old.
-4. The log file is valid and includes outbound traffic information.
+1. Log format matches the expected standard format (format checked upon upload by the Log tool).
+1. Events aren't more than 90 days old.
+1. The log file is valid and includes outbound traffic information.
+1. Configure the appliance to forward only traffic logs. Including unrelated logs in the configuration can inflate the ingested traffic volume.
 
 ## Next steps
 

defender-for-cloud-apps/real-time-agent-protection-during-runtime.md

@@ -63,17 +63,15 @@ The following steps describe the Security Administrator’s required actions to
     > [!IMPORTANT]
     > If the Microsoft 365 connector isn’t properly connected, real-time agent protection during runtime continues to block suspicious activity on the AI agent. Alerts and incidents related to these actions won't show in the Microsoft Defender portal.
 
-1. Make sure to collaborate with the following administrators:
+1. Enter the App ID provided by your Power Platform administrator and select **Save**.
+      :::image type="content" source="media/protect-agents-real-time/turn-on-real-time-agent-protection.png" alt-text="Screenshot that shows how to turn on Real time agent protection during runtime in the Defender portal." lightbox="media/protect-agents-real-time/turn-on-real-time-agent-protection.png":::
 
-   - The **Microsoft Entra Administrator** needs to create [a Microsoft Entra ID application](/microsoft-copilot-studio/external-security-provider#step-1-configure-microsoft-entra-application) and configure a Federated Identity Credential (FIC) using the URL provided in the Microsoft Defender portal. For more information, see: [Authorize the Microsoft Entra application with your provider of choice](/microsoft-copilot-studio/external-security-provider#authorize-the-microsoft-entra-application-with-your-provider-of-choice).
-
-   - The **Power Platform Administrator** needs to  enter the Application ID and URL in the Power Platform settings page. For more information, see: [Enable external threat detection and protection for Copilot Studio custom agents](/microsoft-copilot-studio/external-security-provider#step-2-configure-the-threat-detection-system).
-1. Enter the App ID provided by your Power Platform administrator. The Application (client) ID, uniquely identifies your application and is used in your application's code as part of validating the security tokens it receives from the Microsoft identity platform.
-1. Select **Save**.
-1. Copy the URL provided.
-1. Share the URL with the Power Platform administrator. 
-
-   :::image type="content" source="media/protect-agents-real-time/turn-on-real-time-agent-protection.png" alt-text="Screenshot that shows how to turn on Real time agent protection during runtime in the Defender portal." lightbox="media/protect-agents-real-time/turn-on-real-time-agent-protection.png":::
+    > [!IMPORTANT]
+    > - Completing the onboarding process requires collaboration with a Power Platform administrator. The onboarding instructions on the Power Platform side are specified here: [Enable external threat detection and protection for Copilot Studio custom agents](/microsoft-copilot-studio/external-security-provider#step-2-configure-the-threat-detection-system).
+    > - The application ID that the Power Platform administrator needs to provide is this [Microsoft Entra ID application](/microsoft-copilot-studio/external-security-provider#step-1-configure-microsoft-entra-application).
+    > - To allow the Power Platform administrator to complete the onboarding steps, share the URL provided in the Defender portal with them.
+    
+1. No further action is needed on your part. Once the Power Platform administrator completes the onboarding steps on their side, you’ll see a green **Connected** status.
 
 
 ## Related articles

defender-for-identity/deploy/create-directory-service-account-gmsa.md

@@ -1,57 +1,56 @@
 ---
-title: Configure a DSA for Defender for Identity with a gMSA
-description: Learn how to configure a Directory Service Account for Defender for Identity with a group managed service account (gMSA).
-ms.date: 12/11/2023
+title: Configure a gMSA directory service account for Defender for Identity
+description: Create and configure a group managed service account (gMSA) for use as the Directory service account in Microsoft Defender for Identity.
+ms.date: 10/12/2025
 ms.topic: how-to
 ms.reviewer: rlitinsky
 ---
 
-# Configure a Directory Service Account for Defender for Identity with a gMSA
+# Configure a gMSA directory service account for Defender for Identity
 
-This article describes how to create a [group managed service account (gMSA)](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts) for use as a Defender for Identity DSA entry. 
+This article describes how to create a [group managed service account (gMSA)](/windows-server/security/group-managed-service-accounts/getting-started-with-group-managed-service-accounts) to use as a Microsoft Defender for Identity directory service account entry.
 
-For more information, see [Directory Service Accounts for Microsoft Defender for Identity](../directory-service-accounts.md).
- 
->[!NOTE]
->In multi-forest, multi-domain environments, the sensors that need to use the gMSA need to have their computer accounts trusted by the domain where the gMSA was created.
->We recommend creating a universal group in each domain, containing all sensors' computer accounts so that all sensors can retrieve the gMSAs' passwords, and perform the cross-domain authentications.
->We also recommend creating the gMSAs with a unique name for each forest or domain.
+## Prerequisites
 
-## Prerequisites: Grant permissions to retrieve the gMSA account's password
+- Make sure you have permissions to create gMSAs and security groups in Active Directory.
 
-Before you create the gMSA account, consider how to assign permissions to retrieve the account's password.
+- Assign permissions that allow the sensor to retrieve the gMSA password.
 
-When using a gMSA entry, the sensor needs to retrieve the gMSA's password from Active Directory. This can be done either by assigning to each of the sensors or by using a group.
+- Choose how to configure password retrieval:
 
-- **In a single-forest, single-domain deployment**, if you aren't planning to install the sensor on any AD FS / AD CS servers, you can use the built-in Domain Controllers security group.
+    - Assign the gMSA account directly to each of the sensors.
 
-- **In a forest with multiple domains**, when using a single DSA account, we recommend creating a universal group and adding each of the domain controllers and AD FS / AD CS servers to the universal group.
- 
-If you add a computer account to the universal group after the computer received its Kerberos ticket, it won't be able to retrieve the gMSA's password until it receives a new Kerberos ticket. The Kerberos ticket has a list of groups that an entity is a member of when the ticket is issued.
+    - Use a group that contains all the sensors that need to use the gMSA account.
 
-In such scenarios, do one of the following:
+- Choose the appropriate group based on your deployment:
 
-- **Wait for new Kerberos ticket to be issued**. Kerberos tickets are normally valid for 10 hours.
+    - **Single-forest, single-domain deployment**: Use the built-in Domain Controllers security group if you're not installing sensors on Active Directory Federation Services (AD FS) or Active Directory Certificate Services (AD CS) servers.
 
-- **Reboot the server**. When the server is rebooted, a new Kerberos ticket is requested with the new group membership.
+    - **Forest with multiple domains**: If you use a single Directory service account (DSA), we recommend creating a universal group and adding each of the domain controllers and AD FS or AD CS servers to the universal group.
 
-- **Purge the existing Kerberos tickets**. This forces the domain controller to request a new Kerberos ticket. 
+- In multi-forest or multi-domain environments, make sure the domain where you create the gMSA trusts the sensors’ computer accounts.
+
+- Create a universal group in each domain that includes all sensors computer accounts so that all sensors can retrieve the gMSAs' passwords, and perform the cross-domain authentications.
 
-    To purge the tickets, from an administrator command prompt on the domain controller, run the following command: `klist purge -li 0x3e7`
 
 ## Create the gMSA account
 
-This section describes how to create a specific group that can retrieve the account's password, create a gMSA account, and then test that the account is ready to use.
+1. If you've never used a gMSA account before, you might need to generate a new root key for the Microsoft Group Key Distribution Service (KdsSvc) within Active Directory. This step is required only once per forest.
+    To generate a new root key for immediate use, run the following command:
+
+    ```powershell
+    Add-KdsRootKey -EffectiveImmediately
+    ```
 
->[!NOTE]
-> If you have never used gMSA accounts before, you might need to generate a new root key for the Microsoft Group Key Distribution Service (KdsSvc) within Active Directory. This step is required only once per forest.
->
-> To generate a new root key for immediate use, run the following command:
-> ```powershell
-> Add-KdsRootKey -EffectiveImmediately
-> ```
+1. Run the PowerShell commands as an administrator. This script will: 
+    - Create a gMSA account.
+    - Create a group for the gMSA account.
+    - Add the specified computer accounts to that group.
 
-Update the following code with variable values for your environment. Then, run the PowerShell commands as an administrator:
+1. Before running the script: 
+
+    - Update the variable values to match your environment.
+    - Make sure to give each gMSA a unique name for each forest or domain.
 
 ```powershell
 # Variables:
@@ -81,46 +80,72 @@ New-ADServiceAccount -Name $gMSA_AccountName -DNSHostName "$gMSA_AccountName.$en
  -PrincipalsAllowedToRetrieveManagedPassword $gMSA_HostsGroup
 ```
 
-## Grant required DSA permissions
+
+## Refresh Kerberos tickets after changing group membership
+
+The Kerberos ticket has a list of groups that an entity is a member of when the ticket is issued. If you add a computer account to the universal group after it already received a Kerberos ticket, it can't retrieve the gMSA's password until it gets a new ticket.
+
+To refresh the Kerberos ticket, you can:
+
+- **Wait for new Kerberos ticket to be issued**. Kerberos tickets are typically valid for 10 hours.
+
+- **Reboot the server** to request a new Kerberos ticket with the new group membership.
+
+- **Purge the existing Kerberos tickets** to force the domain controller to request a new Kerberos ticket. Run the following command to purge the tickets, from an administrator command prompt on the domain controller: `klist purge -li 0x3e7`
+
+## Grant required directory service account permissions
 
 [!INCLUDE [dsa-permissions](../includes/dsa-permissions.md)]
 
 ## Verify that the gMSA account has the required rights
 
-The Defender for Identity sensor service, *Azure Advanced Threat Protection Sensor*, runs as a *LocalService* and performs impersonation of the DSA account. The impersonation will fail if the *Log on as a service* policy is configured but the permission hasn't been granted to the gMSA account. In such cases, you'll see the following health issue: **Directory services user credentials are incorrect.**
+The Defender for Identity sensor service, *Azure Advanced Threat Protection Sensor*, runs as a *LocalService* that impersonates the DSA account. If the *Log on as a service* policy is configured but the permission wasn't granted to the gMSA account, the impersonation fails. In that case, you see the following health issue: **Directory services user credentials are incorrect.**
+
+If you see this alert, check to see if the *Log on as a service policy* is configured either in a Group Policy setting or in a Local Security Policy.
+
+### Check the Local Security Policy
 
-If you see this alert, we recommend checking to see if the *Log on as a service policy* is configured. If you need to configure the *Log on as a service* policy, do so either in a Group Policy setting or in a Local Security Policy.
+1. Run `secpol.msc` 
+1. Select **Local Policies** > **User Rights Assignment**
+1. Open the **Log on as a service policy** setting. 
 
-- **To check the Local Policy**, run `secpol.msc` and select **Local Policies**. Under **User Rights Assignment**, go to the **Log on as a service policy** setting. For example:
+    :::image type="content" source="../media/log-on-as-a-service.png" alt-text="Screenshot of the log on as a service property.":::
 
-    :::image type="content" source="../media/log-on-as-a-service.png" alt-text="Screenshot of the log on as a service properties.":::
+1. Once the policy is enabled, add the gMSA account to the list of accounts that can log on as a service.
 
-    If the policy is enabled, add the gMSA account to the list of accounts that can log on as a service.
+### Check the Group Policy setting
+
+1. Run `rsop.msc` 
+1. Go to **Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Log on as a service.**
 
-- **To check if the setting is configured in a Group Policy**: Run `rsop.msc` and see if the **Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Log on as a service** policy is selected. For example:
-    
     :::image type="content" source="../media/log-on-as-a-service-gpmc.png" alt-text="Screenshot of the Log on as a service policy in the Group Policy Management Editor." lightbox="../media/log-on-as-a-service-gpmc.png":::
 
-    If the setting is configured, add the gMSA account to the list of accounts that can log on as a service in the Group Policy Management Editor.
+1. Once the setting is configured, add the gMSA account to the list of accounts that can log on as a service in the Group Policy Management Editor.
 
 > [!NOTE]
-> If you use the Group Policy Management Editor to configure the **Log on as a service** setting, make sure you add both **NT Service\All Services** and the gMSA account you created.
+> If you use the Group Policy Management Editor to configure the **Log on as a service** setting, make sure to add both **NT Service\All Services** and the gMSA account you created.
+
+## Configure a Directory service account in Microsoft Defender XDR
 
-## Configure a Directory Service account in Microsoft Defender XDR
+To connect your sensors with your Active Directory domains, configure Directory service accounts in Microsoft Defender XDR.
 
-To connect your sensors with your Active Directory domains, you'll need to configure Directory Service accounts in Microsoft Defender XDR.
+1. In [Microsoft Defender XDR](https://security.microsoft.com/), go to **Settings > Identities**.
 
-1. In [Microsoft Defender XDR](https://security.microsoft.com/), go to **Settings > Identities**. For example:
+    :::image type="content" source="../media/settings-identities.png" alt-text="Screenshot that shows the settings page and how to access the Defender for Identity page." lightbox="../media/settings-identities.png":::
 
-    [![Screenshot of the Identities settings in Microsoft Defender XDR.](../media/settings-identities.png)](../media/settings-identities.png#lightbox)
+1. Select **Directory service accounts** to see which accounts are associated with which domains. 
 
-1. Select **Directory Service accounts**. You'll see which accounts are associated with which domains. For example:
+    :::image type="content" source="../media/directory-service-accounts.png" alt-text="Screenshot that shows the Directory service accounts page in the Defender portal." lightbox="../media/directory-service-accounts.png":::
 
-    [![Screenshot of the Directory Service accounts page.](../media/directory-service-accounts.png)](../media/directory-service-accounts.png#lightbox)
 
-1. To add Directory Service account credentials, select **Add credentials** and enter the **Account name**, **Domain**, and **Password** of the account you created earlier. You can also choose if it's a **Group managed service account** (gMSA), and if it belongs to a **Single label domain**. For example:
+1. Select **Add credentials** 
+1. Enter the following details:
+   - **Account name**
+   - **Domain**
+   - **Password**  
+1. You can choose if it's a **Group managed service account** (gMSA), or if it belongs to a **Single label domain**. 
 
-    [![Screenshot of the add credentials pane.](../media/new-directory-service-account.png)](../media/new-directory-service-account.png#lightbox)
+    :::image type="content" source="../media/new-directory-service-account.png" alt-text="Screenshot of the added credentials pane." lightbox="../media/new-directory-service-account.png":::    
 
     |Field|Comments|
     |---|---|
@@ -130,12 +155,15 @@ To connect your sensors with your Active Directory domains, you'll need to confi
     |**Domain** (required)|Enter the domain for the read-only user. For example: **contoso.com**. <br><br>It's important that you enter the complete FQDN of the domain where the user is located. For example, if the user's account is in domain corp.contoso.com, you need to enter `corp.contoso.com` not `contoso.com`. <br><br>For more information, see [Microsoft support for Single Label Domains](/troubleshoot/windows-server/networking/single-label-domains-support-policy).|
 
 1. Select **Save**.
-1. (Optional) If you select an account, a details pane will open with the settings for that account. For example:
+1. (Optional) Select an account to open the details pane and view its settings.
+
+
+    :::image type="content" source="../media/account-settings.png" alt-text="Screenshot of an account details pane." lightbox="../media/account-settings.png":::
 
-    [![Screenshot of an account details pane.](../media/account-settings.png)](../media/account-settings.png#lightbox)
 
 > [!NOTE]
-> You can use this same procedure to change the password for standard Active Directory user accounts. There is no password set for gMSA accounts.
+> You can use the same procedure to change the password for standard Active Directory user accounts. 
+> gMSA accounts don't require passwords.
 
 ## Troubleshooting
 

defender-for-identity/deploy/prerequisites-sensor-version-3.md

@@ -18,7 +18,6 @@ The Defender for Identity sensor v3.x:
  - Can't be activated on a server that has a Defender for Identity sensor V2.x already deployed.
  - Doesn't currently support VPN integration.
  - Doesn't currently support ExpressRoute.
- - Doesn't currently offer full functionality of health alerts, posture recommendations, security alerts or advanced hunting data.
 
 ## Licensing requirements