AZ-500 Question 266
Single answerYour organization wants to monitor suspicious sign-in attempts from on-premises Windows servers in Microsoft Sentinel. You have installed the Azure Monitor Agent on each server and connected them to an existing Log Analytics workspace. However, no events appear in the SecurityEvents table in Sentinel. Which immediate step should you take next to ensure Windows Security Events are ingested into Sentinel?
- A
Enable and configure the Windows Security Events data connector in Sentinel, ensuring it collects the SecurityEvent logs from your connected workspace.
- B
Install the Microsoft 365 Defender for Identity sensor on your on-premises servers to route SecurityEvent logs to Sentinel automatically.
- C
Activate the Active Directory DNS connector in Sentinel to bring in sign-in events from your DNS records.
- D
Create a custom Sentinel analytics rule that queries the Windows event subsystem directly on each on-premises server.
Show answer and explanation
Correct answer: A
Explanation
To monitor Windows Security Events in Microsoft Sentinel, you must connect your servers to an Azure Log Analytics workspace with the appropriate agent and enable the Windows Security Events data connector in Sentinel. This ensures the SecurityEvent logs are collected from the workspace and made available for analytics and investigation. For more information, refer to the Microsoft Sentinel documentation on connecting Windows Security Events: https://learn.microsoft.com/azure/sentinel/connect-windows-security-events.
- A. Correct.
Option 1 is correct. Even if you install the Azure Monitor Agent and connect servers to a Log Analytics workspace, you must explicitly enable and configure the Windows Security Events data connector in Sentinel to retrieve SecurityEvent logs from the workspace. This involves specifying the workspace and ensuring that the correct event logs (e.g., SecurityEvents) are collected.
- B. Incorrect.
Option 2 is incorrect. Microsoft 365 Defender for Identity sensors do not automatically forward SecurityEvent logs to Sentinel for general Windows sign-in attempts. They primarily focus on identity-related signals such as Active Directory processes to detect advanced threats, not direct ingestion of all SecurityEvent logs.
- C. Incorrect.
Option 3 is incorrect. The Active Directory DNS connector ingests DNS server logs primarily for threat detection related to DNS queries and domain name resolutions; it does not capture general sign-in activity from Windows event logs.
- D. Incorrect.
Option 4 is incorrect. Custom analytics rules in Sentinel can only query data that is already ingested in the workspace. Without enabling the Windows Security Events data connector, the SecurityEvents table will remain empty.