USERDOMAIN Environmental Variable Returns COMPUTERDOMAIN Value

[RamblingPSTech]

Environment: Windows Server in workgroup mode (not domain joined)

When logged into a Windows OS via Console, Remote Desktop, WinRM session, the %USERPROFILE% ($env:USERPROFILE) %USERDOMAIN% ($env:USERDOMAIN) variable contains the value of the computername (i.e. WIN-1DVQ9PPCF1L) - CORRECT

When logged into a Windows OS via SSH (direct SSH & PowerShell session over SSH), the %USERPROFILE% ($env:USERPROFILE) %USERDOMAIN% ($env:USERDOMAIN) variable contains the value of the workgroup name (i.e. "WORKGROUP") - INCORRECT

Processes that use a syntax of ${env(USERDOMAIN)}\${system_username} to reference a security principal fail when using a remote SSH session, but work with WinRM sessions due to the inconsistent USERDOMAIN value

Related Issues:

• Permissions repair PowerShell scripts do not work in an ssh session. #1877
• installer fails during remote session EnterpriseDB/edb-installers#336

---

PowerShell Session Over WinRM

PS C:\> $pssessionoption = New-PSSessionOption -SkipCACheck -SkipCNCheck -SkipRevocationCheck
PS C:\> Enter-PSSession -SessionOption $PSSessionOption -ComputerName 192.168.0.10 -Credential (Get-Credential) -UseSSL

PowerShell credential request
Enter your credentials.
User: administrator
Password for user administrator: *********

[192.168.0.10]: PS C:\Users\Administrator\Documents> $env:userdomain
WIN-1DVQ9PPCF1L

---

PowerShell Session Over SSH

PS C:\> Enter-PSSession -HostName 192.168.0.10 -IdentityFilePath ~\.ssh\id_ecdsa -UserName administrator
[administrator@192.168.0.10]: PS C:\Users\Administrator\Documents> $env:userdomain
WORKGROUP

Expected behavior

Within Remote SSH session to Windows OS:

Command (cmd.exe): `echo %USERDOMAIN%`
Output: `WIN-1DVQ9PPCF1L` (current remote computer name)

Command (pwsh): `$env:userdomain`
Output:  `WIN-1DVQ9PPCF1L` (current remote computer name)

Actual behavior

Within Remote SSH session to Windows OS:

Command (cmd.exe): `echo %USERDOMAIN%`
Output: `WORKGROUP` (current NETBIOS workgroup name)

Command (pwsh): `$env:userdomain`
Output:  `WORKGROUP` (current NETBIOS workgroup name)

Error details

`${env(USERDOMAIN)}\${system_username}` is used by some processes to add the current user to the accesss control list after disabling inheritance and clearing existing access control entries.

WORKGROUP\USERNAME results in an invalid user SID mapping causing the Access Control List to have no Access Control Entries

Environment data

PSVersion                      7.5.4
PSEdition                      Core
GitCommitId                    7.5.4
OS                             Microsoft Windows 10.0.26100
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Version

OpenSSH_for_Windows_9.8p2 Win32-OpenSSH-GitHub, LibreSSL 4.0.0

Visuals

No response

[StevenBucher98]

@tgauth will take a look and investigate further, thanks for linking the previous issues that revive some of our old investigations 😄

[mgkuhn]

@RamblingPSTech Are you sure you mean USERPROFILE, which should be the path to my home directory, e.g.

>echo %USERPROFILE%
C:\Users\mgk25

Do you not mean just USERDOMAIN in your examples? (Or perhaps USER or LOGNAME, which are formed of USERDOMAIN\USERNAME?)

Likewise, do you mean COMPUTERNAME instead of COMPUTERDOMAIN?

https://ss64.com/nt/syntax-variables.html

[mgkuhn]

I can't find in the source code any place where sshd sets USERDOMAIN, so I suspect this comes from the operating system, i.e. may have to be addressed in Windows rather than sshd.

[o-sdn-o]

USERDOMAIN=workgroup is specific to the Local System account.

[o-sdn-o]

I can't find in the source code

It appears that the user's environment is not being constructed properly.

• https://learn.microsoft.com/en-us/windows/win32/api/userenv/nf-userenv-loaduserprofilea:

  When a user logs on interactively, the system automatically loads the user's profile. If a service or an application impersonates a user, the system does not load the user's profile. Therefore, the service or application should load the user's profile with LoadUserProfile.

[o-sdn-o]

There's a clear understanding of what's happening:

• The user profile is loaded correctly in openssh-portable\contrib\win32\win32compat\win32_usertoken_utils.c:818 (the first child ssd-session.exe of sshd.exe)
• openssh-portable\contrib\win32\win32compat\w32fd.c:1108:
  CreateProcessAsUserW launches child processes (the second child ssd-session.exe) with a variable block from the LocalSystem context:

  A pointer to an environment block for the new process. If this parameter is NULL, the new process uses the environment of the calling process.

• openssh-portable\contrib\win32\win32compat\w32-doexec.c:106:
  The LocalSystem envvar block is updated, instead of the user envvar block. It may be necessary to load the user environment block using CreateEnvironmentBlock and then update it.
• openssh-portable\contrib\win32\win32compat\w32fd.c:1112:
  The updated user environment block should then be passed to CreateProcessW.

[mgkuhn]

It appears that the user's environment is not being constructed properly.

I can see code calling LoadUserProfile in contrib/win32/win32compat/win32_usertoken_utils.c, but only for user "sshd", and nothing calling UnloadUserProfile. So is this really being used?

Are these sufficiently light-weight functions that should be called for each SSH login, or is it a too heavy/slow operation that might be appropriate for a GUI login, but not for a terminal session? What if there are multiple, concurrent SSH logins?

I've seen users with roaming profile and gigabytes of files sitting on their Desktop getting the latter being copied around at each GUI login and logout, and SSH users may not expect the same to happen there (as there is nothing equivalent in the Unix world). So I wonder if any improvised setup of a user profile in OpenSSH for Windows, rather than calling LoadUserProfile, was a design choice rather than an oversight.

[o-sdn-o]

I can see code calling LoadUserProfile in contrib/win32/win32compat/win32_usertoken_utils.c, but only for user "sshd", and nothing calling UnloadUserProfile. So is this really being used?

Are these sufficiently light-weight functions that should be called for each SSH login, or is it a too heavy/slow operation that might be appropriate for a GUI login, but not for a terminal session? What if there are multiple, concurrent SSH logins?

LoadUserProfile is called in the sshd-session.exe child process for each connecting user.

[o-sdn-o]

To fix the issue under discussion, the following is required:

• Use CreateEnvironmentBlock with the connected user's context token (we have one) to obtain the user's environment block (the LocalSystem context's environment block is currently being updated, which is incorrect).
• Ensure that the updated block is passed to CreateProcessW, which launches the resulting user process, such as cmd.exe.

It seems that LoadUserProfile is not necessary for each user, the only thing that is required is to ensure that variables such as %USERPROFILE% are updated (this is already done here):

• CreateEnvironmentBlock

  User-specific environment variables such as %USERPROFILE% are set only when the user's profile is loaded. To load a user's profile, call the LoadUserProfile function.

[o-sdn-o]

@mgkuhn However, LoadUserProfile is called for each user (except sshd)

• std::strcmp:

  Return value

  • Negative value if lhs appears before rhs in lexicographical order.
  • Zero if lhs and rhs compare equal.
  • Positive value if lhs appears after rhs in lexicographical order.

[mgkuhn]

LoadUserProfile is called for each user (except sshd)

Ah, I misread.

[o-sdn-o]

An open question is whether CreateEnvironmentBlock should inherit the environment block from the LocalSystem context when generating the user block, or whether the user environment block should be untouched before updating.

[o-sdn-o]

An open question is whether CreateEnvironmentBlock should inherit the environment block from the LocalSystem context when generating the user block, or whether the user environment block should be untouched before updating.

Apparently, simple inheritance at the last moment before launching cmd.exe isn't suitable. Perhaps the user environment block needs to be loaded before launching the second instance of sshd-session.exe (2.sshd-session.exe):

• sshd.exe (LocalSystem) -> 1.sshd-session.exe (LocalSystem):
  • Add c:\program files\openssh; to PATH
• 1.sshd-session.exe (LocalSystem) -> 2.sshd-session.exe (MEG\test):
  • Changed:

    EnvVar	Old value	New value
    APPDATA	C:\WINDOWS\system32\config\systemprofile\AppData\Roaming	C:\Users\test\AppData\Roaming
    LOCALAPPDATA	C:\WINDOWS\system32\config\systemprofile\AppData\Local	C:\Users\test\AppData\Local
    PATH	...	...
    USERNAME	MEG$	test
    USERPROFILE	C:\WINDOWS\system32\config\systemprofile	C:\Users\test

  • Added:

    EnvVar	Value
    HOME	C:\Users\test
    HOMEDRIVE	C:
    HOMEPATH	\Users\test
    LOGNAME	test
    PROMPT	test@MEG $P$G
    SHELL	c:\windows\system32\cmd.exe
    SSH_CLIENT	::1 52938 22
    SSH_CONNECTION	::1 52938 ::1 22
    TEMP	C:\Users\test\AppData\Local\Temp
    TMP	C:\Users\test\AppData\Local\Temp
    USER	test

• 2.sshd-session.exe (MEG\test) -> cmd.exe (MEG\test):
  • Added:

    EnvVar	Value
    c28fc6f98a2c44abbbd89d6a3037d0d9_POSIX_FD_STATE	AAAAAAICAs0=