1

I have two machines A and B.

both have: psremoting enabled, credssp enables as both client and server.

from machine A I can create a new pssession to B with -Authentication credssp

from machine B I can create a new pssession to A with -Authentication credssp

Everything is working fine at this point. My problem is that I have a script that will run on computer A and start a new pssession on both A and B and move some files around (sharepoint stuffs that's a totally different matter). The script I have written was originally run from an external computer and so it has code that remotes into both systems. But now the script is being run from computer A and for the life of me I cannot get credssp to work on localhost.

I have tried setting -delegatecomputer (for enable-wsmancredssp -role client) and -computername (for new-pssession -authentication credssp) to any of . , localhost , or 127.0.0.1. None of those has allowed me to start a new pssession from computer A back to computer A.

So the core of my question is:

  1. Can you delegate credssp credentials to localhost?
  2. if not is there a way to create a pssession that will allow me to still log in to sharepoint within that session (i.e. pass credentials further)?
  3. Worst case: I'll have to rewrite my script.

1 Answer 1

1

Connecting to the local computer should work just fine. However, just making a quick attempt myself, I had to use the computer name of the local computer to be able to connect, instead of localhost (guessing this has to do with NTLM vs Kerberos). So running the following commands (on a Windows Server 2008 R2 computer with PowerShell 2) forked fine for me:

Enable-WSManCredSSP -Role Server
Enable-WSManCredSSP -Role Client -DelegateComputer MyComputerNameHere
$session = New-PSSession -ComputerName MyComputerNameHere -Authentication Credssp -Credential (Get-Credential)

To get it to work on a non-domain-joined computer (on a Windows 8.1 computer with PowerShell 4), however, I had to also make a group policy change (which was mentioned in the error message provided). The configuration I needed to make was to Enable the Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials with NTLM-only Server Authentication configuration and also add the computer name to the computer name list in that policy. After that change, the above code worked just fine even on a non-domain-joined computer.

3
  • Thanks for your help! This worked on my workstation, but not on the server. But editing the policy was the right move. I ended up allowing delegation to all machines in my domain (wsman/*.domain.com) and that fixed it. (run gpedit.msc to get to these setting for future searchers) Jan 7, 2014 at 16:23
  • Is it possible to configure the "Allow Delegating Fresh Credentials with NTLM-only Server Authentication" setting from a command line? It's unfortunate that Enable-WSManCredSSP doesn't cover this itself, instead adding the DelegatedComputer parameter only to "Allow Delegating Fresh Credentials."
    – bwerks
    Feb 7, 2014 at 18:06
  • I'm guessing it is setting some registry keys, so you could use SysInternals Process Monitor to verify which registry keys are being set and set those manually. Of course, always be careful when editing the registry. Feb 9, 2014 at 8:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .