Пытаясь создать сценарий 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 включен.
Бессен указывает, что порт 5985 является портом по умолчанию для Win7; эта команда, запущенная на сервере, подтверждает значение 5985:
get-item wsman:\localhost\listener\listener*\port
Вопрос: почему я не могу выполнить команду Enable-WSManCredSSP на стороне клиента?
2011.06.07 Обновление
Я нашел решение поставленного выше вопроса: вызов Включить-PSRemoting, рекламируется для настройки компьютера на получить удаленные команды, разрешенные Включить-WSManCredSSP на клиенте для успешной работы! Любопытно, но это страница руководства указывает, что он выполняет несколько различных действий, поэтому я предполагаю, что один из них случайно сделал то, что мне нужно.
Но затем я столкнулся с другим препятствием, когда попытался использовать аутентификацию CredSSP. Вот команда:
Invoke-Command { Write-Host "hello, world" } -computername $serverName `
-credential $testCred -Authentication Credssp
И вот ответ:
Connecting to remote server failed with the following error message: The WinRM client cannot process the request. A computer policy does not allow the delegation of the user credentials to the target computer. Use gpedit.msc and look at the following policy: Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials. Verify that it is enabled and configured with an SPN appropriate for the target computer. For example, for a target computer name "myserver.domain.com", the SPN can be one of the following: WSMAN /myserver.domain.com or WSMAN/*.domain.com. For more information, see the about_Remote_Troubleshooting Help topic.
Я проверил настройки так же, как это было предложено в этом чрезвычайно полезном сообщении об ошибке, и мне кажется, что оно настроено правильно.
Новый вопрос: что это удаленное соединение с 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
Раньше работали только базовые, удаленные и учетные данные 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
Это, конечно, требует, чтобы вы запускали сценарий с соответствующими разрешениями. Это сработало для меня - надеюсь, это поможет вам.
Я получил возможность перенести виртуальную машину с одного сервера Hyper-v 2012R2 на другой, но не смог перенести ее обратно. (Я пытаюсь использовать SAMBA 4.2 в качестве контроллера домена и хотел посмотреть, смогу ли я выполнить миграцию с помощью CredSSP, поскольку я не мог использовать ограниченное делегирование с Samba4).
В конечном итоге я перешел к работающему Hyper-v и скопировал записи реестра в hklm: \ SOFTWARE \ Policies \ Microsoft \ Windows \ CredentialsDelegation на неработающий Hyper-v. После этого работал нормально в обоих направлениях.