RunAs Administrator returning "SYSTEM" as $env:USERNAME in PowerShell

[mpearon]

Windows Terminal version

1.19.2682.0

Windows build number

10.0.22621.0

Other Software

Windows PowerShell 5.1.22621.2428
PowerShell 7.3.8

Steps to reproduce

Launch Terminal as Administrator (Win+X, A)
Issue the following:

$env:USERNAME

Expected Behavior

The username of the currently logged in user should be returned

Actual Behavior

SYSTEM is returned

The screenshot included shows PWSH 7.3.8 running outside Terminal (top left) and inside Terminal (top right) and Windows PowerShell 5.1 running outside Terminal (bottom left) and inside Terminal (bottom right).

The output of $env:USERNAME (which is the expected output) has been redacted in the screenshots and the prompt customized to prevent data leak - but this occurs with no customizations and with a fresh installation of Terminal from the Windows Store.

[mpearon]

I learned something about the $env: automatic variables.
I just assumed they were immutable, but they are not. I would like to see this change in behavior explained, but going forward, I guess I will use [System.Environment]::UserName, because that seems a lot safer.

[DHowett]

Do you use "over-the-shoulder" elevation (where you need to provide an admin username and password which is different from your main user)?

[mpearon]

Do you use "over-the-shoulder" elevation (where you need to provide an admin username and password which is different from your main user)?

@DHowett - I'm leveraging Win+X, A - which triggers UAC. At that prompt, I'm providing a credential that is different than my logged in user.

I could not reproduce:

@237dmitry - Terminal version 1.19.2682.0? Leave it to me to have the weird issue.

[DHowett]

I'm providing a credential that is different than my logged in user.

So, I think it might be because of this. "Over-the-shoulder" elevation is slightly different from the normal split-token kind of elevation that most folks use.

If you launch PowerShell directly as admin, without terminal (Win+R, pwsh, Ctrl+Shift+Enter), do you see the same thing?

[mpearon]

I'm providing a credential that is different than my logged in user.

So, I think it might be because of this. "Over-the-shoulder" elevation is slightly different from the normal split-token kind of elevation that most folks use.

If you launch PowerShell directly as admin, without terminal (Win+R, pwsh, Ctrl+Shift+Enter), do you see the same thing?

@DHowett - No. This is what my screenshot is demonstrating (left side is launching PowerShell outside of Terminal). This issue only occurs when Terminal is in play.

[DHowett]

Whoops, I'm sorry about that. Shows how well I pay attention.

This may be a side effect of us regenerating the user environment block from first principles rather than inheriting it from Explorer. Hmm.

[mpearon]

No worries! I'm sure you see a million of these issues a day.
This behavior breaks a few scripts that use the automatic variables, but it did lead me to "discover" that these are not immutable and really shouldn't be trusted for what I was using them for, so I have switched to using [System.Environment] - but I'm still very curious.

I'm happy to do whatever testing is required.

[lhecker]

Note to self: I probably accidentally fixed this in #16190 and I just need to fix the incorrect comment here:

terminal/src/inc/til/env.h

Lines 435 to 437 in 64b5b28

	// * call LookupAccountSidW to get the USERNAME/USERDOMAIN variables.
	// Windows sets these as values of the "Volatile Environment" key at each login.
	// We don't expect our process to impersonate another user so we can get them from the PEB.

[ghostbuster1002]

I probably accidentally fixed this in #16190

@lhecker
FWIW, I am still getting $env:UserName as SYSTEM when trying this on v1.19.3172.0

[GitUser200607]

I had the same issue when Windows Terminal with PowerShell was elevated via UAC, and to evade it, I changed $Env:USERNAME to [Environment]::UserName

[eryksun]

The regenerate() function initially sets the value of USERNAME from the current environment, via get(til::details::vars::user_name). Then the value gets overwritten by the system environment's USERNAME value of "SYSTEM", due to get_vars_from_registry(HKEY_LOCAL_MACHINE, til::details::vars::reg::system_env_var_root).

regenerate() depends on setting the right value again from the "Volatile Environment" (non-persistent) registry key that gets created for a normal logon session, from get_vars_from_registry(HKEY_CURRENT_USER, til::details::vars::reg::user_volatile_env_var_root). The problem is that OTS elevation doesn't implement a normal logon that creates the "Volatile Environment" registry key. I think OTS elevation should do a full logon, if it can, but Terminal shouldn't depend on that. It should set USERNAME again from the current environment after loading the system environment from the registry.

terminal/src/inc/til/env.h

Lines 445 to 475 in 4a243f0

	void regenerate()
	{
	// Generally replicates the behavior of shell32!RegenerateUserEnvironment
	// The difference is that we don't
	// * handle autoexec.bat (intentionally unsupported).
	// * call LookupAccountSidW to get the USERNAME/USERDOMAIN variables.
	// Windows sets these as values of the "Volatile Environment" key at each login.
	// We don't expect our process to impersonate another user so we can get them from the PEB.
	// * call GetComputerNameW to get the COMPUTERNAME variable, for the same reason.
	get(til::details::vars::system_root);
	get(til::details::vars::system_drive);
	get(til::details::vars::all_users_profile);
	get(til::details::vars::public_var);
	get(til::details::vars::program_data);
	get(til::details::vars::computer_name);
	get(til::details::vars::user_name);
	get(til::details::vars::user_domain);
	get(til::details::vars::user_dns_domain);
	get(til::details::vars::home_drive);
	get(til::details::vars::home_share);
	get(til::details::vars::home_path);
	get(til::details::vars::user_profile);
	get(til::details::vars::app_data);
	get(til::details::vars::local_app_data);
	get_program_files();
	get_vars_from_registry(HKEY_LOCAL_MACHINE, til::details::vars::reg::system_env_var_root);
	// not processing autoexec.bat
	get_vars_from_registry(HKEY_CURRENT_USER, til::details::vars::reg::user_env_var_root);
	get_vars_from_registry(HKEY_CURRENT_USER, til::details::vars::reg::user_volatile_env_var_root);
	get_vars_from_registry(HKEY_CURRENT_USER, fmt::format(FMT_COMPILE(LR"(Volatile Environment\{})"), NtCurrentTeb()->ProcessEnvironmentBlock->SessionId));
	}

Also, some variables from a normal logon session are missing in the OTS case, such as LOGONSERVER, HOMEDRIVE, HOMEPATH, and HOMESHARE. Maybe Terminal should manually set HOMEDRIVE and HOMEPATH based on USERPROFILE if they don't exist in the current environment.

[42sol-eu]

We have a somewhat connected issue (I let you judge if this belongs here if not I will open a separate issue).

System

Or computers have Local Admin users (not the default Administrator).
We can spawn a admin-shell via runas.exe /user:admin{username}

The fault

Let us assume the useris muspet and the domain ourdomain
If using the runas /user:adminmuspet@ourdomain %SystemRoot%\System32\WindowsPowerShell\v1.0\powershell.exe as a start shell.

Enter the password for adminmuspet@ourdomain:
Attempting to start C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe as user "adminmuspet@ourdomain" ...
RUNAS ERROR: Unable to run - C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
1326: The user name or password is incorrect.

[process exited with code 1 (0x00000001)]
You can now close this terminal with Ctrl+D, or press Enter to restart.

Expected Behaviour

• It should show the correct failure (because password and user are definitively correct)
• It should work properly (start the system powershell)

I am human

• Maybe I am missing something OR our IT is doing something strange.