Forum Discussion
Attempting Powershell Remoting but experiencing errors
Hi MBee
From a security perspective, using CredSSP is less of an issue than the approach outlined in the 4sysops article.
In order of preference from most to least, I'd recommend:
- Kerberos constrained delegation;
- Enabling and using CredSSP;
- 4sysops article (which, frankly, I would never use).
With respect to the error, the clue for the final error in red is right there in the second warning in yellow/orange: Using the -Force parameter results in the remote WinRM service restarting, which in turn leads to the I/O operation being aborted. In other words, this is an expected outcome.
Getting back to CredSSP, it may pay to check that it hasn't been disabled by mechanics such as Group Policy, Intune, System Center Configuration Manager, etc. first, otherwise, you won't be able to use it.
Assuming it hasn't been disabled, then the following commandlet has all the examples you need to enable it on both sides, where the computer making the outbound call is the client and the remote server on which the command is being run is the server - it has nothing to do with the operating system being Windows Servervs. 10, 11, etc.
Cheers,
Lain
- MBeeAug 20, 2025Copper Contributor
Hi, LainRobertson.
Thank you very much for the response!
I've been reluctant to use those methods and just tried a few articles like the aforementioned one that states "solve the double-hop" issue and followed blindly., but couldn't get the commands to work.
I will try
- Kerberos constrained delegation;
- Enabling and using CredSSP;
as suggested.
Thank you!
- LainRobertsonAug 20, 2025Silver Contributor
Hi MBee,
Between Kerberos constrained and CredSSP, you will find CredSSP easier to implement and maintain.
If your jump host (the server in the middle) is going to talk to a lot of constantly changing remote servers, you might want to just run with the CredSSP approach.
Kerberos constrained is more secure than CredSSP but you might find the ongoing administration overwhelming.
The only point I wanted to make in my original reply is that the 4sysops article is the least secure option of all three. So, even if you settle on CredSSP instead of Kerberos constrained delegation, at least it's a more secure option than what's in that article.
Cheers,
Lain