Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Important
Attention: All Microsoft Sentinel features will be officially retired in Azure in China regions on August 18, 2026 per the announcement posted by 21Vianet.
This article explains how Microsoft Sentinel assigns permissions to user roles for Microsoft Sentinel SIEM, identifying the allowed actions for each role.
Microsoft Sentinel uses Azure role-based access control (Azure RBAC) to provide built-in and custom roles for Microsoft Sentinel SIEM. Roles can be assigned to users, groups, and services in Azure.
Important
Azure recommends that you use roles with the fewest permissions. This helps improve security for your organization. Global Administrator is a highly privileged role that should be limited to emergency scenarios when you can't use an existing role.
Built-in Azure roles for Microsoft Sentinel
The following built-in Azure roles are used for Microsoft Sentinel SIEM and grant read access to the workspace data. Assign these roles at the resource group level for best results.
| Role | SIEM support |
|---|---|
| Microsoft Sentinel Reader | View data, incidents, workbooks, and other resources |
| Microsoft Sentinel Responder | All Reader permissions, plus manage incidents |
| Microsoft Sentinel Contributor | All Responder permissions, plus install/update solutions, create/edit resources |
| Microsoft Sentinel Playbook Operator | List, view, and manually run playbooks |
| Microsoft Sentinel Automation Contributor | Allows Microsoft Sentinel to add playbooks to automation rules. Not used for user accounts. |
For example, the following table shows examples of tasks that each role can perform in Microsoft Sentinel:
| Role | Run playbooks | Create/edit playbooks | Create/edit analytics rules, workbooks, etc. | Manage incidents | View data, incidents, workbooks | Manage content hub |
|---|---|---|---|---|---|---|
| Microsoft Sentinel Reader | -- | -- | --* | -- | ✓ | -- |
| Microsoft Sentinel Responder | -- | -- | --* | ✓ | ✓ | -- |
| Microsoft Sentinel Contributor | -- | -- | ✓ | ✓ | ✓ | ✓ |
| Microsoft Sentinel Playbook Operator | ✓ | -- | -- | -- | -- | -- |
| Logic App Contributor | ✓ | ✓ | -- | -- | -- | -- |
*With Workbook Contributor role.
We recommend that you assign roles to the resource group that contains the Microsoft Sentinel workspace. This ensures that all related resources, such as Logic Apps and playbooks, are covered by the same role assignments.
As another option, assign the roles directly to the Microsoft Sentinel workspace itself. If you do that, you must assign the same roles to the SecurityInsights solution resource in that workspace. You might also need to assign them to other resources, and continually manage role assignments to the resources.
Additional roles for specific tasks
Users with particular job requirements might need to be assigned other roles or specific permissions in order to accomplish their tasks. For example:
| Task | Required roles/permissions |
|---|---|
| Connect data sources | Write permission on the workspace. Check connector docs for extra permissions required per connector. |
| Manage content from Content hub | Microsoft Sentinel Contributor at the resource group level |
| Automate responses with playbooks | Microsoft Sentinel Playbook Operator, to run playbooks, and Logic App Contributor to create/edit playbooks. Microsoft Sentinel uses playbooks for automated threat response. Playbooks are built on Azure Logic Apps, and are a separate Azure resource. For specific members of your security operations team, you might want to assign the ability to use Logic Apps for Security Orchestration, Automation, and Response (SOAR) operations. |
| Allow Microsoft Sentinel to run playbooks via automation | Service account needs explicit permissions to playbook resource group; your account needs Owner permissions to assign these. Microsoft Sentinel uses a special service account to run incident-trigger playbooks manually or to call them from automation rules. The use of this account (as opposed to your user account) increases the security level of the service. For an automation rule to run a playbook, this account must be granted explicit permissions to the resource group where the playbook resides. At that point, any automation rule can run any playbook in that resource group. |
| Guest users assign incidents | Directory Reader AND Microsoft Sentinel Responder The Directory Reader role isn't an Azure role but a Microsoft Entra ID role, and regular (nonguest) users have this role assigned by default. |
| Create/delete workbooks | Microsoft Sentinel Contributor or a lesser Microsoft Sentinel role AND Workbook Contributor |
Other Azure and Log Analytics roles
When you assign Microsoft Sentinel-specific Azure roles, you might come across other Azure and Log Analytics roles that might be assigned to users for other purposes. These roles grant a wider set of permissions that include access to your Microsoft Sentinel workspace and other resources:
- Azure roles: Owner, Contributor, Reader – grant broad access across Azure resources.
- Log Analytics roles: Log Analytics Contributor, Log Analytics Reader - grant access to Log Analytics workspaces.
Important
Role assignments are cumulative. A user with both Microsoft Sentinel Reader and Contributor roles may have more permissions than intended.
Recommended role assignments for Microsoft Sentinel users
| User type | Role | Resource group | Description |
|---|---|---|---|
| Security analysts | Microsoft Sentinel Responder | Microsoft Sentinel resource group | View/manage incidents, data, workbooks |
| Microsoft Sentinel Playbook Operator | Microsoft Sentinel/playbook resource group | Attach/run playbooks | |
| Security engineers | Microsoft Sentinel Contributor | Microsoft Sentinel resource group | Manage incidents, content, resources |
| Logic App Contributor | Microsoft Sentinel/playbook resource group | Run/modify playbooks | |
| Service Principal | Microsoft Sentinel Contributor | Microsoft Sentinel resource group | Automated management tasks |
Custom roles and advanced RBAC
To restrict access to specific data, but not the whole workspace, use resource-context RBAC or Table-level RBAC. This is useful for teams needing access to only certain data types or tables.
Otherwise, use the following option for advanced RBAC:
- Use Azure custom roles.
Related content
For more information, see Manage log data and workspaces in Azure Monitor