With all the new features added to Microsoft Endpoint Privilege Management (EPM), we must not forget another new and long-awaited feature. This blog will examine how Epm now supports additional file extensions such as MSI and PowerShell Scripts. Yeah, you heard me right… MSI and PS1 files!!
1. EPM File Extensions Introduction
With the EPM Support Approved feature finally seeing the light of day, another EPM feature is lurking around the corner to be released. With everyone excited about the Support Approved feature, this feature may be even more wanted and asked for.
If you have looked at the picture above, you know what feature I was talking about! Microsoft/Intune added the possibility of elevating PowerShell and MSI (Windows installer) files with Endpoint Privilege Management.
This PSI/MSI add-on eliminates one significant EPM shortcoming! With that shortcoming now vanished, I decided to look closer at how we could elevate the MSI (Windows Installer) File Extension with EPM.
2. Elevating an MSI
To find out how we could elevate an MSI with EPM, I first manually enabled the FileExtension flight. 
It’s evident that when this feature is GA, you don’t have to enable it manually! You only need to make sure your EPM version is up-to-date. It seems that version 6.2406.49.2001 is the requirement to have the MSI/PS1 Feature enabled.
After manually enabling it, within a millisecond and right-clicking on the MSI file, the Context Menu Handler showed me the possibility of elevating the MSI! Well, that’s just beautiful, right? Elevating the Make me Admin MSI with EPM.
Before we go a bit deeper into how it works, I also decided to take a little peek at the other file extensions that Microsoft adds to the list of extensions we can elevate with EPM. To find out which file extensions can be elevated, I opened the epmcommon.dll, and to be precise, I opened the ShellExtensionconstants function.
As shown below, we will notice the well-known Exe Context Menu Handler Key but also 2 new ones.
Yeah! Msi and Ps1! So, it looks like, besides MSI files, we can also elevate PowerShell Scripts. Can I get a whoop for Microsoft? Let’s take a closer look at how this works. As mentioned in the introduction, I first needed to add the file extension flight to my EPMAgent.
Without even restarting the EPM service or anything else (I was expecting that I was required to reinstall the EPM Extension), the “Run With Elevated Access” was showing up when right-clicking on the Make Me Admin MSI File (A fantastic and stupid example of what we can do with it… using EPM to Install Make me Admin)
I already had Support Approved in place, so creating the corresponding elevation rule was a piece of cake! I only needed to send over the EPM SA file rapport to the service and approve the request!
When you don’t want to use EPM Support Approved to elevate apps, you could also add the MSI or PS1 file hash to the elevation rules! (without getting errors that you are not allowed to)
But let’s get back to the story! After approving the request, I needed to wait a couple of minutes
After waiting a few minutes until the push notification arrived on my device and triggered the queued task to run the omadmclient, the Make Me Admin MSI Windows Installer was approved.
Now the MSI file was approved, I could relaunch it, but this time, it wasn’t asking me to send over the request because we now have an excellent rule in place!
With the elevation rule in place, I can now click on Continue to start the installation of Make Me Admin!
Once I pressed continue, EPM started trying to fetch the “virtual account elevated token”
With the token in possession, the suspended process in the virtual account could be launched.
If you want to know more about this virtual account and how it seems to work, you will need to check out this blog:
If we don’t have any weird policy to block the virtual account logon, the Make Me Admin MSI file will be executed in an elevated context in the virtual account.
Nice!! MSI Support works!
3.PowerShell Scripts
While playing around with the MSI File Extension feature, I noticed that Microsoft also allows us to elevate PowerShell scripts with EPM. Isn’t that wonderful?
I started by creating a simple PowerShell script allowing the user to open the device management msc snap-in.
With the PowerShell script created, I right-clicked on it to elevate access with EPM
I hoped it showed me the Support Approved window, but this time, it gave me a different message.
Instead of the excellent support-approved notification, I got error 0x8004005, which didn’t tell me anything.
When taking a closer look at the EPMService log, it showed me that it was unable to get the hash of the certificate for file: 0x80070490
Should I assign a certificate to it? to find out if that would change anything, I created a self-signed certificate and attached it to the PowerShell script
#Parameters
$CertificateName = "PowerShell Code Signing"
#Create a Self-Signed SSL certificate
$Certificate = New-SelfSignedCertificate -CertStoreLocation Cert:\CurrentUser\My -Subject "CN=$CertificateName" -KeySpec Signature -Type CodeSigningCert
#Export the Certificate to "Documents" Folder in your computer
$CertificatePath = [Environment]::GetFolderPath("MyDocuments")+"\$CertificateName.cer"
Export-Certificate -Cert $Certificate -FilePath $CertificatePath
#Add Certificate to the "Trusted Root Store"
Get-Item $CertificatePath | Import-Certificate -CertStoreLocation "Cert:\LocalMachine\Root"
#Set Parameters
$CertificateThumbprint = $Certificate.Thumbprint
$ScriptPath = "C:\Temp\devmgm.ps1"
#Get the Certificate from Cert Store
$CodeSignCert = Get-ChildItem -Path Cert:\CurrentUser\My | Where-Object {$_.Thumbprint -eq $CertificateThumbprint}
#Sign the PS1 file
Set-AuthenticodeSignature -FilePath $ScriptPath -Certificate $CodeSignCert
Before trying to elevate the PowerShell script again, I made sure the PowerShell script was indeed signed with the self-signed Certificate.
I got a different error after trying to elevate that PowerShell script again.
As shown above, even with my PowerShell script signed with a self-signed certificate, EPM still gave me the 0x80096010 error AKA TRUST_E_BAD_DIGEST. Thats weird? do we need to have Microsoft’s PowerShell Script signed to use it with EPM? That can’t be true…! I decided to look a bit closer to the EPMService.log
Everything pointed to the fact that it needed to be signed by Microsoft until I noticed this one!
Wait a second. Somehow, the PowerShell script’s default file handler was set to Notepad. Oh, that’s just plain stupid.
One thing is for sure: notepad.exe is NOT allowed as a file handler within the EPM driver. Please Note: manually adding notepad.exe will not work… believe me, I tried!
After changing it to Windows PowerShell, I was immediately given the correct Support Approved prompt.
I sent over the request and allowed the PowerShell script support to approve the request in the Intune Portal.
Once the request was approved, it took a few minutes before I could open the PowerShell script. I right-clicked on it, and this time, I could start without issues. As shown below, this PowerShell script was going to launch the devmgmt console!
Now I know I did an oopsie by having Notepad as a file handler for the PS1 scripts. I created a new PowerShell script but did not sign it this time. Guess what? That was also working as I was expecting in the first place, so bottom line: Don’t have Notepad as a file handler when you want to elevate PowerShell scripts with EPM
4. The MSI/PowerShell Mspaint flow
In this flow, I show you how the new EPM MSI / PowerShell file extension addition works under the hood.
Conclusion
The new support for MSI and PowerShell scripts in Endpoint Privilege Management (EPM) opens up many more possibilities for managing elevated privileges. This update significantly expands the capabilities of EPM. I love it!