Microsoft Sentinel Guide: Data Connectors, Analytics Rules and Automation

Microsoft Sentinel holds the most sensitive telemetry an organisation collects, and the identities that run it, from analysts to playbooks and connector service principals, are rarely governed as tightly as the data they can read. Sentinel is moving from the Azure portal into the Microsoft Defender portal, gaining a data lake tier and new rule options, which changes how incidents, roles and automation behave. For SOC engineers and Azure administrators, this guide explains the platform model, the roles and non-human identities involved, how connectors, analytics rules and automation fit together, and a hardening baseline. For writing the queries themselves, see the KQL for Threat Hunting Guide linked below; for SIEM concepts in general, see the SIEM Guide.

Key takeaways

• The Defender portal is the destination. Microsoft states that after 31 March 2027 Sentinel will be supported only in the Microsoft Defender portal; the date was first announced as July 2026 and later extended.
• Onboarding changes behaviour, not just the user interface. Defender XDR creates the incidents, Fusion and Microsoft incident creation rules are switched off, and automation rules that match on incident titles or the Description field break.
• Sentinel roles are Azure RBAC, the data lake is not. Reader, Responder and Contributor are assigned on the workspace or resource group, while data lake access uses Microsoft Entra roles and Defender unified RBAC, so both planes need review.
• Playbooks and connectors are non-human identities. Logic App managed identities, connector app registrations and automation permissions on playbook resource groups can read or change incidents and often reach far beyond Sentinel.
• Tiering decides what you can detect. Analytics tier data feeds rules and fast hunting; lake tier data is cheap to keep for up to 12 years but must be promoted with jobs or searched before it drives detection.

Platform model: portals, tiers and content

Sentinel is a cloud SIEM and SOAR service on a Log Analytics workspace: connectors feed tables, analytics rules raise alerts and incidents, and automation acts on them. Content is packaged as Content hub solutions.

Azure portal versus Defender portal

Microsoft's "What's new" page first announced that Sentinel in the Azure portal would be retired in July 2026, then in January 2026 updated this: after 31 March 2027 Sentinel will be available only in the Defender portal and remaining Azure portal users will be redirected. Microsoft says the transition has no extra cost. The main operational differences after onboarding a workspace are:

• Incidents: all incidents are created by the Defender XDR correlation engine, the provider name is Microsoft XDR, and related alerts from Sentinel and Defender products merge into one queue.
• Correlation: the Fusion rule is disabled and Microsoft security (incident creation) rules are deactivated to avoid duplicates. Alert grouping settings still appear in rules, but Defender XDR controls grouping.
• Automation: alert-triggered automation rules act only on Sentinel alerts unless the Enhanced Alert Trigger is used, the Incident provider condition disappears, the Description field is removed from SecurityIncident, and incident sync can take 5 to 10 minutes.
• Multi-workspace: the Defender XDR connector attaches only to the primary workspace; standalone Microsoft connectors in secondary workspaces are disconnected.
• Data governance: Defender XDR data privacy policies apply. Log data stays customer-managed-key encrypted, but alerts and incidents are no longer CMK encrypted after onboarding, and lake data uses Microsoft-managed keys.

Analytics tier and data lake tier

Microsoft notes that analytics tier data is mirrored to the lake so one copy is kept, that commitment tiers can be raised at any time but lowered only once every 31 days, and that some sources are free to ingest, including Azure Activity logs, Office 365 audit logs, SentinelHealth and alerts from Defender products. Entra ID sign-in and audit logs are not in the free list. Keep detection-feeding identity logs in the analytics tier and move bulk investigation logs to the lake. See the Log Management and Retention Guide.

How identity and access work in Microsoft Sentinel

Three access planes apply to one deployment, and most permission surprises come from treating them as one.

• Querying across both: advanced hunting over Sentinel data needs at least Sentinel Reader on the workspace in addition to Defender permissions.
• Data lake roles: Microsoft documents broad lake read access for Global Reader, Security Reader, Security Operator, Security Administrator and Global Administrator, and broad write access (KQL jobs and notebooks that write to tables) for Security Operator, Security Administrator and Global Administrator. That means an Entra role, not a Sentinel role, decides who can write data back into the analytics tier.
• Table-level RBAC caveat: after Defender onboarding, IdentityInfo becomes a native Defender table without table-level RBAC, so any restriction set on it in the Azure portal is lost.
• Cumulative assignments: Microsoft warns that combining roles can grant more than intended, and that Azure Owner, Contributor and Reader and Log Analytics Contributor and Reader grant access beyond Sentinel.

For Entra-side role design, see the Entra ID Security Guide and the Azure RBAC and Service Principals Guide.

Admin roles and privileged access

• Assign at the resource group: Microsoft recommends resource group scope so the role covers the workspace, Logic Apps and workbooks together. Avoid subscription-wide Contributor for SOC staff.
• Treat Contributor as privileged: a Contributor can disable a rule, change its query so it never matches, or edit an automation rule that auto-closes incidents. These are defence impairment actions in their own right, mapped in ATT&CK v20 as T1685 Disable or Modify Tools.
• Use just-in-time elevation: make Contributor, Logic App Contributor and Owner eligible rather than permanent through Privileged Identity Management, with approval for Owner. See the Privileged Identity Management (PIM) Guide.
• Global Administrator: Microsoft advises reserving it for emergencies; it should not be the way analysts reach the data lake.

Integrations, API tokens and service accounts

A mature Sentinel workspace often has more non-human identities than human users: connector apps, managed identities on playbooks, Azure Function apps that pull from third-party APIs, and CI/CD identities that deploy content.

Data connectors

Microsoft states that support for the legacy HTTP Data Collector API ends after 14 September 2026, and that connectors using it should move to the Logs Ingestion API or CCF. See the API Key Management Guide.

Playbooks and automation identities

• Authentication options: a playbook's Sentinel connector can sign in as a managed identity (marked preview by Microsoft), a service principal with a client secret, or an Entra user. Microsoft advises against user accounts as the connector identity. Prefer managed identity where supported, because there is no secret to leak or rotate.
• Least privilege: grant the managed identity Sentinel Reader if the playbook only receives incidents, Responder if it updates incidents or watchlists. Response playbooks that disable users, revoke sessions or isolate devices hold separate Graph or Defender permissions: review those as privileged.
• Automation rule permission: to let automation rules run playbooks, the Sentinel service is granted permissions on the playbook's resource group, and Microsoft notes that any automation rule can then run any playbook in that group. Keep high-impact response playbooks in their own resource group.
• Onboarding grants: after Defender onboarding, Sentinel Contributor is assigned to the Microsoft Threat Protection and WindowsDefenderATP apps in the subscription. Document these so access reviews do not flag or remove them by mistake.
• Content as code: Sentinel repositories (generally available since March 2026) deploy content from GitHub or Azure DevOps. The pipeline's identity can rewrite every rule, so use workload identity federation instead of stored secrets and protect the main branch. See the Workload Identity Federation Guide.

Logging and detection

Analytics rule types

Microsoft documents that near-real-time frequency is not available for custom detections that include Sentinel data, so keep latency-critical identity detections as NRT analytics rules or check the current limits before converting. Map each rule to ATT&CK so coverage can be measured. See the Detection Engineering Guide.

Identity data worth connecting first

• Entra sign-in logs: SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs and AADManagedIdentitySignInLogs. The service principal and managed identity tables are where workload identity misuse shows up.
• Entra audit logs: AuditLogs records credential additions, consent grants and role assignments, the persistence steps behind T1098.001 Additional Cloud Credentials.
• Microsoft Graph activity logs: MicrosoftGraphActivityLogs shows what an app actually did with its permissions; it requires Entra ID P1 or P2 and can take up to two hours to arrive.
• UEBA: builds baselines into BehaviorAnalytics (InvestigationPriority 0 to 10), IdentityInfo, UserPeerAnalytics and Anomalies (AnomalyScore 0 to 1). Microsoft added Entra managed identity and service principal sign-ins as UEBA sources in preview in September 2025, and states that UEBA has no extra cost beyond data. See the UEBA Guide.

Monitoring Sentinel itself

• Health and audit: enable auditing and health monitoring so SentinelHealth and SentinelAudit record connector failures, rule failures and changes to rules and automation. SentinelHealth is free to ingest.
• Azure Activity: role assignments on the Sentinel resource group, Logic App edits and diagnostic setting deletions appear in AzureActivity. Alert on deletion of Entra diagnostic settings, which silently stops identity logging.

Metrics that show the platform is working

• Connector health: percentage of critical connectors with data in the last hour, and mean time to detect a silent connector.
• Rule health: count of analytics rules disabled, failing or auto-disabled in the period, each with an owner.
• Coverage: share of prioritised ATT&CK techniques with at least one enabled, tested rule.
• Identity hygiene: number of standing Contributor, Owner and Logic App Contributor assignments (target: zero standing for humans).
• Automation quality: share of incidents auto-closed by automation rules that are later reopened.

Hardening baseline

1. Inventory first: list every workspace, role assignment (Azure and Entra), Logic App, managed identity, connector credential and automation rule. Record an owner for each.
2. Plan the Defender transition: before onboarding, find automation rules that use the Incident provider condition, incident titles or the Description field, and rules relying on Fusion or Microsoft incident creation. Test onboarding with a non-production workspace first.
3. Cut standing privilege: move Contributor, Logic App Contributor and Owner to eligible assignments; scope SOC roles to the Sentinel resource group; remove Global Administrator as an analyst route to the lake.
4. Fix non-human identities: switch playbook connectors to managed identities, separate high-impact playbooks into their own resource group, move connector API keys to Key Vault with rotation, and replace pipeline secrets with federation.
5. Protect the logs: restrict who can edit Entra and Azure diagnostic settings and data collection rules, set table retention to the requirement (analytics plus lake), and use resource-context or table-level RBAC for teams that should not see identity data.
6. Detect tampering: enable SentinelAudit and SentinelHealth and add rules for disabled analytics rules, deleted diagnostic settings, new role assignments on the Sentinel resource group and Logic App identity changes.
7. Manage content as code: put rules and playbooks in a repository with review, so a bad change can be rolled back by redeploying the previous commit.
8. Test: pilot new rules in alert-only or low-severity mode, replay known-bad activity, and measure false positives for two weeks before enabling automation that closes or contains.

Choosing options

• Small organisation, single tenant: one workspace onboarded to the Defender portal, built-in roles, Microsoft solution content and pay-as-you-go until volume justifies a commitment tier.
• Large or regulated organisation: a primary workspace for Defender XDR data, regional workspaces only where data residency requires them, custom roles, content as code and lake retention aligned to legal hold.
• MSSP or multi-tenant: Lighthouse or the multitenant Defender portal, per-customer automation identities and no shared playbook credentials across tenants.

Common misconfigurations

• Service principal logs never connected: only SigninLogs is enabled, so app and managed identity activity is invisible. In the Microsoft Midnight Blizzard breach, a legacy OAuth app and new app credentials and consent grants carried the attack, exactly the activity found in AuditLogs and service principal sign-ins.
• Logging tier too thin to detect: mail access and app activity kept in no table or only in an unqueried tier. The Microsoft Storm-0558 key breach was found because one customer had premium audit logging and a custom alert on MailItemsAccessed; ingesting that data into an analytics tier with a rule is the SIEM lesson.
• Playbook identities with tenant-wide reach: a Logic App managed identity holding Graph permissions such as user management, edited by anyone with Logic App Contributor on a shared resource group.
• Standing Contributor for the whole SOC: any analyst can disable rules quietly, with no alert on the change.
• Connector secrets in plain app settings: third-party API keys in Function app settings, never rotated, with Function app owners outside the security team.

Framework mapping

Practitioner checklist

• Confirm your transition plan to the Defender portal ahead of 31 March 2027 and test it on a non-production workspace.
• Review automation rules for Incident provider, title and Description dependencies before onboarding.
• List all Azure and Entra role holders with access to Sentinel and the data lake, and remove standing Contributor and Owner.
• Connect SigninLogs, AADNonInteractiveUserSignInLogs, AADServicePrincipalSignInLogs, AADManagedIdentitySignInLogs and AuditLogs to the analytics tier.
• Move playbook connectors to managed identities with Reader or Responder only, and isolate high-impact playbooks.
• Move connector API keys and secrets into Key Vault with a rotation owner, and replace the HTTP Data Collector API before its end of support.
• Enable SentinelHealth and SentinelAudit and alert on rule disablement, diagnostic setting deletion and role changes.
• Set retention per table across analytics and lake tiers to match legal and investigation needs.
• Report connector health, rule health, ATT&CK coverage and standing privilege monthly.

Standards and references

• Microsoft Learn: What's new in Microsoft Sentinel
• Microsoft Learn: Transition your Microsoft Sentinel environment to the Defender portal
• Microsoft Learn: Roles and permissions in Microsoft Sentinel
• Microsoft Learn: Microsoft Sentinel data lake overview
• Microsoft Learn: Plan costs and understand Microsoft Sentinel pricing and billing
• Microsoft Learn: Threat detection in Microsoft Sentinel
• Microsoft Learn: Authenticate playbooks to Microsoft Sentinel
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: KQL for Threat Hunting Guide · SIEM Buyer's Guide · SOAR and Security Automation Guide · ITDR Guide · Cloud Logging and Audit Trail Guide