How to enable CredSSP

Question

I am trying to use the -Authentication CredSSP switch when entering with PowerShell (2.0) in order to remotely launch a Script that can write to files or set up new PSDrives.

I get an error when I invoke Enter-PSSession with CredSSP, saying that the target computer is not approved.

I Enabled CredSSP as server on the target computer and as a client on the computer that executes the New-PSSession, with delegate computer set to *.

We are in a domain, the DC runs Windows Server 2008 R2, clients run Windows 7.

In AD, both stations are approved when I look at Properties->Delegation.

I also opened gpedit and activated the delegation specifiying the target computer name.

Here is the error message (French):

La connexion au serveur distant a échoué avec le message d'erreur suivant : Le client WinRM ne peut pas traiter la demande. Une stratégie d'ordinateur ne permet pas la délégation des informations d'identification de l'utilisateur à l'ordinateur cible car ce dernier n'est pas approuvé. L'identité de l'ordinateur cible ne peut pas être vérifiée si vous configurez le service WSMAN pour utiliser un certificat valide à l'aide de la commande suivante : winrm set winrm/config/service '@{CertificateThumbprint="<thumbprint>"}' Sinon, vous ouvez rechercher dans l'Observateur d'événements un événement qui spécifie que le SPN suivant n'a pas pu être créé : WSMAN/<computerFQDN>. Si vous trouvez cet événement, vous pouvez manuellement créer le SPN à l'aide de setspn.exe. Si le SPN existe, mais que CredSSP ne peut pas utiliser Kerberos pour valider l'identité de l'ordinateur cible et si vous souhaitez toujours autoriser la délégation des informations d'identification de l'utilisateur à l'ordinateur cible, utilisez gpedit.msc et examinez la stratégie sui vante : Configuration de l'ordinateur -> Modèles d'administration -> Système -> Délégation d'informations d'identification -> Autoriser les nouvelles informations d'identification avec l'authentification du serveur NTLM uniquement. Vérifiez qu'elle est activée et configurée avec un SPN approprié pour l'ordinateur cible. Par exemple, pour le nom d'ordinateur cible « monserveur.domaine.com », le SPN peut être : WSMAN/monserveur.domaine.com ou WSMAN/*.domaine.com. Renouvelez la demande après ces modifications. Pour plus d'informations, voir la rubrique d'aide bout_Remote_Troubleshooting. + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc eption + FullyQualifiedErrorId : PSSessionOpenFailed

What are the others parameters that can prevent CredSSP ?

Edit: Ok so I have a temporary workaround for mounting a drive on a remote PSSession where CredSSP is not allowed. I use the

net use X: \\xxx.xxx.xxx.xxx /user:username password

syntax when I'm on the remote session (i.e. not the New-PSDrive cmdlet). This seems to work fine, even with the Invoke-Command on a remote Computer.

But still need to enable CredSSP, that would prevent me from hardcoding credentials...

Answer 1

There is a bug in PowerShell 2.0 (fixed in PS 3.0): FileSystem Provider should support credentials

It's not possible to supply alternate credentials when using any cmdlets with the FileSystem provider. Even New-PSDrive, which accepts a -Credentials parameter, won't accept it with the FileSystem provider.

The bottom line here is that the ancient NET USE command has more power than PowerShell's New-PSDrive ...

So if you're stuck with PS 2.0, there is no way (AFAIK) to force New-PSDrive cmdlet to use credentials. Workarounds exist, but they all use hardcoded crdentials:

Net use (as you already did):

net use X: \xxx.xxx.xxx.xxx /user:username password

or

Wscript:

$net = new-object -ComObject WScript.Network
$net.MapNetworkDrive("X:", "\\server\share", $false, "domain\user", "password")