top of page
  • Writer's pictureChris Hudson

Intune - Endpoint Privilege Management

Hear ye, hear ye, gather around, as Endpoint Privilege Management has arrived in Intune!


Is this the beginning of the end for granting end-user accounts full administrator rights to Windows devices? It certainly looks that way, and excuses otherwise are fast running out.


IT Admins have long had it instilled into them; end-users should never be granted local administrator privileges on any device unless completely unavoidable and necessary. This was always easier said than done, however. For the most part, end-users can adequately fulfil their roles using standard user privileges, but what about those power users who rely on elevating certain files or applications as an administrator? Developers are a good example, requiring frequent installation and modification of development tools, and what about those old and clunky applications which absurdly rely on administrator privileges to function correctly?


Until now, a binary choice was forced upon IT teams, either enforce standard user privileges across the board and have Service Desks regularly elevating on demand, or grant those power users full local administrator rights to their entire endpoint, which in turn increases the vulnerability and exploitability of both the end-user account and their device.


With the advent of Endpoint Privilege Management, this rigid and binary choice is negated and our options improved. EPM empowers users with standard user rights to elevate and run specific applications and files as an administrator, all without granting administrator rights to the entire device itself. IT Admins can determine the elevation capabilities for both users and devices via Intune configurable and deployable policies, from defining the approved applications and files allowed for elevation to enforcing methods of validation and justification for each elevation request. From a configuration perspective, two policy types exist; Elevation Settings and Elevation Rules.


Granted, there were (and still are) other tools out there to satisfy this problem, such as those offered by vendors like BeyondTrust (previously Avecto) - But these usually ship with a significant cost and are not native to Microsoft; therefore, not seamlessly integrated into Microsoft 365 or Intune either.

Where third-party offerings tend to facilitate elevation via the "Run as administrator" option, which displays when right-clicking a file, EPM preserves this option for standard local administrator elevations as normal, whilst introducing a new option called "Run with elevated access" for elevation request purposes.


Sounds good, right?


Let's jump into Endpoint Privilege Management: -

 

Prerequisites


Licensing

Endpoint Privilege Management is temporarily free whilst in public preview.

Endpoint Privilege Management requires an additional license beyond the Microsoft Intune Plan 1 license. This additional license can be procured via a stand-alone license that includes EPM only, or via an Intune Suite license that includes EPM as well as other premium Intune features: -

  • Available as a standalone add-on license to an existing Intune Plan 1 SKU.

  • Available via the Intune Suite license, which includes other premium features such as Remote Help and Advanced endpoint analytics.

Device

  • Windows 11, version 22H2 with KB5022913

  • Windows 11, version 21H2 with KB5023774

  • Windows 10, version 22H2 with KB5023773

  • Windows 10, version 21H2 with KB5023773

  • Windows 10, version 20H2 with KB5023773

  • Devices must be enrolled into Intune and either Hybrid Azure AD Joined or Fully Azure AD Joined. Azure AD Registered devices (workplace joined) are not supported.

Network

  • The following host needs to be allowed through any in-scope firewalls: - *.dm.microsoft.com Please note that SSL Inspection is not supported on the 'dm.microsoft.com' endpoint.

 

Elevation Settings Policy


Elevation Settings policies determine the baseline settings for the EPM service on the local endpoint. All configuration options are specific to the behaviour of the EPM agent itself and are not necessarily or specifically related to the granular elevation of approved files or applications. The available configuration items oversee the enablement of the agent, reporting settings, and the default elevation response for files and applications which have not been specified or approved via an Elevation Rules policy.


1. Within the Intune blade, browse to Endpoint Security - Endpoint Privilege Management.


2. Create a new Elevation Settings policy using the "Elevation Settings policy" profile option.


3. Name the new policy according to preference, and then proceed to the "Configuration settings" tab.


4. Within the "Configuration settings" tab, configure the various Elevation settings according to requirements & preferences. Please find a summary of each configuration item below the screenshot to aid decision-making.

  • Endpoint Privilege Management: This setting determines whether Endpoint Privilege Management should be enabled or disabled on the local endpoint. When first enabled, the EPM service is provisioned on each device accordingly. If later disabled, the EPM service will immediately disable upon propagation. However, please note that there can be a delay of up to 7 days before the service is completely removed from the device. This grace period allows administrators to efficiently restore EPM should it have been accidentally disabled or unassigned.

  • Send elevation data for reporting: This configuration item specifies whether the local endpoints should share their diagnostic and usage data with Microsoft and the Intune service. Two types of data are collected; Diagnostic and Usage. Diagnostic data reflects event-driven data that is used by Microsoft to monitor the health of the EPM components on the client. Usage data constitutes elevation data that is leveraged by IT Admins to determine and understand the elevations occurring within their environment; this data resides within the customers' Intune instance and populates the accessible elevation reports. The available options are simply Yes, or No. If Yes is selected, the "Reporting scope" option described below will appear.

    • Reporting scope: This setting defines the scope for the previous configuration item when elevation reporting has been enabled. The available options are: -

      • Diagnostic data and managed elevations only = Endpoints will report diagnostic data and usage data for managed elevations only, being those referenced within and managed by EPM Rules policies.

      • Diagnostic data and all endpoint elevations = Endpoints will report diagnostic data and usage data for all elevations, regardless of whether they have been specifically referenced within and managed by EPM Rules policies or not.

      • Diagnostic data only = Endpoints will report diagnostic data only. No usage data is collected, affecting the population of the elevation reports accessible within Intune.

  • Default elevation response: This configuration item establishes the default response for an elevation request when the file has not been specifically referenced within and is not managed by an EPM Rules policy. To clarify, this setting will only take effect when no EPM Rule exists for the elevation request and file, but only when the end-user has requested elevation through EPM. The available options are: -

    • Deny all requests = Highly Recommended. Rejects elevation requests for files that are not specifically referenced within and not managed by an EPM Rules policy.

    • Require user confirmation = Permits elevation requests for any file, regardless of whether it has been specifically referenced within and managed by an EPM Rules policy or not. If this option is selected, the "Validation" option described below will appear.

    • Not configured = If not configured, the default status for this configuration item is to deny all requests.

    • Validation: This setting specifies the enforced validation method for the previous configuration item when the default elevation response has been set to "Require user confirmation". This setting controls how users validate their elevation requests for files that are not managed via an EPM Rules policy. The available options are: -

      • Business justification = Requires the end user to enter a justification to progress the elevation request.

      • Windows Authentication = Requires the end user to authenticate via their credentials to progress the elevation request.

 

Elevation Rules Policy


Elevation Rules policies define and target specific files and applications to be approved for elevation by standard users. These rules essentially identify and link a file to a corresponding and configured elevation requirement, which can be automatic or user-confirmed, with the latter enforcing validation requisites such as Business Justifications and Windows Authentication. Elevation rules policies can be deployed to users and devices alike and a single policy can encompass one or more rules. If an Elevation rule cannot be identified for a file, the default elevation response setting is applied, defined within the Elevation Settings policy.


1. Within the Intune blade, browse to Endpoint Security - Endpoint Privilege Management.

2. Create a new Elevation Rules policy using the "Elevation rules policy" profile option.

3. Name the new policy according to preference, and then proceed to the "Configuration settings" tab.


4. Within the "Configuration settings" tab, an empty and blank rule will be already provisioned and can be populated by clicking "Edit instance" beside it. Multiple rules can be configured per policy by clicking "Add" just above the list of configured rules. The best approach to take whilst populating rules is to be as specific as possible by satisfying as many attributes as possible. Always remember that the more ambiguous the configured rules are, the more chance they have of being exploited. Configure all necessary elevation rules according to requirements & preferences. Please find a summary of each configuration item below the screenshots to aid decision-making.

  • Rule Name: Required. This text field determines the name of the rule within the rules policy. Use a friendly and easily identifiable name for future reference.

  • Description: Optional. If preferable, enter a description for the rule.

  • Elevation type: Required. This configuration item determines the elevation type for the in-scope file. The two available options are User Confirmed and Automatic. User Confirmed enforces a validation method on the user, such as Windows Authentication or Business Justification. Automatic doesn't enforce a validation method and doesn't require the user to request elevation, instead, the in-scope item will automatically elevate as administrator when opened normally. If User Confirmed is selected, the "Validation" option described below will appear.

    • Validation: This setting establishes the enforced validation method for the previous configuration item when the Elevation type has been set to "User Confirmed". This setting essentially defines how users can validate their elevation request. The available options are: -

      • Business justification = Requires the end user to provide a justification to progress the elevation request.

      • Windows Authentication = Requires the end user to authenticate via their credentials to progress the elevation request.

  • File Name: Required (for File Hash use). This text field should reflect the name of the file subject to the elevation rule. Please note that this name needs to also include the file extension, such as ".exe". For example, "Application-Installer.exe".

  • File Path: Optional. If possible, specify the directory location of the file. If the file runs from multiple locations or the directory is unknown, it is acceptable to leave this field blank. Please note, however, that variables are accepted.

Common sense advocates that only specifying a file name and path as the sole recognition method for a file and elevation rule is inadequate; both these attributes can easily be replicated and exploited by a bad actor. Considering this, there is a requirement within an Elevation Rule policy to configure at least one strong method of file identification, either using a files Certificate, Hash, or both. It's worth noting that the File Hash attribute is generally considered the strongest.

  • Signature: If it's possible to use a signature to validate the file and elevation rule, two options are available: - Directly upload the certificate (.cer) to the rule or leverage an already specified certificate from a reusable settings group. If a signature is not going to be used, set this configuration item to not configured. To retrieve a files certificate, the following PowerShell command can be used: -

Get-AuthenticodeSignature "C:\Folder\File.exe" | Select-Object -ExpandProperty SignerCertificate | Export-Certificate -Type CERT -FilePath "C:\Folder\File.cer"

Once the certificate has been sourced and uploaded, determine the certificate type: - Publisher or Certificate Authority.

  • File Hash: Specifying a File Hash to validate the file and elevation rule is considered the strongest identification method. To retrieve a File hash, the following PowerShell command can be used, or the Endpoint Privilege Management elevation reports can be reviewed (assuming the reporting scope setting within the Elevation Settings policy has been configured suitably): -

Get-FileHash "C:\Folder\File.exe"
  • Minimum version: Optional. This attribute allows a minimum version number of a file to be specified to validate the file and elevation rule. The accepted format is x.x.x.x - To retrieve a file's version number, the following PowerShell command can be used: -

(Get-Item "C:\Folder\File.exe").VersionInfo.FileVersionRaw
  • File description: Optional. This attribute allows the description of a file to be specified to validate the file and elevation rule. To retrieve a files description, the following PowerShell command can be used: -

(Get-Item "C:\Folder\File.exe").VersionInfo.FileDescription
  • Product name: Optional. This attribute allows the product name of a file to be specified to validate the file and elevation rule. To retrieve a files product name, the following PowerShell command can be used: -

(Get-Item "C:\Folder\File.exe").VersionInfo.ProductName
  • Internal name: Optional. This attribute allows the internal name of a file to be specified to validate the file and elevation rule. To retrieve a files internal name, the following PowerShell command can be used: -

(Get-Item "C:\Folder\File.exe").VersionInfo.InternalName

Reminder: The best approach to take whilst populating these rules is to be as specific as possible by populating as many attributes and settings as possible. Always remember that the more ambiguous rules are, the more chance they have of being exploited. If a configured rule does not satisfy the lowest metric to be deemed secure, the following message will appear within the rule setting: -


5. Once all the necessary elevation rules have been defined, proceed through the "Scope tags" and "Assignment" tabs, scoping and assigning the policy to groups of users / devices according to requirements.

 

Elevation Policy Conflicts


Let's now take a look at how Endpoint Privilege Management handles any conflicting settings for each policy type.


Elevation Settings Policy

If an endpoint receives multiple Endpoint Settings policies which conflict, the EPM agent will revert to the default client behaviour until the conflict is resolved. This default behaviour includes the enablement of the EPM service on the device.


Elevation Rules Policy

If an endpoint receives multiple Elevation Rules for the same file, all rules are interpreted and assessed by the device. Once assessed, EPM attempts to resolve any conflicts using the following logic: -

  1. Rules deployed to users take precedence over rules deployed to devices.

  2. Rules with a File Hash defined are always deemed the most specific rule.

  3. If more than one rule applies (with no File Hash specified), the rule with the most defined attributes wins, i.e., the most specific.

  4. If the conflict still can't be resolved using the above logic, the following order determines the winning elevation behaviour: -

 

Reusable Settings


Reusable settings allow IT Admins to specify a centralized group of settings and attributes, which can be referenced by multiple and supporting configuration policies. Reusable settings are useful when the same configuration needs to be referenced by multiple policies. If you later need to modify this configuration, you can do so via the centralized reusable settings group, all changes will then automatically propagate to any affiliated policies.


Reusable settings for Endpoint Privilege Management can only be used to centralize certificate uploads at the time of writing. To create a Reusable settings group, whilst within the EPM blade, select Reusable settings and then "Add".


Enter a suitable name for the new reusable settings group, i.e. "Application Name - Certificate", and then proceed to the "Configuration settings" tab.


Next, upload the relevant certificate (.cer) to the reusable settings group.

Once the reusable settings group has been created, the "Use a certificate file in reusable settings" option within an Elevation Rule policy can be leveraged. Simply select the appropriate option for "Signature source", click "Add or remove a certificate", and then select the relevant reusable settings group which hosts the required certificate.

 

Deployment


The deployment of both policy types (Elevation Settings and Elevation Rules) can be monitored in much the same manner as any other configuration profile, policy, or application deployment within Intune: -

On the client side, we can observe and verify the establishment of the "Elevation Settings" policy and installation of the Endpoint Privilege Management components by validating the presence of the "Microsoft EPM Agent" folder, located in "C:\Program Files".

Additionally, we can also validate a successful install of the EPM agent by right-clicking on a file and identifying the "Run with elevated access" option. Please note that the "Run with elevated access" option is to be used for elevation through Endpoint Privilege Management, not the standard "Run as administrator" option, this option is preserved for standard local administrator elevations as normal.

 

End-user Experience


Without EPM

Run as Administrator

Before Endpoint Privilege Management is deployed, the only option to elevate a file would be via the "Run as administrator" option, which presents the following prompt to standard users, requesting local administrator credentials: -


With EPM

User Confirmed (Business Justification)

After Endpoint Privilege Management has been deployed, and once an elevation rule has been configured to enable a standard user to elevate a file via the business justification validation method, a user can right-click the in-scope file and then select the "Run with elevated access" EPM option.

The Endpoint Privilege Management window will then appear and prompt the user to enter a justification before elevation can occur. Once entered, the user clicks continue to proceed.

The file will now run with local administrative privileges. In this case, an application which requires elevation to install has begun installing.


User Confirmed (Windows Authentication)

After Endpoint Privilege Management has been deployed, and once an elevation rule has been configured to enable a standard user to elevate a file via the Windows Authentication validation method, a user can right-click the in-scope file and then select the "Run with elevated access" EPM option.

The Endpoint Privilege Management window will then appear and notify the user that they will need to verify their identity to elevate the in-scope file. The user clicks Continue to proceed.

After pressing continue, if Windows Hello for Business is enabled, the user will be prompted to satisfy Windows Hello authentication. If WHFB has not been enabled, the user will be prompted to enter their credentials.


Once the Windows Authentication requirement has been successfully satisfied, the file will now run with local administrative privileges. In this case, an application which requires elevation to install has begun installing.


Automatic

After Endpoint Privilege Management has been deployed, and once an elevation rule has been configured to elevate a file automatically for a standard user, a user can simply open the file as normal. With automatic elevations, there is no requirement to right-click the file and select the "Run with elevated access" EPM option as elevation occurs automatically. In this case, an application which requires elevation to install has begun installing automatically.


Unmanaged Files

If a user requests elevation for a file which has not been referenced or has not been correctly defined within an Elevation Rule policy, then the "Default elevation response" setting will be enforced, specified within the deployed Elevation Settings Policy. In this example, we configured the settings policy to deny all requests by default, thus the user receives the following: -

 

Reporting and Logs


Intune Reports

Intune offers two reports for the Endpoint Privilege Management feature, but your access to this data and reporting experience will heavily depend on the selected reporting scope settings within the Elevation Settings policy, specifically the "Send elevation data for reporting" and "Reporting scope" items.

  • Elevation report

The Elevation report displays data about all elevations occurring across the endpoint estate, regardless of whether the elevation has been specified within and managed by an Elevation Rules policy or not.

  • Managed elevations report

The Managed elevation report only displays data about elevations specified within and managed by Elevation Rule policies.


Within each of these reports, the accessible information includes but is not limited to: -

  • File name = The name of the file in scope for the elevation request.

  • User = The user who requested the elevation of the file.

  • Device = The name of the device on which the elevation request was made.

  • Result = Whether the elevation was successful or not.

  • Date and time = When the elevation request was made.

Selecting and opening an entry within either report presents further details about the elevation request and the in-scope file, such as displaying the File Hash: -

Please note that EPM data and reports can take up to 24 hours to populate, at the time of writing.


Client Logs

On the client side, there are plenty of log files available for review within the following directory: - C:\Program Files\Microsoft EPM Agent\Logs


After a very quick skim through the logs, an early and initial interpretation of each log file has been described below. However, as these summaries are based on a brief review only, please don't assume they are absolutely definitive or completely correct.

  • EpmConsentUI.log = Appears to log elevation requests with a particular focus on the end-users elevation and journey through the EPM user interface.

  • EpmService.log = Appears to log the actual elevation processes for the in-scope files, post-completion of the EPM user interface.

  • EpmServiceStub.log = Appears to log the execution of elevation requests for files.

  • EPM.log = Appears to be the "primary" EPM service log, logging the numerous activities, validations, and operations of the EPM agent itself and all of its components, as well as logging elevation requests that occur along with their associated file verification and attribute checks.

 

Considerations


At the time of writing, the following notable limitations & considerations exist for EPM: -

  • Downloaded Files = Windows has an inbuilt security feature that can validate the reputation of files downloaded from the internet. If the reputation of a file isn't validated, it may fail to elevate via EPM. A workaround to this is to open the properties of a file and then unblock the file, but please independently verify and ensure the file is trusted and safe before doing so: -

  • Windows 11 = Windows 11 introduced a new concept for the right-click menu, simplifying its presentation by only displaying commonly used actions. EPM currently presents itself under the 'show more options' selection within this new concept menu. Microsoft advises that this issue will be fixed in a future release.


  • File Formats = At the time of writing, Endpoint Privilege Management supports executable files only. Microsoft is currently working on extending support for other file types (MSI, etc.) and providing an easy method to elevate common operating system tasks.

  • Network Files = At the time of writing, Endpoint Privilege Management officially supports executing files that are locally stored only. Executing files from a network location, such as a network share or mapped drive, is not supported.

  • Parameters = Certain command line parameters and arguments associated with the running of a file may cause elevations to fail on the device. Microsoft advises that this issue will be fixed in a future release.

Please note that the above is not a complete and dynamic list of all considerations, only notable ones at the time of writing, further details can be found here: - Deployment considerations for Endpoint Privilege Management | Microsoft Learn

 

The Future


Endpoint Privilege Management already offers a comprehensive set of capabilities and functionality in its early introductory state, and this solution is only going to grow in time.


One upcoming feature to watch out for is a new elevation type called "Support approved". This Support Approved elevation type will supposedly offer an alternative option for files that require infrequent or one-off elevations only, rather than permanently granting elevation rights. In this case, users will be able to request elevation from an IT function and optionally submit a business justification alongside. Once the user sends their elevation request, it will be swiftly forwarded to IT teams for review. If approved, the user will then be able to elevate accordingly, but only for a specified duration of time.

 

Links


0 comments

Comments


bottom of page