During Microsoft Ignite in November 2021, Azure Sentinel is now called Microsoft Sentinel.
Automation rules streamline your automation use in Azure Sentinel and enable you to simplify complex workflows for your security orchestration, automation, and response (SOAR) processes.
In this article, we will share with you how to resolve the missing required playbook triggering permissions when you attempt to create an automation rule in Azure Sentinel.
Table of Contents
Azure Sentinel is a cloud-native Security Information Event Management (SIEM) and Security Orchestration Automated Response (SOAR) solution. Azure Sentinel delivers intelligent security analytics and threat intelligence across the enterprise, providing a single solution for alert detection, threat visibility, proactive hunting, and threat response.
Automation rules are a new concept introduced in Azure Sentinel. This feature allows you to centrally manage the automation of incident handling. Besides letting you assign playbooks to incidents (not just to alerts as before), automation rules also allow you to automate responses for multiple analytics rules at once, automatically tag, assign, or close incidents without the need for playbooks and control the order of actions that are executed.
To learn more about Automation rules, please check the official documentation from Microsoft.
I was recently creating automation rules in Azure Sentinel by defining to run playbooks as an action. As soon as I hit ‘Apply‘, I received the following error message:
Failed to save automation rule
With the following error message: Error: Caller is missing required playbook triggering permissions on playbook resource, or Azure Sentinel is missing required permissions to verify the caller has permissions.
However, we were able to create automation rules to Change status, Change severity, Assign owner, and Add tags as a set of actions except that we cannot Run playbooks.
When creating an automation rule to run playbook as an action to respond to incidents, Microsoft indicates in their documentation that Azure Sentinel must be granted explicit permissions to run playbooks from automation rules.
In the automation blade, if a playbook appears “grayed out” in the drop-down list as shown in the figure below, it means that Sentinel does not have permission to that playbook’s resource group.
In my case, the playbooks were showing fine without any issue as shown in the figure below.
We can eliminate this potential cause because Azure Sentinel has permission to that playbook’s resource group.
Additionally, if we click on the “Active playbooks” tab under the Automation page as shown in the figure below, we can see the list of all playbooks in the respective subscription and resource group. This again proves that Sentinel has access permission to that playbook’s resource group.
Next, Microsoft also noted that you (yourself) must have “Owner” permissions on any resource group to which you want to grant Azure Sentinel permissions, and you must have the “Logic App Contributor” role on any resource group containing playbooks you want to run.
So let’s look and verify my access under the resource group where Azure Sentinel and Logic Apps are created. As you can see in the figure below, I have full access to “Owner“, “Logic App Contributor“, “Azure Sentinel Contributor“, “Azure Sentinel Automation Contributor“, and more…
This is not a multi-tenant deployment, no Azure Lighthouse setup in this case. So what is the issue?
Finding the cause
After we started eliminating the potential root causes following the prerequisites documented by Microsoft, I noticed that none of them is related directly to my issue. I thought this could be a bug unless there is any reason to do so.
In the same document, Microsoft mentioned that you can configure permissions by clicking the Manage playbook permissions link to assign permissions. In the Manage permissions panel that opens up, select the checkboxes of the resource groups containing the playbooks you want to run, and then click Apply.
I went to the Settings blade > Settings tab, and then Playbook permissions expander. I clicked the Configure permissions button to open the Manage permissions panel. However, I have no results in both, the Browse tab, as well as the Current permissions tab as shown in the figure below.
This gave me an indication that I don’t have the right permissions to do so.
I reached out to the Azure Sentinel team and we start debugging this issue, collecting logs for over two days without success.
As a workaround but not a final solution (more on this in a bit), they told me to assign manually the “Azure Security Insights” (Enterprise Application) on the resource group and give it the “Azure Sentinel Automation Contributor” role. But, I need to find the root cause for this issue.
Fixing the issue
In this tenant, I am invited to Azure AD as a guest B2B user with an external identity and I have read access on the subscription level only. When I tried to add the “Azure Security Insights” enterprise app on the resource group level, I was not able to do so as shown in the figure below.
You are a guest user in this directory. You can search for users by their exact sign-in name, but you cannot search for groups or applications, and you cannot browse.
Since I am a guest user in this tenant, I can add users by their exact sign-in name only, but I cannot add applications (service principals) and groups.
After digging deeper, I found out that you need to have read access on the directory in Azure AD to add enterprise applications (service principals).
In this case, if you want a guest user to have full read access to your directory, then you can add the guest user to the Directory Readers role in Azure AD. Users in this role can read basic directory information, this role should be used for granting service principals access to the directory where Directory.Read.All is not an option.
After my account was assigned to the Directory Readers role in Azure AD, I was able to Configure permissions on the resource group/subscription where I have access by giving Sentinel permissions to run playbooks as shown in the figure below.
And finally, I was able to create automation rules and assign playbooks as actions.
Hope this helps someone out there!
In this quick guide, we showed you what are the required permissions that you need to configure permissions and create automation rules to run Logic Apps as an action.
Azure Sentinel leverages the Azure Security Insights Enterprise Application in Azure AD to grant explicit permissions to run playbooks from automation rules. And since now we know what is the least privileged (Directory Readers) role that we need to give our guest users (partners) to configure and create automation rules. We can also go a step further and create a custom role in Azure AD with the “microsoft.directory/servicePrincipals” as an action instead of using the built-in (Directory Readers) role.
Additional resources I highly encourage you to check:
- Learn how to monitor Azure Storage account activity logs with Azure Sentinel.
- Learn how to monitor Azure AD emergency accounts with Azure Sentinel.
- Learn more about Azure Sentinel, check the official documentation from Microsoft.
- Learn about Analytics Rules, check the official documentation from Microsoft.
- Learn about Playbooks, check the Azure Sentinel’s GitHub page contributed by the community and Microsoft.
The power of Azure Sentinel comes from the ability to detect, investigate, and remediate threats. To do this, you must first ingest data from different sources, such as Azure platform logs, Azure AD, Azure Security Center, or other Microsoft security solutions, as well as other third-party solutions.
Thank you for reading my blog.
If you have any questions or feedback, please leave a comment.