Enable CredSSP from a Windows 7 Home Client

While I do have a Win 7 Pro license, pure laziness has kept me from installing it on my Alienware laptop. This is fine for most things, but I ran into a bit of a problem while writing the Active Directory chapter for the PowerShell Bible. In order to use the ActiveDirectory module via remoting on my 2k8r2 server I needed to use CredSSP as my authentication type. Step one was easy. Launch PowerShell as an admin and run:

Enable-WSManCredSSP -Role client -DelegateComputer server1.home.toenuff.com

Now, if you’ve ever run this before you are probably familiar with the next error message that will return if you try and run Enter-PSSession or Invoke-Command with -Authentication CredSSP:

Enter-PSSession : Connecting to remote server failed with the following error message : The 
WinRM client cannot process the request. A computer policy does not allow the delegation of 
the user credentials to the target computer. Use gpedit.msc and look at the following policy
: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> 
Allow Delegating Fresh Credentials. Verify that it is enabled and configured with an SPN ap
propriate for the target computer. For example, for a target computer name "myserver.domain.
com", the SPN can be one of the following: WSMAN/myserver.domain.com or WSMAN/*.domain.com. 
For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:16
+ Enter-PSSession <<<< -Credential $cred server1 -Authentication credssp
 + CategoryInfo : InvalidArgument: (server1:String) [Enter-PSSession], PSRemoti 
 ngTransportException
 + FullyQualifiedErrorId : CreateRemoteRunspaceFailed

In most versions of Windows you can then follow the instructions in the error message which tell you explicitly how to handle this, but with a home version of Windows this is a bit of a problem because there is no gpedit.msc snapin or local policy to modify. Fortunately, we know that every policy is really just a registry setting. I was able to track it down specifically:

• Create a Dword key called AllowFreshCredentials with a value of 1 in hklm:\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation
• Create a separate String entry for each computer in hklm:\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowFreshCredentials
• Each entry within the AllowFreshCredentials key should be named an integer, and the first entry should be 1

Strangely, the above fix used to work for me, however, recently a new error started appearing that talked about another local policy.  I thought this was related to SP1, but I’ve been told by others that this has existed for some time.   This additional local policy has to be set in order to allow CredSSP to use NTLM authentication instead of Kerberos.  The fix is the exact same as the above except that the AllowFreshCredentials name also has AllowFreshCredentialsWhenNTLMOnly.

The following script will do both of these registry changes for you.  Mind you, it doesn’t handle entries already in the AllowFreshCredentials or AllowFreshCredentialsWhenNTLMOnly key, but you could easily handle that if it was a concern you had:

$allowed = @('WSMAN/*.home.toenuff.com','WSMAN/server1')            

$key = 'hklm:\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation'
if (!(Test-Path $key)) {
    md $key
}
New-ItemProperty -Path $key -Name AllowFreshCredentials -Value 1 -PropertyType Dword -Force            

$key = Join-Path $key 'AllowFreshCredentials'
if (!(Test-Path $key)) {
    md $key
}
$i = 1
$allowed |% {
    # Script does not take into account existing entries in this key
    New-ItemProperty -Path $key -Name $i -Value $_ -PropertyType String -Force
    $i++
}