The long waited for Endpoint Privilege Management is finally in public preview! This post is about my first look at this feature, so not a deep dive post. If you need more details on EPM, please read more from the official doc Learn about using Endpoint Privilege Management with Microsoft Intune | Microsoft Learn
I was curious about the feature, how to configure all the settings in Intune, and how it looks and works on users’ devices. But before we go into details, let’s talk about what is Endpoint Privilege Management, short for EPM.
I remember attending one of the security talks presented by the famous security expert Laiho Sami , he said “Remove all admin rights from your device!“ I totally agreed he is 200% correct, we shouldn’t have admin rights in our devices, it’s a security risk. I believe many organizations understand the risk, but again why are we still giving admin rights? Hm…Because “Our developers need to install many applications”, “Some old and bad applications only work when running as elevated admin rights”, and “We don’t have enough IT to handle this kind of request”… Anyway, we know we always have some reasons, good or bad. 🙂
For a very long time, we wish we can have a “Just in time” method to allow standard users to install or run approved applications with elevated access without giving user administrator privileges. Finally dreams come true! This is Endpoint Privilege Management (EPM)!
Let’s watch this short video. I tried to run powershell.exe as administrator, and my standard user account got UAC prompt as expected. Then I run powershell.exe with EPM elevated access, and I was allowed to run powershell.exe with elevated access. I am NOT saying should let standard users run PowerShell as admin, I just want to test it as an example, because it is kind of cool 🙂
EPM supports Azure AD joined devices and Hybrid Azure AD joined devices. I have tested both scenarios with Windows 11 22H2 March pathed virtual machines.
Okay, let’s go to the configuration. Just a note, this is still in preview at the moment, if you read this post later and see some icons or UI aren’t the same as this post, those are expected changes. At this moment, there are three tabs in the EPM blade:
- Report – There are two built-in reports. Elevation report and Managed elevation report. But these two reports are not ready yet when I was doing my test, I saw no data, maybe I have to wait a little longer.
- Policies – There are two policies. Elevation settings policy and Elevation rules policy. I will break down the details.
- Reusable settings (preview) – This allows you to import the application’s certificate, and reuse the certificate in elevation rule policies.
Elevation settings policy
This is where I started in my first step. The elevation settings policy contains three settings:
- Enable Endpoint Privilege Management. You need to set this to “Enable” for enabling EPM
- Default elevation response. This default response applies to all applications (EXE files), when users right-click on an EXE file, and choose Run with elevated access. There are three options:
- Deny all requests. This will automatically deny all elevated access request
- Require user confirmation. You can select validation methods “Business justification” and/or “Windows Authentication”.
“Business justification” is where users can input information about why they need to run this app.
“Windows Authentication” will require users to use Ctrl+Alt+Del and then input their password again to authenticate.
- Sent data to Microsoft. Choose if you want to send diagnostic data and/or elevation data to Microsoft. Diagnostic data will be sent to Microsoft. Elevation data is for reporting purposes, elevation data is s staying in your Intune tenant. See details in the official doc Review the data that Endpoint Privilege Management collects when used with Microsoft Intune | Microsoft Learn
After my test devices have applied the Elevation settings policy, I waited about 30 minutes, and I saw the EPM Agent is installed. Two folders are interesting to me. One is the EpmTools, there are instructions on how to use PowerShell commands to get more information on the EPM client in the device. Another one is the Logs folder. There are so many logs, I have look into them yet.
Elevation rules policy
You don’t have to use the elevation rule policy if you don’t need to specify different rules for individual applications. But if for example, you use the Elevation setting policy to deny all elevation responses, and want to allow just some applications to run on some devices, in this case, you will need to create an Elevation rules policy.
There are two key matters in the Elevation rule policy:
- Elevation conditions. This allows us to configure elevation type, automatically approve users’ requests, or require user confirmation with “Business justification” and/or “Windows Authentication”
- File information. This is where we can configure individual EXE file information using file hash or certificate. File hash or certificate are required information.
For getting file hash, I use this PowerShell command
Get-FileHash "your exe file path here" | select-object Hash
For exporting the file certificate:
Get-AuthenticodeSignature "your exe file path here" | Select-Object -ExpandProperty SignerCertificate | Export-Certificate -Type CERT -FilePath "c:\temp\YourExeFileCert.cer"
Reusable settings (preview)
As the name of the setting, it’s reusable. In this setting, you can import the EXE file certificate, and reuse this setting in the Elevation rule policy. For example, I have exported the powershell.exe certificate and added it to the Reusable settings
In my Elevation rule policy, I don’t have to upload a new certificate, I can choose to use a certificate file in reusable settings. Then I can choose if I want to use certificate type with Publisher or Certificate authority. The result of this configuration is in the above video.
During my test, Certificate authority didn’t work, so I changed to Publisher.
Update: After this post is published, thanks to Anton Varshavskiy and Chew Hung Pong from Microsoft reaching out to me. Apparently, I was using the “Issuing CA” (intermediate CA), and this is a known issue mentioned already in Microsoft Documentation, which will be fixed in the coming build. More details in Deployment considerations for Endpoint Privilege Management | Microsoft Learn
NOTE: If using the “Root CA“, it should work with the Certificate authority, but it doesn’t mean you should use “Root CA”, because root CA has too wide scope for many applications, you properly don’t want to do that. Ok, please don’t do that. 🙂
As in my examples, I have configured rules for 7-Zip and PowerShell. Here are some screenshots of what it looks like.
In some of the Microsoft demo videos, I saw it should allow users to send requests, and admins can approve the request inside Intune portal, looking forward to this functionality coming in the summertime. Because making rules per EXE file is not as convenient to “approve only once, as the real just-in-time”.
Currently, EPM only supports EXE files, not MSI files. Microsoft Intune team said it will support MSI files in the coming future.
The “Run with elevation access” is under the “classic menu”, so had to click on “Show more options”, which is a bummer. 🙂 But the Microsoft Intune team is actively working on this to make it available in the modern context menu.
Anyway, the first test of Endpoint Privilege Management is satisfying and promising, I am very happy after trying out this feature. So give it a try, and I believe you will like it. In the meanwhile, I am looking forward to seeing what the reporting looks like.
On a standard hybridjoined client all domain users can log in. With our current Privilege Management solution there is a GPO that say that only users that are member of a local security group can get elevated privileges, this group is maintained with a script.
Is there anything similar with EPM that can be automated?
Not at the moment. I agreed to scope members of a group would be a good feature.