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


10

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!


Encore un autre exemple exaspérant de la SEP changer les choses pour le changer !! Je ne suis pas intéressé par la migration en direct ou quelque chose comme ça, je veux juste pouvoir me connecter aux 3 serveurs Hyper-V 2012 que j'ai et créer / supprimer / démarrer / arrêter / redémarrer des machines virtuelles sur eux, cela a parfaitement fonctionné à partir de mon bureau WIn7, maintenant je suis sur win 10 et je dois sauter à travers les cercles à gauche et au centre pour faire quelque chose qui était simple à faire auparavant, Windows 10 me rend actuellement complètement fou: - /
shawty

Réponses:


8

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!


CredSSP est une bonne solution? Microsoft dit: Attention: l'authentification Credential Security Service Provider (CredSSP), dans laquelle les informations d'identification de l'utilisateur sont transmises à un ordinateur distant pour être authentifié, est conçue pour les commandes qui nécessitent une authentification sur plusieurs ressources, telles que l'accès à un partage réseau distant. Ce mécanisme augmente le risque de sécurité de l'opération à distance. Si l'ordinateur distant est compromis, les informations d'identification qui lui sont transmises peuvent être utilisées pour contrôler la session réseau.
Kiquenet

2

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.


Merci pour la suggestion mais elle a toujours échoué avec le même résultat.
Michael Sorens

Je ne sais pas si cela fait une différence, mais mon message d'origine peut avoir été trompeur. J'ai exécuté toutes ces commandes à partir de la machine CLIENT . Donc , « $ ordinateur » dans le deuxième bloc de code était au- dessus du nom du serveur que je tentais de se connecter TO .
jbsmith le

J'avais quelque peu compris cela parce que cela n'avait pas de sens que le serveur devait avoir une connaissance a priori des clients. Je viens de relancer toute la séquence pour être sûr, cependant, et cela échoue avec la même erreur. Une autre variante: j'ai omis le paramètre -Authentication et confirmé que tout le reste dans ma déclaration fonctionne ( Invoke-Command { Write-Host "hello, world" } -computername $serverName -credential $testCred). L'authentification CredSSP est donc strictement le problème.
Michael Sorens

D'accord - WinRM de base est très bien; Je ne sais pas quel est le problème exact, mais je pense qu'il est lié à la politique «autoriser les nouvelles informations d'identification» et au SPN que vous avez configuré. Je regarderais de plus près ce paramètre de politique et creuserais peut-être un peu plus profondément pour vous assurer que vos kerberos fonctionnent correctement. Ce lien semble utile: [link] msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx
jbsmith

Pourquoi utiliser Connect-WSMan to Server, mieux utiliser le serveur enable-wsmancredssp -role, n'est-ce pas?
Kiquenet

1

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.


La copie de l'arborescence du registre a également fonctionné pour moi. hklm: \ SOFTWARE \ ... \ CredentialsDelegation n'existe pas, la valeur a été stockée dans hklm: \ SOFTWARE \ Wow6432Node \ ... \ CredentialsDelegation et dans HKEY_USERS \ ... \ Group Policy Objects \ ... \ CredentialDelegation.
Der_Meister
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.