Explore whether Terminal could be &#39;runas&#39; a different user identity #5908

@bitcrazed commented on GitHub (Jan 16, 2020):

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

@bitcrazed commented on GitHub (Jan 16, 2020): @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.

claunia commented

@parkovski commented on GitHub (Jan 28, 2020):

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.

@parkovski commented on GitHub (Jan 28, 2020): 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.

claunia commented

@cking22001 commented on GitHub (Feb 6, 2020):

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

@cking22001 commented on GitHub (Feb 6, 2020): > 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

claunia commented

@joshuatee commented on GitHub (Mar 5, 2020):

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

@joshuatee commented on GitHub (Mar 5, 2020): > 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

claunia commented

@mcwidg3t commented on GitHub (Mar 5, 2020):

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.

@mcwidg3t commented on GitHub (Mar 5, 2020): > 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.

claunia commented

@bitcrazed commented on GitHub (Mar 5, 2020):

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.

@bitcrazed commented on GitHub (Mar 5, 2020): 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.

claunia commented

@Sarafian commented on GitHub (May 5, 2020):

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.

@Sarafian commented on GitHub (May 5, 2020): 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.

claunia commented

@DHowett-MSFT commented on GitHub (May 5, 2020):

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.

@DHowett-MSFT commented on GitHub (May 5, 2020): 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.

claunia commented

@bitcrazed commented on GitHub (May 5, 2020):

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:

The UWP app model does not (currently) support running modern apps under the identity other than the currently logged-in user
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
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:

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
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!

@bitcrazed commented on GitHub (May 5, 2020): 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](https://security.stackexchange.com/questions/189491/microsoft-said-uac-is-not-a-security-barrier-but-in-what-cases). 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 1. 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](https://arstechnica.com/information-technology/2008/04/vistas-uac-security-prompt-was-designed-to-annoy-you/). 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!

claunia commented

@dadpolice commented on GitHub (May 5, 2020):

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?

@dadpolice commented on GitHub (May 5, 2020): > 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?

claunia commented

@bitcrazed commented on GitHub (May 5, 2020):

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

@bitcrazed commented on GitHub (May 5, 2020): 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 <user> difficult, because if you don't login to said <user> desktop and install Terminal, you wouldn't be able to runas <user> since <user> 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.).

claunia commented

@Sarafian commented on GitHub (May 6, 2020):

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

@Sarafian commented on GitHub (May 6, 2020): @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.

claunia commented

@DHowett-MSFT commented on GitHub (May 6, 2020):

@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. 😄

@DHowett-MSFT commented on GitHub (May 6, 2020): @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:

claunia commented

@Sarafian commented on GitHub (May 6, 2020):

@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?

@Sarafian commented on GitHub (May 6, 2020): @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?

claunia commented

@DHowett-MSFT commented on GitHub (May 6, 2020):

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

@DHowett-MSFT commented on GitHub (May 6, 2020): That's the subject of a very lively discussion in #1386.

claunia commented

@DoCode commented on GitHub (May 6, 2020):

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

@DoCode commented on GitHub (May 6, 2020): So we should and can add a common msi package and distribute in the same way as other tools, like VS, Msbuild, etc. Nice!

claunia commented

@Sarafian commented on GitHub (May 7, 2020):

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

Ok thanks. Continuing there.

@Sarafian commented on GitHub (May 7, 2020): > That's the subject of a very lively discussion in #1386. Ok thanks. Continuing there.

claunia commented

@skadog commented on GitHub (Jul 6, 2020):

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.

@skadog commented on GitHub (Jul 6, 2020): > > 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.

claunia commented

@Clifra-Jones commented on GitHub (Aug 6, 2020):

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.

@Clifra-Jones commented on GitHub (Aug 6, 2020): > 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.

claunia commented

@PeterRoots commented on GitHub (Oct 9, 2020):

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

@PeterRoots commented on GitHub (Oct 9, 2020): 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

claunia commented

@TBBle commented on GitHub (Oct 20, 2020):

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.

@TBBle commented on GitHub (Oct 20, 2020): > 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: <details> ``` 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. . ``` </details> This appears to be a repro-case for #3194, but happens without Chocolately or an elevated session.

claunia commented

@Wittionary commented on GitHub (Oct 26, 2020):

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

@Wittionary commented on GitHub (Oct 26, 2020): @TBBle Running that from an elevated Powershell 5.1 prompt allowed me to run WT as admin. Thanks!

claunia commented

@oising commented on GitHub (Oct 26, 2020):

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.

@oising commented on GitHub (Oct 26, 2020): 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.

claunia commented

@TBBle commented on GitHub (Oct 27, 2020):

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

@TBBle commented on GitHub (Oct 27, 2020): @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.

claunia commented

@Wittionary commented on GitHub (Oct 27, 2020):

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

@Wittionary commented on GitHub (Oct 27, 2020): @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.

claunia commented

@pilgi3 commented on GitHub (Oct 29, 2020):

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.

@pilgi3 commented on GitHub (Oct 29, 2020): 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.

claunia commented

@Sarafian commented on GitHub (Oct 30, 2020):

@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

@Sarafian commented on GitHub (Oct 30, 2020): > @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

claunia commented

@0byt3 commented on GitHub (Dec 10, 2020):

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.

@0byt3 commented on GitHub (Dec 10, 2020): > 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.

claunia commented

@KirkMunro commented on GitHub (Jan 12, 2021):

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 commented on GitHub (Jan 12, 2021): 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.

claunia commented

@KirkMunro commented on GitHub (Jan 13, 2021):

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.

@KirkMunro commented on GitHub (Jan 13, 2021): Regarding [this workaround](https://github.com/microsoft/terminal/issues/4217#issuecomment-712545620) 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.

claunia commented