Explore whether Terminal could be 'runas' a different user identity

[bitcrazed]

Related to #2485, #1053, #3534

This issue is a fork from a conversation started in #146 (specifically this comment onwards) discussing if/whether Terminal can/could support being runas a different user identity than the currently logged-in user.

Note: This is not sudo or run elevated - that's a different concept since elevation runs a process with the current user's identity, but with additional (admin) rights.

The primary ask here is that users, particularly those in enterprise scenarios, often need to run commands/scripts/etc. under a different user account with different permissions/rights than their normal/general user account.

Alas, UWP apps do not currently support the ability to run under a different identity than the currently logged-in user.

Thus, there are a couple of questions:

1. Can the UWP app platform provide a way to run UWP apps under a different/specific user identity?
2. If not, can Terminal be built/delivered allowing users to run under a different identity?

We'll go do some homework and respond to this thread with what we find.

Thanks all on the original thread for sharing their feedback :)

[biltongza]

As a workaround, can you not Enter-PSSession with your alternate identity credentials? (obviously this is only a powershell solution)

[bitcrazed]

@biltongza As you point out, this is only works within PowerShell - the ask above is more general than that. Also, since UWP apps are installed per-user, it's possible that the requested app isn't even installed and available in the secondary account.

[parkovski]

I'm not an enterprise user so I apologize if I don't fully understand the requirements here, but does the terminal GUI really need to run as another user? Or is it enough to spawn shells with runas and/or a potential sudo utility? I was able to get an admin tab with my wsudo POC, and I'd imagine running a shell as another user would work similarly.

[cking22001]

I'm not an enterprise user so I apologize if I don't fully understand the requirements here, but does the terminal GUI really need to run as another user? Or is it enough to spawn shells with runas and/or a potential sudo utility? I was able to get an admin tab with my wsudo POC, and I'd imagine running a shell as another user would work similarly.

That is a whole other thread with its own security concerns. #632

[joshuatee]

The primary ask here is that users, particularly those in enterprise scenarios, often need to run commands/scripts/etc. under a different user account with different permissions/rights than their normal/general user account.

Isn't the primary issue here security? In my book no user, enterprise or not, should be running an admin account hoping UAC is doing its job properly

Bypass User Account Control
https://attack.mitre.org/techniques/T1088/

to me this is a HUGE issue and it seems it is being swept under the rug

[mcwidg3t]

Isn't the primary issue here security? In my book no user, enterprise or not, should be running an admin account hoping UAC is doing its job properly

It's the same issue.

An example of this is that a domain admin should have two AD accounts; a standard user account and a domain admin account. They should be logged into their desktop under their standard user account. Should they need to do some AD work, they should be able to run a terminal window under their domain admin account, perform the work, then close the window.

This is preferable to switching to their domain admin user. It's more convenient and much quicker.

[bitcrazed]

Yes, this is all about security.

Consider the scenario where a domain admin's standard environment is compromised with some form of pernicious malware.

If/when they launch an app from their compromised desktop running as their domain admin account, the malware now has considerable opportunity to key-log/screen-scrape/intercept/divert/delete/block/corrupt/encrypt all kinds of data and systems as domain admin.

Ever wonder how Ransomware takes an entire company offline?

This is why many enterprises and most online services air-gap users from production systems, requiring users to login via RD to a strictly-managed, heavily-restricted hosted VM environment which is severely locked down, regularly re-paved, etc.

Such environments used to be the domain of the rich and famous, but this can now be built very cost effectively with commodity services and tools.

Is this more inconvenient than just runas /user:domainadmin1 "resetpasswords.bat /all"? Yes, but it's designed to be so.

One of the interesting artifacts of such changes is that scripts, automation, and systems get built to replace the user's need to run admin tasks ad-hoc, increasing reliability and repeatability, decreasing errors, and decreasing various other risks. This is where CI/CD came from, and where many enterprises are going.

YMMV.

[Sarafian]

Being redirected from GH-5723 and I understand the security concerns but I think we are missing something from the user experience.

I actually work with a restricted user and when I do "Run as Admin", I elevate with a local admin user for which I need to enter the password. This works with everything, including powershell and cmd prompt. I understand the possible WUP limitations but the 2-user pattern is a much more secure pattern, I think, than a all the time admin with UAC on demand.

If the WUP won't allow for this, shouldn't there be an alternative like a global installation even outside the Windows Store, like PowerShell and every other application. At the end of the day, this looks like a limitation of the WUP because what would happen on systems that only run WUP apps? A Terminal is almost by design an extension to system configuration, so something needs to be considered when re-envisioning a Windows Terminal that can't do admin things.

I also request for this issue to be re-opened or lets create another one. Let me know please.

[skadog]

Isn't the primary issue here security? In my book no user, enterprise or not, should be running an admin account hoping UAC is doing its job properly

It's the same issue.

An example of this is that a domain admin should have two AD accounts; a standard user account and a domain admin account. They should be logged into their desktop under their standard user account. Should they need to do some AD work, they should be able to run a terminal window under their domain admin account, perform the work, then close the window.

This is preferable to switching to their domain admin user. It's more convenient and much quicker.

This is my exact situation. We have a regular AD user account for our workstation and an AD administrator account to do our work. As it stands now, I see no point in continuing to using WT over my standard powershell or command terminal.

[Clifra-Jones]

As a workaround, can you not Enter-PSSession with your alternate identity credentials? (obviously this is only a powershell solution)

This does not work if you are trying to do things like Active Directory management. A simple test is to try to access the c$ admin share on a DC using set-location, it will fail. While opening a Powershell windows "As a different user" works.

[PeterRoots]

Interesting all the points above on security of elevation vs no elevation when running commands in a terminal (cmd, powershell or whatever). A big selling point of windows terminal is the tabs and split panes - great for running stuff remotely when enter-pssession is ideal. There are time though when I need/want to run something locally, at which point I need to ditch terminal and open a powershell window as admin to do it. Sort of defeats the point of having a nice neat all in one place for terminal windows

[TBBle]

In the meantime, if you register the application package for your admin user you should be able to run Terminal as that user.

I recently found myself in the position of wanting to register Store-installed Windows Terminal with a second (high-privilege) account to try and work-around this issue, due to local corporate policies.

By my research, the command should be:

Add-AppxPackage -Register 'C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\AppxManifest.xml' -DisableDevelopmentMode

when running PowerShell as the target user (either privileged or unprivileged), but it fails

Add-AppxPackage : Deployment failed with HRESULT: 0x80073D19, An error occurred because a user was logged off.
error 0x80070002: While processing the request, the system failed to register the windows.sharedFonts extension due to the following error: The system cannot find the file specified.

The Get-AppPackageLog -ActivityID 10f4110e-a0eb-0003-45f6-6b11eba0d601 output:

PS C:\WINDOWS\system32> Get-AppPackageLog -ActivityID 10f4110e-a0eb-0003-45f6-6b11eba0d601

Time                      ID           Message
----                      --           -------
10/20/2020 1:12:12 PM     603          Started deployment Register operation on a package with main parameter AppxManifest.xml and Options 0 and 0. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.
10/20/2020 1:12:12 PM     819          The following packages will be installed: 1527c705-839a-4832-9118-54d4Bd6a0c89_10.0.18362.449_neutral_neutral_cw5n1h2txyewy c5e2524a-ea46-4f67-841f-6a9465d9d515_10.0.18362.449_neutral_neutral_cw5n1h2txyewy E2A4F912-2574-4A75-9BB0-0D023378592B_10.0.18362.449_neutral_neutral_cw5n1h2txyewy
                                       F46D4000-FD22-4DB4-AC8E-4E1DDDE828FE_10.0.18362.449_neutral_neutral_cw5n1h2txyewy InputApp_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.AAD.BrokerPlugin_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.AccountsControl_10.0.18362.449_neutral_neutral_cw5n1h2txyewy
                                       Microsoft.AsyncTextService_10.0.18362.449_neutral_neutral_8wekyb3d8bbwe Microsoft.BioEnrollment_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.CredDialogHost_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.ECApp_10.0.18362.449_neutral_neutral_8wekyb3d8bbwe
                                       Microsoft.LockApp_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.MicrosoftEdgeDevToolsClient_10.0.18362.449_neutral__8wekyb3d8bbwe Microsoft.MicrosoftEdge_44.18362.449.0_neutral__8wekyb3d8bbwe Microsoft.PPIProjection_10.0.18362.449_neutral_neutral_cw5n1h2txyewy
                                       Microsoft.Win32WebViewHost_10.0.18362.997_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.AppRep.ChxApp_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.AssignedAccessLockApp_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.CallingShellApp_10.0.18362.449_neutral_neutral_cw5n1h2txyewy
                                       Microsoft.Windows.CapturePicker_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.CloudExperienceHost_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.ContentDeliveryManager_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.Cortana_10.0.18362.449_neutral_neutral_cw5n1h2txyewy
                                       Microsoft.Windows.NarratorQuickStart_10.0.18362.449_neutral_neutral_8wekyb3d8bbwe Microsoft.Windows.OOBENetworkCaptivePortal_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.OOBENetworkConnectionFlow_10.0.18362.449_neutral_neutral_cw5n1h2txyewy
                                       Microsoft.Windows.ParentalControls_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.PeopleExperienceHost_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.PinningConfirmationDialog_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.SecHealthUI_10.0.18362.449_neutral__cw5n1h2txyewy
                                       Microsoft.Windows.SecureAssessmentBrowser_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.ShellExperienceHost_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.Windows.StartMenuExperienceHost_10.0.18362.449_neutral_neutral_cw5n1h2txyewy
                                       Microsoft.Windows.XGpuEjectDialog_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Microsoft.XboxGameCallableUI_10.0.18362.449_neutral_neutral_cw5n1h2txyewy Windows.CBSPreview_10.0.18362.449_neutral_neutral_cw5n1h2txyewy windows.immersivecontrolpanel_10.0.2.1000_neutral_neutral_cw5n1h2txyewy
                                       Windows.PrintDialog_6.2.1.0_neutral_neutral_cw5n1h2txyewy . The following packages will be removed: NULL
10/20/2020 1:12:12 PM     216          App manifest validation warning: Declared namespace http://schemas.microsoft.com/developer/appx/2015/build is inapplicable, it will be ignored during manifest processing.
10/20/2020 1:12:12 PM     10002        Creating Resiliency File C:\ProgramData\Microsoft\Windows\AppRepository\b7bcf689-76ca-4023-87b5-164ce6fddd37_S-1-5-21-125588297-3509485221-1345772379-124099_2.rslc for Register Operation on Package Microsoft.WindowsTerminal_2020.921.2317.0_neutral_~_8wekyb3d8bbwe.
10/20/2020 1:12:12 PM     607          Deployment Register operation on package Microsoft.WindowsTerminal_2020.921.2317.0_neutral_~_8wekyb3d8bbwe has been de-queued and is running for user SID S-1-5-21-125588297-3509485221-1345772379-124099.
10/20/2020 1:12:12 PM     614          Bundle Uri C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_2020.921.2317.0_neutral_~_8wekyb3d8bbwe\AppxMetadata\AppxBundleManifest.xml contains packages: "CascadiaPackage_1.3.2651.0_x86.msix": Microsoft.WindowsTerminal_1.3.2651.0_x86__8wekyb3d8bbwe "CascadiaPackage_1.3.2651.0_ARM64.msix":
                                       Microsoft.WindowsTerminal_1.3.2651.0_arm64__8wekyb3d8bbwe "CascadiaPackage_1.3.2651.0_x64.msix": Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe.
10/20/2020 1:12:12 PM     854          Successfully added the following uri(s) to be processed:  C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_2020.921.2317.0_neutral_~_8wekyb3d8bbwe\AppxMetadata\AppxBundleManifest.xml C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\AppxManifest.xml.
10/20/2020 1:12:12 PM     855          Finished resolving action lists. DeploymentRequest action lists: addPackageList: Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe Microsoft.WindowsTerminal_2020.921.2317.0_neutral_~_8wekyb3d8bbwe.
10/20/2020 1:12:12 PM     573          Setting Sync Enabled status, package family name Microsoft.WindowsTerminal_8wekyb3d8bbwe, enabled false.
10/20/2020 1:12:13 PM     10000        About to service package Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe. Setting the package state to disabled returned with 0x0.
10/20/2020 1:12:13 PM     8100         Starting validation and setting the Trust Label on package Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe with flags 0x9.
10/20/2020 1:12:13 PM     8106         Package Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe has Trust Label already. Flags: 0x9
10/20/2020 1:12:13 PM     8101         Finished validation and setting the Trust Label on package Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe with flags 0x9.
10/20/2020 1:12:13 PM     306          error 0x80070002: While processing the request, the system failed to register the windows.sharedFonts extension due to the following error: The system cannot find the file specified.
                                       .
10/20/2020 1:12:13 PM     316          error 0x80070002: Cannot register the request because the following error was encountered during the registration of the windows.sharedFonts extension: The system cannot find the file specified.
                                       .
10/20/2020 1:12:13 PM     5507         Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe : C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\microsoft.system.package.metadata\S-1-5-21-125588297-3509485221-1345772379-124099-MergedResources-*.pri : No user-specific merged files found
10/20/2020 1:12:13 PM     5507         Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe : C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\microsoft.system.package.metadata\Resources.????????.pri : No shared merged files found
10/20/2020 1:12:13 PM     5507         Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe : C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\microsoft.system.package.metadata\S-1-5-21-125588297-3509485221-1345772379-124099-MergedResources-*.pri : No user-specific merged files found
10/20/2020 1:12:13 PM     5507         Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe : C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe\microsoft.system.package.metadata\Resources.????????.pri : No shared merged files found
10/20/2020 1:12:13 PM     300          error 0x80073CF6: Cannot register the Microsoft.WindowsTerminal_8wekyb3d8bbwe package due to the following error: Package could not be registered.
                                       .
10/20/2020 1:12:13 PM     605          The last successful state reached was SingletonRegisterAdd. Failure occurred before reaching the next state RegistrationChanged. hr: 0x80073CF6
10/20/2020 1:12:13 PM     330          error 0x80070002: While removing the request, the system failed to de-register the windows.MRT extension due to the following error: The system cannot find the file specified.
                                       .
10/20/2020 1:12:13 PM     7750         warning 0x80070005: The following error occurred while performing Indexed DB cleanup when removing the package: AppxManifest.xml (Access is denied.
                                       ).
10/20/2020 1:12:13 PM     330          error 0x80070005: While removing the request, the system failed to de-register the windows.indexedDB extension due to the following error: Access is denied.
                                       .
10/20/2020 1:12:13 PM     10001        Finished servicing package Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe. Setting the package state to enabled returned with 0x0.
10/20/2020 1:12:13 PM     10001        Finished servicing package Microsoft.WindowsTerminal_1.3.2651.0_x64__8wekyb3d8bbwe. Setting the package state to enabled returned with 0x0.
10/20/2020 1:12:14 PM     401          Deployment Register operation with target volume C: on Package Microsoft.WindowsTerminal_2020.921.2317.0_neutral_~_8wekyb3d8bbwe from:  (AppxBundleManifest.xml)  failed with error 0x80073D19. See http://go.microsoft.com/fwlink/?LinkId=235160 for help diagnosing app deployment issues.
10/20/2020 1:12:14 PM     404          AppX Deployment operation failed for package Microsoft.WindowsTerminal_2020.921.2317.0_neutral_~_8wekyb3d8bbwe with error 0x80073D19. The specific error text for this failure is: error 0x80070002: While processing the request, the system failed to register the windows.sharedFonts extension due to the following error: The
                                       system cannot find the file specified.
                                       .

This appears to be a repro-case for #3194, but happens without Chocolately or an elevated session.

[Wittionary]

@TBBle Running that from an elevated Powershell 5.1 prompt allowed me to run WT as admin. Thanks!

[oising]

I wonder how many of these complaints could be solved with the use of /netonly semantics. It's perfectly possible to run a terminal window as userA and employ runas /netonly to ensure outgoing authenticated connections are made as AdminB. You'd have to create profile that specifically launches cmd or pwsh with runas. I've been doing this for decades.

[TBBle]

@Wittionary How did you install Windows Terminal? I had assumed #3194 would affect everyone who installed it from the Windows Store or Chocolatey, but if you did one of those, then perhaps it's something system-specific that triggers it.

[Wittionary]

@TBBle I believe I initially installed it which Chocolate because the Windows Store was previously blocked at my place of employment. And according to choco list -li I've got "microsoft-windows-terminal 1.0.1811.0" although contradicts what "About" is telling me in Terminal (v1.3.2651.0). However, somewhere along the way, the Store was unblocked and I re-installed from there (to see if it would resolve the multiple admin prompts -> File not found issue).
All that to say - the initial install was via choco although the Store may be managing the updates to it now.

[pilgi3]

In our company we have a second account for doing admin things.
So I open a windows powershell as admin with the admin user.
Then I installed the downloaded msixbundle.
Now I am able to open the terminal als admin. If the application get updated for my admin account i don't know.

[Sarafian]

@TBBle Running that from an elevated Powershell 5.1 prompt allowed me to run WT as admin. Thanks!

If I do & "C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.2.2381.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe" then I still get an

Program 'WindowsTerminal.exe' failed to run: Access is deniedAt line:1 char:1

Both from PowerShell 7 and 5, while in Admin privileged sessions

[0byt3]

Yes, this is all about security.

Consider the scenario where a domain admin's standard environment is compromised with some form of pernicious malware.

If/when they launch an app from their compromised desktop running as their domain admin account, the malware now has considerable opportunity to key-log/screen-scrape/intercept/divert/delete/block/corrupt/encrypt all kinds of data and systems as domain admin.

Ever wonder how Ransomware takes an entire company offline?

This is why many enterprises and most online services air-gap users from production systems, requiring users to login via RD to a strictly-managed, heavily-restricted hosted VM environment which is severely locked down, regularly re-paved, etc.

Such environments used to be the domain of the rich and famous, but this can now be built very cost effectively with commodity services and tools.

Is this more inconvenient than just runas /user:domainadmin1 "resetpasswords.bat /all"? Yes, but it's designed to be so.

One of the interesting artifacts of such changes is that scripts, automation, and systems get built to replace the user's need to run admin tasks ad-hoc, increasing reliability and repeatability, decreasing errors, and decreasing various other risks. This is where CI/CD came from, and where many enterprises are going.

YMMV.

Correct me if I am wrong, but keyloggers and such will still catch everything you type even if you're RDP'd into a VM from where you do domain admin work. The info will be caught before it is sent through RDP, or caught when providing credentials to initiate your RDP connection.

[KirkMunro]

I've run into this issue as well when working with a laptop from a new corporation that I'm working with. The workarounds suggested haven't resolved my issues with Microsoft Terminal, but they did allow me to get winget working (see referenced issue linked above for information if you are interested).

One idea came to mind related to this: if modern apps are all about installation/management for the current, logged in user, and more applications that users may want to run as admin like winget, the Microsoft Terminal, etc. are being built as modern apps to be installed this way, maybe the solution is to reimagine the non-admin login user pairing with an admin elevation user account (cannot log on locally) scenario. The end goal is simply to prevent running day-to-day as admin, while allowing for some content to be run as admin but only as needed, and behind explicit authentication, right? In which case being able to enter elevation credentials (different from your normal password, independently linkable to MFA/modern auth) so that you could execute applications on your system as admin in a more secure manner without dealing with two accounts could solve this problem while supporting the logged on user requirement of modern apps that are installed from the store or sideloaded.

[KirkMunro]

Regarding this workaround mentioned above, I was able to get the winget source package registered in my elevated admin account using that workaround, but as the poster of that linked comment indicated, I receive the same error they did, where the Microsoft Terminal app could not be registered because the Cascadia fonts extension could not be found.

Is there some way to manually register/configure Cascadia fonts for the elevated admin account that cannot log on locally independently of the sideloading workaround for Microsoft Terminal? If the extension is the blocker here, I'm now looking for a workaround to unblock the extension so that I can then just register the Terminal app for my elevated admin account manually.

[conioh]

We do understand the scenario well. But as discussed above:

1. The UWP app model does not (currently) support running modern apps under the identity other than the currently logged-in user

@bitcrazed, what you're saying is interesting but I have evidence to the contrary.

On most of my machines I have at least two user accounts, Me and MeAdmin, the first one being a "standard use" (i.e. member of BUILTIN\Users but not of BUILTIN\Administrators, etc.).

I do most of my work from the standard user, and only specific actions (e.g. upgrade Visual Studio, reconfigure network) through the admin. Usually I do it by "elevating" the required programs (e.g. vs_installer.exe), that is "running them as admin" and only sometimes I log on into another Terminal Services session as the admin user.

When I say "elevate" here I mean what used to be called when UAC just came out "OTS elevation" (Over-The-Shoulder, supposedly when the admin, who's another person, comes and enters the password over my shoulder) rather then "AAM" (Admin Approval Mode; just clicking Yes without entering a password).

Sometimes I get the OTS prompt because the application manifest requires elevation (as does the VS installer prior to 16.9), and sometimes I right click the program and choose Run as administrator (to run cmd.exe or pwsh.exe), but let me be clear here:

In all cases the currently logged on user (to whom the Terminal Services session belongs) is not an administrator. The programs are being run as a different user.

And while logged in as Me, the standard user, I am able to run Windows Terminal as a completely different user, MeAdmin, as long as the following conditions are met:

1. Windows Terminal is installed for both users, and is of the same version. (If I update it for Me but not for MeAdmin it sometimes fails.)

2. I'm running Windows Terminal as the other user elevated, through one of the following methods:

   1. Holding Ctrl+Shift and clicking on the Windows Terminal icons pinned to my taskbar.
   2. Right-clicking the Windows Terminal icon pinned to my taskbar, right-clicking again on Windows terminal in the jumplist, and selecting Run as administrator.
   3. Finding Windows Terminal or wt.exe in the Start menu, holding Ctrl+Shift and hitting Enter.
   4. Locating wt.exe in Windows Explorer, either at C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.6.10571.0_x64__8wekyb3d8bbwe\wt.exe or at C:\Users\Me\AppData\Local\Microsoft\WindowsApps\wt.exe or at C:\Users\Me\AppData\Local\Microsoft\WindowsApps\Microsoft.WindowsTerminal_8wekyb3d8bbwe\wt.exe, right-clicking it and selecting Run as administrator.

   but not

   1. Running wt.exe from an elevated (running as the other user, MeAdmin) cmd.exe/pwsh.exe/etc.
   2. Locating wt.exe as in item (iv) above, right-clicking while holding Shift, and selecting Run as different user.

---

TLDR: Contrary to what you wrote, it is possible to run UWP "modern apps under the identity other than the currently logged-in user" AT LEAST WHEN all the following is true: (a) The app is a Centennial/Desktop Bridge/fulltrust/whatever-you-call-it-today app; (b) It is installed for both users; (c) the other user is an administrator, and (d) It is being run as the other user "elevated", with the full token rather than with the UAC-filtered token.

Are (c) and (d) really requirements? I don't know. Maybe there are other ways to run as a different user, but your sweeping declaration is wrong.

Since it is OBVIOUSLY possible to run Windows Terminal as a different user (come one, reproducing what I just wrote will take you less time that it took me to write it...), it's worth checking inside your employer's other departments whether this can be done without elevation, and if so how.

I understand this is somewhat harder than announcing wrong sweeping declarations, but I must ask you try nonetheless.

[DHowett]

Since it is OBVIOUSLY possible to run Windows Terminal as a different user (come one, reproducing what I just wrote will take you less time that it took me to write it...), it's worth checking inside your employer's other departments whether this can be done without elevation, and if so how.
I understand this is somewhat harder than announcing wrong sweeping declarations, but I must ask you try nonetheless.

I am certain that there would have been ways to frame this that were less incendiary, but you did not choose to use them.

It looks like the discussion on this thread has run its course. Anybody who has something constructive to add is free to e-mail me their comments.