Can't load the module via remote

Nov 16, 2012 at 9:26 AM
Edited Nov 16, 2012 at 9:37 AM

Hi Guys,

Currently, i try to trigger a script with serverA on serverB. I load the PSPKI module In the script on serverB. But thats not possible.

When i trigger ther script on ther serverB with the following code:

Invoke-Command -ComputerName 'serverB' -ScriptBlock {&'E:\Scripts\Dev\Thomas\CA\CAUserRevokedReport - Copy.ps1'}

I receive the message that my remote server have the Powershell version 1.0 but the server is an 2008R2 and Powershell 2.0 is installed by default.

An colleague Peter Kriegel from the german powershell technet forum means that the script works with the command get-host to match the powershell versions but the better way is to use the environmet variable $PSVersionTable. I think so too and can explain my issue with that. Because an Remote session with get-host return allways the version 1.0. This problem is also not solved in the version 3 of Powershell.  Have you already an fix for it or an workarround?

best regards
Thomas

Coordinator
Nov 16, 2012 at 12:24 PM

Hi, PSPKI is not supported to run in remote sessions (via PS Remoting) due to its design and there are no plans to add this support. Module already uses (or intended to use) remote connections to CA servers. If you will run PSPKI module in remote sessions the module will become unusable because of credential delegation issue. Here is a short example:

1) ComputerA (your worksation) -> ComputerC (CA server)

2) ComputerA (your worksation) -> ComputerB -> ComputerC (CA server).

when you run your script on ComputerA and access CA server on ComputerC, the script will work fine, because you are authenticated directly.

When you run commands remotely on ComputerB, the script will fail, because ServerB has delegated credentials and they cannot be used to authenticate you on ComputerC. To resolve this you have to do either:

1) allow credential delegation for ComputerB. Many administrators don't like this option, because it is unsecure. ComputerB will be able to authenticate anyone on other computers and you are in risk of network compromise if only single ComputerB is compromised.

2) use explicit credentail transfer: CredSSP. This is alternate approach. This is more secure way to delegate credentials, however it requires additional configuration, explixit CredSSP use. Also I never tested CredSSP in remoting with smart cards and can't guarantee that this would work as expected.

In addition, I put a lot of effort to make commands in the module to support remote systems as much as possible (though, certain commands runs only locally, however). My main idea is to use the module on administrator's workstation (not directly on CA servers), so he is able to perform required PKI-related management tasks without having to log on to CA servers. That is, if you want to collect some reports about revoked certificates, you should run the module locally, collect all required data from remote CA servers and process them locally too.