By Sandy Zeng Posted on MSEndpointMgr
The much-anticipated Endpoint Privilege Management (EPM) has made its debut in the public preview! This discourse will offer a cursory exploration of this novel feature rather than an exhaustive study. For those seeking in-depth understanding of EPM, I suggest perusing the official documentation: Learn about using Endpoint Privilege Management with Microsoft Intune | Microsoft Learn.
My intrigue was primarily centered around the functionality of this feature, its configuration within Intune, and the user experience on respective devices. However, before delving into the specifics, it would be prudent to shed light on what Endpoint Privilege Management, or EPM, essentially is.
I recall in a security discussion led by the renowned security maven, Laiho Sami, who admonished, “Remove all administrative rights from your device!” I wholeheartedly concurred with his sentiment, echoing that possessing administrative rights on our devices poses a formidable security risk. Many organizations apprehend this peril yet continue to confer administrative rights. Why, one might ask? A myriad of reasons are often cited, ranging from “Our developers require multiple applications” to “Certain antiquated applications operate solely when run as elevated admin rights” and “Our IT department lacks the resources to manage these requests.” Whether these reasons are valid or flawed is subjective, but their existence is undeniable.
For eons, we have yearned for a “Just in Time” approach that would empower standard users to install or operate approved applications with elevated access, without the need for administrative privileges. The manifestation of this dream is the Endpoint Privilege Management (EPM)!
Allow me to direct your attention to this video demonstration. In the video, I attempted to run powershell.exe as an administrator, which, as anticipated, prompted a UAC alert for my standard user account. Subsequently, when I operated powershell.exe with EPM elevated access, the application ran smoothly. This is not an endorsement for allowing standard users to run PowerShell as an admin, rather an illustrative example, merely for its allure.
EPM extends support to Azure AD joined devices and Hybrid Azure AD joined devices, and I have examined both scenarios using Windows 11 22H2 March pathed virtual machines.
Now, let’s navigate to the configuration details. Please bear in mind that this feature is currently in its preview phase. Therefore, any discrepancies observed between this post and the interface you encounter later are anticipated modifications. Presently, the EPM blade incorporates three tabs:
- Report – This section comprises two pre-configured reports: Elevation report and Managed elevation report. During my exploration, these reports were not populated with data, perhaps indicating the need for more patience on my part.
- Policies – Two policies are housed here: Elevation settings policy and Elevation rules policy. I will elaborate on these shortly.
- Reusable settings (preview) – This allows for the importation of the application’s certificate, which can then be utilized in elevation rule policies.
Elevation Settings Policy
This was my starting point. The elevation settings policy includes three settings:
- Activation of Endpoint Privilege Management. To enable EPM, this setting must be activated.
- Default elevation response. This default response applies to all applications (EXE files). When users right-click an EXE file and select ‘Run with elevated access,’ one of the following three options will be enforced:
- Deny all requests. This will result in automatic denial of all elevated access requests.
- Require user confirmation. Validation methods such as “Business justification” and/or “Windows Authentication” can be selected. “Business justification” allows users to provide reasons for needing to run the application. “Windows Authentication” demands users to use Ctrl+Alt+Del and then re-enter their password for authentication.
- Data transmission to Microsoft. Users can select whether they want to forward diagnostic data and/or elevation data to Microsoft. Diagnostic data is sent to Microsoft, while elevation data, which is for reporting purposes, remains within your Intune tenant. For more details, refer to the official documentation: Review the data that Endpoint Privilege Management collects when used with Microsoft Intune | Microsoft Learn.
Upon the application of the Elevation settings policy on my test devices and a 30-minute wait, I observed the installation of the EPM Agent. Two folders piqued my curiosity: EpmTools, which provided instructions on using PowerShell commands to gather additional information on the EPM client in the device, and the Logs folder, filled with various logs that I have yet to peruse.
Elevation Rules Policy
There is no compulsion to utilize the elevation rule policy unless you wish to specify individual rules for each application. However, if the Elevation setting policy is configured to deny all elevation responses and you desire to permit only certain applications to run on specific devices, you will need to create an Elevation rules policy.
This policy primarily consists of two sections:
- Elevation conditions. This allows us to set the elevation type, approve users’ requests automatically, or require user confirmation through “Business justification” and/or “Windows Authentication”.
- File information. Here, we can provide individual EXE file information using the file hash or certificate. File hash or certificate is necessary information.
To obtain the file hash, I utilized the following PowerShell command:
Get-FileHash “your exe file path here” | select-object Hash
To export the file certificate, the following command was employed:
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 suggests, this setting can be reused. It permits the importation of the EXE file certificate, which can then be recycled in the Elevation rule policy. For instance, I exported the powershell.exe certificate and added it to the Reusable settings.
Consequently, in my Elevation rule policy, I could avoid uploading a new certificate by opting to utilize a certificate file in the reusable settings. Subsequently, I was granted the choice of whether to use the certificate type with Publisher or Certificate Authority. The outcome of this configuration is demonstrated in the aforementioned video.
During my examination, the Certificate Authority option was unresponsive, prompting me to switch to Publisher. Update: Post publication of this piece, I was enlightened by Anton Varshavskiy and Chew Hung Pong from Microsoft, that my utilization of the “Issuing CA” (intermediate CA) was a known issue already mentioned in the Microsoft Documentation, and slated for rectification in an upcoming build. More details can be found in Deployment considerations for Endpoint Privilege Management | Microsoft Learn.
Note: Although the “Root CA” should technically work with the Certificate Authority, it is advised not to use it due to its extensive scope encompassing numerous applications, which is likely undesirable. Therefore, it is advised to avoid this practice.
In my tests, I configured rules for 7-Zip and PowerShell. The images below provide a glimpse of what the user interface looks like.
In several Microsoft demo videos, it was depicted that users could submit requests, which could be approved by administrators within the Intune portal. I eagerly await the release of this feature in the summer, as creating rules for individual EXE files does not quite embody the convenience of the “approve only once, just-in-time” paradigm.