Не удается заставить 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:\"

Эта команда вернула ожидаемый результат, содержимое корневого каталога на сервере, без происшествий, подтвердив, что мое полное доменное имя правильно и что 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
и посмотрите на следующую политику: Конфигурация компьютера
-> Административные шаблоны -> Система -> Делегирование полномочий
-> Разрешить делегирование свежих полномочий. Убедитесь, что он включен и
настроен с именем участника-службы, подходящим для целевого компьютера. Например,
для имени целевого компьютера «myserver.domain.com» имя участника-службы может быть одним из
следующее: WSMAN /myserver.domain.com или WSMAN / *. domain.com.
Для получения дополнительной информации см. Раздел справки about_Remote_Trou 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, поэтому расшифровка расширилась следующим образом (и это выполнялось в оболочке не- администратора):

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

Ранее работали только базовые, удаленные и учетные данные. Сейчас все 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 

Это, конечно, требует, чтобы вы запускали скрипт с соответствующими разрешениями. Это сработало для меня - надеюсь, это поможет вам.

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

В конечном итоге я перешел к работающему Hyper-V и скопировал записи реестра в hklm: \ SOFTWARE \ Policies \ Microsoft \ Windows \ CredentialsDelegation в нерабочий Hyper-V. После этого все работало нормально.