just a question for clarification are they doing the Shift+Right click “Run as different user” when they are attempting to elevate under a difference set of credentials?

Yes, run as different user can open as the other user, but not an administrative command prompt as that other user. 

Thanks for that clarification. Raising CMD with elevation is really a high-risk component. Best practice in this regard would be to elevate the commands they are running in CMD rather than elevating the entire application.

For example if I wanted to allow group policy update to be elevated then in my application group I would create an application for this command.  Most of the commands you typically run from CMD are located in the Application templates (When you go to add a new app instead of clicking “Create New Application” use the “Add from Templates”) 

I believe by default EPM doesn’t allow you to elevate CMD because of its extreme risk.

I know I’ve tried adding a rule, and even creating a shortcut and having that shortcut “run as admin” so that when I launch with Password Safe credentials it would be admin, but that also didn’t work. 

Someone else may have a better idea, but that is the route I’ve gone down.

So the run as other works but the process is not elevated?

 

So the run as other works but the process is not elevated?

 

 

This actually made me just think of something…

It might be possible to create a new custom token that has higher privileges, then assign that token in the workstyle to the application rule.  I haven’t tried this method yet, but I know you can get a little more granular with tokens doing this.

​@DavidC  Yes, it’ll open the new command prompt window as the 2nd user, but it can’t open an administrative command prompt as that second user, even though the 2nd user is also a local administrator. From what I’m told certain commands can only be run from the administrative command prompt, no matter what the user’s actual permissions are, which is what’s causing the issue. 

What’s happening here is that the “run as different user” invokes a second logon as that named user, so you would need a workstyle that applies to it.

I tested:

• Enable the Administrators workstyle 
• Create a test Application Group containing an application Executable to match cmd.exe
• Add the group to the workstyle with either of the admin tokens
• Save and unlock etc..
• On the endpoint when I “run as different user” they now get an elevated prompt.

Of course, if the user you are running as isn’t in local admins, you will need a new workstyle at the top of the list.

If the admin logs on interactively, this config will always elevate cmd, so be aware of that.

There are a few things to unpack here. 

Firstly, you describe that the RunAs credentials being used include high privileged accounts which hold Domain Admin privileges. This may just have been an example and not reflect the actual privileges being used - but it would be remiss of me not to highlight (if only for the benefit of others) that this is a bad practice which should be addressed. Domain Admin accounts should only be used to access Tier-0 systems and should never be used on end-user devices, as it’s one of the easiest paths to full domain and wider identity infrastructure compromise. 
 

In terms of the use-case - it would be helpful to understand why the AD credential is required, are you authenticating to and performing privileged operations against remote hosts for example? Or, are you simply trying to separate the actions of these users (for example, in a support scenario) from what it is possible for the primary/logged on user to achieve - perhaps they are not permitted to elevate CMD themselves?

Ultimately there may be several different approaches, such as those described by David above, we could take to meet your requirement, which may be entirely through configuration of the EPM policy (e.g., customization of user messaging options, or use of support session detection), use of different EPM features, or may require adjustments to the wider environment (e.g., creation of appropriately privileged accounts).

Finally, the reason the resulting process does not elevate even when the RunAs account holds local administrator rights, is that the process does not trigger a UAC elevation request when launching. This is because the application manifest does not require it and despite using the Right-Click context menu to invoke via RunAs, this is entirely separate from “Run as administrator” which forces UAC to be triggered.  

You can observe this difference either by trying to launch Regedit via the RunAs mechanism (which will display a native UAC prompt before launching), or by logging on as an administrator and running CMD and Regedit - Regedit’s manifest specifies ‘HighestAvailable’ which for a true administrator requires it be elevated, whereas CMD will still require you to invoke it via ‘Run as administrator’ for it to run elevated. 
 
Hope that helps!

​@Daniel 
Open Command Prompt as "Run As Different User",  provide  that user’s credentials
Type:           Powershell -Command "Start-Process cmd -Verb RunAs"