Last week I wrote the first blog post about getting notified on Microsoft Endpoint Privilege Management elevation requests for which somebody needs to take action.
In that blog post, I showed how we can create our own notification service for Microsoft EPM. In the example, the requester’s manager receives an Adaptive Card in the Teams chat, redirecting the manager to the Microsoft Intune portal.
In this blog post, we expand this solution by allowing the manager to approve or deny the elevation request directly from the Teams client.
We also shortly discuss the information we write back to the EPM service about the approver (in our case the manager) for auditing purposes.
Requirements
The requests for this solution were discussed in part 1 of the blog post, but as we not only want to retrieve the EPM elevation requests but also want to approve/ deny them, the permissions for our Managed Identity are changed.
We need to assign our Managed identity the DeviceManagementConfiguration.ReadWrite.All permission.
Besides that, I also want to inform the end-user when the request is denied, something that’s not handled by EPM. For this we could use the service account that we already have to send a Teams message to the manager. We could also inform the user via a Teams message.
In my example, I inform the user via an e-mail. Thus we also need to make sure the service account has permissions on a shared mailbox, to send an e-mail using a shared mailbox.
Expand our Logic Apps flow
I assume you have built the flow from part 1. We are going to expand this flow with a couple of new actions.
The first step we will take is to replace the Post a card in a chat or channel action, with a Post adaptive card and wait for a response action.
This is almost the same action we previously configured, but with the big difference, this action will wait for a response. In our case, the response is the approval from the manager.
This also means we need to change the design of our Adaptive card. Let’s first have a look at the Adaptive cards designer.
We want the manager to be able to provide feedback on the elevation request. To be able to do that, we need to add Input fields to the card.
We have several Input actions available, so we can design the card for our needs. The below is just an example of how I created it.
In my case, I added an Input.ChoiceSet (1) and Input.Text (2).
In the Input.ChoiceSet I configure a drop-down list from which the manager can choose Approve or Deny.
In the Input.Text the manager needs to enter the justification text for the response.
When we added the Input fields to the card, we need to configure these input fields.
Select the Input.ChoiceSet to configure this input field.
We need to enter an Id (1), add a Label (2) and enter a Placeholder (2).
Besides that I want the field to be a required field, thus I select Required (4).
I enter an Error message (5) which shows up in case an error occurs when submitting the info. And as last I fill in the Choices (6). I enter Approve and Deny (twice). One to show in the Adaptive Card as an option in the list, and the second time it’s the info sent back to the Logic Apps flow.
If we now hit the Preview mode button, we get a preview of our newly designed card. As you can see we can select Approve or Deny.
Next, we need to configure the Input.Text field.
We need to add an Id (1), Label (2) and Placeholder (2) again.
I also want this field to be required (4) and I enter an Error message (5).
Now we need to select the whole adaptive card, click Add an action and select Action.Submit.
If we hit the Preview Mode button again, we can see the result of our card. When we hit the Submit button without selecting a response or filling in an approval justification, an error message is shown as we previously configured.
Now we switch to the Logic Apps flow in the Azure portal.
We need to remove the existing Teams action and add an Post adaptive card and wait for a response action to the flow.
We select Flow bot under Post as and Chat with Flow bot under Post In.
In the Recipient field, we need to add the variable mail from the manager again.
In the Message body field, we need to past the card payload from the card designer and add the variables again, as shown in the previous post.
We need to Parse the output from the Post Adaptive card action with a Parse JSON action, so we can use the information of the action in follow-up actions. We can create the schema we need for the Parse JSON action, like we can create it for an HTTP action, by running the flow and copying the body. So, run the flow and copy the body of the Adaptive card action.
In the Content field add Body from the Adaptive card action. Create the schema via the Use sample payload option.
Next, we need to add a Switch action to our flow, which is a Control action. We use this switch action because we need to take different actions on an approval or deny.
When the response is received from the manager, this is found back in the body under ResponseSelectionId (this is the Id we filled in the Adaptive Card designer for the Input.ChoiceSet field). ResponseSelectionId holds the value Approve or Deny, on which we can make the switch. Therefore under On, we select ResponseSelectionId.
Next, we need to add two Cases in the Switch. In the first one, we enter Approve under Equals. We add Deny in the second case.
It should now look like below, with two cases next to the default one.
Under the approve case, we add a new HTTP action. With this action, we submit a POST Graph call to approve the elevation request. Select POST as Method and enter below URI:
https://graph.microsoft.com/beta/deviceManagement/elevationRequests('[ID]')/approveReplace [ID] with the ID received in the Get elevation request HTTP action.
In the body field we enter below:
{
"reviewerJustification": ""
}In the body, we add the variables userPrincipleName and ResponseApprovalJustificationId between the quotes.
The userPrincipleName is from the action which retrieves the managers information. We add this information for auditing purpose as we can’t change who submitted the approval (that will be our Managed Identity).
ResponseApprovalJustificationId is retrieved from the Post adaptive card action.
As Authentication type select Managed identity.
Select your Managed identity from the list.
And add https://graph.microsoft.com as Audience.
Under the Deny case, we also add an HTTP action, but with below URI:
https://graph.microsoft.com/beta/deviceManagement/elevationRequests('[ID]')/denyThe other field are the same as the approve HTTP action.
This is what our switch action including the HTTP action looks like.
Because the user is not informed about the denial of the elevation request, I find it nice to send a notification. A notification can be sent in multiple ways, in the example I use a shared mailbox to send an e-mail to the user.
Thus we add a Send an email from a shared mailbox action to the flow.
The action first wants us to sign in with an account that has the proper permission to send out an e-mail from a shared mailbox.
Next, we need to fill in the Original Mailbox Address (from which the mail is send). And we need to add a To address, this is emailAddress from the user who submitted the elevation request.
We need to add a Subject and in the Body field we enter the text we would like to include variables to inform the user about the denied elevation request.
And then we have expanded our flow with these actions and is the flow ready to send out notifications and handle the elevation requests.
End-result
This is how the adaptive card looks like in the managers’ Teams client.
The manager can select a response and enter an approval justification.
And the e-mail is sent to the user when the request is denied.
And if we have a look at the request in the Intune portal, we can see the UPN is added in the Admin’s reason field, which we can use for auditing purposes!
The auditing part is a great suggestion of Jose!
That’s it for the blog posts about the EPM elevation request automation.
Thanks for reading!
