PowerShell Remoting Security - Second Hop without CredSSP

Hi All,

I am looking to enable PowerShell Remoting in my new company and have always previously just enabled CredSSP to resolve the Second Hop issue.
However, on this occasion, I have had to investigate further and came across some interesting information regarding the security concerns with CredSSP, especially when using it to connect to Workstations, which as domain joined but are not always as trusted as servers.

I then came across a Presentation from Lee Holmes where he addresses this with the two potential options:

–Update the permissions on the remote resource (i.e.: file server) to grant access to the machine account of the remoting host rather than the users.


–Provide explicit credentials to remote resources. For example, New-PSDrive \FileServer\Share –Credential (…), or net use \FileServer\Share

I thought that this was an interesting solution and would be a quick fix.
I was expecting to create a DFS Share and add permissions for domain computers to have access to it.
Then host scripts, logs and software on this share to allow access to PS Remoting sessions.

This does not seem to work, even when adding the ANONYMOUS USER to the permissions.

I then came across a method that creates a Custom PSSessionConfiguration and sets a RunAsUser and stores the password.
This can then be using when initiating the PS Remoting session and does seem to eliminate the Second Hop issue.

Does anyone have any suggestions to this topic as the CredSSP appears to create a significant security vulnerability.
I understand that I can add security to only allow delegation by computers that are *.domain.local etc. But I still see this being an issue when accessing work stations.

I have scoured Google, but am flooded with the basics.

Would love to hear some creative ideas!


When you’re crossing domain boundaries, there aren’t any great options - custom PSSessionConfigurations probably being the best of the lot. You can also look into configuring Kerberos delegation in AD - but obviously, only within a domain, and it’s a domain-wide thing, so it’s not super-granular.

i struggled with this for a long time a couple of years ago also, and as you say most of what is around is basics & points you back in the direction. So far i have just continued to use CredSSP, can you post a link to the custom PSSession stuf you found, would mind a read


Hi Don,

Appreciate your input on this!

We are not actually crossing domain boundaries - this is purely PS remoting to domain joined PCs and Servers all in one domain.

Regarding the Kerberos Delegation, am I correct in thinking that this would have to be done domain wide to allow all PCs and Servers to delegate my credentials?

@Mark, see below for the link to the article I used.
To summarize, I ran the following:

Register-PSSessionConfiguration -Name Remoting -RunAsCredential domain\remotinguser

This then prompts for a password, which is then stored as a secure string.
I was also not entirely sure if this was safe/secure…

I just feel like this might be better than passing the Hash of my own account that has local admin permissions to servers and workstation, plus other permissions.

Then to use it, run the following:

Enter-PSSession -ComputerName DC -ConfigurationName Remoting


Or am I just over complicating this and should trust CredSSP with the Trusted hosts setting of *.domain.local ?




I also ran into the double hop problem when setting up PowerShell Web Access. I ended up using the same solution as you did, with making a separate config for our admins to use RunAsCredential with. The only annoying thing with this is that they need to update the PSSessionConfiguration every time they change their password.

Do you have the Windows Remote Management Framework on your servers? I am able to do an enter-pssession to other servers without entering a config name or credential while logged in with domain account. You may just need to setup your main admin server as a TrustedHost

Try this for solving the double hop issue securely:

Ashley McGlone

Thank you very much for the notice Ashley!
I don’t think we are quite ready with the 2012 domain controllers, but nice to know there are some good workarounds out there! :slight_smile: