Microsoft Endpoint Privilege Management (EPM) has been available for some time now, and Microsoft is expanding its capabilities by adding more and more features. However, EPM lacks the option to get notified of new Endpoint Privilege Management elevation requests waiting for approval. This could lead to less productive colleagues when they are waiting on their elevation request’s approval, as nobody is constantly checking the Intune portal for new elevation requests.
This blog post shows an option to send out a notification when a new EPM elevation request is pending approval. In this example, a notification is sent via Teams to the manager of the requester. This is just an example, as others can have completely different needs as to who and via which method a notification is sent. This solution only shows how to send out a notification. A step further could be an option to approve or deny the pending request without visiting the Intune portal, maybe by building a PowerApp.
The solution in short
When a user submits an EPM elevation request, the pending request is waiting for approval in the Microsoft Intune portal.
This information is not only available in the Intune portal but also via the Microsoft Graph API.
By running an API query, for example with a Microsoft Logic App, we can retrieve all elevation requests and further process that information in a Logic App.
The information on the elevation request contains information about who the requester is, information about the product for which elevation is requested, like file name and file version, and of course also a justification.
The elevation information also holds information about the device from which the elevation is requested. But that is only a device ID and not the hostname/ display name of the device. Therefore I run another (optional) API query to also retrieve some information about the device.
As written, I would like to send the notification to the manager of the requester, thus a third API query is run to retrieve enough information from the manager to send this person a notification.
And as last, I will post a card in a Teams chat (of the manager) with all the information relevant to the EPM elevation request.
Requirements
To create this solution, we have a few requirements.
To query Microsoft Graph, we need to have the right permissions to do so. There are different options to authenticate to MS Graph and assign permissions, but I prefer an Azure Managed Identity.
The required Graph (Application) permission to retrieve the EPM elevation request is:
DeviceManagementConfiguration.Read.All
To query MS Graph for some additional device information, we also need the DeviceManagementManagedDevices.Read.All permission.
And to retrieve the requesters manager information, we need User.Read.All the permission.
As I send a notification via Teams, another requirement is a (service) account with a proper Teams license to post these cards (certainly as the Webhook I previously used in some automation solution will be deprecated in the ner future.
Based on the method you choose to send notifications, you could have different requirement.
Setup the Logic App flow
Whent the requirements are inplace, we can start building our solution.
Sign in to the Azure portal and open the Logic App service. I created a Logic App of type Consumption.
We need to select a subscription, resource group, region and enter a name of the flow before we can create the Logic Apps flow.
When the flow is created, click on the name of the flow at the top of the screen, open the Identity section, and on the tab User assigned add your Managed Identity.
Browse to the Overview tab and click on Edit.
The first thing we need to add to the flow is a Trigger.
With the trigger we configure what triggers the flow to start. in my case, I want to run the trigger on a schedule.
We can search for several different triggers.
Search on Schedule to find the trigger type we need.
In this trigger we can configure the schedule interval to our needs. In this example I want the flow to run every 15 minutes, thus I enter 15 as interval and select minutes from the drop-down list.
Click on the plus button under the Schedule trigger, to add our first action.
We search for a HTTP action.
With this HTTP action, we query Microsoft Graph for the EPM elevation requests.
Select GET as Method.
Next, select Authentication under Advanced paramaters
As Authentication type select Managed identity.
Select your Managed identity from the list.
And add https://graph.microsoft.com as Audience.
By default the Graph query (https://graph.microsoft.com/beta/deviceManagement/elevationRequests) retrieves every EPM elevation request. I only want to retrieve the pending requests, that are new since the last time the flow ran.
For the first requirement we use a filter to only retrieve the requests with a status of pending.
For the second requirement we filter on the requestCreatedDateTime.
Enter below URI:
https://graph.microsoft.com/beta/deviceManagement/elevationRequests?$filter=(Status%20eq%20%27pending%27) and (requestCreatedDateTime%20gt%20)
To retrieve only the new requests, we need to query the requests that are created in the last 15 minutes (at least when your flow also runs every 15 minutes.
We need to add the current date and time (in UTC) to our URI minus 15 minutes, to get this job done.
For this we use an expression.
Make sure the cursor is located before the last ) sign in the URI box, and select on the left (in blue) the fx button to add an expression.
Enter below experession and click Add;
formatDateTime(addMinutes(utcNow(),-15),'yyyy-MM-ddTHH:mm:ssZ')
This is how our HTTP action looks like.
Next, we need to add a Parse JSON action, which is a Data operations action. We parse the output of the HTTP action, to be able to use the values later on in the flow.
Add the Parse JSON action to the flow.
The content to get parsed is found in the body of the HTTP action. Put the cusror in the Content box and hit the lightning button (in blue) on the left to add data from the previous step. Select Body from the list.
We don’t have to write the schema ourselves, we can generate it by adding a sample payload. We can get this example payload, by running the current flow and grabbing the output from the HTTP action. We can also grab the body when we run the same query via Graph Explorer.
We can paste that response information from the HTTP action or Graph Explorer into the example payload box.
And our schema is created.
To retrieve some information about the device from which the request is done, we add an (optional) HTTP action.
Select GET as Method and enter below URI:
https://graph.microsoft.com/beta/deviceManagement/manageddevices('')
We need the device ID from the previous Parse JSON action to query for the device information. This ID needs to be located between the quotation marks in the URI box and can be added by selecting Body requestedOnDeviceId from the list.
As soon as we add the requestedOnDeviceId to our HTTP action, the action is added to a For each action. Nothing to worry about 😉 This is bacause we could have retrieved multiple elevation requests, which will now be hanled separately because of the for each action.
Next, select Authentication under Advanced paramaters
As Authentication type select Managed identity.
Select your Managed identity from the list.
And add https://graph.microsoft.com as Audience.
We need to Parse this information again. I assume you now know what information needs to be added to this action.
The next HTTP action is also optinal. I use this to retrieve the manager information of the requester. If you have other needs to send the notification to, this action is ofcourse not needed.
The URI to retrieve is;
https://graph.microsoft.com/v1.0/users/[requestedByuserId]/manager?$select=id,displayName,mail
Make sure to replace [requestedByuserId] with the requestedByuserId from the previous step (the Parse JSON action used to query for the elevation requests).
And the HTTP action is followed by a Parse JSON action.
I choose this time to send an (Adaptive) card to the Teams chat of the manager of the requester.
Adaptive cards can be design online via https://adaptivecards.io/designer/
Here we need to make sure we select Microsoft Teams as host app (1).
In the box below that optin, we see our card design (2).
We can add several different elements and actions to the card. When we select an element or action, we can change the properties on the left of the screen (3).
And when we are finished creating the card, we can copy everything in the card payload editor (4) (this can also be done by hitting the Copy card payload button on the top) and paste that information into our flow.
If your Adaptive card isn’t showing correctly in Teams, I suggest switching the Target version in the card designer to 1.4.
This is my scheme, that I created in the Adaptive cards designer;
{
"type": "AdaptiveCard",
"body": [
{
"type": "TextBlock",
"size": "Large",
"weight": "Bolder",
"text": "Please review this EPM elevation request"
},
{
"type": "TextBlock",
"text": "Hello ,",
},
{
"type": "TextBlock",
"text": "Please review this Endpoint Privilege Management elevation request:",
"wrap": true
},
{
"type": "TextBlock",
"text": "Requester information:",
"wrap": true,
"weight": "Bolder"
},
{
"type": "ColumnSet",
"columns": [
{
"type": "Column",
"width": "stretch",
"items": [
{
"type": "TextBlock",
"text": "Displayname: ",
"wrap": true
}
]
},
{
"type": "Column",
"width": "stretch",
"items": [
{
"type": "TextBlock",
"text": "Device name: ",
"wrap": true
}
]
}
]
},
{
"type": "TextBlock",
"text": "E-mail address: ",
"wrap": true
},
{
"type": "TextBlock",
"text": "Application details:",
"wrap": true,
"weight": "Bolder"
},
{
"type": "ColumnSet",
"columns": [
{
"type": "Column",
"width": "stretch",
"items": [
{
"type": "TextBlock",
"text": "Application name: ",
"wrap": true
}
]
},
{
"type": "Column",
"width": "stretch",
"items": [
{
"type": "TextBlock",
"text": "Version: ",
"wrap": true
}
]
}
]
},
{
"type": "TextBlock",
"text": "File name: ",
"wrap": true
},
{
"type": "TextBlock",
"text": "File description: ",
"wrap": true
},
{
"type": "TextBlock",
"text": "Publisher name: ",
"wrap": true
},
{
"type": "TextBlock",
"text": "Request justification: ",
"wrap": true
}
],
"actions": [
{
"type": "Action.OpenUrl",
"title": "Review the request",
"url": "https://intune.microsoft.com/#view/Microsoft_Intune_Workflows/SecurityManagementMenu/~/epm"
}
],
"$schema": "http://adaptivecards.io/schemas/adaptive-card.json",
"version": "1.4"
}
We add a Post card in a chat or channel to our flow.
It first asks us to Sign in with our (service) account that is assigned the Teams license.
We select Flow bot under Post As and Chat with Flow bot under Post in.
The information from the Card Payloud Editor (where we can design an adaptive card) can be pasted into the Adaptive card box.
We can also add data from previous sessions in the Adaptive card box. Ths way we can add for example the display name of the manager, display name of the requester and information about the elevation request.
When we have added all the information needed to the Post a card action, our flow is ready!
The end result
The end result is that the requester’s manager receives a chat message in Teams.
The Adaptive card contains all kinds of information regarding the elevation request.
The Review the request button brings the manager to the EPM section of the Intune portal.
What’s next?
Be creative and we can most likely come to nice solutions to approve/ deny the elevation request without visiting the Intune portal.
As long as your solution can run a Graph API (post) call, you should be good to go.
This is for example the documentation to approve a request, which requires running the call;
POST /deviceManagement/elevationRequests/{privilegeManagementElevationRequestId}/approve
And if you wonder what the {privilegeManagementElevationRequestId} is? That’s the ID we retrieved when querying Graph for existing elevation requests;
Stay tuned for a part 2 on this topic.
In that part, I describe how we can expand the flow and allow the manager to approve or deny the elevation request!