#powershell
Вопрос:
Я пытаюсь использовать пользовательскую функцию PS, которая примет команду powershell в качестве строкового параметра и выполнит/сохранит результаты в переменной внутри самой функции, на которую будут ссылаться позже. Проведя некоторые исследования, я нашел способ сделать это, передав «Get-WinEvent» в качестве строковой переменной в функцию, а затем в функции, преобразующей эту переменную в блок сценариев, например:
$PowershellQueryScript = [Scriptblock]::Create($PowershellQuery)
Как только я это сделал, я вызвал переменную в своем цикле foreach и сохранил результаты следующим образом:
$myResults = Invoke-Command -ComputerName $server -ScriptBlock $PowershellQueryScript
Теперь ошибка, которую я получаю, связана с тем, что WinRM не включен («Не удалось подключиться к удаленному серверу myServer со следующим сообщением об ошибке : WinRM не может обработать запрос».) и, к сожалению, я не думаю, что мне будет разрешено изменить эти настройки в производстве. Если бы я вызвал эту команду непосредственно с моего сервера -> производство без использования команды Invoke, тогда все работает так, как ожидалось, поскольку я думаю, что не нужно создавать удаленный сеанс PS на удаленном сервере, поэтому WinRM не требуется.
Существуют ли какие-либо другие обходные пути, позволяющие пользователю вызывать мою функцию со строкой и выполнять эту строку в самой функции БЕЗ необходимости включения WinRM?
Комментарии:
1. Используйте аутентификацию DCOM. Удаленное взаимодействие Powershell по умолчанию имеет значение WinRM. Почему бы не включить WinRM?
2. Изменения настроек на серверах prod требуют одобрения, поэтому я бы предпочел не вносить изменения, даже если они незначительны. Кроме того, я полагаю, что удаленное подключение PS представляет собой угрозу безопасности, поэтому оно будет изучено дополнительно. Изменить: Похоже, что он включен по умолчанию, но не уверен, почему у меня возникают проблемы при выполнении моей команды, если это так. Я знаю, что вызовы RPC работают, но не могу этого сделать И все еще использую свою функцию PS ( docs.microsoft.com/en-us/powershell/scripting/learn/remoting/… )
3. Вы можете использовать DCOM, но, как вы и сказали, он включен по умолчанию. Вероятно, это служба, которая еще не запущена.
4. «По умолчанию исключение брандмауэра WinRM для общедоступных профилей ограничивает доступ к удаленным компьютерам в пределах одной локальной подсети». Вы можете проверить, работает ли WinRM на локальных и/или удаленных компьютерах, запустив
Test-WSMan5. Я искренне считаю, что лучший подход-включить WS-Man в организации, если вы просмотрите документы по безопасности для нее, как вы начали делать выше. Это такой же риск, как и любое другое подключение в вашей среде — вы снижаете его, ограничивая доступ к набору конечных точек, требуя учетных данных и хорошего управления учетными данными. Это лучше, чем альтернатива, когда люди спрашивают о способах обойти ее, делают вещи, которые создают риски для безопасности, или используют такие инструменты, как PsExec и т. Д.
Ответ №1:
После еще нескольких исследований я обнаружил, что WinRM уже включен, и соответствующие настройки брандмауэра также уже настроены. Проблема заключалась в том, что я использовал cnames, а не полные доменные имена (Полные доменные имена), поэтому DNS не разрешался должным образом. Проблема устраняется путем преобразования cname в значение, которое можно устранить:
$ServerFQDN = [System.Net.Dns]::GetHostEntry([string]$ServerCname).HostName