Microsoft Sentinel Setup From Scratch 2026: Portal, Defender & Infrastructure-as-Code

Log Analytics Workspace

The storage and query engine. All logs land here in typed tables you query with KQL. Retention, cost and access are all governed at the workspace level.

Data Connectors

Deployed from the Content hub as solutions. They forward events from Entra ID, Azure Activity, Defender XDR, firewalls and Syslog/CEF sources into the workspace.

Analytics Rules

Scheduled KQL queries that run on an interval, map entities and MITRE techniques, and raise alerts that group into incidents.

Automation & Playbooks

Automation rules trigger Logic Apps playbooks — disable a user, isolate a device, post to Teams — turning Sentinel from SIEM into SOAR.

Workbooks & Hunting

Workbooks visualise your data; hunting queries and bookmarks let analysts proactively search across the whole workspace for threats no rule caught.

UEBA & Threat Intel

Entity behaviour analytics baselines users and hosts; the TI connector matches indicators from feeds against your logs to surface known-bad activity.

Sentinel needs a home. Create a dedicated resource group and a Log Analytics workspace in your chosen region. You can do this in the portal, but the CLI is faster and repeatable.

In the Azure portal, search for and open Microsoft Sentinel, click Create, select the workspace you just built, and click Add. This attaches the Sentinel analytics layer to that workspace.

• 1Portal home > search Microsoft Sentinel > Create.
• 2Select law-sentinel-prod from the list, then Add.
• 3Wait for provisioning; Sentinel opens on the Overview blade.

The portal "Add" button is really an onboarding-state resource. If you prefer to script it — for example inside a deployment runbook — the Az.SecurityInsights module does the same thing in one line.

Confirm the onboarding state exists:

Legacy pricing tiers default to 30-day retention. Sentinel includes 90 days of analytics-log retention at no extra ingestion charge, so raise it. You can extend interactive retention up to two years, and archive older data for long-term compliance.

Before ingesting data, confirm Sentinel is genuinely attached. Open Logs and run a metadata query — even an empty workspace answers this.

New tenants with Owner or User Access Administrator rights are onboarded automatically. If yours was not, connect it manually from the Defender portal.

• 1Select the law-sentinel-prod workspace as the primary workspace for the tenant.
• 2Confirm; provisioning the unified experience takes a few minutes on first use.
• 3Sentinel now appears in the Defender navigation with its nodes nested beneath it.

Once onboarded, some navigation moves. Data connectors and analytics live under Sentinel's own nodes; incidents merge into the single Defender queue. The KQL is identical — Advanced Hunting in Defender queries the same tables as Logs in Azure.

The azurerm provider models both the workspace and the Sentinel onboarding as first-class resources. This is the minimum viable Sentinel, fully declarative.

If you are all-in on Azure Resource Manager, Bicep expresses the same deployment. The Sentinel resource is Microsoft.SecurityInsights/onboardingStates, scoped to the workspace.

All three land you a working Sentinel. Pick based on how you will operate it long-term.

Use Sentinel's purpose-built roles, not broad Owner grants. Responders should be able to work incidents without touching workspace configuration.

User and Entity Behavior Analytics baselines normal activity per user and host, so anomalies (a first-time admin action, an atypical geography) become scoreable signals. Enable it early — it needs time to learn.

Everything in Sentinel — detections, hunting, workbooks — is KQL. If you have never written it, these five operators cover most of what you will do daily. Run them in Logs / Advanced hunting.

The Content hub is the marketplace for connectors and detections. Install the solution first; the connector page appears afterwards.

Identity is where most intrusions become visible. The Entra ID connector streams sign-in and audit logs — the foundation for detecting password spray, impossible travel and consent abuse. It is a diagnostic-settings connector, configurable from Entra.

Azure Activity logs every control-plane operation — role assignments, resource deletions, policy changes. The modern connector is delivered through an Azure Policy assignment so every subscription in scope forwards automatically.

• 1Open the Azure Activity connector page, click Launch Azure Policy Assignment Wizard.
• 2Set Scope to the subscription(s) you want to monitor.
• 3On the Parameters tab, set the primary workspace to law-sentinel-prod.
• 4Review + create. New subscriptions in scope are covered automatically.

There are hundreds of connectors. Connecting all of them is how bills explode and signal drowns in noise. Sequence by detection value per GB.

Firewalls and appliances that emit Syslog/CEF send to a dedicated Linux VM running rsyslog and AMA. The VM receives on 514 and AMA ships the parsed events to your workspace. Size it modestly — one forwarder handles thousands of EPS.

Install AMA on the forwarder as a VM extension. On an Azure VM this is one command; for an on-prem host, enroll it in Azure Arc first, then install the same extension.

The DCR tells AMA which facilities and severities to collect and where to send them. Create it from the connector page (CEF via AMA / Syslog via AMA), which also drops the rsyslog forwarding config onto the VM. Verify that config landed:

If you onboarded to the Defender portal (Phase 4), XDR incidents already flow in. Otherwise, enable the Defender XDR service-to-service connector to pull endpoint, identity, email and cloud-app alerts into Sentinel with one toggle — no agent, no cost for the alert data.

• 1Content hub > install Microsoft Defender XDR solution.
• 2Open the connector > connect incidents & alerts.
• 3Optionally stream raw advanced-hunting tables (DeviceEvents, IdentityLogonEvents) for custom KQL.

Every solution you installed shipped rule templates. Enable the relevant ones before authoring anything custom — they are maintained by Microsoft and cover the common cases.

A scheduled rule is a KQL query plus a schedule, entity mapping and MITRE tagging. This one flags a single source IP failing against many distinct accounts — classic password spray.

• 1Run frequency 1 hour, lookup period 1 hour.
• 2Entity mapping: Account → UserPrincipalName, IP → IPAddress.
• 3Tactics: Credential Access; Technique: T1110 Brute Force.
• 4Incident grouping: group alerts on the same IP into one incident.

Click-built rules drift and vanish with the person who made them. Define detections in Terraform so they are versioned, reviewed and repeatable across environments.

A playbook is a Logic App triggered by an automation rule. Common first playbooks: post the incident to a Teams/Slack channel, disable a compromised user in Entra, or isolate a device via Defender. Wire it to the rule with an automation rule.

• 1Content hub or Configuration > Automation > import/create a playbook (Logic App).
• 2Grant the playbook's managed identity the Sentinel Responder role so it can act on incidents.
• 3Create an automation rule to run the playbook on matching incidents.

Not every threat trips a rule. The Hunting node ships MITRE-aligned queries you run on demand; bookmark interesting rows and promote them into incidents. A useful starting hunt: newly created service principals with credentials added — a common persistence move.

Before committing to a tier, measure. This query shows your daily ingestion by table over the last week — the numbers that decide your commitment tier and reveal which table to move to a cheaper plan.

A firewall that stops logging is a blind spot you will not notice until an incident. Alert on data-source silence and monitor the SentinelHealth table for connector and automation failures.

Nearly every "Sentinel isn't working" ticket is one of these. Check them in order before opening a support case.

Bake these into a recurring runbook so the instance stays sharp instead of slowly rotting.

• 1Weekly: review the Usage query, tune noisy rules, clear the incident backlog.
• 2Monthly: update Content hub solutions, review new rule templates, check SentinelHealth trends.
• 3Quarterly: re-validate commitment tier against actual ingestion; run SOC optimization recommendations.
• 4Continuously: ship every new detection through IaC and code review, not the portal.