Execute command or access to resources, on other computer, is denied
Please note that an administrative PowerShell console at the ScriptRunner Service host is required to run the cmdlets.
Here's a typical scenario, how you might run into the dreaded double-hop problem:
After you connect to a remote computer with PowerShell remoting and attempt to issue commands to a resource outside that computer, you might receive this message: Access is denied.
You might think it should have worked because you authenticated credentials on the remote computer and those credentials have permissions to access the second remote computer.
However, Active Directory domains use Kerberos for authentication, which does not allow passing credentials beyond the first machine to prevent malicious activity.
The most used solution:
Activate CredSSP on the ScriptRunner service computer and the executing computer.
The ScriptRunner service becomes the role Client and the executing computer the role Server.
You can either use the command Enable-WSManCredSSP or the script Set-SysMCredSSP.ps1 from our ActionPack WinSystemManagement.
Use CredSSP with ScriptRunner
Register the target systems as delegate computers on the ScriptRunner service computer
Enable-WSManCredSSP -Role Client -DelegateComputer '*.domainA.local', 'target.domain.com'
Enable CredSSP on the target systems
Enable-WSManCredSSP -Role Server
In the ScriptRunner Admin App, activate the option Use a non-default PS Remoting authentication method at the ScriptRunner target and set CredSSP: Credential Security Service Provider
More resources on this topic:
Enable-WSManCredSSP CmdLet
Making the second hop in PowerShell Remoting
PowerShell Remoting Kerberos Double Hop Solved Securely
Solving Double Hop Safely with PowerShell Remoting and Kerberos
ScriptRunner ActionPack WinSystemManagement
Get-WSManCredSSP CmdLet
This page has been automatically translated and may contain grammatical errors or inaccuracies