Microsoft Sentinel — Integration Setup

Note: This guide covers Microsoft Sentinel, Microsoft's cloud SIEM. It is unrelated to SentinelOne, the EDR vendor — if you're looking for that integration, see integration-setup-sentinelone.md instead.

Prerequisites

• A Microsoft Sentinel workspace connected to Microsoft 365 Defender's unified security operations (so its incidents surface through Microsoft Graph)
• An administrator who can grant Microsoft Graph admin consent (and, self-hosted, register an Azure AD app)
• CMDash Essentials tier or above

How CMDash connects

Sentinel uses CMDash's Microsoft app registration with application permissions and an app-only token (the client-credentials grant) — no signed-in user, no refresh token. Which directory is read depends on how the deployment runs its Microsoft integrations; see How CMDash connects to Microsoft.

• CMDash SaaS (per directory): available once CMDash's Microsoft apps are registered. Until then Connect answers that the Microsoft app registration is not set up on this deployment. Once it is, Integrations → Microsoft Sentinel → Connect, fill in the workspace fields, sign in as an active Global Administrator or Privileged Role Administrator and accept the permissions for your organisation; the connection is bound to your directory. Commercial cloud only for now (not GCC High or DoD). What CMDash checks and records is described once, in the Entra ID guide.
• Self-hosted (single directory): Steps 1–4 below.

Step 1 (self-hosted): Register an Azure AD App

1. Go to Azure Portal → App registrations.
2. Click New registration.
3. Name: CMDash Integration.
4. Supported account types: Single tenant.
5. Redirect URI: leave blank — a single-directory connection has no sign-in step.
6. Click Register, then copy the Application (client) ID and Directory (tenant) ID.

Step 2 (self-hosted): Grant Microsoft Graph Security Permissions

1. In the app registration, go to API permissions → Add a permission → Microsoft Graph → Application permissions.
2. Add SecurityIncident.Read.All.
3. Click Grant admin consent for [your org].

Step 3 (self-hosted): Create a Client Secret

1. Go to Certificates & secrets → New client secret.
2. Description: CMDash. Expiry: 24 months (set a calendar reminder to rotate).
3. Copy the Value immediately — it will not be shown again.

Step 4 (self-hosted): Configure the deployment, then connect

The tenant id, client id and secret are server settings, not fields in the connect dialog.

1. Set AZURE_TENANT_ID, AZURE_CLIENT_ID and AZURE_CLIENT_SECRET in the API's environment (leave AZURE_MULTI_TENANT unset) and restart the API.
2. In CMDash, navigate to Integrations, find Microsoft Sentinel and click Connect.
3. Fill in the Log Analytics workspace Sentinel runs on — Subscription ID, Resource group, Workspace name. They are used for detection-rule coverage (Sentinel analytics rules, read from Azure Resource Manager); incidents come from Microsoft Graph and do not depend on them. Reading analytics rules additionally needs an Azure Resource Manager token, which this connection does not request yet, so that step is currently skipped rather than failing the sync.
4. Click Save & Test Connection.

What Syncs

CMDash pulls Sentinel incidents through the Microsoft Graph Security API's unified incidents queue (not Sentinel's own Log Analytics workspace API directly), sorted newest-first and paginated via @odata.nextLink, capped at 2,000 incidents per sync. This means incidents only appear here if your Sentinel workspace is connected to Microsoft 365 Defender's unified security operations platform — a standalone Sentinel workspace not linked into that unified queue will show no data.

Note: Today this adapter syncs incident-level records only. It does not call the separate alert-level Graph endpoint (/security/alerts_v2), so individual alerts underlying an incident are not surfaced as their own CMDash records — only the rolled-up incident.

Troubleshooting

• 401 Unauthorized: Self-hosted: the client secret behind AZURE_CLIENT_SECRET expired, or admin consent for SecurityIncident.Read.All was never granted. SaaS: the CMDash app was removed from your directory — reconnect.
• 403 Forbidden: The app registration lacks the SecurityIncident.Read.All application permission, or consent wasn't granted at the tenant level.
• No incidents even though Sentinel shows activity: Confirm your Sentinel workspace is onboarded to Microsoft 365 Defender's unified incident experience — Graph's /security/incidents endpoint only surfaces incidents from workspaces connected that way.
• Connection shows UNHEALTHY: The health check queries /security/incidents?$top=1; a persistent failure usually means the secret expired or consent was revoked.

Rate Limits & Sync Behavior

Credential Rotation

• CMDash SaaS: there is nothing on your side to rotate; CMDash rotates its own app's secret.
• Self-hosted: Azure AD client secrets expire (max 24 months). The secret is a server setting (AZURE_CLIENT_SECRET), shared by every CMDash Microsoft integration, and CMDash does not warn before it expires — keep a calendar reminder.

To rotate before expiry (self-hosted):

1. Go to App registrations → CMDash Integration → Certificates & secrets → New client secret.
2. Copy the new Value immediately.
3. Update AZURE_CLIENT_SECRET in the API's environment and restart the API.
4. Delete the old secret in Azure once a sync succeeds.

Multiple Instances / Multi-Site

A CMDash workspace holds one Sentinel connection, bound to one directory. If you run Sentinel in more than one Azure AD tenant (a production tenant and a subsidiary's, say), each needs its own CMDash workspace: on CMDash SaaS each workspace connects its own directory; a single-directory self-hosted install reads only AZURE_TENANT_ID, so a second directory needs the per-directory mode (AZURE_MULTI_TENANT=true, see the Entra ID guide) or its own deployment.

Compliance Framework Coverage

The Microsoft Sentinel integration provides evidence for the following controls. Coverage is automatically mapped when data is synced.