In the opening section of this chapter, we will explore the importance of implementing EPM and examine the potential risks and vulnerabilities that can arise in its absence within an organization.

The need for EPM

In IT administration, security professionals often advocate against granting users administrative access to their devices. This stance is rooted in the belief that admin access can expose both the devices and the enterprise to significant vulnerabilities. With admin privileges, users can inadvertently install malicious files, leading to system-level changes that compromise security.

To mitigate these risks, security administrators prefer to limit users to standard user accounts. This restriction minimizes their privileges, preventing them from installing unauthorized applications and making critical system changes.

Here are the major risks associated with granting admins privileges to users:

...

We’ll begin by examining the behind-the-scenes flow that takes place during the installation of the EPM agent on a device and its communication with the service post installation.

Agent installation flow

By default, the EPM agent is not present in the Windows OS. It is installed when the EPM elevation setting policy is deployed to the device. Let’s examine the background process during the EPM agent installation using the following diagram:

Figure 2.2: Block diagram showing the flow of EPM agent installation

With the preceding block diagram as a reference, let’s walk through the background steps that lead to the installation of the EPM agent on the device:

1. When the EPM elevation setting policy is deployed to the device, it automatically sends a Device Health Monitoring (DHM) policy to the device from Intune. This can be tracked in real time by examining the SyncML trace on the...

In this section, we’ll delve into the key files and .dlls involved in EPM’s operation and take a closer look at the relevant logs and registry entries. This is going to be very important while troubleshooting related issues.

Working directory

The working directory for EPM is located at C:\Program Files\Microsoft EPM Agent. Within this directory, we will find many folders that are essential for the processing of EPM. These folders contain various files, including .dll, .exe, .inf, .sys, .dat, and .config files. Additionally, this directory houses the log files for EPM, which we will examine in detail in the next section.

Figure 2.10: File/folder structure for EPM

Later in this chapter, we will explore how all these files within the EPM directory structure are utilized.

EPM logs

Understanding EPM log files is crucial, as they play a key role in diagnosing issues, identifying root causes...

The following diagram illustrates the troubleshooting approach we should follow when addressing any EPM-related issues. It is essential to adhere to a systematic, phased approach. This troubleshooting method aligns with the flow we have established previously.

Figure 2.28: Block diagram illustrating the recommended troubleshooting approach for EPM issues

Let’s now examine each component in the diagram and outline a structured approach to troubleshooting EPM-related issues.

Step 1: Verifying EPM policy creation

Ensure that the EPM policy has been created correctly. This involves several checks within the console. For instance, if a user is unable to elevate a specific application using EPM, begin by verifying the elevation rule policy and the elevation setting policy in the portal. Confirm that the logic for detecting the application in the EPM rule policy is accurate (e.g., validating the file hash or certificate used for the application...

The EPM reports are accessible from the Reports tab within the Endpoint Privilege Management node in the Microsoft Intune admin center. Navigate to Endpoint security | Endpoint Privilege Management and select the Reports tab. The report data is retained for 30 days.

We have the following categories of elevation reports:

• Managed elevation report: This report displays similar details to the elevation report but focuses only on elevations managed by a Windows elevation rule policy
• Elevation report by applications: This report provides details for all managed and unmanaged elevations, aggregated by the application that was elevated
• Elevation report by Publisher: This report displays details for all managed and unmanaged elevations, aggregated by the publisher of the application that was elevated
• Elevation report by User: This report provides details for all managed and unmanaged elevations, aggregated by the user that was...

Rolling out EPM to devices is not a single-step process. It is essential to conduct thorough due diligence before deploying EPM and removing admin rights from users. Here, I have outlined the steps that can serve as our deployment strategy for rolling out EPM to our production users:

Figure 2.34: Block diagram illustrating the EPM deployment approach

Now, let’s discuss each of the blocks in detail.

Step 1: Onboarding devices to EPM in audit mode

In this step, we need to create an EPM elevation setting policy in Intune and assign it to the users/devices. This will install the EPM agent on the devices, collect relevant data, and send it to Intune for the administrator to review and act. This process is hidden from the end user, who will not notice any changes.

In order to create the EPM settings policy, we must go to the Intune admin center | Endpoint Security | EPM | Policies | Create Policy | Elevation Setting Policy and enable the...

Rolling out EPM in a production environment involves multiple steps, as illustrated in the following diagram. On the device side, it’s essential to ensure that all EPM prerequisites are fulfilled and that the device is enrolled in Intune. On the administrative side, the Intune administrator must deploy EPM by configuring the appropriate policies. Finally, the rollout progress can be monitored by reviewing the logs discussed earlier in this chapter.

Figure 2.36: Block diagram illustrating the steps for EPM rollout

In this section, we are going to focus on the task at the admin end for onboarding devices to EPM.

There are two steps involved in the process.

Step 1: Creating the EPM elevation setting policy

This policy is going to enable the EPM functionality on the device. It is going to install the EPM agent and send diagnostic information from the device to the Intune service. Creating this is pretty straightforward; we just have to change...

The preferred method for deploying applications should always be through Microsoft Intune using the Required intent, ensuring that essential applications are automatically installed on user devices. If there is uncertainty about whether a user needs a particular application, it should be deployed using the Available intent, allowing users to install it on demand via the Company Portal app.

When to use EPM

EPM should be used in specific cases such as the following:

• A user needs to install an application that has not been pre-provisioned and is not commonly used across the organization
• A user requires temporary elevation to run tools in an administrative context for legitimate troubleshooting or diagnostic purposes (e.g., using tools such as ProcMon, Command Prompt, or PowerShell with elevated privileges)

When not to use EPM

EPM is not intended to restrict or block the execution of applications. If the goal is to...

Making users administrators on their machines is never advisable. Therefore, we must first ensure that all users in our workforce are standard users.

Does this mean we need to assign EPM licenses to all users so they can elevate themselves to admin status for an application session? The answer is no. Our primary method for installing applications on devices should be to push them as required via Intune. If we are unsure whether an end user truly needs an application, we have the option to push those apps as Available. This makes the applications accessible in the Company Portal app, allowing users to download and install them as needed without requiring elevation to admin status.

EPM is designed for scenarios where users may need to perform extensive testing and install applications that are not commonly deployed by the admin through the Intune portal. Instead of relying on the admin to deploy the application, the user can request elevation for an application...

In this chapter, we explored the importance of EPM and its alignment with Microsoft’s Zero Trust principles. We examined the underlying processes involved in EPM agent installation and policy deployment. Additionally, we conducted a detailed review of relevant logs and registry entries to establish a structured approach to troubleshooting EPM-related issues. We also introduced the EPM tools at the device level that support diagnostics and validation. The chapter concluded with a discussion on EPM deployment strategies and an overview of supplementary reference resources to support further learning.

In the next chapter, we will delve into Enterprise App Management (EAM), a key component of the Intune Suite. This chapter will highlight how EAM enhances the efficiency of deploying and updating third-party applications across the organization.

Apart from official Microsoft docs, I highly recommend exploring the blogs by Rudy Oms (at https://call4cloud.nl). He is an exceptionally talented blogger who has authored insightful and technically rich articles on EPM, infused with a touch of humor. His blogs are invaluable resources and should be bookmarked by anyone planning to understand EPM in greater detail.