PowerShell / JEA

Just Enough Administration
http://aka.ms/JEAdocs
MIT License
257 stars 60 forks source link

Shortcut to script running in JEA context #20

Closed jhack31 closed 7 years ago

jhack31 commented 7 years ago

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.

rpsqrd commented 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.

jhack31 commented 7 years ago

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.

rpsqrd commented 7 years ago

Hmm, could you shoot your script to me in an email (ryanpu @ MSFT)? Would be interested to see what's going on.

jhack31 commented 7 years ago

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 -ScriptBlock {stop-service }.

rpsqrd commented 7 years ago

@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.

jhack31 commented 7 years ago

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 .

rpsqrd commented 7 years ago

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?

jhack31 commented 7 years ago

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 .

jhack31 commented 7 years ago

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!

rpsqrd commented 7 years ago

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 }
jhack31 commented 7 years ago

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!

rpsqrd commented 7 years ago

Great! I'm going to close this issue but feel free to open another if something else comes up.