Why do I get ACCESS DENIED when running commands on a remote PS runspace?


This blog entry describes the reasons behind getting “Access Denied” on certain commands run on remote PS runspaces and ways to work around them. The category of commands include ones that authenticate to other services, try to access network resources and others that depend on the “impersonation” level of the security token.


The commands would otherwise work when run on locally.


A brief context of why this problem occurs : Powershell uses WSMan (or WinRM) to communicate to a remote endpoint. The default authentication that WinRM supoprts (Kerberos or Negotiate) ends up generating a “network” token on the server side that does not have authentication privileges. Powershell remote runspace and all associated commands run in the context of the “network” token.


 To support these scenarios, WinRM has added the support for CredSSP in version 2.0. CredSSP authentication results in server side token that is capable of doing authentication. Refer http://msdn.microsoft.com/en-us/library/ee309365(VS.85).aspx for more details


 

Comments (1)

  1. Brian Coverstone says:

    That's great that Microsoft made CredSSP.  However, it's unusable in some scenarios because WinRS still does not have a switch to use default credentials, so you end up having to put in your username/password in the script to make it work.  A bit of a security issue here.