Terminal: [Question] Configuring Windows Terminal profile to always launch elevated

[pingzing]

Hi! Is there a way to configure a profile so that the commandLine it launches always starts with elevated (admin) permissions?

Currently, you can launch the entire application as Administrator, but then every single commandLine runs as Administrator, which is not ideal.

[zadjii-msft]

There is not. I don't think we plan on supporting mixed elevated and unelevated tabs, because it's a bit of a security hole.

Yes I know sudo is a thing, but we've had lots of discussions with the security team about the creation of a sudo for Windows. The main problem is due to the fact that any unelevated processes can send keystrokes to any other unelevated windows.

If you had an elevated commandline running in an unelevated window, an untrusted bad actor could execute an elevation-of-privilege attack by driving the unelevated windows that's running the elevated commandline.

(as a matter of linking related threads, #146)

---

EDIT (Feb 14 2020)
Okay, so this comment didn't age super well. Originally, there was _no_ plan to support this, since it wouldn't work with the single HWND we had. We're working on designing a solution that _might_ support this in the future, but we can't commit to anything until we're sure that we can come up with an appropriately secure solution, that ensures that a lower privileged process can't drive a higher privilege terminal.

[pingzing]

Seems reasonable. I think having something like a combination of #576 (Open as Admin in the jump list), and maybe some kind of hotkey to launch an Admin session of the Terminal would solve most of my pain here.

[mdtauk]

What about having a standard and elevated Terminal open in a single window but separate tabs?

[zadjii-msft]

@mdtauk I think that unfortunately falls under the same category. Since all the tabs are under the same HWND, the root HWND is what would need to be elevated to prevent non-elevated apps from driving the window.

[sba923]

From a security standpoint (ignoring Windows Terminal's design, single root HWND etc.), how "less secure" is Terminal running mixed-elevation tabs compared to running, say, one elevated PowerShell instance next to one non-elevated one in the current UX? The fact the console apps are hosted in Terminal tabs doesn't make a difference to me...

[dasMulli]

On a similar note: How is having a non-elevated window more secure even if I open a remote PS session where I may now have admin privileges on a remote server that a non-elevated could now drive. For me this seems much worse than gaining local admin access, so I don't think that running a tab as admin is any different than remoting / ssh-ing into other servers. In both cases, I need to feel comfortable enough with my system to do it. It's an "I'm old enough and I understand the risks" thing.

[LuisCor]

Whenever I try to run the Terminal app with an administrator account, right click -> run as administrator, the UAC pops up twice and an error occurs saying:
"Windows cannot find (path\WindowsTerminal.exe) Make sure you typed ...".

The path exists and the app works correctly for the non admin user that built the app, but the other administrator user is unable to run it.
If I login to the admin user the terminal app is not present in either the settings or the start menu, as if it was never installed on the system.

Is there a way to build the app so that it installs for all users? Or does the root of the project have to be on a non user specific directory?

[mhouston100]

@

Whenever I try to run the Terminal app with an administrator account, right click -> run as administrator, the UAC pops up twice and an error occurs saying:
"Windows cannot find (path\WindowsTerminal.exe) Make sure you typed ...".

The path exists and the app works correctly for the non admin user that built the app, but the other administrator user is unable to run it.
If I login to the admin user the terminal app is not present in either the settings or the start menu, as if it was never installed on the system.

Is there a way to build the app so that it installs for all users? Or does the root of the project have to be on a non user specific directory?

I'm seeing the same issue happening also.

Windows version 18922.1000

[cking22001]

Right, so running store apps as admin or different user is not working (by design BTW). Many of us are logged in (to PC) as a normal non-elevated account. We run powershell/cmd/etc as an admin to do certain tasks.

If the final choice is to deploy this app is the Windows store, it is useless to me without some way to open elevated tabs. My 2 cents.

[sba923]

"Useless" is maybe a bit harsh, but indeed we do need a way to use the new terminal both for non-elevated and for elevated console apps / shells. And for me the best UX would be to support a mix of elevated and non-elevated tabs in the same Windows Terminal instance. Less preferable: support zero to many (typically one) elevated instances (each with one to many tabs) alongside zero to many (typically one) non-elevated instances.

[pratnala]

ConEmu is able to mix elevated and non-elevated tabs in the same window. Can't something like that be done here?

[SamuelEnglard]

Could we have an elevated Terminal launch non-elevated tabs? I still need to launch elevated BUT I can open a new tab that's "protected".

[WSLUser]

If we want to go very Windows-specific and ignore other platforms that may eventually see Terminal, perhaps usage of Windows Containers or virtualized processes could help this pain point for some. I personally am just fine with current solution but getting console apps to run as a isolated processes by default wouldn't be such as bad idea from security point of view.

[kort3x]

Mixed elevation in one window is a must, for me at least.
Could it be an optional feature to be toggled in settings?

[oising]

@pratnala With ConEmu it only _looks_ like it's doing that, but it's not really doing that at all. The elevated and unelevated "tabs" are just views into two completely separate, isolated root windows/processes. It does this by scraping the windows' contents among other things and proxy/broker elevation helpers etc . Sure, it's technically possible, but what ConEmu does is actually kinda unsafe. It's one thing for a third party program to do this and have people opt into the risk by downloading ConEmu, but quite another for Microsoft to officially endorse this by doing this itself. If I want to hide my front door keys under the doormat, then fine - that's my dumb risk to take. But what if every door you bought put a set of keys under the doormat?

[robomac]

But see, I develop in C++ (and C#, PowerShell, Ruby, Python, GoLang, pretty much anything that comes my way.) I have ConEmu and TakeCommand installed, along with mingw. I know which way to hold the scissors while I run.

PowerShell _is_ a security hole. A very useful automation tool, allowing all sorts of unexpected access. And what we're asking for (mixed modes) is certainly safer than the alternative (all elevated.) Really this (terminal) is a power tool for power users, most of whom probably understand the security landscape extremely well... and understand pragmatic compromise.

Zero-trust only works when it's not debilitating.

[DHowett-MSFT]

@robomac If we could convince the security team (who has told us on multiple occasions to not even venture remotely close to mixed elevation) that only people who know how to hold their scissors the right way and not run with them would _use_ this project, we'd probably do it. I don't know if I believe it myself. Here's why:

Like as not, if Terminal is running in mixed elevation (from a Medium-IL host to a High-IL client), it can still be forced to receive input by anything else running as that user. Even if the person behind the keyboard is a saint and only elevates for the ten seconds she needs to elevate for, _any application running under her user account can impersonate the administrator without an additional elevation prompt_. Likely entirely undetected, even.

[robomac]

@DHowett-MSFT I thank you for responding. You make an assumption that we are allowing malicious processes running anyhow. We restrict permissions out of "Best Practices" mantras we do with our downward-facing-dog pose every morning, but if you really have a concern that a few hours, even, of elevated terminal access puts you at risk _on your own system that you're developing on_ ...

1. You shouldn't be running Terminal and
2. You should wipe and start over.

I'll grant you that a (computer) virus researcher shouldn't risk this in a vector path... but even early on we were sandboxing them in VMs. But "Terminal" isn't for your unsavvy relatives; it's a power tool.

There is a standard way of dealing with the risk. Brought to you by the browser world. When you go to the advanced flags, you receive a warning of, roughly, "Here be dragons". (I think it's precisely that in Pale Moon... which is the serious hard-core security browser.) Add the (non-UAC, additional) warning, but let the user decide.

One other question: Would two distinct sessions of Terminal, one elevated, one not, behave as expected? Or would both be vectors for any sessions?

[DHowett-MSFT]

I don't disagree that people should be able to opt into something like this. :smile:

two distinct sessions

Oh, yeah, that should absolutely work today -- and not be a vector (the elevated one is fully running on the High-IL side of the world and cannot be driven by any other Medium-IL process)

[pratnala]

that should absolutely work today

In the same spirit, can't 2 tabs run in different processes and thus enable mixed elevation in the same window?

[robomac]

@DHowett-MSFT So why can't the two distinct sessions be hosted in the over-arching app? It really isn't hard to do.

[sba923]

I think I understand the security implications of having elevated console apps in the first place, but what I can't grasp is why having two types of tabs (elevated and non-elevated) within Windows Terminal would be _more risky_ than what Windows has supported for ages i.e. running elevated and non-elevated CMD's / PowerShell's side-by-side. Can someone shed some light on this?

[DHowett-MSFT]

@robomac
[1] It is trivial when you are _hosting traditional windows_ with traditional window handles. That works very well in the conemu case, or in the tabbed shell case, where you can take over a window in an elevated session and re-parent it under a window in a non-elevated session.

When you do that, there's a few security features that I'll touch on in [2]. Because of those, you can parent it but you can't really force it to do anything.

There's a problem, though. The Terminal isn't architected as a collection of re-parentable windows. For example, it's not running a console host and moving its window into a tab. It was designed to support a "connection" -- something that can read and write text. It's a lower-level primitive than a window. We realized the error of our ways and decided that the UNIX model was right the entire time, and pipes and text and streams are _where it's at._

Given that we're using Xaml islands to host a modern UI and stitching a DirectX surface into it, we're far beyond the world of standard window handles anyway. Xaml islands are fully composed into a single HWND, much like Chrome and Firefox and the gamut of DirectX/OpenGL/SDL games. We don't have components that can be run in one process (elevated) and hosted in another (non-elevated) that aren't the aforementioned "connections".

Now, the obvious followup question is _"why can't you have one elevated connection in a tab next to a non-elevated connection?"_ This is where @sba923 should pick up reading (:smile:). I'm probably going to cover some things that you (@robomac) know already.

[2] When you have two windows on the same desktop in the same window station, they can communicate with eachother. I can use SendKeys easily through WScript.Shell to send keyboard input to any window that the shell can see.

Running a process elevated _severs_ that connection. The shell can't see the elevated window. No other program at the same integrity level as the shell can see the elevated window. Even if it has its window handle, it can't really interact with it. This is also why you can't drag/drop from explorer into notepad if notepad is running elevated. Only another elevated process can interact with another elevated window.

That "security" feature (call it what you like, it was probably intended to be a security feature at one point) only exists for a few session-global object types. Windows are one of them. Pipes aren't really one of them.

Because of that, it's trivial to break that security. Take the terminal as an example of that. If we start an elevated connection and host it in a _non-elevated_ window, we've suddenly created a conduit through that security boundary. The elevated thing on the other end isn't a window, it's just a text-mode application. It immediately does the bidding of the non-elevated host.

Anybody that can _control_ the non-elevated host (like WScript.Shell::SendKeys) _also_ gets an instant conduit through the elevation boundary. Suddenly, any medium integrity application on your system can control a high-integrity process. This could be your browser, or the bitcoin miner that got installed with the left-pad package from NPM, or really any number of things.

It's a small risk, but it _is_ a risk.

---

Other platforms have accepted that risk in preference for user convenience. They aren't wrong to do so, but I think Microsoft gets less of a "pass" on things like "accepting risk for user convenience". Windows 9x was an unmitigated security disaster, and limited user accounts and elevation prompts and kernel-level security for window management were the answer to those things. They're not locks to be loosened lightly.

[sba923]

@DHowett-MSFT Thank you so much for the clarification. I think we'll have to get used to running one elevated instance of Windows Terminal and one non-elevated instance side-by-side, much like we're doing with console apps these days.

[robomac]

Fascinating. Thank you. Terminal being more a connection-renderer than a window does make sense. Does that give PowerShell, already rather pipe/connection focused, any additional control over previously in a windowed console?

Are separate Terminal sessions fully isolated from each-other?

[damnsalvation]

I'd be entirely satisfied with just having an indication that I'm in an elevated session. Like "Administrator: \ I'm missing that pretty bad right about now.

[DHowett-MSFT]

???

[Fisico]

"Run as different user" is a thing all windows admins need! This would be very helpful if it is available. The best option would be to have it with a flag in the config for each profile.

[ecki]

BTW, speaking of window isolation, let me quote the latest ctfmon vulnerability report

The obvious attack is an unprivileged user injecting commands into an Administrator's console session, or reading passwords as users log in. Even sandboxed AppContainer processes can perform the same attack.

[oising]

@ecki That is quite a disturbing piece of news alright. I'm sure Tavis is off partying tonight after that one.

[Fisico]

@DHDHowett-MSFT
As many here have written, if the new terminal is not able to start with option "run as different user" than for a big number of users it is not very usable, also it is not compatible with Microsoft’s “Active Directory administrative tier model” if you for example have an AD user with default rights, and run PS Scripts with an Adminuser on a domain controller.

I don’t have many cases where I start a terminal with my currently logged in user… so I ask you, what is the use case of this Terminal than? Ping, nslookup etc,.. if that is the intention than why are you putting so much work into all this?

With “run as Administrator” you have some valid points, but why other Consoles like (PS6/7) still support these functions, if it is that insecure?

I always thought the new Terminal App will replace all the separate cmd/PS/… windows, but as it seems it is not usable in many real world scenarios. This is kind of sad tbh...

[DHowett-MSFT]

@Fisico your experience is not universal, and I’d encourage you to consider that when asking somebody to justify their project’s very existence.

[DHowett-MSFT]

To your overarching point about "run as different user" not existing/not working: that's a platform limitation that we're trying to get lifted. It's not through malice or incompetence that we do not support it.

As for why other console applications _do_ support it, it is not insecure when they do because they are specifically not hosting different elevation levels in the same window. That's the core issue here. Because they are hosted in standalone processes with standalone windows, they are free from the restriction on cross-integrity-level manipulation.

[Fisico]

@DHowett-MSFT
Sorry if I offended you with my post, it was not my intention, I put too much emotion into it.
I think the Terminal is a great idea and has a very big potential and I’m glad you are developing it with the community to get the most out of it.

At this point there is so much confusion on what is implemented and what not.
“Run as Administrator” for the whole app is working at the moment, is this here to stay?

As I understand, “Run as Administrator” for each tab/profile is not something you want to implement. I think this ok for most of us.

“Run as different user” is not possible because Windows does not support it for apps, and you/we have to wait until Windows supports it? If so are we speaking of years?

“Run as different user” per tab/profile is also something you do not want to implement?

[robomac]

@DHDHowett-MSFT
As many here have written, if the new terminal is not able to start with option "run as different user"
than for a big number of users it is not very usable, ... I always thought the new Terminal App will
replace all the separate cmd/PS/… windows, but as it seems it is not usable in many real world scenarios. This is kind of sad tbh...

I don't agree. This is a huge advance over what we had before. Unfortunately, most of us probably have gotten in the habit of running our shells elevated because of lack of a more granular approach... and we still can. We can't _mix_ them... but we never did. Seriously, at the _last three_ companies I've been at, the Developer Wiki has doing all builds/tests in an elevated VS prompt. We implement security through real-time scans, aggressive active firewalls and knowing that our developers seldom screw up. The _non-developers_ never run elevated, because (1) we can't trust them and (2) they don't need to.

So I, for one, am appreciative of this new Terminal. It's not perfect, but neither is Take Command / TCC. At least this is standard.

[Fisico]

@DHDHowett-MSFT
As many here have written, if the new terminal is not able to start with option "run as different user"
than for a big number of users it is not very usable, ... I always thought the new Terminal App will
replace all the separate cmd/PS/… windows, but as it seems it is not usable in many real world scenarios. This is kind of sad tbh...

I don't agree. This is a huge advance over what we had before. Unfortunately, most of us probably have gotten in the habit of running our shells elevated because of lack of a more granular approach... and we still can. We can't _mix_ them... but we never did. Seriously, at the _last three_ companies I've been at, the Developer Wiki has doing all builds/tests in an elevated VS prompt. We implement security through real-time scans, aggressive active firewalls and knowing that our developers seldom screw up. The _non-developers_ never run elevated, because (1) we can't trust them and (2) they don't need to.

So I, for one, am appreciative of this new Terminal. It's not perfect, but neither is Take Command / TCC. At least this is standard.

elevated != run as different user.
I run PowerShell more with other AD users, then with my own one.
I’m with you that you often run a cmd or PS as admin even if you don’t have to, but there are so many cases where you have to run it as admin. Most sysadmin tasks require admin rights or a different user with some sort of privileges.
Sure if you need to run cmd’s in user context it is all ok.

[robomac]

I understand that "elevated != run as different user". I just don't believe "run as different user" is nearly as common as you claim.

[Fisico]

I understand that "elevated != run as different user". I just don't believe "run as different user" is nearly as common as you claim.

If you have something to do with the Microsoft universe than you absolutely need it.
It is not the best idea to login to windows machines with domain admin rights for example.
Running PS scripts with a user that has domainadmin rights or some other rights is very common.

[SamuelEnglard]

@Fisico why not use the New-PSSession command then?

[WSLUser]

Automated scripts that require some type of specific elevation for a service typically require 'run as different user'. Whether that applies to Terminal is a different story. You can always change your login once in a CMD or PS session using the runascommand. This would not change the elevation state of the tab as it's utilizing the underlying login, which is your regular user. Also any scripts you'd run using Task Scheduler or a cron job won't require Terminal to run unless you're utilizing it to get a functionality that somehow doesn't exist in a normal console session. If that's the case, the utilization of parameters to run that script with Terminal, which launches as a background process would be the solution.

Therefore mixed elevation for tabs isn't necessary. We have a workaround and it's easy enough to copy the specific runas commands you need to a txt file that you can copy/paste into the Terminal and then fill out your password (you should never save your password to anything that's unencrypted).

[Fisico]

@SamuelEnglard
i don't want to connect to a remote host, to run a script.

@WSLUser yea it is a option to use runas, but it is much more convenient to simply run the terminal or PS as a different user. I don't see why this should be a problem.

[SamuelEnglard]

@Fisico New-PSSession doesn't need to connect to a remote computer, see the secondfirst syntax entry.

[jkavanagh58]

@SamuelEnglard
i don't want to connect to a remote host, to run a script.

@WSLUser yea it is a option to use runas, but it is much more convenient to simply run the terminal or PS as a different user. I don't see why this should be a problem.

It is pretty standard operation for a user to pin PowerShell to taskbar and Right-Click to run as Admin or in some environments RunAs OtherUser as an elevated account is needed to run and enterprise level script. To say not possible for terminal is like the environments that leverage PSLockDown and force RunAs Admin just to load the shell or VSCode
IMHO

[SamuelEnglard]

If you really need to have a tab run as a different user you could have a profile that runs New-PSSession -Credential | Enter-PSSession at start.

DISCLAIMER: I take no responsibility for computers ruined from doing this.

[jkavanagh58]

If you really need to have a tab run as a different user you could have a profile that runs New-PSSession -Credential | Enter-PSSession at start.

> DISCLAIMER: I take no responsibility for computers ruined from doing this.

Sure, or the "security" standing here could be re-considered. Again, I pin PowerShell to my Task bar, from there I can launch PowerShell non-elevated; I can right-click that and choose "Run As Administrator" and if in a corp environment I can Right-Click on the icon, then Shift-Right-Click on "Windows PowerShell" and select "Run as Different User" to launch PowerShell with alternate credentials. No sessions, no RDP'ing to another host to obtain those creds.

[SamuelEnglard]

Sure, or the "security" standing here could be re-considered. Again, I pin PowerShell to my Task bar, from there I can launch PowerShell non-elevated; I can right-click that and choose "Run As Administrator" and if in a corp environment I can Right-Click on the icon, then Shift-Right-Click on "Windows PowerShell" and select "Run as Different User" to launch PowerShell with alternate credentials. No sessions, no RDP'ing to another host to obtain those creds.

Yes, and I can also do that with Windows Terminal. Agreed. I don't see how that helps those who want to have a mix of tabs that are running as different users (or different elevation).

[cking22001]

"mixed tabs" aside, I just want to clarify, you CANNOT do that with (the released preview) Windows Terminal due to the design of Windows Store apps. You can only run as the user that installed that app and logged in as that same user.

All I want is to be able to do what I do today, log onto the PC as normal user and run elevated shells. If Windows Terminal is released as is, it is little use to me.

[sba923]

Very good point. This limitation doesn't exist with private (non-store) builds of Windows Terminal.

[pratnala]

"mixed tabs" aside, I just want to clarify, you CANNOT do that with (the released preview) Windows Terminal due to the design of Windows Store apps. You can only run as the user that installed that app and logged in as that same user.

All I want is to be able to do what I do today, log onto the PC as normal user and run elevated shells. If Windows Terminal is released as is, it is little use to me.

I just opened 2 instances of the store build of Windows Terminal - one elevated, and one not. So I don't know why is it not working for you.

[cking22001]

Ok, I have to believe you are a local admin on your PC. To be clear, maybe I should clarify. I am never a local admin on my workstation. So when I go to 'run as admin' I am prompted for user/password.

The 'admin' account I use is different from my normal malware/email reading account. So technically what I do is run as different user. This is the Windows Store app limitation. The solution (and maybe they will do this) is to release this as a Windows component that won't have those limitations.

[Lummox342]

*[URGENT] ALL I HAVE FOUND A SOLUTION TO THIS ISSUE!**

By following this guide
https://www.maketecheasier.com/access-windowsapps-folder-windows-10/
you are able to make the windows app folder your own!

once you've done this you can locate the Microsoft.WindowsTerminal._blahblahYourVersion_ folder. Once inside, locate WindowsTerminal.exe Shown below

Once you have found it, Create a shortcut of this file and place it wherever you'd like. After doing so, set it to run as administrator. You can do this by right clicking and going to _Properties>Advanced>Run as administrator_ After that click okay and you are all set!

Personally I needed this because I use the shortcut in my taskbar so that I can just hit _Windows+1_ to launch it as admin. Not the long way of navigating through my start menu to run it correctly.

[DHowett-MSFT]

You could also just unzip the bundle we put on the releases page. It’s just a ZIP file. Please note, we _do not officially support_ unpackaged execution!

[sba923]

But this still means there's no _supported_ way to run elevated! I think this is a must-have feature.

[zadjii-msft]

[sba923]

Indeed, I stand corrected.

What _is_ missing is the "run as administrator" entry in the taskbar shortcut's right-click menu.

[dasMulli]

Talked to a few people yesterday at a meetup and a few people said they mainly launch powershell with Windows+X and would love to have terminal / terminal as admin in there.

[sba923]

Very good point!

[Lummox342]

That's exactly my point! This is the solution for running it from taskbar
with admin privileges!

On Sun, Aug 25, 2019, 1:08 AM Stéphane BARIZIEN [e-mail]
wrote:

Very good point!

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/microsoft/terminal/issues/632?email_source=notifications&email_token=AKO4CP6JWWDNLGCHWNIJGFTQGIOULA5CNFSM4HL5EE72YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD5CNA6Q#issuecomment-524603514,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AKO4CPZ6YRX5V3ERW4L2GWLQGIOULANCNFSM4HL5EE7Q
.

[scottrudy]

Indeed, I stand corrected.

What _is_ missing is the "run as administrator" entry in the taskbar shortcut's right-click menu.

In the taskbar right-click twice. Once on the icon to make the context menu come up, then a second time on app name. e.g. "Windows Terminal (Preview)" and choose "Run as Administrator"

[sba923]

I feel confused.

Blushing.

Ashamed.

How come I didn't think of this?

Thanks anyway for sharing with us all!

[PhMajerus]

Let's look at the problem from the other end...
Windows lets non-elevated processes control other non-elevated processes, sending keystrokes, capturing their UI, etc... but prevents non-elevated process from doing that to a window of an elevated process.
The Windows Terminal is designed to be also used to manage remote servers, through ssh, PowerShell remoting, etc...
This means the Windows Terminal becomes a security hole as soon as it is used for administration, as a local malware could wait for a Windows Terminal session to spy on what the user is doing, and as soon as it detects a remote shell, try to inject commands to infect the server using admin rights.

Preventing the Windows Terminal from being run as admin doesn't seem like a security improvement at all, as running it as admin would instead protect the user from non-elevated processes hijacking their remote shell sessions. Running it as admin should be recommend to the user whenever they use a tool that gives them an elevated command prompt, locally or remotely.

And about sudo for Windows, doesn't running the sshd service and then connecting to localhost from a non-elevated shell exhibit the same security issue?

[SamuelEnglard]

This means the Windows Terminal becomes a security hole as soon as it is used for administration, as a local malware could wait for a Windows Terminal session to spy on what the user is doing, and as soon as it detects a remote shell, try to inject commands to infect the server using admin rights.

While it's true that the remote system could be infected (assuming the remote process has admin rights), that doesn't mean we should also let it infect the local system too.

Preventing the Windows Terminal from being run as admin doesn't seem like a security improvement at all, as running it as admin would instead protect the user from non-elevated processes hijacking their remote shell sessions. Running it as admin should be recommend to the user whenever they use a tool that gives them an elevated command prompt, locally or remotely.

Nothing is stopping you from running the Windows Terminal with admin rights right now. The issue at hand is about having mixed elevated and non-elevated tabs.

[zadjii-msft]

@SamuelEnglard spot on response.

To add, what we're trying to do is avoid adding _new_ security holes. The original console was the same problems w.r.t. remote server management. Nothing we can do about that unfortunately. Users doing remote server management are always running their consoles/terminals elevated, and that will give them some additional security (though I'm no security expert and I wouldn't construe that statement as advice)

[PoolloverNathan]

Idea for progress on this issue: Try to run the entire _app_ as elevated, and if that succeeds, add a button next to each "open" button with the icon of a UAC shield, and add a prefix keybind for opening an elevated tab: CtrlShiftE. (I checked and this was unbound.) It only works for the next tab open.

Anyway, the opened tabs have a UAC icon before their regular icon, and are ran as administrator. (Remember, programs can't send this keys anymore. We ran the app as administrator.)

The app should try to auto-elevate, and if that fails, run normally, and ignore this entire thread.

[sba923]

Indeed, I stand corrected.
What _is_ missing is the "run as administrator" entry in the taskbar shortcut's right-click menu.

In the taskbar right-click twice. Once on the icon to make the context menu come up, then a second time on app name. e.g. "Windows Terminal (Preview)" and choose "Run as Administrator"

Just noticed that the UAC prompt one gets in that case says "Unknown program."

Rather unexpected if you ask me...

[DHowett-MSFT]

@sba923 that's #2289 :smile:

[sba923]

@DHowett-MSFT thanks for the info; good to know that's (already) tracked.

[SamuelEnglard]

The best answer to this I can think of is to have the option to have a profile the must be elevated and if the current windows is not elevate, start a new elevated instance with that profile. (Think how private browsing sessions work)

[sba923]

Very good idea

[EmTschi]

I used this way to add the Terminal in the Win+X menu:
Create a new shortcut with the target:
C:\Windows\explorer.exe shell:appsFolder\Microsoft.WindowsTerminal_xxxxxxxxxxxx!App
edit:
Sorry, this won't work if you want to run the App as Admin.
Instead you can use nircmd and create a shortcut with
cmd.exe /q /c nircmd elevate "shell:appsFolder\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App"

(the correct path for "Microsoft.WindowsTerminal_xxxxxxxxxxxx" can be find out with the PS command "Get-appxpackage *WindowsTerminal*", use the entry in PackageFamilyName)

This shortcut can be used to start the terminal with administrator privileges with simple an doubleclick and with WinXEditor it can be added in the Win+X menu.
Note: The terminal must be also installed in the administrator account.

[ravensorb]

Is the idea to load every profile as Administrator or only certain ones? Ideally I'd like to have it by individual profile. Maybe a property that is the "runas" account and another one as "iselevated"?

[sba923]

As discussed at length in this thread, you can't have a mix of elevated and non-elevated in the same instance of Windows Terminal, and this will not be added.

[aaronsteers]

Indeed, I stand corrected.
What _is_ missing is the "run as administrator" entry in the taskbar shortcut's right-click menu.

In the taskbar right-click twice. Once on the icon to make the context menu come up, then a second time on app name. e.g. "Windows Terminal (Preview)" and choose "Run as Administrator"

FWIW, I just tested shift-and-right-click which gives the "Run as administrator" option right away - only slightly faster than the two right-clicks option which was previously my go-to.

[Misaka-0x447f]

Hey guys did you forgot the UAC? Application cannot click things in safe desktop.

[Jannnnnnnnnnnn]

FWIW, I just tested shift-and-right-click which gives the "Run as administrator" option right away - only slightly faster than the two right-clicks option which was previously my go-to.

You can also ctrl + shift + left-click on the icon to bring up the UAC instantly.

[sba923]

Terrific, thanks a bunch! How many shortcuts do we have to remember? ;-)

[miketheitguy]

To your overarching point about "run as different user" not existing/not working: that's a platform limitation that we're trying to get lifted. It's not through malice or incompetence that we do not support it.

As for why other console applications _do_ support it, it is not insecure when they do because they are specifically not hosting different elevation levels in the same window. That's the core issue here. Because they are hosted in standalone processes with standalone windows, they are free from the restriction on cross-integrity-level manipulation.

Definitely hope running as a different user is something that comes at some point. While not the majority of my day-to-day activity, some powershell cmdlets require elevation (and I run with different users, think a protected user admin).

It's not the end of the world, but will certainly be annoying having to drop back to the legacy shells.

In time, I guess!

[sba923]

There is absolutely no issue / limitation with using Windows Terminal elevated, so no need to stick with the "legacy shells" (or to be more exact: to the legacy console host).

It's just that you can't mix elevated and non-elevated in (different tabs within) the same instance.

[miketheitguy]

There is absolutely no issue / limitation with using Windows Terminal elevated, so no need to stick with the "legacy shells" (or to be more exact: to the legacy console host).

It's just that you can't mix elevated and non-elevated in (different tabs within) the same instance.

I guess I may have misinterpreted the above, but there's a platform limitation with running the terminal under a different user context altogether from what I'm reading.

[cking22001]

I guess I may have misinterpreted the above, but there's a platform limitation with running the terminal under a different user context altogether from what I'm reading.

Yah, this thread has been all over the board on that point. I am not an admin on my workstations so 'run as admin' merely prompts me to enter my 'elevated creds'.

We should probably simply have a new thread about that use case.

To be clear, what I mean (and I think a lot of 'admins' need) is the ability to be logged into our workstation as a normal user. Then run 'some shell' as an elevated user as in say Domain Admin to do AD work.

Right or wrong, that is what some of us do and need. All the tricks about installing the Console from the store as that user and devising clever shortcuts have not really worked for me.

And yes, I can do this in a number of ways and maybe I should be restricting some of these activities to a protected workstation but reality is, as a normal user, I don't need a shell generally.

[sba923]

IMVHO the confusion stems from the fact people are (hold pre-Vista habits dying hard) more or less interchangeably using the terms "elevated" and "as another [domain] [admin] user."

Running as another user is not the same thing as running elevated.

1. Some of the people on this thread have the need, when logged on as an admin user, to run Windows Terminal workloads with elevation.

2. Some other people have the need, when logged on as a normal (or non-domain-admin) user, to run Windows Terminal workloads as another, admin user, typically with elevation.

3. One could also consider the case where people are logged on as normal user A and want to run Windows Terminal workloads as user B without elevation.

In #2 and #3, the Windows Store based deployment makes the story more complex, because Windows Terminal will not run as the logged on user, where the "store apps" are deployed for that user.

Hope I understand the situation correctly. If I do, I hope this clarifies the matter a little bit.

[cking22001]

You got it right exactly.

[JakeMoe]

Just FYI, that exact issue, unable to elevate ("Run As Administrator", as opposed to running as another administrative user, "Run As Different User") when the account you are logged in with is not a local administrator on the system, as per best practices), was briefly covered in another issue: https://github.com/microsoft/terminal/issues/1538. That was closed with an explanation of it being a Windows problem, not a Terminal problem, as it seems to be a limitation of Store apps.

Without getting into a debate as to whether this should have been released as an MSI install instead of using the Store, there is a workaround in that thread I've used; log in briefly as your admin account, install the app from the Store, and then log back out again. Run As Administrator then worked for my normal user account (until the next update, when it'll have to be done again).

[sba923]

Yes there should be a MSI available. My new employer disallows (public) Store installs so the only way I'll be able to use Windows Terminal will be to build from source...

[garethmorris78]

Disappointed to see you can't run Windows Terminal "as administrator " without errors and then having to implement a workaround. I'd say a lot of companies implement a separation of privilege approach for identities (with ICT employees having a privileged and non-privileged account). So, being able to accommodate this requirement by providing an optional MSI deployment as per @sba923 suggestion would be a neat approach until such time store bundled apps can cope with privilage seperation ?

[SamuelEnglard]

This is a PREVIEW not even 1.0 release...

[aaronsteers]

I feel this topic has been fairly well discussed at this point, but there's one perspective I haven't understood yet: why can we not create a Windows shortcut to this app? That's the typical workaround to "always launch as administrator" - the typical workaround is to create a shortcut and change the shortcut to use elevated access as default.

Can someone please explain to me why we can't create a shortcut to this app? This is probably more related to the inner workings of Windows than the inner workings of Terminal, but I feel we are beating around the bush if I don't ask it directly.

Thanks.

[Firehawke]

I keep nircmd in my c:\utils folder along with a lot of other commonly used tools.
I added a profile that looks like this:

        {
            "name": "Admin Terminal",
            "startingDirectory": "c:\\utils\\",
            "commandline": "cmd.exe /q /c nircmd elevate \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
            "hidden": false
        },

It brings up a UAC elevation request, then opens up an admin instance of Windows Terminal. It's a decent workaround for the moment.

I'd be fine with the ability to tag sessions as Elevated and have them open in a new window, honestly.

[glooms]

I came here looking for a neat solution but as it does not seem to exist so I'll just share my hacky-ish solution. I added a profile for running powershell elevated:

{
...
  "commandline" : "powershell.exe -Command \"Start-Process PowerShell -Verb RunAs\"",
...
}

It pops up in a seperate window but it gets the work done.

[DHowett-MSFT]

I feel this topic has been fairly well discussed at this point, but there's one perspective I haven't understood yet: why can we not create a Windows shortcut to this app? That's the typical workaround to "always launch as administrator" - the typical workaround is to create a shortcut and change the shortcut to use elevated access as default.

Can someone please explain to me why we can't create a shortcut to this app? This is probably more related to the inner workings of Windows than the inner workings of Terminal, but I feel we are beating around the bush if I don't ask it directly.

Thanks.

@aaronsteers, you're right that it's more about Windows than it is about Terminal. The main issue here is that we're distributed and installed as a "modern application package." They've got a number of restrictions and accidental limitations compared to native applications, but it's necessary for Terminal because it's also the least difficult way to use components of the "modern Windows API" (WinRT). It's terrifically frustrating to everybody on the team almost all the time. :smile:

We're trying to turn that frustration, and the community's frustration, into advancement for the platform. I'll apologize, though, that change isn't quick over here in Windows!

[robomac]

@DHowett I'm really trying to understand, because I 2/3 like Terminal, but it's not doing some basics I'm accustomed to with TakeCommand or ConEmu, etc.

I can't mix elevations in the various tabs. If I'm understanding, that's because you're a different kind of app and aren't really hosting the shell?

The scrollback buffer never clears, in any of the three environments (cmd, PowerShell, wsl bash.) It does in my normal shells. Again, because of how it's hosted?

And it would be quite nice to have a context or drop-down menu more accessible. For example, to clear that scrollback, considering even the console escape trick didn't work for me.

The integration of the environments, and how well it picks up WSL Linux shells, is really nice. But it's costing a lot of usability through the elevation and scrollback issues, so I seldom use it.

[zadjii-msft]

@robomac There's a great post by @DHowett-MSFT here that explains why we can't mix elevated and unelevated tabs in the same unelevated window.

The tl;dr is: If we allowed users to connect to elevated commandlines from an unelevated Terminal window, then that creates a giant security hole, where other unelevated applications could effectively drive the elevated process, via the Terminal window.

I don't know how ConEmu mitigates this risk, if they do at all. It's entirely possible that it's a security hole that conemu creates which we're not comfortable shipping as a part of the Windows Terminal.

The rest of your concerns are all issues that are tracked elsewhere in this repo, I suggest searching for them to track their progress individually. We'd prefer keep this thread on the single topic of "mixed elevation of tabs"/"having a profile that launches elevated"

---

On topic: I do want to experiment with the "launch another instance elevated" route for "elevated" profiles. If the user experience isn't too bad, then that's a possible route forward here, at least as an option.

[DJackman123]

ConEmu does not mitigate this risk. They pass that risk onto their users. (I'm not even sure they are documenting this risk.)

On the "launch another instance elevated" topic: I wouldn't mind this behavior as long as it can use the same elevated instance of Terminal for these tabs and not launch a new instance each time I invoke an "elevated" profile.

[agr]

In my opinion, the "giantness"of the that security hole is a bit overstated. It is not normal to have a malware on one's computer that sits and waits for a chance to get elevated, so sacrificing convenience for security does not feel right.

On the other hand, if the end goal is to have WT to be shipped with Windows as a default terminal, that would increase the attack surface dramatically. But again, in this case, I personally would mitigate a risk by using an unpopular alternative that is unlikely to be a target for such attack and provides the required convenience (assuming detecting the presence of an elevated tab in a terminal is non-trivial enough to be terminal-specific).

[SeSeKenny]

Some of this is tl;dr for me, but if you take and dump the package, you can run wt outside of sandboxing, meaning elevation, and run as different user works without issue. I had talked to MSFT at ignite about this and was told to submit a pull request, but my VS skills are pretty weak. What would be easy enough to do is sign it properly (had to do this with my own internal pki so I could run on applocker) and put it in an MSI or MSIX distributable format. There is the odd bug here or there that may be specific to running it this way but overall it works really nicely. For now I just have a function to extract, sign and replace/update a program files based version from the store based version.

[JWilh]

I understand the risk of that feature of "plugging" elevated tabs into an unelevated process, but isn't it possible to go the other way around?
Meening for people how need this, let the Terminal itself also run as Elevated and allow to start unelevated Tabs?
Of course, that have other disadvantages, but for me (and I think for others also) they are acceptable.
(sure, that could be "interesting" as the terminal is a windows store app, not sure if that works)

Ps. Sorry for reopen this issue (also if another person already made that suggestion and I "read over" that).

[nt4f04uNd]

Thanks to @EmTschi, I made simple and 100% convenient solution
It uses context menu and acts pretty the same as PowerShell 7 does
https://github.com/nt4f04uNd/wt-contextmenu
There you can find a guide how to implement it and all needed files

[JWilh]

Thanks for the tip, I will try out that later.
Currently I'm working with two shortcuts at my desktop, that are mapped to the keys Ctrl+Alt+T and Ctrl+Alt+Shift+T for an elevated terminal, it's also ok as an workaround, but... not as nice as it could be and miles away from something like sudo.

[tbiles]

@

Whenever I try to run the Terminal app with an administrator account, right click -> run as administrator, the UAC pops up twice and an error occurs saying:
"Windows cannot find (path\WindowsTerminal.exe) Make sure you typed ...".
The path exists and the app works correctly for the non admin user that built the app, but the other administrator user is unable to run it.
If I login to the admin user the terminal app is not present in either the settings or the start menu, as if it was never installed on the system.
Is there a way to build the app so that it installs for all users? Or does the root of the project have to be on a non user specific directory?

I'm seeing the same issue happening also.

Windows version 18922.1000

Just installed on Win10 update 1909, and I have the same issue with trying to run as Administrator

[MikaelUmaN]

Same problem here. Can't use windows terminal now because I always need to run docker and then I always need to be admin in the terminal...

[fluffynuts]

I have a hack-around solution for anyone who wants it:

1. download the msixbundle from the release page
2. unzip that, in there, find the msix that is for your platform (typically the x64 one)
3. unzip that into a folder somwhere
4. copy that folder wherever you please and run WindowsTerminal.exe elevated or however you please

A lot of this failing seems to come from the convenience of having this as a store app. There's a discussion about this on #1386 and someone there has mentioned perhaps installing with Scoop, which automates the above extraction process.

It would be nice if the following were treated as first-class citizens:

1. Portable installations (zip files -- even if the config isn't portable yet, as it lives under AppData\Local when running out of the windows store installation area)
2. A regular old .exe installer (or, if you must, .msi) for people who don't want the Store or to use the Store Installer

Both are not that tricky to implement from the current build procedure, as evidenced by the Scoop automation. And now that Windows Terminal is getting Really Rather Good, I'd like to be able to use it like I can any other terminal.

[sba923]

While we're at it: unless there are API incompatibilities, it would be great to have the option to install Windows Terminal without the Store (even the "portable" way) on earlier versions of Windows 10 (my employer blocks us at 1809/RS5, and installing from the Store is blocked).

[DHowett-MSFT]

@sba923 if we didn’t rely on APIs that only exist in 1903, we would not require 1903.

[sba923]

Sure... was my guess 😜

Will have to lobby for upgrading company-wide, probably will hit a wall...

[hparadiz]

This is so stupid.

Let's make a new unified terminal for command prompt, powershell, and bash for windows.
Can I run cmd.exe as admin?
No.

Guess I'll just keep my cmd.exe and powershell icons preset to run as admin on my taskbar indefinitely then.

Dumb stuff like this is why my main work machine is still a Macbook.

[NickStrupat]

This is so stupid.

Let's make a new unified terminal for command prompt, powershell, and bash for windows.
Can I run cmd.exe as admin?
No.

Guess I'll just keep my cmd.exe and powershell icons preset to run as admin on my taskbar indefinitely then.

Dumb stuff like this is why my main work machine is still a Macbook.

I agree in this case. I want a single Windows Terminal window that houses all the terminal tabs I need, where each terminal tab can be one of the multiple installed terminal hosts, and be elevated or not.

It really seems like this mixed elevation feature is being held back by the technical design decision to host all tabs on a single HWND handle.

[SamuelEnglard]

1) Can you run the new terminal as Admin? YES (There are issues doing so depending on how you installed it/launch it but there is no desire for this to not work). (If you do not know how to do this, see multiple posts above on how.

2) Can you have one tab with elevated while another isn't? No. See https://github.com/microsoft/terminal/issues/632#issuecomment-519375707 for why.

Can people please remember that this issue is about mixed elevation tabs?!? If you want to launch the whole process elevated and cannot please open a new issue.

@DHowett-MSFT Could we rename this issue to be about mixed elevation tabs?

[janilahti]

Whatever way this gets handled or not, elevated terminals or tabs should have some kind of indicator. Now if I start new terminal with Run as administrator, there's no way to easily notice my cmd tabs have elevated access compared to ones in the next window.

EDIT after @SamuelEnglard 's comment: Obviously I hastily chose cmd as a bad example. Yes, cmd shows 'Administrator:' in tab title. But WSL Ubuntu bash on my default tab overwrites whatever there might be in it's tab title. I guess bash doesn't know (or even care) about the elevation of Windows Terminal, so that info cannot be used when updating title from within bash (there's of course sudo situation, but that's a different thing).

In Terminal's profiles.json, there's
"showTabsInTitlebar": false
but with this setting Terminal's title bar doesn't signal the elevation.

[SamuelEnglard]

@janilahti do elevated CMD tabs not look like
for you?

[danvenn]

Security is a moot point if no-one wants to use your tool...

[hparadiz]

Ya'll should just make a sudo command for windows that works in both cmd.exe and powershell. That would save me the trouble of having a shortcut for both set to run as admin.

[gerardog]

FYI, I wrote a sudo for windows, called gsudo: https://github.com/gerardog/gsudo

It supports to elevate cmd/powershell/pwsh commands or the whole shell. It's easy to install and use and should resemble the original *nix sudo. There are others sudo implementations in the wild but IMHO, gsudo is the most versatile and easy to use.

You can use it, for example, to create a WT profile that calls gsudo cmd/gsudo pwsh or gsudo WhateverShell to launch elevated tabs. Install gsudo and add a WT profile:

    {
      "hidden": false,
      "name": "PowerShell Core elevated",
      "commandline": "gsudo.exe pwsh"
    }

It's a C# client-server app that acts as a client when non-elevated, and launches itself elevated as a server. Both instances communicates via secured named pipes. Other windows sudos in the wild are mostly like PowerShell 'runas' scripts that pop-up a new window, but being a full app allowed me add far more features.

I've read the thread and the security of a sudo command has been discussed and some valid points are made. I've taken all security measures that I could think of and I am open (and planning) to introduce more of them. At this point it should be as secure/insecure as if you open a remote admin PS session or if you do ssh root@server from a non-elevated console. (eg. vulnerable to keystrokes or screen scrapping, and correct me if I'm wrong but my understanding is that *nix sudo is also vulnerable in this way). There is also the credentials cache, which reduces the amount of UAC popups during a 5 minutes session (inspired in *nix sudo), which clearly is an attack vector, that can be disabled via config. For those worried about security I am planning to add a very easy way to tighten it (by disabling features like the credentials cache) with a simple command or via an enterprise group policy/registry setting.

One interesting point made in this comment is that Microsoft cannot afford "accepting risk for user convenience". If that is the final word from MS, then at least this looks like a decent (fully-functional) workaround, and all feedback/issues or ideas on how to improve security are welcomed.

[hparadiz]

Can't be something I have to install that isn't official supported. Kills any ability to use it in a corporate environment.

[gerardog]

Then @hparadiz you would have to wait until a new version of windows is released with a new security design that allows an official sudo (or mixed elevations tabs) without security risks. Looks like it won't happen soon. Your best shot is to wait until the whole WT can be launched as admin, tracked in #4217, likely to be released sooner.

[SteveGTR]

Found a nice hack from a blog:

http://nuts4.net/post/windows-terminal-run-as-admin

[fluffynuts]

@gerardog do you have a scoop bucket for gsudo? or is it in one of the known one? I'm currently on a linux box, so can't check.

[gerardog]

@fluffynuts It's in scoop's main repo. So just 'scoop install gsudo'. Also other instalation methods are listed in https://github.com/gerardog/gsudo . But lets keep this discussion on the WT topic. 😉

[dadpolice]

Open question: if it is a security risk to mix elevated and unelevated tabs, then is that risk present in ConEmu? Because it can do exactly that. Or is ConEmu implementing that feature in a different way than you would in Terminal? And more broadly I would note that many of the features being requested here (in this thread and others) are already extant in other terminals, ConEmu being just one example, so when Terminal devs suggest these features would either never be implemented or not implemented for a very long time, you're implicitly just confirming that we shouldn't use Terminal.

if we didn’t rely on APIs that only exist in 1903, we would not require 1903.

@DHowett-MSFT Is there any public documentation available regarding what APIs these are and why they are necessary? Because as an outside observer, when I see this decision and the decision to use UWP, I don't see the value add. I just see obstacles towards adding what many enterprise users consider to be basic functionality.

[SamuelEnglard]

@dadpolice See https://github.com/microsoft/terminal/issues/632#issuecomment-518888895 for what ComEmu does.

[LeoDavidson]

I thought "UAC isn't a security barrier" according to Microsoft? It was treated like one in Vista. Then we were told it wasn't one and any issues like this were a joke in Windows 7. Now it is one again today?

Maybe you need to review the design of File Explorer and the UAC whitelist in this case. :)

Or does it just depend on whether or not it's an excuse to take a shortcut in designing something that normal developers aren't allowed to do (File Explorer) or not implement an essential feature (in this case)?

[zadjii-msft]

not implement an essential feature (in this case)?

I want to make it clear - we're not trying to _not_ implement this feature. It's certainly an important feature that we _want_ to implement. It's something that I'm running into daily right now - having a second elevated window is _okay_ but it's not _good_.

It's just going to take a while for us to be able to design an appropriately secure solution, then also do the engineering effort to actually implement it. It's something we whiteboarded for a while this week even.

[kort3x]

@zadjii-msft

[...]
I don't think we plan on supporting mixed elevated and unelevated tabs, because it's a bit of a security hole.
[...]

(as a matter of linking related threads, #146)

Weird that people were under the impression the feature will not be implemented. sarcasm sign

[SamuelEnglard]

@kort3x There's a difference between "No Plan" (aka we're not promising it) and not wanting to and doing what they can do find a way implement it.

As @zadjii-msft put it:

It's just going to take a while for us to be able to design an appropriately secure solution, then also do the engineering effort to actually implement it. It's something we whiteboarded for a while this week even.

As long as they don't have a secure solution they won't plan (aka promise) to support mixed elevation tabs. I'm willing to be though that the second that do have a secure solution they will add it to the plan (though I can't promise anything).

[nikbackm]

I thought "UAC isn't a security barrier" according to Microsoft? It was treated like one in Vista. Then we were told it wasn't one and any issues like this were a joke in Windows 7. Now it is one again today?

As I understand it's a security barrier if configured as "Always notify", otherwise it's not.

[chadmoore]

Well, this is disappointing. I like the terminal (which is saying a lot, as I'm pretty enamored with non-MS tools generally), but the inability to smoothly elevate is a real barrier to me doing more work on this OS.

[zadjii-msft]

LOL okay yea, I can see how that's confusing. I originally wrote that comment days after we first announced, when there wasn't a plan. After a few months of discussing, I've certainly come around to the idea this might be possible, with more effort. I'll go update the comment to reflect that. @SamuelEnglard is right though, it's hard to _commit_ to doing this until we _know_ that it's possible to do correctly.

[DJackman123]

This is encouraging to hear. Is it possible to extend this enthusiasm to other teams, so #3581 can actually be fixed?

[rapus95]

It'd be nice if the tabs were allowed to be different processes (similar to how chrome manages it) in the first place because then I wouldn't have to restart all tabs after grouping them nicely just to get an updated environment in a single cmd tab...
Once the Windows Terminal is just a manager it could run in a non-elevated mode while still holding elevated command prompts. That would be nice. (well, having the wt run elevated while holding non-elevated terminals would be ok for me too)

[SamuelEnglard]

@rapus95 technically the tabs are, in that the "console" is a different process. Windows Terminal is just a manager already

[tmeckel]

EDIT (Feb 14 2020)
Okay, so this comment didn't age super well. Originally, there was _no_ plan to support this, since it wouldn't work with the single HWND we had. We're working on designing a solution that _might_ support this in the future, but we can't commit to anything until we're sure that we can come up with an appropriately secure solution, that ensures that a lower privileged process can't drive a higher privilege terminal.

Aside some other points, that's the main reason why I'm still using ConEmu. And I bet I ever will.
https://conemu.github.io/ @Maximus5

[tmeckel]

This is so stupid.

Let's make a new unified terminal for command prompt, powershell, and bash for windows.
Can I run cmd.exe as admin?
No.

Dumb stuff like this is why my main work machine is still a Macbook.

@hparadiz Have a look at ConEmu :-D No issues running multiple Shells as tabs in ONE Window; even running elevated Powershell and cmd.exe sessions aside non elevated ones.

[drdamour]

@tmeckel are we sure conemu doesn't have the security vulnerabilities that the terminal team is worried about? users often pick less secure software because it does what they want, but at their own peril.

[dadpolice]

@drdamour @tmeckel It does. I asked the same question above, it's answered in another thread: https://github.com/microsoft/terminal/issues/632#issuecomment-518888895

I've been pretty critical of Terminal so far, but to be fair, ConEmu and ConsoleZ and other similar tools already exist. There's little value in Microsoft simply copying them, but there's great value in recreating those features in a way that's secure. That said I do still think it's very silly to build a terminal emulator as a Store-only UWP app, especially now that Microsoft seems to be moving away from UWP (e.g. the new Edge is a Win32 app).

[zadjii]

That said I do still think it's very silly to build a terminal emulator as a Store-only UWP app, especially now that Microsoft seems to be moving away from UWP (e.g. the new Edge is a Win32 app).

To be clear, the Terminal is not Store-only (there are .msix's available here), nor is it a UWP application. It's a Win32 application using UWP XAML as its UI framework.

[rapus95]

@rapus95 technically the tabs are, in that the "console" is a different process. Windows Terminal is just a manager already

Well then, why is it that the environment isn't updated for a new cmd instance? I always need to open a new Windows Terminal which in some sense reduces the overall usability of having multiple tabs...

[SamuelEnglard]

@rapus95 while I'm not positive (I'd have to go digging through the code) I'm pretty sure each sub-process is launched with its parent's environment not a new one.

[rapus95]

that doesn't seem like making sense for a terminal manager 🤔

[zadjii-msft]

@rapus95 It's actually a bug we're tracking over here: #1125

[dadpolice]

To be clear, the Terminal is not Store-only (there are .msix's available here), nor is it a UWP application. It's a Win32 application using UWP XAML as its UI framework.

That just sounds like UWP with extra steps. Whatever it is that makes it so I can't right click on Terminal and run it as a different user, as I can with any normal Win32 application, that was a strange choice.

[gerardog]

It's not a UWP app nor a Store-only app.
It just happens that one of the distribution methods is the Store, which requires a UWP package.
Only those who installed it using the store are not able to Right click -> Run As Admin.
Uninstall and use the msix or via scoop

[mrwensveen]

Uninstall and use the msix or via scoop

Or chocolatey.

[dadpolice]

@gerardog I didn't say run as admin, I said run as different user.

[gerardog]

Doesn't Shift+Right Click work for you?

(Please note I've installed using scoop)

[dadpolice]

No. I've installed using the msix package and that option is not there.

[drdamour]

I installed as chocolatey and do not have run as admin either

[47780]

To be clear, the Terminal is not Store-only (there are .msix's available here), nor is it a UWP application. It's a Win32 application using UWP XAML as its UI framework.

That just sounds like UWP with extra steps. Whatever it is that makes it so I can't right click on Terminal and run it as a different user, as I can with any normal Win32 application, that was a strange choice.

Same here, I have tried both msix and store app. I still don't have the "Run as different user" option.

[NickStrupat]

What about making all elevated tabs background color red so it's obvious that it's elevated?

[sba923]

I'd rather has this configurable: background color, tab title...

[dmiller423]

https://github.com/gerardog/gsudo works nicely as a temporary solution

[KindDragon]

Maybe implement something like wt elevated that opens a new elevated window with the current shell with the same environment.
EDIT: or #3158 but as new window and elevated

[gabsoftware]

I don't get why would you do not copy the way Linux does it.

To my understanding or the Linux world (correct me if I'm wrong), the terminal apps (gnome-terminal, mate-terminal...) do not need to be elevated even if you type su or sudo and execute command as the root user. The terminal app's only mission is to run a shell in a different process (bash, ksh...) that is or is not elevated, and to redirect the shell input and output so that we can interact with the shell.

If you type "su" or begin a command with "sudo" in a linux terminal, it does not open a different window.

[mrwensveen]

@gabsoftware I am unsure about the security of this even on Linux. It's possible to send keystrokes to X windows in Linux as well, and my guess is that it's possible to send keystrokes to terminal clients running in an X window even if the running terminal is elevated with sudo or su. It may even be possible to send keystrokes to elevated X windows, but I really don't know for sure.

[DonnerVarg]

To be clear, the Terminal is not Store-only (there are .msix's available here), nor is it a UWP application. It's a Win32 application using UWP XAML as its UI framework.

That just sounds like UWP with extra steps. Whatever it is that makes it so I can't right click on Terminal and run it as a different user, as I can with any normal Win32 application, that was a strange choice.

Same here, I have tried both msix and store app. I still don't have the "Run as different user" option.

I can't "Run as a different user" by shift-right-clicking the tile in the start menu, but I can if I shift-right-click WindowsTerminal.exe

[mrwensveen]

@gabsoftware I am unsure about the security of this even on Linux. It's possible to send keystrokes to X windows in Linux as well, and my guess is that it's possible to send keystrokes to terminal clients running in an X window even if the running terminal is elevated with sudo or su. It may even be possible to send keystrokes to elevated X windows, but I really don't know for sure.

I've done some experiments, and now I am rather sure of the insecurity of this on Linux. I'm not a security expert, so I'm not sure about the implications of this (anyone?). Turns out it's really easy to send keystrokes to X windows that have just run sudo and are open to new sudo commands without asking for a password. Blog post here, sorry for the shameful plug...

My conclusion would be that unless there's a way to disallow sending keystrokes to mixed-elevation windows, this should only be implemented as an option for users willing to accept the risk (big fat warning signs, etc.).

As a side note, how does Windows' on-screen keyboard send keystrokes to elevated windows?

[gerardog]

I've released gsudo v0.7 and is relevant to this thread:

EDIT: For context: gsudo is a sudo for windows, and allows to elevate a simple command or a shell in the current console. When invoked from a Cmd/Pwsh within WT, it elevates the tab. Also, you can edit your profile, name it 'Elevated Powershell' and your change your command to gsudo Powershell and voilá, you got an elevated tab profile. See here.

But since gsudo, or any sudo for windows, jumps over the UAC isolation, it has been labeled 'insecure'. What follows is a more complicated workaround that allows you to do mixed elevations of tabs while keeping security. /END EDIT

gsudo can now launch applications with any integrity level. For example we can launch Windows Terminal with MediumPlus integrity level, this means a 'semi-elevated' mode: no-admin rights but isolated, unreacheable from other regular (Medium Integrity) processes. (a UAC popup will appear)

So, first step should be to always launch WT with: gsudo -i MediumPlus WT
(You may change your WT shortcut). This protects WT from malicious processes, screen-scrapping, sendkeys, dll-injection, etc.
(EDIT: if it doesn't work use: gsudo -n -i MediumPlus cmd /c cmd /c start wt)

Then you can use gsudo safely within WT to elevate commands, or even create an elevated profile with: "commandline": "gsudo cmd.exe" in profiles.json

My conclusion would be that unless there's a way to disallow sending keystrokes to mixed-elevation windows... this should only be implemented as an option for users willing to accept the risk (big fat warning signs, etc.).

Done, and done. (I've added security warnings to gsudo).

Also, since I've learned that if the user is invoking gsudo from a regular/Medium integrity process, then gsudo's credentials cache (the feature to show less UAC popups) can't ever be fully protected... So, now the credentials cache must be explictily enabled via gsudo cache on/off or gsudo config cachemode auto.

[gerardog]

Turns out "Changing your WT shortcut" is not trivial at all: Given the MSIX/AppStore model, you ran into #4217 and #4459.

The following powershell script workaround those issues to create a Windows Terminal shortcut on the desktop and associates it with Ctrl+Alt+T hotkey:

$shortcutPath = [Environment]::GetFolderPath("Desktop") + "\Windows Terminal Isolated.lnk"

# Use this if installed via Scoop. 
$wtPath = "$home\scoop\apps\windows-terminal\current\WindowsTerminal.exe"

# Use this if installed via Chocolatey or Ms Store
$wtPath = (Get-Command 'wt.exe').Path

$cmdPath = (Get-Command 'cmd.exe').Path
$gsudoPath = (Get-Command 'gsudo.exe').Path

$WshShell = New-Object -comObject WScript.Shell
$link = $WshShell.CreateShortcut($shortcutPath)
$link.TargetPath = $gsudoPath
$link.Arguments = "-n -i MediumPlus cmd /c cmd /c start $wtPath"

#Optional, set global Keyboard Hotkey
$link.Hotkey="Alt+Ctrl+T"

# Optional, download icon.
$icoPath = [IO.Path]::GetDirectoryName($wtPath) + "\wt.ico"
Invoke-RestMethod -Method Get -Uri "https://raw.githubusercontent.com/microsoft/terminal/master/res/terminal.ico" -OutFile $icoPath
$link.IconLocation="$icoPath,0"

$link.Save()

Once you've started WT as MediumPlus (i.e. Ctrl+Alt+T), you can use gsudo as mentioned [above] (https://github.com/microsoft/terminal/issues/632#issuecomment-613751789) to elevate commands in what AFAIK should be safe.

[gitolicious]

My workaround to this is using Luke Samson's _Sudo for Windows_. Profile config is:
"commandline": "pwsh.exe -Command sudo.ps1 pwsh.exe",
When starting a new tab with that profile, UAC pops up and then you end up in an elevated Powershell Core. Also works with any other terminal.
"commandline": "powershell.exe -Command sudo.ps1 powershell.exe",
"commandline": "powershell.exe -Command sudo.ps1 cmd.exe",
If you don't use scoop, I am sure the concept can be extracted and used independently. Check out the source code here: https://github.com/lukesampson/psutils/blob/master/sudo.ps1

[KMoraz]

I'm using the schtasks workaround to run Windows Terminal as Administrator and bypass UAC:

1. Start Task Scheduler.
2. Create a new task. Give it a name and check the "Run with highest privileges" checkbox.
   

3. On the Actions tab, select to start a program: wt

4. On the Settings tab, make sure "Allow task to be run on demand" is checked and uncheck "Stop the task if running for longer than" checkbox.

5. Create a shortcut by right clicking the Desktop and select New -> Shortcut and type schtasks.exe /run /TN "{task name}"
   
6. Optionally change the shortcut icon and drag it to the taskbar.

[holynakamoto]

Looks like I will have to stick to cmder until this is fixed.

[drdamour]

now that there's an inkling of a plan supposedly, can we get the docs
updated to no longer say there's no current plan?

https://github.com/microsoft/terminal/blob/master/doc/user-docs/index.md#starting-a-new-powershell-tab-with-admin-privilege

[zadjii-msft]

@drdamour Once there _is_ a plan, I'd love to remove that section. Right now though, there's only a plan to research a way to make a plan. Once there is a real plan, and a way we can safely do it, I'll remove that section.

[Fell]

The method described by @KMoraz works great as a workaround for now. Thank you for posting this.

[Bigous]

Hi people,

I was using ConsoleZ until I discovered this one yesterday.
ConsoleZ has some features and one is to start a new tab as administrator using UAC (it pops the dialog of UAC).
I find it very useful because you don't need to take of the hands of keyboard to open a new elevated tab.

What if it were a configuration inside profile configuration? That's how it's done in ConsoleZ.

[ghost]

Hi All,

I found another Shortcut workaround that's simple and works great for those who have to enter local admin credentials when running anything As Administrator.

This link explains, but needs a full path for the wt.exe reference:
http://nuts4.net/post/windows-terminal-run-as-admin

My full shortcut string is: C:\Windows\System32\cmd.exe /c start /b C:\Users\myUserName\AppData\Local\Microsoft\WindowsApps\wt.exe

UPDATE 21 May 2020:
The above used to work prior to version 1.0.1401.0.

See this new issue too: https://github.com/microsoft/terminal/issues/6013

Now Crtl-Shift click does NOT work either when you have to elevate with a local admin account.

See the below error screenshot I get after being prompted twice for elevate permissions:

[LordFPL]

For information, imho gsudo is perfect for this, thx https://github.com/microsoft/terminal/issues/632#issuecomment-613751789

My config have only this profile to gain privilege :

            {
                "name": "Admin Powershell",
                "commandline": "cmd.exe /c gsudo powershell.exe",
        "titleText": "Admin Powershell",
                "icon": "ms-appx:///ProfileIcons/{574e775e-4f2a-5b96-ac1e-a2962a402336}.png"
            },

[SuperRembo]

For me the easiest way to open Windows Terminal as administrator, is to pin it as the first item on the task bar. Then Win+Ctrl+Shift+1 opens it as admin

[sba923]

For me the easiest way to open Windows Terminal as administrator, is to pin it as the first item on the task bar. Then Win+Ctrl+Shift+1 opens it as admin

Indeed very convenient, but this only works for accounts that are members of the Administrators group.

If you are acting as the admin for someone else, you won't be able to run Windows Terminal as your (admin) user from their account.

[kenmartin-unix]

I think it would be nice to have one tab setup to run cmd as administrator not everything.

[sba923]

I think it would be nice to have one tab setup to run cmd as administrator not everything.

As explained elsewhere here, this is not possible with the current design.

[u84six]

is there a flag that can be used to run as admin? Then we could just create a shortcut for it.

[sba923]

If you pin Windows Terminal to the taskbar, you can launch it _elevated_ using Ctrl+Shift+click.

This will do the same as right-click on icon, right-click on "Windows Terminal", followed by "Run as administrator."

Note: Windows Terminal being a Store app, you can't run it as _another user_.

[shem-sargent]

I would love to see the ability to have "mixed-integrity-level tabs" in Windows Terminal, with the integrity level as an option in each profile. This is mostly as a convenience in my normal sysadmin/devops work to minimize workflow interruptions and context switching.

I have found a simple alternative that works for me for now. This doesn't address all the scenarios presented here by other users. It doesn't depend on third party apps, shortcut files, key combinations, or Scheduled Tasks. It doesn't require identifying the location of the Windows Terminal executable. It just makes a separate entry in the Windows Terminal profile list that launches a second Windows Terminal instance elevated. This triggers a UAC prompt once. I only use this if and when I need elevation.

The result is two Windows Terminals. Anything in one is standard and anything in the other is elevated. For me, this an acceptable level of interruption and context switching. The elevated Windows Terminal also prepends each tab title with "Administrator:" which gives good visual confirmation of the difference.

Edit: I have Powershell 7 installed,

            "name" : "Launch Windows Terminal Elevated",
            "commandline" : "pwsh.exe -command Start-Process -Verb RunAs wt.exe"

[shem-sargent]

@IarwainBen-adar, I seem to recall recently reading in the new docs that you can't use the commandline item and and the source item together. Does it work as expected without the source item?

[kenmartin-unix]

I tried his code and can not even get the new item to appear in the pull
down menu.

[IarwainBen-adar]

@shem-sargent sorry about that, I deleted my comment here because the extraneous source declaration was indeed the problem. Although, now that I have the menu entry working, unfortunately I still can't launch an elevated instance of Windows Terminal — I'm running into issue #3145 with a failure of The file cannot be accessed by the system.

[shem-sargent]

@IarwainBen-adar Sorry, I cannot reproduce #3145. Otherwise, I would try troubleshooting on my end.

[jeferwang]

pin to task bar and shift+right click

[Reeceeboii]

Cheers @LordFPL and of course @gerardog , I had never heard of gsudo (https://github.com/gerardog/gsudo for others that are interested) before, but this makes elevated sessions a breeze now. Thanks! Either add it to the profile object in the settings file, or just use the sudo alias as you would do on a Linux system. Perfect!

[smokeintheshell]

@zadjii-msft my apologies, but I don't exactly understand what the issue here is. Windows supports token manipulation and impersonation, it's how runas works isn't it? using gsudo from @gerardog i can have a low(er) integrity wt hosting a high(er) integrity shell at the same time as any other level integrity shell, be it powershell, pwsh, cmd, or any wsl shell. From my limited testing, none of the low(er) integrity shells can debug into that higher integrity shell. What is the roadblock here to having this as a builtin terminal, or even more preferable at the OS level, feature?

[DHowett]

@smokeintheshell https://github.com/microsoft/terminal/issues/632#issuecomment-519375707

A low(er)-integrity window _receiving input and funneling it directly into a high(er)-integrity process_ opens that high(er)-integrity process up to control by other low(er)-integrity things on the system.

It means a potentially malicious process only needs a lateral move at the same privilege level to gain EoP.

[kbirger]

@smokeintheshell #632 (comment)

A low(er)-integrity window _receiving input and funneling it directly into a high(er)-integrity process_ opens that high(er)-integrity process up to control by other low(er)-integrity things on the system.

It means a potentially malicious process only needs a lateral move at the same privilege level to gain EoP.

yes, I read that explanation at the beginning of the thread, but I don't understand why it's okay for Linux, and probably Mac, but not OK for Windows? Windows currently protects input to elevated processes from non-elevated processes. In either this issues or a related one, someone suggested that we need a separate process per tab. I would think this is already the case since each tab has its own command to execute (eg: pwsh.exe). Is it because they are all children of the same root process under one HWND?

Does Ubuntu's terminal suffer from the same issue with tabs if I either:

• have a tab with su open
• have a tab where I have elevated with sudo already and don't need to enter my PW again per configuration policy?

Or is Ubuntu's architecture somehow hardened against cross-process input injection attacks?

[mrwensveen]

Does Ubuntu's terminal suffer from the same issue with tabs if I either:

* have a tab with `su` open

* have a tab where I have elevated with `sudo` already and don't need to enter my PW again per configuration policy?

Or is Ubuntu's architecture somehow hardened against cross-process input injection attacks?

If you look at my comment here, I've actually reproduced / exploited the issue on Linux. Both su and sudo are probably equally "vulnerable", in that you can send keystrokes to lower-integrity windows running those commands. The sudo password timeout (not having to enter your password at the next sudo command within 15 minutes), makes this even easier. You can harden Ubuntu by disabling the X extension that is necessary for the attack. Not sure if this is possible in a Wayland environment (the attack and/or the hardening).

I completely understand the decision to not implement mixed-elevation tabs, unless there is some way to disable virtual keyboards and other software input methods.

[yume-chan]

I would think this is already the case since each tab has its own command to execute (eg: pwsh.exe). Is it because they are all children of the same root process under one HWND?

@kbirger Yes there are separate processes for each tab, but all your mouse and keyboard inputs are still sent to Windows Terminal's window (which is low-integrity), then routed to each shell processes via standard input streams. That's how all Windows Terminal's keyboard shortcuts work.

---

I wonder if it's possible to detect if the input is forged, for example using the GetCurrentInputMessageSource API. I can't find much information about this API other than the official example, but from the description it should be able to identify the input source (hardware/from processes with uiAccess, mostly accessibility software/from processes without uiAccess, maybe malicious)

[GoldenCrystal]

why it's okay for Linux, and probably Mac, but not OK for Windows?

I'm pretty sure that one of thre reasons is that Microsoft is selling security as a feature to other large corporations, or governements.

There are also a few other resons that come to my mind as to why that might not have been a problem until now:

• For a long time, and formany reasons (such as "hackers" not liking Windows, and "everyone" using Windows ^^), Windows used to be the primary (≈only) target of all kinds of malware. It needed better security (protecting elevated windows), while other didn't care that much.
• As explained earlier in this issue, it should not have been possible for malware to easily access your elevated console host on Windows, so it's likely that not many have invested in that issue (I'm no security expert, so I don't know if some have)
• Malware usually have had other ways of elevating themselves than trying to find an elevated command prompt in your OS of choice
• Only developers and sysadmins use terminals (this only reduces the target demographic of the attack; governments and large corporations are still a concern)

Now, by introducing the feature naively (as we'd all have done, i'm sure 😄) you'd be introducing a new (huge) flaw in some Windows installations. With the development being done in the open, you can be sure that everyone in need would be aware of the flaw and start coding against it.
The quick countermeasure being to ban Windows Terminal (and likely all other terminal emulators out there now that the flaw is public), you could then kiss goodbye to your dreams of using Windows Terminal in any kind of corporate environment 😟

I'm still very much hoping that a secure version of this feature wil see the light of the day, though 🤞

[kbirger]

I see. Thanks for the explanations!

[yume-chan]

As a side note, how does Windows' on-screen keyboard send keystrokes to elevated windows?

@mrwensveen AFAIK there are three ways to send inputs to elevated windows:

1. Elevate yourself. However you still can't send inputs to system processes (e.g. Task Manager, UAC dialog, login screen).
2. Register a Windows Service. Now your program runs as SYSTEM so you can do anything you want. I have seen some Remote Access programs do this.
3. Declare the uiAccess flag, digitally sign your binary, install to a location that's not writeable for current user. It's a "backdoor" for accessibility softwares, allowing them to read/write any other programs (including system processes), and displaying on top of any other windows (including Secure Desktop where UAC popups show and login screen), all without running elevated. See https://docs.microsoft.com/en-us/windows/win32/winauto/uiauto-securityoverview.

On-Screen Keyboard (osk.exe), Narrator.exe (, and maybe other screen readers) all uses method 3.

(A screenshot showing the embedded program manifest of osk.exe with uiAccess=true)

---

Looks like the uiAccess flag can also protect the program from being accessed by other low-integrity programs (despite from still running unelevated), maybe we can use this "feature" to protect WT?

[mrwensveen]

@yume-chan Cool, that's very interesting, thanks! Are uiAccess programs allowed to send keystrokes to other uiAccess programs? We still want OSK to be able to interact with windows terminal, and if this means other programs should at least be signed before it's allowed to send input to windows terminal, is that a high enough barrier?

[yume-chan]

Are uiAccess programs allowed to send keystrokes to other uiAccess programs?

@mrwensveen Yes, programs with uiAccess privilege can access each other.

I prefer the GetCurrentInputMessageSource API way (https://github.com/microsoft/terminal/issues/632#issuecomment-651114562) cause this is not uiAccess's intended usage. Also with the API we may still allow low-integrity programs to send keystrokes to unelevated tabs, while not to elevated ones.

[Bigous]

Little workaround I've made here:

I've installed PowerToys which has some cool features. One of them is to show the windows shortcuts and I've discovered that when you press Win + number, it opens the app in the windows bar correspondent to the number it appears in the bar.

So, I've putted the terminal in the bar as the first icon
.

When I press Win + 1, the terminal opens.

When I press Win + Ctrl + Shift + 1, it opens elevated.

I'll put my terminal configuration and powershell profile here too if you wanna get the features of show the git branch and conda environment in the prompt and the user in red if it's an elevated terminal...

[Firehawke]

That's existed since at least Windows 7; it's not a PowerToys thing.

[Bigous]

@Firehawke Yes, I just discovered because of PowerToys ... it's not needed thow.

[bb010g]

Here's a profile for launching elevated that works on Windows Store & has a proper icon:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

EDIT: Credit to @glooms, @shem-sargent, @LordFPL, and @Firehawke for different components of this snippet. As this command calls pwsh.exe, it looks like some people have ran into #4228 (a 0x80070002 error when launching) with this due to corrupted PATH environment variables or strange binaries in their path named powershell.exe or pwsh.exe. @zurkz fixed this by referencing powershell.exe, but I don't think that's reliable now. #6684 addresses this problem for Windows Terminal, and you'l find a fixed version below, following that solution, which shouldn't have this issue at all.

[shem-sargent]

Here's a profile for launching elevated that works on Windows Store & has a proper icon:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

@bb010g That works well! Thank you.

[Kazamario]

Here's a profile for launching elevated that works on Windows Store & has a proper icon:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

@bb010g ❤💯

[Kazamario]

Here's a profile for launching elevated that works on Windows Store & has a proper icon:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "pwsh.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

@anyone Forgive my ignorance, does this get dropped in the Windows Store config? If so, can someone post the path? If not, where is this bad boy supposed to live?

TYIA!

[shem-sargent]

@Kazamario
It goes in the Windows Terminal settings.json file, in the profiles section.

[munael]

It causes an error: 0x80070002 when launching. pwsh 7.1.

[zurkz]

I changed it to:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "powershell.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

and UAC prompted to elevate permissions.

[faulander]

I changed it to:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "powershell.exe -command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

and UAC prompted to elevate permissions.

that worked for me quite well. Thank you!

[farag2]

Here is how to start Windows Terminal elevated if it was pinned to Start.
https://github.com/farag2/Utilities/blob/master/Windows%20Terminal/Pin%20to%20Start.ps1

[bb010g]

@narfanar It looks like you've ran into #4228, where Windows Terminal emits error 0x80070002 upon startup when the PATH environment variable is messed up or other binaries are floating around in the path named powershell.exe or pwsh.exe. I don't think @zurkz's snippet really fixes this, as it just shifts potential problems from pwsh.exe over to powershell.exe. #6684 fixed this for WT, so here's a snippet adjusted to that solution:

{
    "name": "Windows Terminal (elevated)",
    "commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs \"shell:appsFolder\\Microsoft.WindowsTerminal_8wekyb3d8bbwe!App\"",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png"
}

[Benny1007]

console-z does this well

[MikeChristensen]

Note that Cmder has this feature, which is incredible useful. Would love to see it implemented in Windows Terminal. Even if it has to launch a separate window for the Admin tabs or something..

[ofsaleem]

my default profile is set to bash rather than powershell, and i'd like to keep it that way. the snippet above works great, but id love to be able to make it launch a new elevated terminal with the powershell profile loaded. ive spent like 3 hours trying to figure this out (not a big fan of / have much experience with powershell) and i can't figure it out -- pleaaaase help. it seems like there's some combination of single quotes, double quotes, escaping, spaces, newlines, that might make it work but i cannot get start-process and argumentlist to do what i want. ive boiled it down to :

Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p "Windows PowerShell"'
this works in a .ps1 file if i run it myself, i get a new elevated windows terminal with the powershell profile loaded. but it does not work in the commandline parameter of settings.json, no matter how i try to mangle it, explicitly calling argumentlist instead of using cmd /c, various forms of escaping and quote usage, etc.

"commandline": "%SystemRoot%\\System32\\WindowsPowerShell\\v1.0\\powershell.exe -Command Start-Process -Verb RunAs cmd.exe '/c start wt.exe -p \"Windows PowerShell\"'",
does not work. the best i can do is get it to launch a weird hybrid of what i want. ill get an "Administrator: Ubuntu" window loaded, that looks like my bash profile but is actually running powershell. wrong font and everything. if i use that window to open a new powershell tab it will be elevated as desired. when its like this i can stick whatever garbage i want into the "Windows PowerShell" part of the profile loading and I get the exact same behavior, so I know it's not really attempting to load the profile i'm passing it.

[iyruk]

So I'm having an issue trying to still run this as elevated, i've done every option listed above and i either get the "Can't find the file" error or this.

Start-Process : This command cannot be run due to the error: The system cannot find the file specified.
At line:1 char:1
+ Start-Process -Verb RunAs shell:appsFolder\\Microsoft.WindowsTerminal ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [Start-Process], InvalidOperationException
    + FullyQualifiedErrorId : InvalidOperationException,Microsoft.PowerShell.Commands.StartProcessCommand

Anyone else having the issue still or haven't been able to get these to run just fine?

[NoSubstitute]

my default profile is set to bash rather than powershell, and i'd like to keep it that way.

Me too. I run WSL most of the time, but every now and then I need to run PS elevated, and I'd like to do it in a tab of the new WT.

[ayfine]

I was also unable to get any of the examples to work - even with correcting my file paths. I found and installed gsudo which can elevate the current tab, or be used as a profile to open an elevated tab in the same window. I am unsure if the solutions above started in a new window (some attempts I made before using gsudo would only start in a new window). It will open an UAC popup.

This is the profile I am using:

{
    // Elevated Powershell using gsudo
    // https://github.com/gerardog/gsudo
    "name": "Elevated PowerShell",
    "commandline": "powershell.exe gsudo powershell.exe -nologo",
    "hidden": false,
    "icon": "ms-appx:///Images/Square44x44Logo.targetsize-32.png",
    "suppressApplicationTitle": true
}

I am using supressApplicationTitle so that the tab title not display Administrator: as its redundant with Elevated.

[bb010g]

@ayfine If https://github.com/microsoft/terminal/issues/632#issuecomment-663686412 is indeed not working for you, could you send a transcription of the exact errors / unexpected behavior you're getting with that config? (Make sure to add in extra configuration, like suppressApplicationTitle, in as small as steps as possible, so that if any of your configuration is breaking WT it'll be easier to tell where & when it's happening.)

If any other configurations here got slightly further than the linked one for you, details on how those are breaking would also be appreciated.

[ayfine]

@bb010g I am not encountering any error messages - my apologies for not being more precise in my reply. When using https://github.com/microsoft/terminal/issues/632#issuecomment-663686412 I ran in to the issue of Windows Terminal loading my WSL Ubuntu shell (my default). I had taken this originally to mean that it was not working correctly but I see now that in that new window, if I start a new (default profile) Powershell tab it is in fact elevated. Regardless, both by opening a new window and having to start a new tab within that, it's not any easier than running an elevated process from my start menu. What I described in my original reply provides with the exact behavior I was imagining.

[NoSubstitute]

@ayfine - and I copied your gsudo example. That's a good-enough solution until something built-in is coded. Thanks.

[MikeChristensen]

@ayfine I tried the gsudo thing, but it's a pretty awful experience. Any sort of TAB completion seems to break, and Unicode (non-ASCII) characters don't seem to display. I'm guessing it's some sort of process that redirects input and output, and does a terrible job at it. I think the solution with a separate window works better.

[DHowett]

If you are having issues with gsudo please report them to @gerardog and not in this thread. Every message on this thread (this one included; sorry!) e-mails hundreds of subscribers.

I am going to lock this thread to further non-maintainer comments, as we are reaching the point where further comments aren’t moving the discussion forward a meaningful amount.

Please file new issues if you have concerns that are not covered here.