Forum Discussion

Alfred_Schreuder's avatar
Alfred_Schreuder
Copper Contributor
Feb 12, 2024

Microsoft Defender XDR / Defender for Endpoint data connectors inconsistent failures

Hello,

 

We are deploying our SOC (Sentinel) environments via Bicep. Now the Defender XDR (

MicrosoftThreatProtection) and Defender for Endpoint (
MicrosoftDefenderAdvancedThreatProtection) data connectors are failing to deploy inconsistantly. It seems to be a known issue due to the following posts:
- https://github.com/Azure/SimuLand/issues/23
- https://github.com/Azure/Azure-Sentinel/issues/5007
 
Next to this issue I see almost no development on the data connectors API, is there some news to be spread how to enable data connectors automated in the future, since it seems to be moving to Content Hub. It is hard to find any docs about how to deploy this for example via Bicep!?
 
Also I have a question regarding 'Tenant-based Microsoft Defender for Cloud (Preview)' data connector. We deploy this now via GenericUI data connector kind, but this has no option to enable it via automation. Same as the question in the previous paragraph, how would this be made possible?

1 Reply

  • cuongdohcm's avatar
    cuongdohcm
    Occasional Reader

    Hi Alfred, a few things have changed since you posted, so here is where this stands as of October 2026.

    1. Check the prerequisites against your pipeline identity. The Defender XDR connector requires a valid Defender XDR license. The identity that enables it needs the Security Administrator role on the tenant (or equivalent), read/write on the workspace, and membership in the same Entra tenant as the workspace. In a pipeline, that identity is your service principal or managed identity, not your admin account, so I'd check this first when deployments fail from Bicep but work from the portal.

    2. Bicep shape (Microsoft.SecurityInsights/dataConnectors). For Defender XDR use kind 'MicrosoftThreatProtection' with properties.tenantId and dataTypes.incidents.state = 'Enabled' (required); dataTypes.alerts is optional. For Defender for Endpoint use kind 'MicrosoftDefenderAdvancedThreatProtection' with properties.tenantId and dataTypes.alerts.state = 'Enabled'. Use a stable API version and check the change log before you move between versions.

    3. The bigger change: the Defender portal. Workspaces onboarded to Microsoft Sentinel after 1 July 2025 are onboarded to the Defender portal automatically. Once a workspace is in the Defender portal, the Defender XDR connector is enabled automatically. Sentinel in the Azure portal is retired after 31 March 2027. For new SOC environments, it is simpler to deploy the workspace and Sentinel with Bicep and onboard to the Defender portal than to deploy the XDR connector yourself.

    4. Tenant-based Defender for Cloud. The dataConnectors schema has no kind for it (AzureSecurityCenter is the subscription-based one), and the docs only describe portal setup. In the Defender portal you don't need it: Defender for Cloud alerts already flow into Defender XDR, and the tenant-based connector isn't listed there.

    Docs on Microsoft Learn: "Stream data from Microsoft Defender XDR to Microsoft Sentinel", "Connect Microsoft Sentinel to the Microsoft Defender portal", "Ingest Microsoft Defender for Cloud alerts into Microsoft Sentinel", and the template reference for Microsoft.SecurityInsights dataConnectors.