Practice Free SC-200 Exam Online Questions

Explanation:

To the AD DS domain controllers, deploy: Microsoft Defender for Identity sensors

For Sentinel1, configure: The Security Events data source

To enable User and Entity Behavior Analytics (UEBA) in Microsoft Sentinel using data from on-premises Active Directory Domain Services (AD DS), you must collect detailed identity and authentication events. This requires integration with Microsoft Defender for Identity (MDI) ― the native tool designed to monitor domain controller traffic and send identity telemetry to Microsoft Sentinel.

Step 1: Deploy Microsoft Defender for Identity sensors

According to Microsoft documentation:

“To collect signals from your on-premises Active Directory domain controllers, install Microsoft Defender for Identity sensors directly on each domain controller or on a dedicated server.”

These sensors capture Windows event logs and network authentication data (Kerberos, NTLM, LDAP) and send the information securely to Defender for Identity cloud service.

The Azure Connected Machine agent and Azure Monitor agent do not provide the specialized identity telemetry required by UEBA. Therefore, the correct deployment is the Microsoft Defender for Identity sensors.

Step 2: Configure the Security Events data source in Sentinel

After integrating Defender for Identity, you must connect the right data source in Microsoft Sentinel.

The Security Events data source ingests domain controller event logs (such as sign-ins, account management, and group membership changes) that UEBA relies on for behavioral baselines and anomaly detection.

Microsoft Sentinel UEBA documentation confirms:

“UEBA uses data from identity-related data sources, such as SecurityEvents and Azure Active Directory sign-ins, to build user and entity profiles and detect anomalies.”

The Audit Logs and Signin Logs tables are specific to Azure AD and cloud identity events ― not on-premises AD DS domain controllers.

✅ Final Configuration:

Deploy Microsoft Defender for Identity sensors to the domain controllers.

Configure The Security Events data source for Sentinel1.

Explanation:

In Microsoft Sentinel workbooks, parameters can be referenced directly in KQL. For multi-select parameters that include an All option, the recommended pattern is to check the parameter’s label for “All” and otherwise filter by the selected values.

Hence:

where ("{Operations:label}" == "All" or Operation in ({Operations}))

This lets the visual treat All as a single choice while still supporting one or many explicit operations.

You also need a Users parameter, so you’d typically include:

| where UserId in ({Users})

Because the data source is OfficeActivity, to scope to SharePoint and OneDrive activity:

| where OfficeWorkload in (‘OneDrive’,’SharePoint’)

Finally, to exclude empty site URLs, filter out blanks:

| where Site_Url != ”

Putting it together (for context):

OfficeActivity

| where ("{Operations:label}" == "All" or Operation in ({Operations}))

| where OfficeWorkload in (‘OneDrive’,’SharePoint’)

| where UserId in ({Users})

| where Site_Url != ”

| project Site_Url, UserId, Operation, TimeGenerated

Explanation:

For SQL Server on Azure VMs (VM1), Defender for Cloud’s Advanced Threat Protection and Vulnerability Assessment for SQL “on machines” are enabled by registering the instance as a SQL virtual machine using the SQL IaaS Agent extension. This single Azure VM extension onboards the SQL workload, exposes SQL VM resource management, and lights up Defender for SQL (ATP + VA) with minimal admin effort―no separate agents are required on Azure VMs beyond this extension for these features.

For on-premises/Arc servers (Server1), the machine is already Arc-enabled. To protect SQL instances with Defender for Cloud and to surface vulnerability assessment and threat protection signals, you deploy the Azure Arc SQL Server extension (delivered as an Arc “virtual machine extension”) to register the instance with Azure. In addition, Arc scenarios use the Azure Monitor Agent (AMA) for data collection and security signal ingestion in Defender for Cloud (the legacy Log Analytics agent is not recommended). This combination satisfies ATP/VA requirements while keeping operations simple and consistent with current agent guidance.

Therefore:

VM1: only the Azure VM extension (SQL IaaS Agent extension).

Server1: AMA + an Azure (Arc) extension (Arc SQL Server extension).