Search code examples
powershell32bit-64bitcredentialsremote-serveraccess-denied

Invoke-Command runs OK as Administrator, but not as current user

The following code works fine when I run it in the PowerShell ISE as Administrator (i.e. I start the PS ISE as Admin) 

Invoke-Command -ScriptBlock {[IntPtr]::Size}

Invoke-Command -ScriptBlock {[IntPtr]::Size} -ComputerName $env:COMPUTERNAME -Credential $Credential

Invoke-Command -ScriptBlock {[IntPtr]::Size} -ComputerName $env:COMPUTERNAME -Credential $Credential -ConfigurationName Microsoft.PowerShell32

I get the expected responses of

8
8
4

This tells me that WinRM is correctly configured and running, and that my $Credential is correctly setup. However, when I try running the same in the PS ISE as a user (with or without Admin rights) I get the following errors for the second and third commands

[<ComputerName>] Connecting to remote server <ComputerName> failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
    + CategoryInfo          : OpenError: (<ComputerName>:String) [], PSRemotingTransportException
    + FullyQualifiedErrorId : AccessDenied,PSSessionStateBroken

I will be substituting the ScriptBlock code with something more substantive, that needs to run in 32 bit mode because of dependencies on 32 bit DLLs, and the ability for users to run some of the code in 64 bit mode and other parts in 32 bit mode is important.

Any thoughts?

Solution

  • PSRemoting uses an endpoint, or session configuration, on the remote computer. You're obviously aware of this, as your third command includes the ConfigurationName parameter. These endpoints -- Microsoft.PowerShell, Microsoft.PowerShell32, etc. -- include permissions on them that indicate who can connect to them.

    Go to your remote computer (your local computer in this instance), and run Get-PSSessionConfiguration and take a look at the Permission property. You'll quickly realize that you administrative access is a requirement. This is by design; it's a good thing!

    Your options are to one, edit the endpoint(s) and add your user(s), two, grant required access to your user (whether that be Admin or potentially Remote Management Users access), three, use a credential object when you run Invoke-Command, passing the credentials, or four, creating your own endpoint with the necessary permissions.