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. https://github.com/microsoft/terminal/issues/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.

[DHowett-MSFT]

On systems that only run universal “modern” applications, there is no local administration scenario. Sorry.

This issue tracks the work we need from the application deployment team to make launching a modern packaged application with any identity that isn’t your local logged-in user identity work. This issue will be sufficient for tracking your request.

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

[bitcrazed]

Hey Alex. I think your scenario is similar to those above so no need for a new one.

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
2. The venerable Windows Console (the UI you traditionally see when you run Cmd/PowerShell directly) is a standard Win32 app and can be run under a different user's identity
3. Running under a different user identity does offer some security risk mitigation, but does not protect one from malware (e.g. keyloggers) running in the current user session.

Before we continue, let's remember ...

UAC is not a security barrier!

Elevating a process via UAC does help protect against several forms of attack, but UAC is NOT a security barrier. Nor is running tools under the identity of an arbitrary user account. They can help mitigate some risks, but they're not a security mechanism

Consider UAC:

When UAC is enabled:

1. Apps normally run without the admin bit set on the user's security token (even if the user is in the admin group), and the app is not permitted to do things that require admin rights
2. When an app is launched "elevated", after the UAC prompt, the launched process receives the identity and user token of the specified user - whether it's the current user or a different identity, but with the admin bit set. The elevated process is seen by the OS as running with elevated admin rights, and is granted permissions to do things that may affect machine-wide state and/or bypass certain standard protections. This is why it's unwise to run tools elevated by default, or elevated for extended periods of time - when elevated, such apps can "do things to things" that might not be appreciated!

However, once again, UAC/elevation is not a security barrier. UAC does not protect you from locally running malware, it does not protect you from keyloggers, it does not protect you from ransomware, etc. No single security feature will!

The best approach to protect one's self and/or one's systems from malware attack is multiple layers of defense.

UAC helps. As does correctly ACLing sensitive resources. As does running an OS & app platform that provides several layers of defense throughout. As does remoting (via something like Remote Desktop that itself implements several layers of protection) into a desktop session running on a carefully managed and highly restricted remote/virtual environment that requires biometric/2FA authentication, etc., in which only specifically permitted apps and tools can run.

Of course, this degree of security may be too costly, time-consuming, annoying, etc. for your needs/scenarios, but it does achieve the goals that many here aim to achieve. Up to where on this spectrum one is willing to invest time and resources is entirely up to you.

Get to the point Rich 😜

Sorry for the lengthy exposition, but I want to be sure we're all on the same page re. the true efficacy (from a security perspective) of launching a Terminal "as a different user" whether with or without admin rights. With this understanding (I hope) it's clear why the modern/future Windows app platform chose NOT to support running apps as a different user - the security benefits of doing so are not as valuable or effective as some might assume.

What does this mean for Terminal?

We build Windows Terminal as a modern Windows app. We chose to do so for many reasons, but in doing so, we did recognize that there would need to trade-off vs. certain capabilities/features. If Terminal doesn't meet some specific needs, we encourage you to continue to use Console or whatever 3rd party Terminal app does meet your needs. After all, no one tool can do it all for everyone!

However, do know that we remain in close contact with the app plat and security teams and continue to investigate and explore several approaches & features that will help provide layers of defense around Terminal scenarios.

Bear with us!

[dadpolice]

We build Windows Terminal as a modern Windows app. We chose to do so for many reasons, but in doing so, we did recognize that there would need to trade-off vs. certain capabilities/features. If Terminal doesn't meet some specific needs, we encourage you to continue to use Console or whatever 3rd party Terminal app does meet your needs. After all, no one tool can do it all for everyone!

@bitcrazed Is it possible to (very briefly) explain some of the functionality in modern apps that led you to that decision?

[bitcrazed]

Hey @dadpolice - sure.

We wanted to be able to take advantage of:

• Modern UX & WinUI controls (inc. Tab controls) with greater consistency with other Windows apps and tools
• Acrylic backgrounds
• Independent & clean per-user install & uninstall*
• Always Up To Date via the Store
• Push the app plat into new territory**

* Interestingly, this need, provided for inherently by the modern app platform (all users get their own independent mutable app state) is what makes supporting runas difficult, because if you don't login to said desktop and install Terminal, you wouldn't be able to runas since wouldn't have the app installed!

** We also wanted to push the app plat into new territory, and ensure that it was able to support scenarios which the app plat was originally designed to prevent (e.g. launching & communicating with arbitrary external processes, e.g. Cmd, PowerShell, WSL, ping/ipconfig/etc.).

[Sarafian]

@DHowett-MSFT and @bitcrazed I really appreciate you sharing your insight and I learned somethings as well.

We build Windows Terminal as a modern Windows app. We chose to do so for many reasons, but in doing so, we did recognize that there would need to trade-off vs. certain capabilities/features. If Terminal doesn't meet some specific needs, we encourage you to continue to use Console or whatever 3rd party Terminal app does meet your needs. After all, no one tool can do it all for everyone!

@bitcrazed Is it possible to (very briefly) explain some of the functionality in modern apps that led you to that decision?

To extend the question of @dadpolice, I've already proposed a different release format if possible because I do understand the limitations of WUP.

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.

I don't know if that is possible though. Not sure if an app built for WUP can be packaged and run outside of WUP. If not then given the "limitations" of the WUP then this won't work. Maybe, a recompilation of the same code for non WUP could be an option. As long as it is not a big hassle to implement, then adding a another release format is not a technical problem and more of a choice. It might be that there are some reasons to stay only on WUP. Looking forward to your insight on these topics as well.

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

I actually never thought about this.

Thank you all guys.

[DHowett-MSFT]

@Sarafian So, this is one of those cool things that we get sorta "for free". Terminal is actually built as a classic Win32 application and then packaged later.

The end result of this is that you can, if you're so motivated, extract the msixbundle like a zip file, then extract the msix for your architecture inside it. You'll get a folder of DLLs and EXEs. If you then double-click WindowsTerminal.exe or put it on your path or what-have-you it'll work just fine, and it'll work for any user who can access that folder.

There's a minor issue you'll run into with the dropdown icons doing it that way, but it is functional. :smile:

[Sarafian]

@DHowett-MSFT cool. Have you guys considered what I proposed? Creating another form of deliverable additional to WUP? A traditional installer that could be even leveraged by chocolatey for fast updates?

[DHowett-MSFT]

That's the subject of a very lively discussion in #1386.

[DoCode]

So we should and can add a common msi package and distribute in the same way as other tools, like VS, Msbuild, etc. Nice!

[Sarafian]

That's the subject of a very lively discussion in #1386.

Ok thanks. Continuing there.

[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.