8.2 Microsoft First-Party Connectors

Microsoft First-Party Connectors

Introduction

Microsoft first-party connectors are the simplest to deploy and the most important to enable. They require no agent installation, no intermediate infrastructure, and no complex configuration — enable them in the Sentinel portal and data starts flowing within minutes. These connectors populate the core investigation tables you mapped in Module 7.6.

Microsoft Entra ID connector

The Entra ID connector ingests identity data — the single most queried data category in security operations.

What it ingests:

SigninLogs — every interactive user sign-in (authentication to M365, Azure, and Entra-integrated apps). AADNonInteractiveUserSignInLogs — automated and token-based sign-ins (service principals, managed identities, token refreshes). AADServicePrincipalSignInLogs — application/service principal authentications. AADManagedIdentitySignInLogs — managed identity authentications. AuditLogs — directory changes (user creation, group membership changes, role assignments, conditional access policy modifications, app registrations). AADProvisioningLogs — user provisioning events from connected apps. AADRiskyUsers and AADUserRiskEvents — identity protection risk detections.

Configuration: Navigate to Sentinel → Data connectors → Microsoft Entra ID (or install the Entra ID Content Hub solution). Open the connector page. Select which log types to enable — at minimum, enable SigninLogs and AuditLogs. For comprehensive coverage, enable all log types.

Cost consideration: AADNonInteractiveUserSignInLogs can generate 5-10x the volume of interactive SigninLogs in environments with many service principals and automated processes. If cost is a concern, consider: enabling non-interactive logs but applying a DCR transformation (subsection 8.7) to filter routine token refreshes, or starting with interactive sign-ins only and adding non-interactive after baselining the volume.

Verification query:

1
2
3
4
5

// Verify Entra ID connector is delivering data
SigninLogs
| where TimeGenerated > ago(1h)
| summarize Count = count() by bin(TimeGenerated, 10m)
| order by TimeGenerated desc

If this query returns results with recent timestamps, the connector is working. If it returns zero results, check: is the connector status “Connected” in the Data connectors page? Does the tenant have Entra ID P1 or P2 licences (required for sign-in logs)? Is there a diagnostic setting conflict (Entra ID diagnostic settings in the Azure portal can conflict with the Sentinel connector)?

Azure Activity connector

The Azure Activity connector ingests Azure management plane operations — the audit trail for your cloud infrastructure.

What it ingests: AzureActivity table — every Azure Resource Manager (ARM) operation: resource creation, modification, and deletion; RBAC role assignments; policy evaluations; service health events; and autoscale operations.

Configuration: The Azure Activity connector is deployed through Azure Policy rather than a simple toggle. Navigate to Sentinel → Data connectors → Azure Activity → Open connector page → Launch Azure Policy Assignment wizard. The policy creates a diagnostic setting on each Azure subscription that sends Activity Log data to the Sentinel workspace.

Why Azure Policy? Unlike other connectors that connect at the tenant level, Azure Activity is per-subscription. An organisation with 10 Azure subscriptions needs the diagnostic setting on each one. Azure Policy automates this — including for new subscriptions created after the initial deployment.

Verification query:

1
2
3
4

AzureActivity
| where TimeGenerated > ago(1h)
| summarize Count = count() by CategoryValue
| order by Count desc

Expected categories: Administrative (resource operations), ServiceHealth, Alert, Recommendation, Policy, Autoscale, Security.

Microsoft 365 (Office 365) connector

The M365 connector ingests audit data from Exchange Online, SharePoint Online, and Teams.

What it ingests: OfficeActivity table — Exchange mailbox operations (mail send, receive, delete, forward), SharePoint file operations (upload, download, share, delete), and Teams events (channel creation, membership changes, meeting activity).

Configuration: Sentinel → Data connectors → Office 365 → enable Exchange, SharePoint, and Teams. Each can be toggled independently.

Overlap with CloudAppEvents: If you have Defender for Cloud Apps, the CloudAppEvents table contains similar (and often richer) data for these services. OfficeActivity and CloudAppEvents overlap significantly for Exchange and SharePoint operations. In practice, many organisations enable both — OfficeActivity for the unified audit log format, CloudAppEvents for the Defender-enriched format with additional fields. If cost is a concern, CloudAppEvents (ingested through the Defender XDR connector) may be sufficient, and OfficeActivity can be skipped.

Verification query:

1
2
3
4

OfficeActivity
| where TimeGenerated > ago(1h)
| summarize Count = count() by OfficeWorkload
| order by Count desc

Expected workloads: Exchange, SharePoint, MicrosoftTeams (if Teams is enabled).

Microsoft Defender for Cloud connector

The Defender for Cloud connector ingests security alerts and recommendations from Azure’s cloud workload protection platform.

What it ingests: SecurityAlert table (alerts from all enabled Defender plans — Defender for Servers, Defender for Storage, Defender for SQL, etc.) and SecurityRecommendation table (CSPM posture recommendations).

Configuration: Sentinel → Data connectors → Microsoft Defender for Cloud → enable. Select which subscriptions to connect. Enable bi-directional sync to create Sentinel incidents from Defender for Cloud alerts.

Important: Enabling bi-directional sync means Defender for Cloud alerts automatically create incidents in the Sentinel incident queue. If you also have analytics rules that detect based on SecurityAlert data from Defender for Cloud, you may get duplicate incidents. Configure either bi-directional sync OR analytics rules — not both — to avoid duplication.

Verification query:

1
2
3
4

SecurityAlert
| where TimeGenerated > ago(24h)
| where ProviderName == "Azure Security Center"
| summarize Count = count() by AlertSeverity

Entra ID diagnostic settings: avoiding the conflict trap

The Entra ID connector in Sentinel and the Entra ID diagnostic settings in the Azure portal both send the same data — but they use different mechanisms. If both are configured to send to the same workspace, you get duplicate data (and double the ingestion cost). If they are configured to send to different workspaces, the Sentinel connector may appear to work but data lands in the wrong workspace.

Best practice: Use only the Sentinel connector (enable it from the Data connectors page). Do NOT also configure Entra ID → Diagnostic settings → to the same workspace. If a diagnostic setting already exists (perhaps configured by an Azure administrator before Sentinel was deployed), check where it sends data. If it sends to the Sentinel workspace, you have two paths:

Option A: Disable the Sentinel connector and use only the diagnostic setting. The data arrives in the same tables (SigninLogs, AuditLogs) either way.

Option B: Remove the diagnostic setting and use only the Sentinel connector. This is cleaner because the Sentinel connector is visible in the Data connectors page and its health is monitored by SentinelHealth.

Never have both active simultaneously for the same workspace.

Entra ID connector: all log types explained

The Entra ID connector offers multiple log type toggles. Understanding each helps you decide which to enable.

Sign-in logs (interactive) — SigninLogs table. Every human-initiated authentication. Essential — always enable. Volume: 0.5-2 GB/day per 1,000 active users.

Sign-in logs (non-interactive) — AADNonInteractiveUserSignInLogs table. Token refreshes, background app authentication, service principal sign-ins. Very high volume (5-20x interactive). Enable for comprehensive coverage, but consider DCR filtering if cost is a concern.

Audit logs — AuditLogs table. Every directory change. Essential — always enable. Moderate volume: 0.2-1 GB/day depending on admin activity.

Provisioning logs — AADProvisioningLogs table. User provisioning events from connected apps (HR-driven provisioning, SCIM). Low volume. Enable if you use automated provisioning.

Risky users — AADRiskyUsers table. Users flagged by Entra ID Protection as risky. Very low volume. Enable for identity risk investigation.

User risk events — AADUserRiskEvents table. Individual risk detection events (leaked credentials, impossible travel). Low volume. Enable for identity risk investigation.

Network access logs — if using Global Secure Access (Entra Private Access / Internet Access). Enable only if you use these features.

Service principal sign-in logs — AADServicePrincipalSignInLogs table. Application/service principal authentications. Moderate volume. Enable for OAuth and API security monitoring.

Managed identity sign-in logs — AADManagedIdentitySignInLogs. Managed identity authentications. Low volume. Enable for Azure resource security monitoring.

For a complete deployment: enable all log types. For a cost-conscious deployment: enable Sign-in (interactive), Audit, Risky users, and User risk events. Add non-interactive and service principal sign-ins only after baselining volume.

Azure Activity connector: the Azure Policy approach in detail

The Azure Activity connector uses Azure Policy to create diagnostic settings on each subscription. Here is the step-by-step:

1. Navigate to Sentinel → Data connectors → Azure Activity → Open connector page.
2. Click “Launch Azure Policy Assignment wizard.”
3. Scope: select the management group or subscription to apply the policy.
4. Parameters: select your Sentinel Log Analytics workspace as the destination.
5. Remediation: enable “Create a remediation task” to apply the policy to existing subscriptions retroactively.
6. Review + create.

The policy creates a diagnostic setting named setByPolicy-sentinel on each subscription. This setting sends Activity Log data to the Sentinel workspace. The policy is evaluated periodically — new subscriptions created after the assignment automatically get the diagnostic setting.

Verification after policy deployment:

1
2
3
4
5
6

// Check which subscriptions are sending Azure Activity data
AzureActivity
| where TimeGenerated > ago(24h)
| summarize EventCount = count(), LastEvent = max(TimeGenerated)
    by SubscriptionId
| order by EventCount desc

If a subscription you expect to see is missing from the results, check: is the policy assigned to that subscription’s scope? Has the remediation task completed? Is the subscription in a different management group?

Microsoft Defender for Cloud connector: bi-directional sync options

The Defender for Cloud connector offers two modes.

Alerts only: Security alerts from Defender for Cloud plans (Defender for Servers, Storage, SQL, Key Vault, DNS, Resource Manager, App Service, Containers) are ingested into the SecurityAlert table. No incidents are automatically created in Sentinel — you must create analytics rules that evaluate the SecurityAlert data and generate incidents.

Bi-directional sync (recommended): Security alerts are ingested AND incidents are automatically created in the Sentinel incident queue. Status changes (triage, assignment, closure) sync between the Defender for Cloud and Sentinel portals. This eliminates the need for separate “Microsoft Security” analytics rules for Defender for Cloud alerts.

Subscription selection: Unlike the Azure Activity connector (which uses Azure Policy), the Defender for Cloud connector is configured per-subscription in the Sentinel portal. Toggle each subscription individually. Ensure all subscriptions with Defender plans enabled are connected.

Data freshness expectations per connector

Not all connectors deliver data at the same speed. Understanding normal latency prevents false alarm troubleshooting when data appears “delayed.”

Entra ID (SigninLogs, AuditLogs): 2-5 minutes typical latency. Sign-in events generated during authentication appear in Sentinel within minutes. If latency exceeds 15 minutes, investigate the connector.

Azure Activity: 5-15 minutes typical latency. ARM operations are batched before transmission. A 15-minute delay for Azure Activity events is normal — do not troubleshoot unless latency exceeds 30 minutes.

Microsoft 365 (OfficeActivity): 5-30 minutes typical latency. The unified audit log in M365 has inherent processing delay. Some event types (SharePoint file operations) appear faster than others (Teams events). Latency up to 30 minutes is within Microsoft’s documented SLA.

Defender for Cloud (SecurityAlert): Near-real-time for security alerts (2-5 minutes). Recommendation data may be batched (up to 1 hour delay).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

// Measure actual latency per first-party connector
union
    (SigninLogs | where TimeGenerated > ago(1h)
        | extend Latency = ingestion_time() - TimeGenerated
        | summarize AvgLatency = avg(Latency), P95 = percentile(Latency, 95)
        | extend Table = "SigninLogs"),
    (AzureActivity | where TimeGenerated > ago(1h)
        | extend Latency = ingestion_time() - TimeGenerated
        | summarize AvgLatency = avg(Latency), P95 = percentile(Latency, 95)
        | extend Table = "AzureActivity"),
    (OfficeActivity | where TimeGenerated > ago(1h)
        | extend Latency = ingestion_time() - TimeGenerated
        | summarize AvgLatency = avg(Latency), P95 = percentile(Latency, 95)
        | extend Table = "OfficeActivity")
| project Table, AvgLatency, P95

Common first-party connector misconfigurations

Misconfiguration 1: Duplicate Entra ID diagnostic settings. An Azure administrator configured Entra ID → Diagnostic settings → to send sign-in logs to the workspace before the SOC team enabled the Sentinel connector. Now both are active — resulting in duplicate events in SigninLogs (double volume, double cost, double alert count from analytics rules). Detection: SigninLogs | where TimeGenerated > ago(1h) | summarize count() by CorrelationId | where count_ > 1 | count. If the count is high, you have duplicates.

Misconfiguration 2: Azure Policy scope too narrow. The Azure Activity policy was assigned to a single subscription, but the organisation has 5 subscriptions. Activity data from the other 4 subscriptions is missing. Detection: compare the subscription list in AzureActivity | distinct SubscriptionId with the full subscription list in Azure portal → Subscriptions.

Misconfiguration 3: Office 365 connector enabled for all workloads when CloudAppEvents covers Exchange. Both OfficeActivity and CloudAppEvents ingest Exchange audit events — creating duplicate data for mail operations. Detection: compare counts per time period for the same operation type across both tables.

Misconfiguration 4: Defender for Cloud connector without bi-directional sync. Alerts arrive in SecurityAlert but no incidents are created in the Sentinel queue. The SOC team misses Defender for Cloud alerts because they only monitor the incident queue, not the raw SecurityAlert table. Fix: enable bi-directional sync, or create a Microsoft Security analytics rule to generate incidents from Defender for Cloud alerts.

Connector status monitoring

After enabling all first-party connectors, verify their collective health:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

// All first-party connectors — data freshness check
let ConnectorTables = datatable(TableName:string, Connector:string) [
    "SigninLogs", "Entra ID",
    "AuditLogs", "Entra ID",
    "AzureActivity", "Azure Activity",
    "OfficeActivity", "Office 365",
    "SecurityAlert", "Multiple"
];
union withsource=TableName *
| where TimeGenerated > ago(4h)
| summarize LastEvent = max(TimeGenerated), EventCount = count() by TableName
| join kind=inner ConnectorTables on TableName
| project Connector, TableName, LastEvent,
    MinutesSinceLastEvent = datetime_diff('minute', now(), LastEvent),
    EventCount
| order by MinutesSinceLastEvent desc

Any table with MinutesSinceLastEvent greater than 60 warrants investigation — the connector may have disconnected or the data source may have stopped generating events.

Knowledge check