Terminal: Run As Administrator

[mohammedha]

Seems there is an issue running the terminal "As Administrator"

Error: Windows cannot find "C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_0.2.1831.0_x64__8wekyb3d8bbwe\WindowsTerminal.exe" Make sure you've typed the name correctly, then try again

[zadjii-msft]

@DHowett-MSFT I could've swore we had a duplicate issue sitting around somewhere for this, but I can't find it now. Do you remember what causes this?

[mohammedha]

Ahh man, sorry if it is a duplicate.

there is no reason, start the app fine but r-click and start as admin fails, windows UAC prompt for admin password twice then you get the error.

[ghost]

I'm also currently experiencing this issue. I searched for terminal in the taskbar

Then I was prompted to enter my admin credentials twice! One admin prompt after another. Then when I finished entering my credentials the second time this error message popped up:

I just installed the terminal today.

Terminal Version:
Version: 0.2.1831.0

OS Version:
Windows 10 Pro
10.0.18362 Build 18362

[ghost]

Also as a suggestion instead of running the WHOLE terminal as admin from the taskbar, perhaps have alternatives?

For example:

When opening a new tab prompt the user or have some UI asking if they want to open the new instance as an administrator?

Or just right click on the terminal to open up a admin tab from the exact same directory. (That would be very useful for powershell-core since it doesn't have nice functionality like sudo)

[fcharlie]

Windows Terminal support running in admin mode may not be a good behavior, which means that all shells in other tabs opened from Ctrl+T may be administrator privilege. As far as I know, Windows Terminal does not implement any code from the Administrator to the restricted user. In fact, what Windows lacks is the kind of privilege implementation that does not require UI interaction, like sudo.

But implementing sudo can also be cumbersome. The flow of runas verb is roughly as follows (if anything is wrong, please remind me):

1. AppInfo goes and talks to the Local Security Authority to get the elevated token of the logged in user of Session 1.
2. AppInfo loads up a STARTUPINFOEX structure (new to Vista), and calls the brand new Vista API InitializeProcThreadAttributeList() with room for one attribute.
3. OpenProcess() is called to get a handle to the process that initiated the RPC call.
4. UpdateProcThreadAttribute() is called with PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, and uses the handle retrieved in step 3.
5. CreateProcessAsUser() is called with EXTENDED_STARTUPINFO_PRESENT and the results of steps 1 and 4.
6. DeleteProcThreadAttributeList() is called.
7. Results are gathered, and handles are cleaned up.

We can draw a simple conclusion. In fact, runas is actually a normal process that initiates an RPC request to a high-privileged process. The high-privilege process (AppInfo service) creates an Administrator process and sets its parent process as a normal process.

AppInfo does not currently support setting up a working directory, input and output (although calling CreateProcessAsUser) when launching the administrator process. This is a problem that needs to be solved to enable sudo support to run in Windows Terminal. (ShellExecuteEx SEE_MASK_NO_CONSOLE not work)

SHELLEXECUTEINFOW:

typedef struct _SHELLEXECUTEINFOW {
  DWORD     cbSize;
  ULONG     fMask;
  HWND      hwnd;
  LPCWSTR   lpVerb;
  LPCWSTR   lpFile;
  LPCWSTR   lpParameters;
  LPCWSTR   lpDirectory;
  int       nShow;
  HINSTANCE hInstApp;
  void      *lpIDList;
  LPCWSTR   lpClass;
  HKEY      hkeyClass;
  DWORD     dwHotKey;
  union {
    HANDLE hIcon;
    HANDLE hMonitor;
  } DUMMYUNIONNAME;
  HANDLE    hProcess;
} SHELLEXECUTEINFOW, *LPSHELLEXECUTEINFOW;

See: https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute

|Value | Meaning|
|---|---|
|PROC_THREAD_ATTRIBUTE_PARENT_PROCESS|The lpValue parameter is a pointer to a handle to a process to use instead of the calling process as the parent for the process being created. The process to use must have the PROCESS_CREATE_PROCESS access right.

Attributes inherited from the specified process include handles, the device map, processor affinity, priority, quotas, the process token, and job object. (Note that some attributes such as the debug port will come from the creating process, not the process specified by this handle.)|

[DHowett-MSFT]

This is definitely a windows platform issue. I'm assigning it to myself to follow up with the team that owns it and close this out. Thanks.

[FranklinYu]

I like @YMba9g8j9CJp0wLoQf5y’s proposal of authorizing a tab with escalated privilege. I’m from ConEmu where we can create a tab with or without admin privilege. When creating an admin tab I will be prompted with UAC (for good).

[cking22001]

Is this not just normal behavior of Windows store applications? This looks like the Preview app recently released.
But I do need a way to run elevated shells. It does not seem possible to do that today (open tabs as admin).

[DHowett-MSFT]

Hey, we're not sure there's anything we can do about this. Would you mind filing feedback in the "Developer Platform > App Deployment" category? That'll help get it routed to the right team, and collects some very useful diagnostic information.

[DHowett-MSFT]

Linking: this is also #1538

[musm]

Even though I agree with the decision. It does make it quite painful to use chocolatey without having the explicitly run in admin mode. (

[Bananaman]

@musm I just have this in my PowerShell 6 config:

function GoAdmin { start-process pwsh –verb runAs }

(replace pwsh with powershell if you are using the old powershell)

So whenever I need to install/update packages via chocolatey I type GoAdmin (in Windows Terminal's hosted PowerShell), which takes me to a separate Admin powershell window. There I can run all chocolatey admin commands. Then I simply close the admin window, and type refreshenv in my Windows Terminal session to update all PATH variables. It's pretty easy.

I would definitely like a way to launch wt (Windows Terminal) instead of directly going to a "bare" pwsh, but that doesn't seem possible. But it's a minor gripe. Meh. :-)

[hudo]

Im still getting an error when I want to start WT (0.9.433.0) as admin:

Happens on several machines, with latest WT and Windows (v10.0.18363.657).
Don't quite understand why is this issue closed and what's the workaround.

[mohammedha]

Actually it never worked, the last comment I got was, it is a Windows issue and they will raise it with the team.

[FranklinYu]

they will raise it with the team.

I don’t think so. It’s more like “you should raise it with the team”.

[hudo]

Im sure they're not thinking of releasing Win Terminal v1 with one of the most important functionality broken.
Too bad since it makes current pre-release versions of WT unusable.

[CraigHead]

This will pop a new powershell window with administrator. Not exactly what we want but it's a work around. Create a new profile with the following command line.

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

[A9G-Data-Droid]

Why is this closed? There still need to be an elevate tab feature.

[DHowett-MSFT]

This is being tracked in a bunch of other issues on this repository, that's why.

[FranklinYu]

@DHowett-MSFT Thanks. Which issue should we follow? I don’t think it’s mentioned above.

[mian-muhammad]

@musm I just have this in my PowerShell 6 config:

function GoAdmin { start-process pwsh –verb runAs }

(replace pwsh with powershell if you are using the old powershell)

So whenever I need to install/update packages via chocolatey I type GoAdmin (in Windows Terminal's hosted PowerShell), which takes me to a separate Admin powershell window. There I can run all chocolatey admin commands. Then I simply close the admin window, and type refreshenv in my Windows Terminal session to update all PATH variables. It's pretty easy.

I would definitely like a way to launch wt (Windows Terminal) instead of directly going to a "bare" pwsh, but that doesn't seem possible. But it's a minor gripe. Meh. :-)

In windows where is this config file located?

[FranklinYu]

@mian-muhammad I think he meant PowerShell profile. https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_profiles

[Steffen-Jens]

I found a workaround. You can use chocolatey to install a package called sudo (choco install -y sudo). Then you can use sudo as expected.

[FranklinYu]

It seems like I can currently open the terminal as administrator; at least it works on my machine. It would be even better if we can create a tab as administrator like ConEmu (which is discussed in #632), but there is currently no point to re-open this issue.

Other related pending feature requests:

• #146 sudo which @Pens99 might be interested in
• #576 task bar jumplist; I regard this as substitution of #632 due to security implication (which I fully understand coming from security industry), especially when combined with #3246.

Hope this help everyone following this thread.

[danstur]

@DHowett-MSFT Which issue should we follow and star to get this resolved? The only other referenced issue I can see is #1538 which is also closed.

I'm sure Microsoft's stance can't be that everybody should have administrative rights on their standard user instead of using a separate admin account if they want to use modern Windows apps. This is after all contrary to standard security practices.

[DHowett-MSFT]

@danstur Best I can offer for that concern is #4217. We're pursuing a fix with the team who owns app deployment. The issue is that apps are _installed_ globally, but only registered per-user. This was some infrastructure that was built for Windows 8 that has only very slowly evolved to support even running standard win32 applications like Terminal. #1386 tracks us getting out of the package and distributing as something more traditional for enterprise customers and folks who are having trouble with the package deployment engine.

[danstur]

@DHowett-MSFT Thanks for the issues, glad to hear that it's being tracked.

To clarify: If I install the application via the options mentioned in #1386 will I then be able to run it as a different user or would that still not work? I wouldn't mind having to register the app (does that mean running Add-AppxPackage?) with the other users.

[DHowett-MSFT]

@DHowett-MSFT Dustin Howett FTE Thanks for the issues, glad to hear that it's being tracked.

To clarify: If I install the application via the options mentioned in #1386 will I then be able to run it as a different user or would that still not work? I wouldn't mind having to register the app (does that mean running Add-AppxPackage?) with the other users.

That should work fine. You'll need to Add-AppxPackage as those users, yes. :smile:

[SirStumfy]

Glad to see its being tacked.

This need to be resolved, as now in any Windows environment set up with separate admin and user accounts (as it should be) the terminal is not usable for admins if installed from the (recommended) MS Store

[Mr-Sawyer]

Glad to see its being tacked.

This need to be resolved, as now in any Windows environment set up with separate admin and user accounts (as it should be) the terminal is not usable for admins if installed from the (recommended) MS Store

A workaround that worked for me was logging in as the admin user in the local machine and "install" again the terminal from the Store. Then, when logged as a standard user, I could run the terminal as an administrator

[SirStumfy]

Yes the problem seems to be Store registers the app for current user only. That is fine for most apps (actually thats how most apps should be installed anyway) but is not good for administrative apps like terminals.

[zadjii-msft]

Hey future me: the store registration issue is being tracked internally with MSFT:20356613 and discussed at length in #4217

[williscarl]

Hello,
I ran into this issue as well on my regular account. The solution is to install the Terminal app again while signed into an administrator account. Then you'll be able to run as admin on your regular account.

[kathodion]

Same here. problem seems not to be solved

[jt-github]

I have yet another less-than-perfect workaround which doesn't allow opening a _tab_ running as administrator, but it does allow opening a PowerShell window as Administrator from an existing (non-admin) tab:

https://github.com/jt-github/elevate

This works the same way as adding the profile as suggested by @CraigHead above:
"commandline": "powershell.exe -Command \"Start-Process powershell.exe -Verb RunAs\"",

Except that my my version is executed by running the elevate command.

[A9G-Data-Droid]

@jt-github That's like sudo.

See here: https://github.com/pldmgg/Sudo

[jt-github]

Exactly, only sudo is way cooler than mine but mine is so dead simple that it's easy to understand and use.

[BanterBoy]

Like many of you, I have also run into this issue, so I created the following functions in order to open an Admin shell from either powershell.exe, pwsh.exe or Microsoft terminal

# Function        Test-IsAdmin
function Test-IsAdmin {
    <#
    .Synopsis
    Tests if the user is an administrator
    .Description
    Returns true if a user is an administrator, false if the user is not an administrator
    .Example
    Test-IsAdmin
    #>
    $identity = [Security.Principal.WindowsIdentity]::GetCurrent()
    $principal = New-Object Security.Principal.WindowsPrincipal $identity
    $principal.IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
}


# Function        New-AdminShell
function New-AdminShell {
    <#
    .Synopsis
    Starts an Elevated PowerShell Console.

    .Description
    Opens a new PowerShell Console Elevated as Administrator. If the user is already running an elevated
    administrator shell, a message is displayed in the console session.

    .Example
    New-AdminShell

    #>

    $Process = Get-Process | Where-Object { $_.Id -eq "$($PID)" }
    if (Test-IsAdmin = $True) {
        Write-Warning -Message "Admin Shell already running!"
    }
    else {
        if ($Process.Name -eq "powershell") {
            Start-Process -FilePath "powershell.exe" -Verb runas -PassThru
        }
        if ($Process.Name -eq "pwsh") {
            Start-Process -FilePath "pwsh.exe" -Verb runas -PassThru
        }
    }
}

# Function        New-AdminTerminal
function New-AdminTerminal {
    <#
    .Synopsis
    Starts an Elevated Microsoft Terminal.

    .Description
    Opens a new Microsoft Terminal Elevated as Administrator. If the user is already running an elevated
    Microsoft Terminal, a message is displayed in the console session.

    .Example
    New-AdminShell

    #>

    if (Test-IsAdmin = $True) {
        Write-Warning -Message "Admin Shell already running!"
    }
    else {
        Start-Process "wt.exe" -ArgumentList "-p pwsh" -Verb runas -PassThru
    }
}

I hope someone finds them useful. I have added them to my PowerShell Profiles, so they are always available.

[smallzeh13]

Hello,
I ran into this issue as well on my regular account. The solution is to install the Terminal app again while signed into an administrator account. Then you'll be able to run as admin on your regular account.

This worked for me as well, its super annoying but on a corp network thats pretty much the only way that has worked for me. If you don't have local admin this app is pretty much a bust for elevated privs on a corp network.

[clowg]

Glad to see its being tacked.
This need to be resolved, as now in any Windows environment set up with separate admin and user accounts (as it should be) the terminal is not usable for admins if installed from the (recommended) MS Store

A workaround that worked for me was logging in as the admin user in the local machine and "install" again the terminal from the Store. Then, when logged as a standard user, I could run the terminal as an administrator

Nah, that didn't work for me :(

[hsrizvi]

So i figured it out.

You have to have it installed in BOTH the administrator account and also in the main account, but also the administrative account must be signed in for it to work. By this, i mean that the computer has to be logged into administrator, then switch the user (not sign out) and log into the other account. This will allow the app to run in administrator mode.

I'm guessing store apps installed on both accounts cannot be run as administrator unless an administrator account is logged into.

[AndrewLane]

So i figured it out.

You have to have it installed in BOTH the administrator account and also in the main account, but also the administrative account must be signed in for it to work. By this, i mean that the computer has to be logged into administrator, then switch the user (not sign out) and log into the other account. This will allow the app to run in administrator mode.

I'm guessing store apps installed on both accounts cannot be run as administrator unless an administrator account is logged into.

This works for me. 👍