Closed jhack31 closed 7 years ago
Can you share the exact message? Putting the script path in VisibleExternalCommands
is the right way to do it and worked on my system. One thing to double check is the execution policy of your session configuration file -- you may need to drop it to Unrestricted or Bypass if the script you're authorizing is not signed.
Hey Ryan, I suspect it is the fact that I haven't signed the script, but here is the exact error:
The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.
Hmm, could you shoot your script to me in an email (ryanpu @ MSFT)? Would be interested to see what's going on.
I was able to get this to work with changing the session configuration to Full Language and using invoke-command in my script to connect to the server in question (e.g. invoke-command -computername
@jhack31 Great to hear you're unblocked! Just to confirm, though, on which machine did you change the language mode. We do not recommend using FullLanguage inside a JEA endpoint as it would allow users to invoke arbitrary .NET APIs which can circumvent the sandbox we put in place.
It was on the endpoint. Is there another language mode I could use besides no language and maintain the integrity of jea?
On May 8, 2017 1:36 PM, "Ryan Puffer" notifications@github.com wrote:
@jhack31 https://github.com/jhack31 Great to hear you're unblocked! Just to confirm, though, on which machine did you change the language mode. We do not recommend using FullLanguage inside a JEA endpoint as it would allow users to invoke arbitrary .NET APIs which can circumvent the sandbox we put in place.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PowerShell/JEA/issues/20#issuecomment-299935854, or mute the thread https://github.com/notifications/unsubscribe-auth/ARM-UyiMnnx2ZNBu4aNiBCveI4Mzu5Dlks5r31KwgaJpZM4NLyRD .
NoLanguage is the only recommended configuration for security sensitive endpoints. I see you're just calling Stop-Service on the remote endpoint -- is that not working in NoLanguage mode? Or is "invoke-command" what is sent to the JEA endpoint, used to manage a further system?
I use Invoke-command with Scriptblock to manage the service on a remote endpoint.
Scenario is user would log into a jump server and double click a shortcut (to a script) that remotely restarts a service on a JEA endpoint.
On May 8, 2017 4:18 PM, "Ryan Puffer" notifications@github.com wrote:
NoLanguage is the only recommended configuration for security sensitive endpoints. I see you're just calling Stop-Service on the remote endpoint -- is that not working in NoLanguage mode? Or is "invoke-command" what is sent to the JEA endpoint, used to manage a further system?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/PowerShell/JEA/issues/20#issuecomment-299978742, or mute the thread https://github.com/notifications/unsubscribe-auth/ARM-U0-1yJSVP-G84mQm2ljvdbOh6qlPks5r33iggaJpZM4NLyRD .
I got this to work in NoLanguage mode by using Import-PSSession and then performing the stop/start service commands rather than using Invoke-Command. I think this can be closed if you agree that is an appropriate way to accomplish this?
Thanks!
That's really weird. Invoke-Command should support JEA no problem.
What is the exact syntax you're using with Invoke-Command? The way you describe this would indicate that you're using some language element like variables which would explain why implicit remoting works but Invoke-Command does not.
For example, the below command will always fail with JEA:
Invoke-Command -ComputerName mydesktop -ConfigurationName jea -ScriptBlock { $s = Get-Service Spooler; Stop-Service $s }
As will this (because there is no link between the variable in the script block and the one on your gateway):
$variableOnMyLocalComputer = 'Spooler'
Invoke-Command -ComputerName mydesktop -ConfigurationName jea -ScriptBlock { Stop-Service $variableOnMyLocalComputer }
But this will succeed, because the $using:
syntax tells PowerShell to put the value in the specified variable into the script block, not to declare a new variable in the script block context:
$variableOnMyLocalComputer = 'Spooler'
Invoke-Command -ComputerName mydesktop -ConfigurationName jea -ScriptBlock { Stop-Service $using:variableOnMyLocalComputer }
You're correct. I was using language elements within the script block like If/Else in order to provide a status to the user running it.
Invoke-Command -ComputerName mydesktop -ScriptBlock {Stop-Service $using:service}"
works fine.
Invoke-Command -ComputerName $server -ScriptBlock {
Stop-Service -Name $using:service
if((Get-Service -Name $using:service).Status -eq "Stopped")
{
"$using:service service is stopped."
}
fails with the error:
The syntax is not supported by this runspace. This can occur if the runspace is in no-language mode.
Thanks for your assistance on the issue!
Great! I'm going to close this issue but feel free to open another if something else comes up.
Is it possible to allow a script to run in the context of JEA? For example, I am trying to allow someone who is not at all comfortable or familiar with PowerShell to restart a specific service. Could I put a shortcut to a PowerShell script that restarts that service on their desktop so when they run it, it runs in the context of JEA and allows them to restart the service?
I have played around with setting that up as a VisibleExternalCommand, but got an error saying ScriptsNotAllowed.
Thanks.