SC-500 Microsoft Sentinel: Workspaces, Roles, Data Connectors, Automation Rules and Retention

Microsoft Sentinel runs on top of a Log Analytics workspace: you create (or choose) a workspace and then add Microsoft Sentinel to it, and every connector, rule, playbook and retention setting afterwards belongs to that workspace. Data is isolated per workspace, so the workspace design decides where logs live and who can see them.

Prerequisites for enabling Microsoft Sentinel

• Contributor on the subscription that holds the workspace is the documented prerequisite for enabling Microsoft Sentinel; Sentinel- or Log Analytics-specific roles on their own aren't that prerequisite, and Microsoft Entra directory roles (such as Security Administrator) grant no Azure resource permissions at all.
• Defender for Cloud default workspaces are not eligible. The workspace that Defender for Cloud creates automatically doesn't appear in the list when you add Microsoft Sentinel. The only fix is a workspace you create yourself: build a new Log Analytics workspace in the region you want and add Microsoft Sentinel to that one. Eligibility is a property of how the workspace was created, not of permissions or plans attached to it.
• Plan the location first. After Microsoft Sentinel is deployed on a workspace, the workspace can't be moved to another resource group or subscription. If governance later requires it somewhere else, you build a new workspace there, enable Microsoft Sentinel and redeploy connectors, rules and automation (for example from exported templates or a content repository).

The Microsoft Defender portal

Microsoft Sentinel is now operated from the Microsoft Defender portal, where it is unified with Microsoft Defender XDR (Microsoft has announced that Microsoft Sentinel in the Azure portal is retired after 31 March 2027). A tenant can connect several workspaces to the Defender portal, but exactly one is the primary workspace; the rest are secondary and stay visible.

• The Defender XDR data connector follows the primary workspace: Defender XDR incidents and alerts are correlated with the primary workspace's data.
• To correlate XDR with a different workspace, change which workspace is primary, rather than enabling the XDR connector workspace by workspace or disconnecting the others.

Microsoft Sentinel uses three main Azure built-in roles, each adding to the previous one: Reader views data and content, Responder also manages incidents, and Contributor also creates and edits content such as analytics rules, workbooks and connectors. Assign them on the resource group that contains the workspace, so they also cover the workspace's other Sentinel resources. Role assignments are cumulative: a user with two roles has the union of both.

Least-privilege reasoning follows the table. A Reader who needs to save workbooks gets Workbook Contributor added, not Responder (which adds incident management and still no workbook rights). An analyst who must close incidents but not author rules needs Responder, not Contributor. Running playbooks is a separate permission from Sentinel's own roles: Microsoft Sentinel Contributor does not by itself let a user run playbooks.

Playbook permissions: who can run, edit and attach playbooks

Playbooks are Azure Logic Apps, so three different identities need three different permissions: users who run them need Microsoft Sentinel Playbook Operator, users who build them need Logic App Contributor, and Microsoft Sentinel itself needs permissions on the playbooks' resource group before automation rules can call them.

• Running manually from an incident or alert: Microsoft Sentinel Playbook Operator on the playbooks (or their resource group). It is the least-privilege choice when users must not create or modify playbooks.
• Creating and editing: Logic App Contributor. It includes edit rights, so it is too broad for run-only users.
• Running from automation rules: automation rules run playbooks as Microsoft Sentinel's service account, not as the user who created the rule. In Settings → Manage playbook permissions you select the resource groups that hold playbooks; this grants the service account Microsoft Sentinel Automation Contributor on them.

Two symptoms point to the same gap. If playbooks in a separate resource group appear greyed out in an automation rule's Run playbook list, the service account has no permissions there. Fixing it requires the person who uses Manage playbook permissions to hold Owner on that resource group (granting a role needs role-assignment rights; Microsoft Sentinel Contributor plus Logic App Contributor isn't enough). The principle: automation-rule access is always about the service account's rights on the playbooks' resource group, granted through Manage playbook permissions, never about the rights of the person who wrote the rule.

The Content hub is where you discover and install Microsoft Sentinel content; a solution bundles everything for one product or scenario (data connectors, parsers, analytics rule templates, hunting queries, workbooks and playbook templates), while standalone content items install individually. To onboard a new vendor's data in one step, install the vendor's solution from the Content hub. The Data connectors, Analytics and Workbooks pages only show content that is already installed.

• Permission: installing or updating content requires Microsoft Sentinel Contributor on the workspace's resource group. Responder can't install content; subscription-wide scope is broader than needed.
• Whole-solution installs: a solution is installed as a unit.
• Dependencies: many vendor solutions rely on a generic connector, such as Common Event Format (CEF) via AMA, Syslog via AMA or Custom Logs via AMA, that ships in its own solution. Choose Install with dependencies so the required connector solution is installed too.
• Templates are not active rules. Installing a solution adds analytics rule templates; nothing detects until you create rules from them.
• Updates: when a newer version of an installed solution is available, the Content hub flags it and you update it yourself (you can update several solutions at once), whereas standalone content items are kept up to date automatically.

Most Microsoft data connectors for Azure resources don't use an agent: they route platform logs into the workspace with diagnostic settings, and the connector deploys those settings at scale through an Azure Policy assignment.

Azure Activity and resource-log connectors

• The Azure Activity connector collects a subscription's control-plane operations (resource creation, deletion, role assignments). The connector page launches an Azure Policy assignment wizard that targets your Microsoft Sentinel workspace; it doesn't install agents, use the Logs ingestion API or rely on a Defender plan.
• Resource-log connectors (for example Azure Key Vault, which sends AuditEvent logs) work the same way: assign the connector's policy at the scope that covers your resources, such as the subscription, and every new resource receives the diagnostic setting automatically.
• Existing resources are only evaluated by a policy assignment. Create a remediation task (or tick the option in the assignment wizard) so the diagnostic setting is deployed to resources that already exist. Configuring each resource by hand doesn't scale and misses future resources.

Microsoft Entra ID connector

The Microsoft Entra ID connector streams Entra logs into tables such as SigninLogs and AuditLogs. Audit logs work with any Entra ID licence, but sign-in logs require Microsoft Entra ID P1 or P2. A tenant on the Free licence therefore sees AuditLogs fill while SigninLogs stays empty. The service-principal risk tables additionally need Microsoft Entra Workload ID Premium. Connecting requires Global Administrator or Security Administrator on the tenant plus workspace permissions.

Devices that can only send Syslog or Common Event Format (CEF) messages over the network, such as firewalls, proxies and appliances, reach Microsoft Sentinel through a Linux log forwarder: a Linux machine running a Syslog daemon (rsyslog or syslog-ng) that listens for remote messages and the Azure Monitor Agent (AMA), which a data collection rule (DCR) configures.

Setting up the forwarder

1. Make the forwarder an Azure resource. The DCR wizard's Resources tab lists only Azure VMs and Azure Arc-enabled servers. An on-premises or other-cloud forwarder must first be onboarded to Azure Arc by installing the Azure Connected Machine agent. Only an Azure resource identity (Azure VM or Arc) makes a machine selectable in a DCR; agents, endpoints and permissions don't create one.
2. Create the DCR from the connector page (Syslog via AMA or CEF via AMA) and select the forwarder. The DCR installs AMA and sets which facilities and log levels to collect.
3. Run the forwarder installation script on the machine so the Syslog daemon listens for remote messages on port 514 (TCP/UDP) and passes them to AMA.

Agents can't run on the appliances themselves, which is why the forwarder exists; Windows machines are not the forwarder for this pattern, and Custom Logs via AMA reads local files rather than network messages.

Choosing log levels

The connector page offers a minimum log level per facility, which is inclusive: choosing warning also collects error, critical, alert and emergency. To collect an exact set of levels (for example warning and error but not critical and above), create the DCR through the API, which accepts specific levels. The trade-off is that you install AMA on the forwarder manually before creating that DCR.

Avoiding duplicate Syslog and CEF ingestion

If a forwarder has both a Syslog via AMA DCR and a CEF via AMA DCR that collect the same facility, every CEF event is ingested twice: once into CommonSecurityLog and once into Syslog. Microsoft documents two fixes:

• Separate facilities at the source. Configure CEF devices to use a facility (for example local4) that only the CEF DCR collects, and remove that facility from the Syslog DCR. This works only if the sources can be changed and no plain Syslog source needs the same facility.
• Filter with an ingestion-time transformation on the Syslog DCR's stream that drops messages identified as CEF (for example by the CEF: header in the message or the process name). Use it when the facility is shared and can't be changed.

Both fixes work on what actually separates the two kinds of message, the facility or the CEF header. Settings that don't separate them, such as severity, can't remove duplicates, and each connector should still receive only the format it is built for.

Windows Security events reach Microsoft Sentinel through the Windows Security Events via AMA connector, which writes to the SecurityEvent table, or, when servers already forward their events to a collector with Windows Event Forwarding (WEF), through the Windows Forwarded Events connector, which writes to the WindowsEvent table.

Windows Security Events via AMA

The connector creates a DCR that installs AMA on the selected machines and chooses which Security events to collect:

To ingest only a handful of event IDs for cost reasons, use Custom with an XPath query; Common and Minimal are fixed sets that include more events, and collecting all events then filtering in queries still pays for ingestion. Machines outside Azure must be Azure Arc-enabled first, otherwise they don't appear in the DCR wizard. The legacy Log Analytics agent is retired and isn't an option.

Windows Event Forwarding

With WEF, source machines (such as domain controllers) forward events to a Windows Event Collector (WEC), so no agent is needed on the sources. To bring those events into Microsoft Sentinel:

1. Arc-enable the collector if it's on-premises (only the collector, not each forwarding server).
2. Create a Windows Forwarded Events DCR that targets the collector; AMA on the collector reads the ForwardedEvents channel. A Windows Security Events DCR on the collector would read only the collector's own Security log.

The table matters. Forwarded events land in WindowsEvent, even when they originally came from the Security log, not in SecurityEvent, Event or CommonSecurityLog. Many built-in analytics rules query SecurityEvent, so they won't match forwarded data. If those rules must work unchanged, collect the Security events with the Windows Security Events via AMA connector on the source servers. Otherwise you adapt the rules' queries, for example to ASIM normalized content that reads both tables. The destination table is fixed by the connector, not by how WEF is configured, so the decision is which connector collects the events.

A custom table stores data that has no built-in table, and its name always ends in _CL: create AppAudit on the Tables page and the portal names it AppAudit_CL, which is what you query in KQL. The DCR refers to the same table through a stream called Custom-AppAudit_CL. A suffix of _CF marks a custom column added to an Azure (built-in) table, not a table.

Creating the table and feeding it

• From the Log Analytics workspace's Tables page, create a new DCR-based custom log table, upload a JSON sample of the data, and optionally write a transformation; the wizard creates the table and a DCR together.
• Applications that can send data use the Logs ingestion API with that DCR. A DCR of kind Direct exposes its own ingestion endpoint, so it needs no separate data collection endpoint (DCE).
• For applications that only write text or JSON files on a machine and can't be changed, use the Custom Logs via AMA connector, which reads the files through the agent into a custom table (Microsoft Learn still labels this connector preview).

Schema changes don't flow through automatically

A DCR declares the incoming stream's columns and the transformation that maps them to the table. If you add a column to the table, the DCR is not updated automatically: until you add the field to the DCR's stream declaration and transformation, it is dropped before it reaches the table, and the new column stays empty. The fix is always on the DCR side: the stream declaration and transformation must know about every column you expect to arrive.

Table plans

The deciding questions are whether detections use the data (then Analytics) and how long it must stay directly queryable. Auxiliary trades query features for cost while staying queryable for its whole retention; Basic gives only a month of interactive queries before data needs search jobs or restore.

Automation rules are lightweight, centrally managed rules that run when an incident is created, an incident is updated, or an alert is created, check conditions, and then take actions: change status, severity or owner, add tags or tasks, and run playbooks. They handle routine triage without writing Logic Apps; playbooks handle anything that needs external systems.

Triggers and matching playbooks

• When incident is created and When incident is updated act on incidents; When alert is created acts on alerts. For an analytics rule with incident creation turned off there are no incidents, so only the alert trigger can respond.
• In the Defender portal, all incident creation happens in Microsoft Defender XDR, so Microsoft Sentinel's own incident-creation rules are turned off for onboarded workspaces. To act on Microsoft Sentinel analytics alerts there, use the alert trigger. The alert trigger doesn't cover Defender XDR alerts in the Defender portal; those are handled by the Defender portal's own automation.
• A playbook's trigger must match the rule: incident-trigger playbooks run from incident-trigger rules, and alert-trigger playbooks run from alert-trigger rules.

Update-trigger conditions

Update rules can test changes, not just states. Changed to fires when a property moves to a value (Severity changed to High), whereas Equals also matches incidents that were already High and were updated for some other reason. The Updated by condition tells you what made the change (for example a user, an application, an automation rule, a playbook or alert grouping), so you can react to an analyst's change while ignoring changes made by other automation.

Order and expiration

• Rules run in ascending order number, separately for each trigger. Each rule sees the incident as earlier rules left it: if one rule changes a property that a later rule tests (a tag, the owner, the severity), the later rule sees the changed value, so give the rule that must see the original data the lower order number. Rules with the same order number have no guaranteed sequence.
• Update-trigger rules run after the create-trigger rules for the same incident, so moving logic to the update trigger doesn't make it run earlier.
• An expiration date disables a rule automatically, which suits temporary handling, such as auto-closing incidents from a scheduled maintenance window or known test activity while keeping them on record, without someone remembering to switch the rule off. Suppression on the analytics rule is different: it stops the incidents being created at all.

Each table has two retention settings: analytics retention, during which data is fully queryable and used by detections, and total retention, after which data is deleted; the time between them is long-term retention, which is cheap but reachable only through search jobs or restore.

• Analytics retention can be set up to two years. Microsoft Sentinel-enabled workspaces include 90 days of analytics retention at no extra retention charge.
• Total retention can be set up to 12 years, so long regulatory retention (for example seven years) is met with a short analytics period and a long total period rather than paying for years of analytics retention.
• Table settings override the workspace default. A table with its own retention ignores later changes to the workspace default; change the table itself.
• Shortening retention has a grace period. When you reduce retention, Azure Monitor waits 30 days before removing the data that falls outside the new period, so a mistaken reduction can be reversed by setting the old value back within that window, at no extra cost.

Getting data back from long-term retention

Interactive tools, including hunting queries, Advanced hunting, workbooks and Livestream, don't reach long-term retention. Data export only copies newly ingested data, so it can't recover older records.

The Audit page in the Microsoft Defender portal searches the Microsoft 365 unified audit log, the same log and the same search experience as Audit in the Microsoft Purview portal, so SOC analysts can investigate user and admin activity in Exchange, SharePoint, OneDrive, Teams, Microsoft Entra ID and other services without leaving Defender.

Permissions

• View-Only Audit Logs (assigned in the Microsoft Purview portal) allows searching the audit log only, which is least privilege for analysts.
• Audit Logs also allows managing audit settings such as audit retention policies.
• Broad roles like Compliance Administrator reach far beyond auditing, and Microsoft Sentinel roles don't grant access to the unified audit log.

Search jobs

An audit search runs as a search job in the background; you can leave the page and return to the results later.

Default retention depends on the acting user's licence

So whether an old record still exists depends on two things: the licence of the user who performed the action and the workload it came from. With no custom audit retention policy, anything older than 180 days survives only for Audit (Premium) users in the four one-year workloads. Missing records are a retention question, not a portal question: Defender and Purview search the same data.