Using Managed Identities in Azure AD response playbooks
Some notes related to authenticating with the out-of-the-box (OOTB) provided Microsoft Sentinel Playbooks for Azure AD.
The Microsoft Sentinel Content Hub Solution for Azure Active Directory contains a few interesting Playbook templates:
I have deployed these for customers and noted some things related to authentication that are important to understand when using the Solution templates:
The Playbooks use the standard Azure AD Actions in Logic Apps, which do not support using Managed Identity to connect to Azure AD.
This is important, as identity best practice guides us to avoid using traditional Service Accounts in the cloud and to use service principals and Managed Identities instead.
When we look at one of the built-in Playbook templates, it may give us the idea that we can actually do response activities with the Managed Identity of the Azure AD Playbooks.
For reference, see ”Post deployment step #2” in the screenshot from playbook template Block AAD user - Incident:
This is a bit misleading, as in reality these API permissions would not work for this template, as the Azure AD Actions provided by Logic Apps only support a normal logged in user:
The Add new button in Azure AD actions directs to regular user login, there is no option to use the Logic App’s Managed Identity.
So unlike the template instructs us, we either have to
Accept this and use a Service Account with one of the Azure AD roles that allow Blocking an account, such as User Administrator.
Rewrite the template to not use the Azure AD connector and instead call the Azure AD API with HTTP requests using Managed Identity.
I have prepared a version of this Playbook that uses the alternative HTTP approach. At the end of this article I have a link to it, but before that some explanations are in order.
The relevant action in the Playbook template is this use of the Update user Azure AD Action:
This sets account enabled = No setting for the target user.
Luckily this same setting is very easy to control with a HTTP request.
We need to call the Graph API with the following request and body:
PATCH https://graph.windows.net/v1.0/users/{user_id}
{
"accountEnabled": false
}This is easy to transfer to a Logic App HTTP action:
As you can see, we can now use the Managed Identity to authenticate to Graph API.
The API permissions I have set for this Managed Identity are “User.Read.All” and “User.EnableDisableAccount.All”. The first one mainly as I prefer to check the existence of the target account before proceeding in the Logic App.
One thing to note here is that the User.EnableDisableAccount.All permission can disable any account in Azure AD so if you use this in a fully automated response situation, you want to make sure you control the logic and never target critical accounts you never want automatically disabled.
Going through the other playbook templates and replacing the Azure AD actions with HTTP is pretty easy. I have one actual example for you below.
Template for deployment
I have created a custom version of the Block-AADUser-Incident that uses this HTTP approach. You can find and deploy it from this repository:
https://github.com/mikoiv/MicrosoftSentinel-Playbooks/tree/main/Block-AADUser-Incident-HTTP
This is mostly the same as Microsoft-provided template, with the following changes:
Azure AD Actions replaced with HTTP requests.
The “send e-mail to user’s manager” action is removed as I have no need for that.
This is rough sketch, works in my lab tenant, as always you want to test and investigate for yourself before using these.
Remember to grant the API permissions for the Managed Identity after deployment.
Reference documentation
Below are some links related to this article:
Use the Microsoft Graph API - Microsoft Graph | Microsoft Learn
Microsoft Graph permissions reference - Microsoft Graph | Microsoft Learn