This is the first unofficial blog about a nice new Endpoint Privilege Management feature called Support Approved. I will show you what it looks like and how I enabled this cool flight independently, even when the feature is not enabled in my tenant. Besides showing you how I enabled this feature on my client, I will also show you some other cool EPM flights that will take off in the future!
Please Note: If you want to read the blog when Support Approved was officially released, please read this blog: Support Approved | EPM | Endpoint Privilege Management (call4cloud.nl)
1. Introduction
After watching Microsoft’s technical takeoff on Endpoint Privilege Management (EPM) and finishing this blog, the word “Flight” will have a new meaning. Let me tell you why! In this technical takeoff, Microsoft demonstrated how a new feature called Support Approved is coming to EPM.
The live demo was great and showed a lot of potential! I was looking forward to playing around with it. Why? It’s a 50/50 split. Half of me wants to know how it works and share some knowledge. The other half is curious if this feature will help convince customers to get rid of their other privilege management tool.
It’s a shame I wasn’t part of the preview, but that doesn’t mean I couldn’t get it working, right? Let me show you the path I took to enable this wonderful new feature on my device! When Microsoft announced it, I was already looking at some new DLL files that arrived in the EPM folder.
In that folder, I had some nice new files: EcsClient.dll/ EpmEcs.dll/ Microsoft.odata.client.dll/ Microsoft.Management.Services.SelfServicePortal.Common.Portable.dll (funny name…)
I started by looking at the EcsClient.dll and what the purpose of this new DLL file was. While I was digging through the DLL file and looking at how I could enable it, I stumbled upon this function in the epmservice.exe. This function shows how it tries to find if the feature is enabled when setting up the Ecsclient 
When spending some time trying to determine how it checks if this feature was enabled it showed me this nice \epmagent\flighting registry key
If we restart the EPMservice, it will also try to open this registry key. So it seems quite important 🙂
That specific flighting registry key doesn’t exist in a normal situation (living on the edge… so I manually created that Flighting registry key)
From there on, I started playing around trying to enable the ECSClient by configuring the missing dword value in this flighting registry key.
2. Flights Enabled
While trying to determine what the EcsClient was doing or could do for us, I became increasingly curious about finding the flight number for the new Support Approved feature.
Within a couple of minutes, I stumbled upon the Epm Support Approved Flighted
SupportApproved = Yep… Support Approved… the “One” I was looking for!
So at this point, I decided to drop my search for ECS for now and started playing around with the SupportApproved functionality and added the corresponding bfa08cb1-909d-4b73-a19b-4ad7ba028f97 flighting registry key as shown below.
After restarting the EPMService, I indeed noticed that the SupportApproved feature was now enabled!
Nice!!! Was it that simple? Just boarding the flight and nothing more? Well… it wasn’t that simple!
3. Support Approved not working
After I boarded the SupportApproved flight and made sure the EPMService was restarted nothing changed and trying to elevate an unknown executable still got me the famous EPM deny page. It looked like I missed some important parts. When looking back at the technical take-off video, it started all making sense.
I didn’t configure the default behavior to make sure it is configured to “support approved”
But how the “F” am I going to configure this default behavior when I am not in the private preview? I only have the option to configure the default behavior in the EPM client settings?
That’s where I come in! The EpmService will try to determine the clientsettings by looking at the ClientSettings corresponding DAT file in the EPM Policies folder.
If we open that DAT file, we will spot the DefaultBehavior 2 in it.
This value 2, seems to correspond to the DeclineElevation setting in the EPM code
Mmm… so I decided to do the stupid thing and just change that defaultbehavior setting from a system shell to a value of “0” (the value of 3 also seems to work?)
Changing the data file itself was only the first part because, with the power of declared configurations, this setting will be refreshed aka overwritten once the scheduled task to refresh any setting is executed.
Luckily I have some experience with declared configurations and with this scheduled task. The second stupid thing is incoming! I changed the corresponding raw and cooked declared configuration documents in the registry.
As shown above, in both of them I changed the defaultbehavior to 0 and tried to elevate the process again.
4. Access Denied
After restarting the EPMservice and kicking off the declared configuration refresh task, I tried to elevate an unknown executable again. This time, it was not the Request denied message but just nothing? No error just nothing? That’s weird?
I opened the EPMconsentui log again to find out what was happening
As shown below, in the log file, it now mentioned that it failed to check if the feature was enabled with the error code 0x8013150a and mentioned that registry access is NOT ALLOWED?
That’s weird? Luckily I had Procmon running and configured to only show the Access Denied results, so it took me 1 minute to find out what was happening
As shown above, I was getting denied access to the flighting registry key I manually created? That’s odd, let’s change that…
I retried to elevate the unknown executable again while watching Procmon (and changed the filters). As shown below, this indeed looks way better. It now has access to the flighting key to determine if the support-approved flight was enabled.
The moment it tried to find out the flighting key it also tried to find something called the registration code?
5. RegistrationCode
Somehow this registration code is quite important in the flow. After manually creating the registrationcode in the Epmagent registry node, I noticed that somehow this registration code was set to 6
That got me interested! As that registration code is used to determine the Environment Endpoints
That’s funny! I am getting a Deja Vu! While I was on holiday a couple of months ago, I stumbled upon a change in how the MMP-C Declared Configuration Enrollment now needs a separate CSP to determine the discovery endpoint I need to discover the enrollment services.
DiscoveryEndpoint | Declared Configuration Enrollment (call4cloud.nl)
So, I decided to take a quick look at this discovery endpoint and what endpoints it will use when I change it to something else. As shown below, the value 6, seems to be pointing to the graph.microsoft.com/v1.0 endpoint and login.windows.net
I am the Fiddler guy, so It’s obvious that I also have Fiddler up and running.
In the response we get, we will notice that it indeed contained the endpoints. I also tried to change this registrationcode to 2 instead of 6.
Look at what I got!!! Isn’t that nice? A nice Yellow Microsoft Canary
Mentioning the fact that my tenant is restricted from accessing this environment…
6. Submit the Justification
Once we have configured the requirements and trying to elevate an unknown executable, the default behavior will kick in and show us the EpmClient request approval window
If we take a look at what it is sending over, we will notice that the request contains the Signature (AKA MS-Organization-Certificate), the SignedPayload, and the SubmitterJustification
If we take a look at the contents of the signedpayload, we will notice that it contains all the information Intune needs to approve the executable.
The funny thing about this is that I noticed that another Gpanalytics.EPMApiserviceDLL I spotted, was being called upon to add those details to the elevation request.
7. Parsing the Payload
After the approval message was sent to the service with the signed elevation request and the justification, it stopped working.
After a second or two, a nice EPM window popped up and showed me the error 0x80004005 error with the message that something went wrong (who was expecting that?)
When looking at the Fiddler response, we will indeed notice in the Payload response, that somehow it was a bad elevation request? Mmm.. damn… now we need to get serious!
Luckily, we again have Microsoft to thank for some additional information. As in the technical take-off, you could have noticed that we have a new tab called: Elevation Requests
I opened the Graph Explorer to find out if I could poke around this new tab on my own
As shown above, after making sure the permissions were set, I fired off a get command to the deviceManagement/elevationrequests url.(took me some attempts to find it)
The graph response I got, indeed showed me the fact that: This feature is not enabled for this tenant
That could explain why it doesn’t proceed, as my tenant isn’t enabled for it! So for now I am not able to get the request approved notification.
If my tenant is flighted for this new EPM feature, I will update the corresponding flow with all the details to this blogpost
8. The Flow
And the Mspaint picture that shows you how it all started. (Please note: in this drawing, I used the defaultbehavior of 3, which gave me the same experience)
Conclusion
I can’t wait until this feature is enabled for my tenant so I can have another look at it. For now, it feels pretty amazing. My next blog will show why Skype is mentioned in the Endpoint Privilege Management client and how the other Flights seem to work (or break the EPMService)!
And please … don’t do what I did in your production environment…. somehow it’s not supported.