Terminal: 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