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

10

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!

Michael Sorens
quelle
Noch ein verrücktes Beispiel dafür, wie MS Dinge ändert, um sie zu ändern !! Ich bin nicht an Live-Migration oder Ähnlichem interessiert. Ich möchte mich nur bei den 3 Hyper-V 2012-Servern anmelden können, auf denen ich VMs erstellen / löschen / starten / stoppen / neu starten kann. Es hat perfekt funktioniert Mein WIn7-Desktop, jetzt bin ich auf Win 10 und ich muss durch die Reifen nach links und in der Mitte springen, um etwas zu tun, was vorher einfach war. Windows 10 macht mich derzeit blutig wahnsinnig: - /
shawty

Antworten:

8

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!

Michael Sorens
quelle
CredSSP ist eine gute Lösung? Microsoft sagt: Achtung: Die CredSSP-Authentifizierung (Credential Security Service Provider), bei der die Anmeldeinformationen des Benutzers zur Authentifizierung an einen Remotecomputer übergeben werden, ist für Befehle konzipiert, die eine Authentifizierung für mehr als eine Ressource erfordern, z. B. den Zugriff auf eine Remotenetzwerkfreigabe. Dieser Mechanismus erhöht das Sicherheitsrisiko der Fernbedienung. Wenn der Remotecomputer gefährdet ist, können die an ihn übergebenen Anmeldeinformationen zur Steuerung der Netzwerksitzung verwendet werden.
Kiquenet
2

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.

jbsmith
quelle
Vielen Dank für den Vorschlag, aber es schlug immer noch mit dem gleichen Ergebnis fehl.
Michael Sorens
Ich bin mir nicht sicher, ob dies einen Unterschied macht, aber mein ursprünglicher Beitrag war möglicherweise irreführend. Ich habe alle diese Befehle von der CLIENT- Maschine ausgeführt. So „$ Computer“ in dem zweiten Codeblock war oben der Name des Servers , dass ich zu verbinden versuche TO .
jbsmith
Ich hatte das etwas herausgefunden, weil es keinen Sinn machte, dass der Server von vornherein über die Clients Bescheid wissen musste. Ich habe die gesamte Sequenz nur noch einmal wiederholt, um sicherzugehen, und sie schlägt mit demselben Fehler fehl. Eine weitere Variante: Ich habe den Parameter -Authentication weggelassen und bestätigt, dass alles andere in meiner Anweisung funktioniert ( Invoke-Command { Write-Host "hello, world" } -computername $serverName -credential $testCred). Die CredSSP-Authentifizierung ist also ausschließlich das Problem.
Michael Sorens
Einverstanden - grundlegendes WinRM ist in Ordnung; Ich weiß nicht genau, worum es geht, aber ich vermute, dass dies mit der Richtlinie "Neue Anmeldeinformationen zulassen" und dem von Ihnen eingerichteten SPN zusammenhängt. Ich würde mir diese Richtlinieneinstellung genauer ansehen und vielleicht etwas tiefer gehen, um sicherzustellen, dass Ihr Kerberos richtig funktioniert. Dieser Link scheint
jbsmith
Warum Connect-WSMan to Server verwenden, besser enable-wsmancredssp -role Server verwenden, nicht wahr?
Kiquenet
1

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.

Bruce
quelle
Die Registrierungsbaumkopie funktionierte auch für mich. hklm: \ SOFTWARE \ ... \ CredentialsDelegation-Knoten war nicht vorhanden, der Wert wurde in hklm: \ SOFTWARE \ Wow6432Node \ ... \ CredentialsDelegation und in HKEY_USERS \ ... \ Group Policy Objects \ ... \ CredentialDelegation gespeichert.
Der_Meister