Неможливо отримати автентифікацію CredSSP для роботи в PowerShell

При спробі створити скрипт PowerShell за допомогою вилучення я зіткнувся з проблемою подвійного переходу . У цій статті Перріман дає короткий опис проблеми, а також конкретні кроки для вирішення проблеми (майже тривіально, якщо ви знаєте команди, але для когось менш знайомого, як я, ця інформація була неоціненною!).

Я біг Enable-WSManCredSSP Serverна своєму сервері Win7 без випадків, але спроба запустити Enable-WSManCredSSP Client –DelegateComputer <FQDN of the server>на своєму клієнті Win7 генерувала цю помилку:

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

Запуск winrm quickconfig підтвердив, що мій сервер працює під WinRM:

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

І Get-WSManCredSSP підтвердив, що мій сервер готовий прийняти облікові дані від клієнта:

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

Я також знайшов статтю Боссена про WinRM, в якій він описує загальну настройку WinRM, і знайшов один примх, щоб отримати корисну точку даних для діагностики; ця команда, запущена на клієнті, використовує інструмент winrs для віддаленого доступу до сервера:

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

Ця команда повертала очікуваний результат, вміст кореневого каталогу на сервері, без випадків, підтверджуючи, що мій FQDN правильний і WinRM увімкнено.

Boessen вказує, що порт 5985 є типовим для Win7; ця команда, запущена на сервері, підтверджує значення 5985:

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

Питання: Чому я не в змозі виконати команду Enable-WSManCredSSP на стороні клієнта?

Оновлення 2011.06.07

Я знайшов рішення вищезазначеного питання: викликаючи Enable-PSRemoting , рекламувавшись для налаштування комп'ютера для отримання віддалених команд, дозволив Enable-WSManCredSSP на клієнті успішно працювати! Цікаво, але його сторінка людини вказує, що вона робить ряд різних дій, тому я припускаю, що один із тих, хто випадково зробив те, що мені потрібно.

Але тоді я дійшов до чергової перешкоди, коли я намагався використовувати автентифікацію CredSSP. Ось команда:

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

І ось відповідь:

Помилка підключення до віддаленого сервера за допомогою наступного повідомлення про помилку:
Клієнт WinRM не може обробити запит. Комп'ютерна політика не дозволяє
делегування облікових даних користувачів на цільовий комп'ютер. Використовуйте gpedit.msc
і перегляньте таку політику: Конфігурація комп'ютера
-> Адміністративні шаблони -> Система -> Делегування облікових даних
-> Дозволити видалення свіжих облікових даних. Переконайтеся, що він увімкнено та
налаштований з SPN, відповідним для цільового комп'ютера. Наприклад,
для назви цільового комп'ютера "myserver.domain.com" SPN може бути однією з
наступні: WSMAN /myserver.domain.com або WSMAN / *. domain.com.
Для отримання додаткової інформації див. Тему довідки about_Remote_Troubleshooting.

Я перевірив налаштування так, як це надзвичайно корисне повідомлення про помилку, і мені здається, що воно налаштовано належним чином.

Нове запитання: чим ця спроба віддаленого з'єднання з CredSSP не вдалася?

Відповідаючи, будь ласка, майте на увазі наступне: Дозвольте мені заздалегідь розвіяти будь-яке уявлення про те, що я знаю, що я тут роблю, і будь-яка зовнішність незважаючи на це. :-) Адміністратор Windows - це не моя область знань!

Я повернувся до цього після короткого перерви, щоб знову подивитися свіжими очима (як моїми, так і колегами) і вирішив знову повернутися до основ:

На клієнті, який я виконав (в оболонці адміністратора):

enable-wsmancredssp -role client -delegatecomputer devremvm03 -force

На сервері, який я виконав (в оболонці адміністратора):

enable-wsmancredssp -role server -force

Обидва повернули нормальний вихід із вказівкою на те, що CredSSP тепер "справжній".

Потім я використовував такий код тренажера, щоб пройти через рівень складності:

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

Все , що є в моєму run.ps1 сценарій так , транскрипт пішов наступним чином (і це RAN в , НЕ -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

Раніше працювали лише основні, віддалені та облікові записиA. Зараз усі 5 працюють. Вау!

Коли мені довелося це зробити, це те, що я зробив, щоб він працював (можливо, були і деякі налаштування GPO, але схоже, що ви їх охопили).

Щоб дозволити КЛІЄНТУ використовувати CredSSP для підключення до будь-якої машини в домені:

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"

Потім я запустив наступне на кожній цільовій машині (сервері), щоб увімкнути автентифікацію CredSSP:

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

Це, звичайно, вимагає, щоб ви виконували сценарій з відповідними дозволами. Це працювало для мене - сподіваюся, це допоможе тобі.

Я потрапив там, де міг жити мігрувати VM з одного сервера гіпер-v 2012R2 на інший, але не міг перенести його назад. (Я намагаюся використовувати SAMBA 4.2 в якості мого контролера домену, і хотів дізнатися, чи можу я перенести міграцію з CredSSP, оскільки я не можу використовувати обмежену делегацію з Samba4).

Врешті-решт я перейшов до робочої гіпер-v і скопіював записи реєстру на hklm: \ SOFTWARE \ Policies \ Microsoft \ Windows \ CredentialsDelegation до непрацюючої гіпер-v. Після цього добре працювали обома способами.