Fix/remove runas comparison from documentation

[agowa]

Description of the new feature / enhancement

Some of the things mentioned about runas within the documentation can easily be interpreted incorrectly or are just wrong. I'll quote the sections of the docs and comment below it one by one. (See also this comment in another ticket that talks about runas PowerShell/PowerShell#15562 (comment) )

From https://learn.microsoft.com/en-us/windows/sudo/#how-is-sudo-for-windows-different-from-the-existing-runas-command:

The runas command offers a way to run programs as any user, including administrator if you so choose.

and

runas allows you to run programs as other users, including but not limited to as administrator. This funtionality is on the roadmap for the sudo command, but does not yet exist.

In fact it is NOT possible to use runas to elevate aka. run anything "as Admin". This functionality was never implemented (or was it removed in early Vista?). In fact runas cannot even be used to start an elevated process from another already elevated process.

e.g. runas /showtrustlevels will (regardless of the current console trust level and elevation status) return:

The following trust levels are available on your system:
0x20000 (Basic User)

And runas /help reads:

/trustlevel       <Level> should be one of levels enumerated in /showtrustlevels.

This has been a common issue for us admins and has been requested countless times for MS to "fix" in order to allow using it to elevate from Medium to High. Basically this has been wished for exactly the same use case as sudo now provides.
Ironically we "only" requested for runas to work similar to Start-Process -Verb RunAs but even that was never implemented. Basically cutting cmd scripts off entirely from being able to request elevating anything by itself.

runas only has two features:

1. Allow to run a program as another user but still only limited trust (as it is not able to elevate)
2. Allow to somewhat drop privilges but not in a secure way. As it does not drop integrity level, but only disables the administrators group. The started process will still be of high-trust (S-1-16-12288). And therefore the executed application could probably easily just re-enable the administrators group and defeat the entire point of dropping privileges and thereby rendering this feature useless in practice (example command runas /trustlevel:0x20000 "cmd /K whoami /groups").
3. The examples given in the help output of runas do not even work (and haven't for a long time now, last version was XP, maybe some early Vista builds before it was considered a security issue and removed. I only vaguely recall people mentioning something the lines of "removed for security reasons" at conferences around that time)

And talking about the examples, let's move on to the next claim about runas:

• You can choose to do so in a new window, which resembles the runas administrator flow.

The help has this example:

Examples:
> runas /noprofile /user:mymachine\administrator cmd
> runas /profile /env /user:mydomain\admin "mmc %windir%\system32\dsa.msc"
> runas /env /user:user@domain.microsoft.com "notepad \"my file.txt\""

I just now tried the 2nd one from an already elevated powershell console:

C:\> runas /profile /env /user:myDomain\myAdminUser "mmc %windir%\system32\dsa.msc"
Enter the password for pmcs\klaus.frank:
Attempting to start mmc %windir%\system32\dsa.msc as user "myDomain\myAdminUser" ...
RUNAS ERROR: Unable to run - mmc %windir%\system32\dsa.msc
740: The requested operation requires elevation.

So which "runas administrator flow" are you talking about? The one we had on Windows XP?

Now two claims that are correct:

• You can choose to connect the elevated process to the current console window with the disableInput and normal configuration options. This is not supported with runas.
• runas can prompt users for a password in the command-line.

From https://learn.microsoft.com/en-us/windows/sudo/#how-to-configure-sudo-for-windows:

This is similar to the behavior of the runas /user:admin command.

No it's not because runas /user:admin doesn't work. Well, it'll switch the user context but not the elevation context thereby not providing any elevation at all. Similarly also Start-Process -Credential $explicitCredentials -Verb RunAs doesn't work. -Verb RunAs (which causes the elevation) cannot be used together with -Credential. And even if the credentials are for an administrative user the started process still will only be Medium Trust. Furthermore it'll start on the same WinStation and Session but at least for cmd and pwsh it won't accept any keyboard input (mouse however works, and keyboard also works for notepad).
But most importantly IT WON'T EVER BE ELEVATED (S-1-16-12288).

Tl;Dr: runas is almsot completely useless and/or broken since Vista. There is no way (besides sudo) to get a higher trust process connected to a lower trust console. The only thing that currently works (without sudo) is to use two nested commands. 1) switch user context (and still be Medium Trust) 2) Trigger UAC from within the target user and be able to use Approval Mode even though the original user was not a member of the administrators group and therefore would normally have gotten the username+password UAC prompt.
e.g. by: Start-Process -Credential $creds -FilePath pwsh -ArgumentList @("-NoP", "-EP", "ByPass", "-NoExit", "-Command", "& { Start-Process -Verb RunAs -FilePath cmd.exe -ArgumentList @('/K', 'whoami', '/groups') }") This will spawn two new processes. The first one with the $creds.UserName context and the 2nd one within Elevated $creds.UserName context.

Scenario when this would be used?

Not getting an incorrect perception of the capabilities of runas.

Supporting information

No response

[joadoumie]

Thanks so much for your thoughtful feedback here. I'll take some time to review your comments and work to make the appropriate changes where needed.