Enable Windows standard users with Endpoint Privilege Management in Microsoft Intune

Matt_Call This isn't currently supported in the Azure Virtual Desktop. When AVD be supported? 

GeorgeF- 

1) This depends on how the allow rule is configured.  If it uses the certificate that signed the app, then doesn't specify a version, then a new version of the same app (presuming it is signed by the same certificate), a new rule would not be required.

2) The only way I know would be testing.  If you allow an installer to elevate because the installer requires elevation to install, the actual app executable can be a different file.  If they are signed by the same signing cert, you can create a certificate based rule that allows anything signed by that certificate.  But you should be careful with this, as it can allow anything singned by the cert to elevate, and you may not know what other applications are signed by the same cert, and they may be dangerous to allow to elevate.

Question -

1. If we use a Deny All Policy then create rules to allow specific apps. - If the app is updated by the publisher, does that mean to install the new updated app, we need to create new rule each time there is a change to allow the new app to install and then another new rule to allow them to run the new app if it requires elevated permissions?

2. How do we know if to run an app once it is installed, elevated permissions are required (in order to create a rule for that app)?

FishingNotPhishing, thank you very much for your response. Of course you are absolutely right with your comments about cmd.exe. The possibility to specify the handling of child processes sounds exciting anyway. I am looking forward to further improvements of the already great solution.

MelmixDK Oskaloq TM-GTN thank you for your feedback.  We appreciate you taking the time to share it with us.

Allowing users to run cmd.exe as elevated is not something we would typically recommend anyone do.  As you noted, once you have cmd.exe running with administrator level permissions, the user can use it to launch any other process.  All child processes inherit the permissions of the parent process, which means everything launched from the cmd.exe window will be elevated as well.

We are working on adding the ability to control what happens with any child processes, giving the administrator the ability to specify if those child processes will be allowed to run elevated.  This will be coming in a future release.

We will also have other fixes and improvements coming in each monthly service release, which will take care of many of the issues you have noted above. We're excited to continue to add value for you each month.

When are Microsoft going to secure this properly?

We have implemented an Endpoint Privilege Management policy in Intune which allows users to run EXE files with elevated access if they submit their password.
We have found that if a user WITHOUT local administrator rights navigates to windows\system32 folder and right clicks on CMD.EXE, then selects "Run with elevated access" they can then run a "net localgroup" command and add themselves as local administrator on their device. 

They can do likewise with MMC.EXE (and add the computer mgmt snap in which will run with elevated access) or with CompMgmtLauncher.exe which does the same thing.
Any user without local administrator rights can bypass the restriction put in place by the EPM settings policy, unless you're running with "Deny All" policy and a white list of applications which have to be added individually. (I don't know how many man hours that would require and how much outage it would cause as new apps come on stream, it doesn't bear thinking about). 

Great solution! Anyway, some feedback from our testing:

1) If you create policies for cmd or powershell (I know, it´s not intended to do so), these command lines cannot be invoked from Windows Terminal app anymore, even when Terminal app is started unelevated.

2) If you create policies for mmc, the computer management links won´t work anymore (empty mmc dashboard), even if started unelevated.

3) With a policy for tools like Notepad++, calling these tools via file context menu is no longer possible (see comments above).

4) Windows hello just seems to be implemented inconsistently. Some of our users can only authenticate with password, others via PIN, others via biometrics. No systematic recognizable for us ...

5) With an elevated app it´s not possible to access network shares (elevation starts in separated local user context)

6) It would be great, if you could start Windows internal system functions like network adapter configuration via EPM (see comments above). The elevation of third-party tools like "simple ip config" is not really feasible for us. We also don´t want our users to have such permissions permanently eg via membership in the local network configuration operators group.

7) It would be great, if EPM could allow users to install any esp. Microsoft store apps with elevated permissions without the need to manage these apps in a software deployment solution.

😎 We also would appreciate an approval workflow for elevations like its implemented in the access packages workflows.

We are looking forward to see new EPM features in the near future!

Feedback from some of our test users:

1) It's not running in the user's own context, so they have to reconfigure a lot of stuff for some applications.

2) They don't have access to the files they need because the files are on a network location.

3) They can no longer right-click files and select Edit with Notepad++. They have to open Notepad++ and from there open the file. (Workaround is to not have a specific configuration for Notepad++ in EPM and then re-register the notepad++ extension dll). 

4) It's great that "Program A" is set to always start elevated as this should be standard, but occasionally they actually need to run it as their own user. If it's set to automatically start elevated, there should be a way to force it not to start elevated.

Feedback from me as an admin: Why is it such a mess to get log files from the elevations and why is filtering those logs so limited? We had 20 people enabled and for the first week we got like 10 log items from a single device on day 2 and then nothing for like a week and now we're getting logs from like 4 people and their devices. Everything is enabled, nothing is blocked by the firewall and EPM says everything is succesfully configured and we're enabled in settings to send all logs. 

treestryder 

"I have never needed root access on my phone."

This is because smartphones are very much locked down into walled gardens with their respective app stores gatekeeping any and all app installations.  To achieve this with Windows you need to look into S-Mode.
https://support.microsoft.com/en-us/windows/windows-10-and-windows-11-in-s-mode-faq-851057d6-1ee9-b9e5-c30b-93baebeebc85#WindowsVersion=Windows_11

This may or may not be the future of the Windows OS but I can see lots of reasons why it may be impossible in the real world.  People and businesses would be giving up tremendous amounts of freedom to install and run apps from anywhere with a tradeoff of much tighter security.

I would like to see the "need" for local administrator access eliminated. I have never needed root access to my phone.

Through simplifying our configurations and attempting to manage everything through Intune (and the Company Portal), we have come close. Reaching the limits of this policy, we would like to give a group of people local administrator rights to a group of "less managed" devices. Can EPM be used in this way?

At the moment, it is looks like we may have to assign traditional local administrator rights through an Account Protection policy to the group of PCs for our group of admins. Then, if we want EPM's reporting, and don't mind the price, we can assign a "deny all" Elevation Policy.