L16. Onboarding Data to Microsoft Sentinel: Workspaces, Connectors & Event Collection
Video generating
Check back soon for the video lesson on Onboarding Data to Microsoft Sentinel: Workspaces, Connectors & Event Collection
Course outlineLesson 16 of 18
A SIEM is only as good as what it can see, and Sentinel's entire ingestion story is really just three problems: getting Azure-native signals in, getting non-native devices in through syslog and Windows event forwarding, and knowing where a custom log should live once it arrives.
Creating and Connecting Workspaces
Microsoft Sentinel is deployed on top of a Log Analytics workspace, its query engine, storage, and cost model. Enabling Sentinel on a workspace doesn't create a new store, it layers Sentinel's SIEM/SOAR capabilities (analytics rules, incidents, workbooks, automation) onto an existing Log Analytics workspace. Workspace design decisions (single central workspace vs. multiple regional/business-unit workspaces) affect both query performance and role-based access boundaries, since access can be scoped at the workspace level.Assigning Roles in Microsoft Sentinel
Sentinel has its own set of built-in Azure RBAC roles, layered on top of general Log Analytics workspace roles:
- Microsoft Sentinel Reader: view data, incidents, and workbooks only
- Microsoft Sentinel Responder: Reader rights plus managing incidents (assign, close, comment)
- Microsoft Sentinel Contributor: Responder rights plus creating and editing analytics rules, workbooks, and other Sentinel resources
Assigning the narrowest applicable role (a Tier 1 analyst as Responder rather than Contributor, for example) follows the same least-privilege discipline covered in earlier lessons, applied specifically to SOC tooling.
Content Hub Solutions
The content hub packages a related bundle of analytics rules, workbooks, playbooks, and a data connector together for a specific product or scenario (for example, an "Azure Activity" or a specific third-party firewall solution), so onboarding a new data source is a single install rather than manually recreating each individual artifact from scratch.
Data Connectors for Azure Resources
Most Azure-native signals reach Sentinel through diagnostic settings configured on the resource itself, forwarding logs to the connected Log Analytics workspace, plus purpose-built connectors (Microsoft Entra ID sign-in/audit logs, Azure Activity, Microsoft 365 Defender) that require enabling the connector but little further configuration since the data source and Sentinel are both first-party Microsoft services.
Syslog and CEF Collection
Non-Windows and network/security appliances typically forward via Syslog or the richer, more structured Common Event Format (CEF). Collection today runs through the Azure Monitor Agent (AMA) installed on a Linux forwarder machine, configured via a Data Collection Rule (DCR) that defines exactly which facilities/log levels to collect and where they land, replacing the older legacy Log Analytics agent (MMA), which is retired.
Windows Security Event Collection
Similarly, Windows Security events are collected via AMA and a DCR specifying which event collection tier to gather (All Events, Common, Minimal). For servers that cannot run AMA directly (isolated network segments, legacy OS), Windows Event Forwarding (WEF) lets a central collector machine gather events from many source machines over the native Windows event subscription mechanism, and that collector then forwards to Sentinel via its own AMA installation, extending coverage without installing an agent on every individual source machine.
Custom Log Tables
When a data source has no existing connector or standard schema, a custom log table can be defined directly in the workspace, using a DCR to specify ingestion-time transformations (parsing, filtering, renaming columns) so the data lands in a clean, purpose-built schema rather than requiring transformation logic to be repeated in every KQL query written against it afterward. Exam tip: The exam distinguishes the *collection mechanism* (AMA + DCR is the modern path for nearly everything now, syslog/CEF, Windows Security events, custom logs) from the *legacy* mechanism (the retired Log Analytics/MMA agent), and expects you to recognize Windows Event Forwarding specifically as the answer when a source machine cannot run AMA directly itself.
- ✓Microsoft Sentinel layers SIEM/SOAR capabilities onto an existing Log Analytics workspace rather than creating a separate data store
- ✓Sentinel RBAC roles (Reader, Responder, Contributor) should be assigned at the narrowest level a given analyst's job actually requires
- ✓Content hub solutions bundle analytics rules, workbooks, playbooks, and a connector together for one-step onboarding of a data source
- ✓Syslog/CEF and Windows Security event collection both run through the Azure Monitor Agent configured via a Data Collection Rule, replacing the retired legacy Log Analytics agent
- ✓Windows Event Forwarding lets a central collector gather events from source machines that cannot run AMA directly, with the collector then forwarding to Sentinel via its own AMA
- ✓Custom log tables use ingestion-time DCR transformations so data lands in a clean schema instead of requiring repeated parsing logic in every KQL query
1. A Tier 1 SOC analyst needs to view and triage incidents (assign, close, comment) but should not be able to create or modify analytics rules. Which built-in Sentinel role fits?
2. A legacy on-premises server sits on an isolated network segment and cannot run the Azure Monitor Agent directly. How can its Windows Security events still reach Microsoft Sentinel?
3. What is the primary benefit of installing a content hub solution instead of manually recreating a data connector, analytics rules, and workbooks individually?
Recommended: Pluralsight
This free course covers the theory. Pluralsight adds structured Cloud and AI Security Engineer learning paths, hands-on Azure and Defender for Cloud labs, and timed practice exams to make it stick before exam day.