5.7 Enabling the Entra ID Connector

90 minutes · Module 5

Enabling the Entra ID Connector

By the end of this subsection, you will have configured the Entra ID diagnostic settings to send sign-in and audit logs to your Sentinel workspace.

The M365 Defender connector brings device, email, and cloud app data. The Entra ID connector brings identity data — sign-in logs, audit logs, and provisioning logs. Together, they give your workspace the complete picture.

Why a separate connector?

Entra ID data is not part of the Defender XDR data pipeline. It flows through Azure Monitor diagnostic settings, not the Defender connector. This means you configure it separately, and it uses a different ingestion path.

Configuration

  1. Navigate to Entra ID → Monitoring → Diagnostic settings
  2. Click Add diagnostic setting
  3. Name it: sentinel-signin-audit
  4. Select the log categories to send:

Select these:

  • SignInLogs (interactive sign-ins)
  • NonInteractiveUserSignInLogs (token refreshes, API calls)
  • AuditLogs (directory changes, app consents, group changes)
  • ServicePrincipalSignInLogs (app-to-app authentication)
  • RiskyUsers (identity protection risk events)
  • UserRiskEvents (risk event details)

Optional (enable if needed):

  • ManagedIdentitySignInLogs (Azure managed identity sign-ins)
  • ProvisioningLogs (user provisioning events)
  • ADFSSignInLogs (on-premises ADFS, if applicable)
  1. Under Destination details, select Send to Log Analytics workspace
  2. Select your Sentinel workspace
  3. Click Save
Both sign-in log types are required

Module 4 taught you that token replay appears only in NonInteractiveUserSignInLogs. If you enable only SignInLogs (interactive), you miss the entire token replay detection pattern. Always enable both. The non-interactive table is higher volume but contains the most critical investigation data.

Verification

1
2
3
4
5
6
union withsource=TableName
    SigninLogs,
    AADNonInteractiveUserSignInLogs,
    AuditLogs
| where TimeGenerated > ago(1h)
| summarize EventCount = count(), LastEvent = max(TimeGenerated) by TableName
Expected Output
TableNameEventCountLastEvent
SigninLogs2342026-03-21 14:30
AADNonInteractiveUserSignInLogs1,8472026-03-21 14:32
AuditLogs422026-03-21 14:28
What to look for: All three tables should have recent events. Non-interactive events are typically 5-10x the volume of interactive — that is normal (token refreshes happen continuously). If SigninLogs shows data but AADNonInteractiveUserSignInLogs does not, check that you selected NonInteractiveUserSignInLogs in the diagnostic settings.
Entra ID P2 required for risk data

The RiskyUsers and UserRiskEvents tables only populate if you have Entra ID P2 licensing. E5 includes P2. If you are on E3, these tables will exist but remain empty. This means risk-based conditional access and identity protection analytics rules will not have data to work with.

Check your understanding

1. You enabled SignInLogs in the diagnostic settings but not NonInteractiveUserSignInLogs. What detection capability did you lose?

None — interactive logs are sufficient
Password spray detection
Token replay detection — stolen tokens generate non-interactive sign-in events. Without this table, the anti-join detection pattern from Module 4 cannot run, and AiTM token replay is invisible to your Sentinel analytics rules.