Die CredSSP-Authentifizierung kann in PowerShell nicht ausgeführt werden

Beim Versuch, ein PowerShell-Skript mithilfe von Remoting zu erstellen, stieß ich auf das Double-Hop-Problem . In diesem Artikel gibt Perriman eine kurze Beschreibung des Problems sowie die spezifischen Schritte zur Behebung des Problems (fast trivial, wenn Sie die Befehle kennen, aber für jemanden, der weniger vertraut ist wie ich, waren diese Informationen von unschätzbarem Wert!).

Ich Enable-WSManCredSSP Serverhabe ohne Zwischenfall auf meinem Win7-Server ausgeführt, aber der Versuch, Enable-WSManCredSSP Client –DelegateComputer <FQDN of the server>auf meinem Win7-Client ausgeführt zu werden, hat diesen Fehler generiert:

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".

Durch Ausführen von winrm quickconfig wurde bestätigt, dass auf meinem Server WinRM ausgeführt wurde:

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

Und Get-WSManCredSSP bestätigte, dass mein Server bereit war, Anmeldeinformationen von einem Client zu akzeptieren:

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

Ich fand auch Boessens Artikel über WinRM, in dem er das allgemeine WinRM-Setup beschreibt und einen Leckerbissen fand, um einen nützlichen Datenpunkt für die Diagnose zu erhalten. Dieser auf dem Client ausgeführte Befehl verwendet das Tool winrs , um remote auf den Server zuzugreifen:

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

Dieser Befehl gab das erwartete Ergebnis, den Inhalt des Stammverzeichnisses auf dem Server, ohne Zwischenfälle zurück und bestätigte, dass mein FQDN korrekt und WinRM aktiviert ist.

Boessen gibt an, dass Port 5985 die Standardeinstellung für Win7 ist. Dieser auf dem Server ausgeführte Befehl bestätigt den Wert 5985:

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

Die Frage: Warum kann ich den Befehl Enable-WSManCredSSP auf der Clientseite nicht ausführen?

2011.06.07 Update

Ich habe eine Lösung für die obige Frage gefunden: Durch das Aufrufen von Enable-PSRemoting , das zum Konfigurieren eines Computers zum Empfangen von Remotebefehlen angekündigt wurde , konnte Enable-WSManCredSSP auf dem Client erfolgreich ausgeführt werden! Neugierig, aber seine Manpage zeigt an, dass es eine Reihe verschiedener Aktionen ausführt, also gehe ich davon aus, dass einer von denen versehentlich das getan hat, was ich brauchte.

Aber dann erreichte ich eine andere Straßensperre, als ich versuchte, die CredSSP-Authentifizierung zu verwenden. Hier ist der Befehl:

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

Und hier ist die Antwort:

Die Verbindung zum Remote-Server ist mit der folgenden Fehlermeldung fehlgeschlagen:
Der WinRM-Client kann die Anforderung nicht verarbeiten. Eine Computerrichtlinie erlaubt dies nicht
die Delegierung der Benutzeranmeldeinformationen an den Zielcomputer. Verwenden Sie gpedit.msc
Beachten Sie die folgenden Richtlinien: Computerkonfiguration
-> Administrative Vorlagen -> System -> Delegierung von Anmeldeinformationen
-> Erlaube das Delegieren neuer Anmeldeinformationen. Stellen Sie sicher, dass es aktiviert ist und
konfiguriert mit einem für den Zielcomputer geeigneten SPN. Zum Beispiel,
Für einen Zielcomputernamen "myserver.domain.com" kann der SPN einer von sein
Folgendes: WSMAN /myserver.domain.com oder WSMAN / *. domain.com.
Weitere Informationen finden Sie im Hilfethema about_Remote_Troubleshooter.

Ich habe die Einstellungen überprüft, wie in dieser bemerkenswert hilfreichen Fehlermeldung vorgeschlagen, und es sieht für mich so aus, als ob sie richtig konfiguriert sind.

Die neue Frage: Was schlägt dieser Remoteverbindungsversuch mit CredSSP fehl?

Beachten Sie bei der Beantwortung bitte Folgendes: Lassen Sie mich im Voraus jede Vorstellung zerstreuen, dass ich weiß, was ich hier tue, ungeachtet gegenteiliger Erscheinungen. :-) Windows-Administrator ist nicht mein Fachgebiet!

Nach einer kurzen Pause kam ich darauf zurück, um noch einmal mit neuen Augen zu schauen (sowohl meine als auch eine Mitarbeiterin), und beschloss, noch einmal auf die Grundlagen zurückzukommen:

Auf dem Client, den ich ausgeführt habe (in der Administrator-Shell):

enable-wsmancredssp -role client -delegatecomputer devremvm03 -force

Auf dem Server, den ich ausgeführt habe (in der Administrator-Shell):

enable-wsmancredssp -role server -force

Beide gaben die normale Ausgabe zurück, was darauf hinweist, dass CredSSP jetzt "true" ist.

Ich habe dann den folgenden Übungscode verwendet, um durch die zunehmende Komplexität zu gehen:

$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 }
      }
}

All das befindet sich in meinem Skript run.ps1, sodass das Transkript wie folgt ablief (und dies in einer Nicht- Administrator-Shell ausgeführt wurde):

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

Bisher funktionierten nur Basic, Remote und CredentialA. Jetzt arbeiten alle 5. Wütend!

Als ich dies tun musste, habe ich Folgendes getan, um es zum Laufen zu bringen (möglicherweise gab es auch einige GPO-Einstellungen, aber es sieht so aus, als hätten Sie diese abgedeckt).

So aktivieren Sie, dass der CLIENT CredSSP verwendet, um eine Verbindung zu einem beliebigen Computer in der Domäne herzustellen:

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"

Anschließend habe ich auf jedem Zielcomputer (Server) Folgendes ausgeführt, um die CredSSP-Authentifizierung zu aktivieren:

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

Dies setzt natürlich voraus, dass Sie das Skript mit den entsprechenden Berechtigungen ausführen. Das hat bei mir funktioniert - ich hoffe es hilft dir weiter.

Ich habe festgestellt, wo ich eine VM live von einem Hyper-V 2012R2-Server auf einen anderen migrieren kann, konnte sie jedoch nicht zurück migrieren. (Ich versuche, SAMBA 4.2 als Domänencontroller zu verwenden, und wollte wissen, ob ich mit CredSSP live migrieren kann, da ich mit Samba4 keine eingeschränkte Delegierung verwenden kann.)

Letztendlich ging ich zum funktionierenden Hyper-V und kopierte die Registrierungseinträge unter hklm: \ SOFTWARE \ Policies \ Microsoft \ Windows \ CredentialsDelegation in das nicht funktionierende Hyper-V. Hat danach in beide Richtungen gut funktioniert.