Удаленное присоединение компьютера к домену с помощью PowerShell и WMI

Для среды CI/CD я создаю сценарий PowerShell для создания новой виртуальной машины Hyper-V, которая по сути является клоном «base-vm». Этот base-vm не является членом домена, он является членом рабочей группы Windows.

При попытке добавить компьютер в домен у меня возникает следующая проблема: приведенный ниже сценарий работает при запуске непосредственно на целевой машине, которая является хостом Hyper-V (работает под учетной записью администратора), но не при запуске с сервера сборки. (Дженкинс).

Процесс показан на следующей схеме: Схема развертывания Jenkins

И часть сценария, которая терпит неудачу, следующая:

Invoke-Command -Session $remoteSession -Scriptblock {
    Rename-Computer -NewName $args[0] -Restart 
} -ArgumentList $vmSettings.ComputerName

Start-Sleep -s 30

$newVmRemoteSession = New-PSSession -ComputerName $vmSettings.ComputerName -Credential $credentials

Invoke-Command -Session $newVmRemoteSession -Scriptblock {
    Add-Computer -Domainname myfunny.domain -Credential $args[0] -Restart
} -ArgumentList $domainAdminCredentials

Remove-PSSession $newVmRemoteSession
Remove-PSSession $remoteSession

Write-Host "Done creating new VM"

Переменная $remoteSession содержит удаленный сеанс PowerShell на основе учетных данных локального администратора.

Переменная $newVmRemoteSession содержит удаленный сеанс переименованной виртуальной машины с учетными данными локального администратора.

Ошибка, которую я получаю при запуске этого скрипта через задание сборки:

[base-vm] Не удалось подключиться к удаленному серверу base-vm со следующим сообщением об ошибке: WinRM не может завершить операцию. Убедитесь, что указанное имя компьютера является допустимым, что компьютер доступен по сети и что исключение брандмауэра для службы WinRM включено и разрешает доступ с этого компьютера. По умолчанию исключение брандмауэра WinRM для общедоступных профилей ограничивает доступ к удаленным компьютерам в той же локальной подсети. Дополнительные сведения см. в разделе справки about_Remote_Troubleshooting.

Команда, которая выдает исключение:

Invoke-Command -Session $newVmRemoteSession -Scriptblock {
    Add-Computer -Domainname myfunny.domain -Credential $args[0] -Restart
} -ArgumentList $domainAdminCredentials`

Я искал решение этой проблемы, но не могу найти ошибку. Сначала я подумал, что это связано с доверительными отношениями между сервером сборки и виртуальной машиной, но когда я использовал WinRM для добавления этих отношений, сборка все еще не удалась.

Я использовал: winrm s winrm/config/client '@{TrustedHosts="*"}', чтобы добавить отношения.

ОБНОВЛЕНИЕ: Еще одна вещь, которую я сделал, это запустить скрипт с тем же пользователем, что и сервер сборки. Это дало мне ту же ошибку, что и выше. Странно то, что пользователь является локальным администратором на сервере, с которого запускается сценарий, а также является членом группы «пользователи удаленного управления» на этом сервере.

ОБНОВЛЕНИЕ 2: я обнаружил, что проблема связана с аутентификацией Kerberos и Negotiate. При запуске сценария с рабочей станции, присоединенной к домену, сценарий запускается по схеме Kerberos по умолчанию, а при запуске с автономной рабочей станции он работает по схеме Negotaite, для которой требуется SPN для того, что я прочитал на https://msdn.microsoft.com/en-us/library/windows/desktop/aa378748(v=vs.85).aspx.


person Wilko van der Veen    schedule 23.05.2016    source источник
comment
Сообщение об ошибке предлагает несколько советов. Вы следовали этому? Каковы результаты? Кроме того, какое именно утверждение вызывает ошибку в первую очередь?   -  person Ansgar Wiechers    schedule 23.05.2016
comment
Я искал решение этой проблемы, но не могу найти ошибку. Сначала я подумал, что это связано с доверительными отношениями между сервером сборки и виртуальной машиной, но когда я использовал winrm для добавления этих отношений, сборка все еще не удалась. Я использовал: `winrm s winrm/config/client '@{TrustedHosts=*}'`, чтобы добавить связь.   -  person Wilko van der Veen    schedule 23.05.2016
comment
На вашем хосте Jenkins: вы проверили, что а) новое имя виртуальной машины может быть преобразовано в IP-адрес и б) вы можете подключиться к порту 5985 на виртуальной машине?   -  person Ansgar Wiechers    schedule 23.05.2016
comment
Хост Jenkins не имеет доступа к новой виртуальной машине, в отличие от хоста Hyper-V. И ошибка возникает перед переименованием, скрипт не может получить доступ к «base-vm», которая является виртуальной машиной шаблона, которую необходимо переименовать. Я попытаюсь добавить схематический обзор для этой установки.   -  person Wilko van der Veen    schedule 23.05.2016
comment
Оказывается, проблема, вероятно, заключается в следующем: при локальном запуске я нахожусь в домене как пользователь, но при удаленном запуске скрипт не запускается на компьютере, присоединенном к домену. Я проверю это и вернусь к этому. msdn.microsoft.com/en-us/library /aa384295(v=vs.85).aspx   -  person Wilko van der Veen    schedule 24.05.2016


Ответы (2)


Вы правы в том, что это, вероятно, проблема с авторизацией. PowerShell использует для этих целей Kerberos и настроен для присоединения к домену. Я думаю, что вы были на правильном пути с добавлением доверенных хостов...

На странице http://powershell.com/cs/blogs/tips/archive/2016/01/25/enabling-powershell-remoting-with-ntlm.aspx, где объясняется, как его настроить, и используется немного другой синтаксис для то, что вы описали. Может быть, попробовать это?

person Dave    schedule 25.05.2016
comment
Я предположил, что winrm/config/client '@{TrustedHosts=*}' от WinRM сделал свое дело. Я посмотрю ссылку, которую вы разместили. - person Wilko van der Veen; 25.05.2016

Компьютер не был доступен через домен, поэтому я использовал CredSSP, чтобы подключиться к нему. Чтобы включить credssp, мне пришлось запустить командлет enable-wsmancredssp на клиенте и сервере, а также использовать надстройку gpedit.msc для настройки доступа.

person Wilko van der Veen    schedule 31.05.2016