Powershell: Invoke-Command : Windows Principal functionality is not supported on this platform.

[corretge]

Sometimes, When I try to execute a remote command in a PowerShell Session from PowerShell in Linux, I get this error:

Invoke-Command : Windows Principal functionality is not supported on this platform.

From PowerShell in Mac works fine, but with PowerShell in Linux doesn't.

Steps to reproduce

We are connected to a Linux powershell session though a PowerShell session in a system with sshd Subsystem powershell /usr/bin/pwsh -sshs -NoLogo -NoProfile.
Once into the system, we want to execute a command to another Linux powershell session

$pss = New-PSSession -Hostname x.x.x.x -Username xxx -Port xx -KeyFilePath ~/.ssh/xxx
Invoke-Command $pss { $PSVersionTable }

Expected behavior

Name                           Value
----                           -----
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
Platform                       Unix
OS                             Linux 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20 20:32:50 UTC 2017
PSVersion                      6.0.1
PSEdition                      Core
GitCommitId                    v6.0.1

Actual behavior

Invoke-Command : Windows Principal functionality is not supported on this platform.
At line:1 char:1
+ Invoke-Command $pss { $PSVersionTable }
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Invoke-Command], PlatformNotSupportedException
+ FullyQualifiedErrorId : System.PlatformNotSupportedException,Microsoft.PowerShell.Commands.InvokeCommandCommand

Environment data

> $PSVersionTable
Name                           Value
----                           -----
PSVersion                      6.0.2
PSEdition                      Core
GitCommitId                    v6.0.2
OS                             Linux 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 UTC 2018
Platform                       Unix
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

But if I execute Enter-PSSession I get an error, and then Invoke-Command runs like a charm.

If we connect to the linux machine though ssh with bash, and execute /usr/bin/pwsh Invoke-Command works at first attempt.

[PaulHigin]

This looks like a weird double hop issue. I'll try to repro when I get some time.

[flxflx]

I am getting the same error for the following line of code when I am on WSL or connected remotely to a Linux box over ssh.

$nodes | foreach-object { start-job -ScriptBlock $function:createRemoteNode -ArgumentList ($_, ($nodeId++) + $constArgs)} | receive-job -Wait -AutoRemoveJob

[neel015]

Facing the same error when trying to run invoke-command using Powershell core 6.1 with Microsoft.Powershell.SDK dlls.
Working on a linux ubuntu 16.04, I am able to run the command from powershelll core directly. However, when I try to run the same script from C#, I am getting the same error message.

$TargetSession = New-PSSession -HostName $TargetComputerName -UserName $Username -KeyFilePath $KeyFilePath

Invoke-Command -Session $TargetSession -ScriptBlock {
 get-process
}

[JustinGrote]

This happens to me when doing SSH remoting from a Linux system to a Windows system via SSH if the commands are wrapped in jobs. Doesn't seem to matter if it's a process job or a runspace job.

Works perfectly fine from Posh 6.1 on Windows to Windows via SSH

Normal SSH Session (works)

PS /tmp> $s = new-pssession -SSHTransport -HostName _REDACTED_ -KeyFilePath /tmp/tmpblvmbP.tmp -UserName _REDACTED_ -Verbose;sleep 1;icm -session $s -scriptblock {echo "test"}
test

Inside Process via Start-Job (fails)

PS /tmp> start-job {$s = new-pssession -SSHTransport -HostName 172.30.2.89 -KeyFilePath /tmp/tmpblvmbP.tmp -UserName sa-awsmodelingstatus -Verbose;sleep 3;icm -session $s -scriptblock {echo "test"}} | receive-job -wait -AutoRemoveJob
Windows Principal functionality is not supported on this platform.
+ CategoryInfo          : NotSpecified: (:) [Invoke-Command], PlatformNotSupport                           edException
+ FullyQualifiedErrorId : System.PlatformNotSupportedException,Microsoft.PowerSh                           ell.Commands.InvokeCommandCommand
+ PSComputerName        : localhost

Inside Runspace via Start-Threadjob (fails)

PS /tmp> start-threadjob {$s = new-pssession -SSHTransport -HostName _REDACTED_ -KeyFilePath /tmp/tmpblvmbP.tmp -UserName _REDACTED_-Verbose;sleep 1;icm -session $s -scriptblock {echo "test"}} | Receive-job -wait -AutoRemoveJob
icm : Windows Principal functionality is not supported on this platform.
At line:1 char:136
+ ... ingstatus -Verbose;sleep 3;icm -session $s -scriptblock {echo "test"}
+                                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [Invoke-Command], PlatformNotSupportedException
+ FullyQualifiedErrorId : System.PlatformNotSupportedException,Microsoft.PowerShell.Commands.InvokeCommandCommand

@SteveL-MSFT does your PR #8232 address this?
EDIT: Just tested on 6.2.0-preview3 with #8232 included. It does not 👎

[JustinGrote]

Tried doing it with -SSHConnection and ran into #8589. SSH Remoting still feels pretty half-baked unfortunately...

[PaulHigin]

@JustinGrote Unfortunately I am still unable to repro this error. But the error indicates that there is still some Windows code lurking in Linux code paths. I recently found and fixed a number of similar issues pertaining to Windows impersonation flow. The problem was found during remote debugging but it is possible it is related to your problem (#8451). However, the fix won't be available until the next release (I think Feb), unless you want to build your own version to test with. Also, if you can include the error stack trace, it may pinpoint the offending code path.

[danports]

I am working on a similar scenario as @neel015 and also ran into this issue on 6.1.3. Here's a stack trace @PaulHigin:

System.PlatformNotSupportedException: Windows Principal functionality is not supported on this platform.
   at System.Security.Principal.WindowsIdentity.GetCurrent()
   at System.Management.Automation.RemoteDebugger.CheckForValidateState()
   at System.Management.Automation.RemoteDebugger.set_UnhandledBreakpointMode(UnhandledBreakpointProcessingMode value)
   at Microsoft.PowerShell.Commands.ExecutionCmdletHelper.ConfigureRunspaceDebugging(Runspace runspace)
   at Microsoft.PowerShell.Commands.ExecutionCmdletHelperRunspace.StartOperation()
   at System.Management.Automation.Remoting.ThrottleManager.StartOneOperationFromQueue()
   at System.Management.Automation.Remoting.ThrottleManager.StartOperationsFromQueue()
   at System.Management.Automation.Remoting.ThrottleManager.SubmitOperations(List`1 operations)
   at System.Management.Automation.PSInvokeExpressionSyncJob.StartOperations(List`1 operations)
   at Microsoft.PowerShell.Commands.InvokeCommandCommand.CreateAndRunSyncJob()
   at Microsoft.PowerShell.Commands.InvokeCommandCommand.ProcessRecord()
   at System.Management.Automation.Cmdlet.DoProcessRecord()
   at System.Management.Automation.CommandProcessor.ProcessRecord() at at <ScriptBlock>, <No file>: line 6

[danports]

@neel015 I was able to bypass the problematic code by calling RunspaceFactory.CreateRunspace(new WSManConnectionInfo {...}) to create a remote runspace rather than using New-PSSession and Invoke-Command, which feels cleaner anyhow.

[SteveL-MSFT]

@danports Thanks for the stack trace! With that, I see that @PaulHigin made a change in https://github.com/PowerShell/PowerShell/pull/8451 that would have fixed this issue. That change would only be in PSCore6.2. Can you try 6.2-RC1 and see if you're original problem repros?