Impossible d'obtenir l'authentification CredSSP pour fonctionner dans PowerShell

En tentant de créer un script PowerShell à l'aide de l'accès à distance, je suis tombé sur ce que je crois être le problème du double saut . Dans cet article, Perriman donne une description succincte du problème ainsi que les étapes spécifiques pour résoudre le problème (presque trivial si vous connaissez les commandes, mais pour quelqu'un moins familier comme moi, cette information était inestimable!).

J'ai couru Enable-WSManCredSSP Serversur mon serveur Win7 sans incident, mais la tentative d'exécution Enable-WSManCredSSP Client –DelegateComputer <FQDN of the server>sur mon client Win7 a généré cette erreur:

Enable-WSManCredSSP : The client cannot connect to the destination specified
in the request. Verify that the service on the destination is running and
is accepting requests.
Consult the logs and documentation for the WS-Management service running
on the destination, most commonly IIS or WinRM. If the destination
is the WinRM service, run the following com mand on the destination
to analyze and configure the WinRM service: "winrm quickconfig".

L'exécution de winrm quickconfig a confirmé que mon serveur exécutait WinRM:

WinRM already is set up to receive requests on this machine.
WinRM already is set up for remote management on this machine.

Et Get-WSManCredSSP a confirmé que mon serveur était prêt à accepter les informations d'identification d'un client:

The machine is not configured to allow delegating fresh credentials.
This computer is configured to receive credentials from a remote client computer.

J'ai également trouvé l' article de Boessen sur WinRM dans lequel il décrit la configuration générale de WinRM et a trouvé une friandise pour obtenir un point de données utile dans le diagnostic; cette commande exécutée sur le client utilise l' outil winrs pour accéder à distance au serveur:

winrs -r:http://<FQDN of my server>:5985 -u:<myDomain>\msorens "dir c:\"

Cette commande a renvoyé le résultat attendu, le contenu du répertoire racine sur le serveur, sans incident, confirmant que mon nom de domaine complet est correct et que WinRM est activé.

Boessen indique que le port 5985 est la valeur par défaut pour Win7; cette commande exécutée sur le serveur confirme une valeur de 5985:

get-item wsman:\localhost\listener\listener*\port

La question: pourquoi ne puis-je pas exécuter la commande Enable-WSManCredSSP côté client?

2011.06.07 Mise à jour

J'ai trouvé une solution à la question ci-dessus: invoquer Enable-PSRemoting , annoncé pour configurer un ordinateur pour recevoir des commandes à distance, a permis à Enable-WSManCredSSP sur le client de fonctionner correctement! Curieux, mais sa page de manuel indique qu'il fait un certain nombre d'actions différentes, donc je suppose que l'un d'eux a fait par inadvertance ce dont j'avais besoin.

Mais j'ai atteint un autre barrage routier lorsque j'ai essayé d'utiliser l'authentification CredSSP. Voici la commande:

Invoke-Command { Write-Host "hello, world" } -computername $serverName `
-credential $testCred  -Authentication Credssp

Et voici la réponse:

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 informatique ne permet pas
la délégation des informations d'identification de l'utilisateur à l'ordinateur cible. Utilisez gpedit.msc
et regardez la stratégie suivante: Configuration de l'ordinateur
-> Modèles d'administration -> Système -> Délégation des informations d'identification
-> Autoriser la délégation de nouveaux pouvoirs. Vérifiez qu'il est activé et
configuré avec un SPN approprié pour l'ordinateur cible. Par exemple,
pour un nom d'ordinateur cible "myserver.domain.com", le SPN peut être l'un des
les éléments suivants: WSMAN /myserver.domain.com ou WSMAN / *. domain.com.
Pour plus d'informations, consultez la rubrique d'aide about_Remote_Troubleshooting.

J'ai vérifié les paramètres exactement comme ce message d'erreur remarquablement utile l'a suggéré, et il me semble qu'il est correctement configuré.

La nouvelle question: qu'est-ce que cette tentative de connexion à distance avec CredSSP échoue?

En répondant, veuillez garder à l'esprit ce qui suit: Permettez-moi de dissiper à l'avance toute idée que je sais ce que je fais ici, malgré toute apparence contraire. :-) L'administrateur Windows n'est pas mon domaine d'expertise!

J'y suis revenu après un bref hiatus pour regarder à nouveau avec des yeux frais (les miens et un collègue) et j'ai décidé de revenir à l'essentiel:

Sur le client que j'ai exécuté (dans le shell administrateur):

enable-wsmancredssp -role client -delegatecomputer devremvm03 -force

Sur le serveur que j'ai exécuté (en shell administrateur):

enable-wsmancredssp -role server -force

Les deux ont renvoyé une sortie normale indiquant que CredSSP était désormais "vrai".

J'ai ensuite utilisé le code d'exercice suivant pour parcourir des niveaux de complexité croissants:

$block = {
  Write-Host ("hello, world: {0}, {1}" -f $env:USERNAME, (hostname))
}
$username = "test_user"
$password = "..."   
$adjPwd = $password | ConvertTo-SecureString -asPlainText -Force
$testCred = (New-Object System.Management.Automation.PSCredential($username,$adjPwd))    

switch ($choice)
{
  "basic"       { Invoke-Command $block }
  "remote"      { Invoke-Command $block -computername $serverName }
  "credentialA" { Invoke-Command $block -computername $serverName -credential $testCred  }
  "credentialB" { Invoke-Command $block -computername $serverName -credential $testCred  -Authentication Credssp}
  "session"     { 
      $testSession = New-PSSession -computername $serverName -credential $testCred -Authentication Credssp
      if ($testSession) { Invoke-Command $block -Session $testSession; Remove-PSSession $testSession }
      }
}

Tout cela est dans mon script run.ps1, donc la transcription s'est déroulée comme suit (et cela a fonctionné dans un shell non administrateur):

PS C:\> .\run.ps1 basic
hello, world: msorens, MyLocalMachine
PS C:\> .\run.ps1 remote MyRemoteServer
hello, world: msorens, MyRemoteServer
PS C:\> .\run.ps1 credentialA MyRemoteServer
hello, world: test_user, MyRemoteServer
PS C:\> .\run.ps1 credentialB MyRemoteServer
hello, world: test_user, MyRemoteServer
PS C:\> .\run.ps1 session MyRemoteServer
hello, world: test_user, MyRemoteServer

Auparavant, seules les fonctionnalités de base, distantes et d'identificationA fonctionnaient. Maintenant, tous les 5 fonctionnent. Ouf!

Quand j'ai dû le faire, c'est ce que j'ai fait pour le faire fonctionner (il y avait peut-être aussi des paramètres GPO, mais il semble que vous les ayez couverts).

Pour permettre au CLIENT d'utiliser CredSSP pour se connecter à n'importe quelle machine du domaine:

Enable-WSManCredSSP -Role Client -DelegateComputer "*.my.domain.com" -Force | out-null
#the following is used because -delegatecomputer (above) doesn't appear to actually work properly.
Set-ItemProperty HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowFreshCredentialsDomain -Name WSMan -Value "WSMAN/*.my.domain.com"

Ensuite, j'ai exécuté ce qui suit sur chaque machine cible (serveur) pour activer l'authentification CredSSP:

Connect-WSMan -ComputerName $computer 
Set-Item "WSMAN:\$computer\service\auth\credssp" -Value $true 

Bien sûr, cela nécessite que vous exécutiez le script avec les autorisations appropriées. Cela a fonctionné pour moi - j'espère que cela vous aide.

J'ai réussi à migrer une machine virtuelle d'un serveur hyper-v 2012R2 vers un autre, mais je n'ai pas pu la migrer. (J'essaie d'utiliser SAMBA 4.2 comme contrôleur de domaine et je voulais voir si je pouvais migrer en direct avec CredSSP car je ne pouvais pas utiliser la délégation contrainte avec Samba4).

En fin de compte, je suis allé à l'hyper-v fonctionnel et j'ai copié les entrées de registre à hklm: \ SOFTWARE \ Policies \ Microsoft \ Windows \ CredentialsDelegation vers l'hyper-v qui ne fonctionne pas. A bien fonctionné dans les deux sens après cela.