Nie można uzyskać uwierzytelnienia CredSSP w programie PowerShell

Podczas próby utworzenia skryptu PowerShell przy użyciu narzędzia do zdalnej obsługi natrafiłem na problem związany z podwójnym przeskokiem . W tym artykule Perriman podaje zwięzły opis problemu, a także konkretne kroki w celu rozwiązania problemu (prawie banalne, jeśli znasz polecenia, ale dla kogoś mniej znanego jak ja, ta informacja była bezcenna!).

Uruchomiłem Enable-WSManCredSSP Serverna moim serwerze Win7 bez incydentów, ale próba uruchomienia Enable-WSManCredSSP Client –DelegateComputer <FQDN of the server>na moim kliencie Win7 wygenerowała ten błąd:

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

Uruchamianie programu WinRM Quickconfig potwierdziło, że na moim serwerze działa WinRM:

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

I Get-WSManCredSSP potwierdził, że mój serwer jest gotowy do zaakceptowania poświadczeń od klienta:

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

Znalazłem również artykuł Boessena na temat WinRM, w którym opisuje on ogólną konfigurację WinRM i znalazłem jeden smakołyk, aby uzyskać użyteczny punkt danych w diagnozie; to polecenie uruchomione na kliencie używa narzędzia winrs do zdalnego dostępu do serwera:

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

To polecenie zwróciło oczekiwany wynik, zawartość katalogu głównego na serwerze, bez incydentów, potwierdzając, że moja nazwa FQDN jest poprawna i że WinRM jest włączony.

Boessen wskazuje, że port 5985 jest domyślny dla Win7; to polecenie uruchomione na serwerze potwierdza wartość 5985:

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

Pytanie: Dlaczego nie mogę wykonać polecenia Enable-WSManCredSSP po stronie klienta?

Aktualizacja 2011.06.07

Znalazłem rozwiązanie na powyższe pytanie: wywołanie Enable-PSRemoting , reklamowane w celu skonfigurowania komputera do odbierania poleceń zdalnych, pozwoliło Enable-WSManCredSSP na kliencie na pomyślne działanie! Ciekawe, ale jego strona podręcznika wskazuje, że wykonuje wiele różnych działań, więc zakładam, że jedna z nich przypadkowo zrobiła to, czego potrzebowałem.

Ale potem doszedłem do kolejnej blokady, gdy próbowałem użyć uwierzytelnienia CredSSP. Oto polecenie:

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

A oto odpowiedź:

Połączenie ze zdalnym serwerem nie powiodło się z powodu następującego komunikatu o błędzie:
Klient WinRM nie może przetworzyć żądania. Zasady komputera nie zezwalają
delegowanie poświadczeń użytkownika na komputer docelowy. Użyj gpedit.msc
i spójrz na następujące zasady: Konfiguracja komputera
-> Szablony administracyjne -> System -> Delegacja poświadczeń
-> Zezwól na delegowanie świeżych poświadczeń. Sprawdź, czy jest włączony i
skonfigurowany z SPN odpowiednią dla komputera docelowego. Na przykład,
dla nazwy komputera docelowego „myserver.domain.com” SPN może być jedną z
następujące: WSMAN /myserver.domain.com lub WSMAN / *. domain.com.
Więcej informacji można znaleźć w temacie pomocy about_Remote_Trou Rozwiązywanie problemów.

Ustawienia zweryfikowałem tak, jak sugerował ten niezwykle pomocny komunikat o błędzie, i wygląda na to, że jest poprawnie skonfigurowany.

Nowe pytanie: co próba tego zdalnego połączenia z CredSSP kończy się niepowodzeniem?

Odpowiadając, proszę pamiętać o następujących kwestiach: Pozwólcie mi z góry wyjaśnić, że wiem, co tu robię, niezależnie od tego, co się wydaje przeciwnie :-) Administrator systemu Windows nie jest moim obszarem specjalizacji!

Wróciłem do tego po krótkiej przerwie, by spojrzeć ponownie świeżymi oczami (zarówno moje, jak i współpracownika) i postanowiłem wrócić do podstaw:

Na kliencie wykonałem (w powłoce administratora):

enable-wsmancredssp -role client -delegatecomputer devremvm03 -force

Na serwerze wykonałem (w powłoce administratora):

enable-wsmancredssp -role server -force

Oba zwróciły normalne wyjście wskazujące, że CredSSP było teraz „prawdziwe”.

Następnie użyłem następującego kodu ćwiczącego, aby przejść przez rosnący poziom złożoności:

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

Wszystko to znajduje się w moim skrypcie run.ps1, więc transkrypt przebiegał w następujący sposób (i działał w powłoce innej niż administrator):

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

Wcześniej działały tylko podstawowe, zdalne i referencje A. Teraz wszystkie 5 działa. Uff!

Kiedy musiałem to zrobić, to właśnie zrobiłem, aby to działało (być może były też pewne ustawienia GPO, ale wygląda na to, że je masz).

Aby umożliwić KLIENTOWI korzystanie z CredSSP do łączenia się z dowolnym komputerem w domenie:

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"

Następnie uruchomiłem następujące czynności na każdym komputerze docelowym (serwerze), aby włączyć uwierzytelnianie CredSSP:

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

Wymaga to oczywiście uruchomienia skryptu z odpowiednimi uprawnieniami. To zadziałało dla mnie - mam nadzieję, że ci pomoże.

Mam miejsce, w którym mógłbym żyć, migrować maszynę wirtualną z jednego serwera Hyper-v 2012R2 na inny, ale nie mogłem migrować jej z powrotem. (Próbuję użyć SAMBA 4.2 jako kontrolera domeny i chciałem sprawdzić, czy mogę przeprowadzić migrację na żywo za pomocą CredSSP, ponieważ nie mogę użyć ograniczonej delegacji z Samba4).

Ostatecznie przeszedłem do działającej funkcji hyper-v i skopiowałem wpisy rejestru z hklm: \ SOFTWARE \ Policies \ Microsoft \ Windows \ CredentialsDelegation do niedziałającej funkcji hyper-v. Potem działało dobrze w obie strony.