In Microsoft Sentinel, the ‘Defender for Cloud (MDC)’ native data connector provides a method for syncing security alerts from MDC to Sentinel. It’s important to understand that part of the needed configuration is configured on the Azure subscription side, the same manner as MDC enhanced security features.

The latest addition by the product group(s) was bi-directional sync between Sentinel and Defender for Cloud (Azure subscription-related service) to enhance the integration between the solutions. With bi-directional sync, an organization can take Sentinel incident management in better control when the source is MDC. In this blog post, I’ll go through typical challenges I have seen in different environments, (notes from the field).

MDC Data Connector

Defender for Cloud data connector is a built-in Microsoft connector and extremely easy to configure from the portal. When you enable (connect) the data connector the bi-directional sync is enabled at the same time. To establish you need to have “security admin/write” permission on the target Azure subscription.

When the connector is enabled/configured from the portal the following actions take place:

  • Alert sync is enabled – this setting is configured in Microsoft Sentinel side
  • Bi-directional sync is enabled – this setting is configured in target Azure subscription

The Challenge

I’ve seen many environments where Azure subscriptions are not aligned with each other in terms of basic security settings. Imagine a scenario where Microsoft Sentinel is acting as a SIEM and there are tens or hundreds of Azure subscriptions. Security policy is defined on paper which states that these subscriptions should be connected to Sentinel and bi-directional sync should be enabled. Because these tasks are often configured manually admin forgets to enable the connector (or bi-directional sync) or there might be operational responsibilities between different service providers which can lead to a situation where the operating responsibility of Sentinel data connectors, especially Defender for Cloud, is in the grey area.

I’ve seen these scenarios “live” in multiple environments. I just finalized a task to activate the MDC connector in an environment where are close to 100 Azure subscriptions. Worth mentioning, I have seen the exact same situation in the environment where Azure is built as infrastructure as a code (IaC) instead of manually deploying the configuration.

The Solution

If Azure is built with IaC it is important to take all needed Azure subscription security-related configurations into account (such as bi-directional sync) when planning and deploying configurations. For that reason, I suggest adding configurations of these settings to the deployment pipeline (or process) no matter what tool you are using. From the next chapter, you can find commands to automatically deploy the aforementioned configurations to REST API.

Enable Microsoft Sentinel Defender for Cloud data connector

The following REST API call enables the connector from the Sentinel side. PowerShell used in tests I made and for that reason, there is formatting that’s required by PS included in the body.

#Set parameters for MDC Connector
$body = @"
{ "kind": "AzureSecurityCenter",
"properties": {
"subscriptionId": "b1762f48-e754-4c53-a83a-5234b7825747",
"dataTypes": {
"alerts": {
"state": "Enabled"

##Set Sentinel data connector to enabled state
$SentinelDataConnMDC = Invoke-restmethod -Method Put -uri '' -body $body -ContentType "application/json" -Headers $h

When alerts are synced and flowing to Sentinel bi-directional sync configuration needs to be set. As said, if the configuration is triggered from the portal this step is activated automatically.

Side note: bi-directional sync is configured on the Azure subscription (target) side, not on the Microsoft Sentinel side.

##Enable MDC data connector bi-directional sync
$body = @"
        "kind": "AlertSyncSettings",
        "properties": {
            "enabled": true

$SetMDCBirectSync = Invoke-restmethod -Method Put -uri '' -body $body -ContentType "application/json" -Headers $h

After configuration takes place its related events are found from Azure Monitor – Activity Log

Azure Policy

Azure Policy does not help us here because to the best of my knowledge these settings are not auditable through policy mechanism.

Hope this helps when deploying Microsoft Sentinel and Defender for Cloud configurations!


Connect Defender for Cloud to Microsoft Sentinel

Update or create Sentinel data connectors through REST API

Deploy and Manage Microsoft Sentinel as a code