H PowerShell Remoting — настройка и удаленное управление Tutorial. Powershell удаленное управление

Удаленное управление с помощью PowerShell – ITSM

Существует довольно много методов для работы с удаленными компьютерами. Есть Windows Management Instrumentation (WMI), широко используемый в VBScript. Есть различные утилиты, которые позволяют осуществлять удаленное управление, типа PSExec от Sysinternals. Даже многие командлеты PowerShell имеют параметр ComputerName для выполнения на удаленных компьютерах

В общем методов полно, но у каждого из них есть свои минусы. Во первых — разный синтаксис, в котором легко запутаться. Во вторых — некоторые команды ведут себя по разному в зависимости от того, локально или удаленно они выполняются. Ну и наконец, для связи может потребоваться открытие дополнительных портов на брандмауэре, что не есть хорошо с точки зрения безопасности.

PowerShell Remoting решает большинство описанных проблем. Он основан на Microsoft реализации протокола Web Services for Management (WS-Management), а для связи использует службу Windows Remote Management (WinRM). Связь между компьютерами осуществляется по HTTP (по умолчанию) или HTTPS. Весь трафик между двумя компьютерами шифруется на уровне протокола (за исключением случаев, когда используется SSL). Поддерживаются несколько методов аутентификации, включая NTLM и Kerberos.

В отличие от утилит, использующих различные программные интерфейсы, PS Remoting работает следующим образом: команды, вводимые на локальном компьютере, передаются на удаленный компьютер и там выполняются, затем результат передается обратно. Поскольку все команды выполняются локально, нет необходимости заботится о совместимости. Кроме того, для работы PS Remoting нужен всего один открытый порт на брандмауэре.

Есть несколько способов управления с помощью PowerShell Remoting.

Управление «один к одному»

Самый простой способ удаленного управления — интерактивно открыть удаленную сессию и в ней выполнить нужные действия. Например, откроем сессию на компьютер SRV4 и рестартуем на нем сервис печати:

Enter-PSSession -ComputerName SRV4 Restart-Service -Name spooler

Посмотрим состояние сервиса и закроем удаленную сессию:

Get-Service -Name spooler Exit-PSSession

Интерактивная работа подходит для решения несложных задач удаленного администрирования. Если же надо автоматизировать процесс, то лучше воспользоваться командлетом Invoke-Command. Вот так с его помощью можно сделать то же самое действие:

Invoke-Command -ScriptBlock {Restart-Service spooler} -ComputerName SRV4

Эта команда откроет удаленную сессию на SRV4, выполнит блок команд, указанный в параметре -ScriptBlock, и закроет сессию. А чтобы задание выполнялось в фоновом режиме, дополнительно можно указать параметр -AsJob.

Cледует помнить о том, что при работе в фоновом режиме PowerShell не возвращает результат. Для его получения придется воспользоваться командлетом Receive-Job.

Для того, чтобы выполнить не пару-тройку команд, а какой либо скрипт, у Invoke-Command есть параметр –FilePath, который можно использовать вместо –ScriptBlock для определения файла сценария. Для примера я создал скрипт, который выводит список остановленных служб и запустил его на удаленной машине SRV4:

Invoke-Command -FilePath .\script.ps1 -ComputerName SRV4

Управление «один ко многим»

Довольно часть возникает необходимость параллельно выполнить одну задачу на нескольких компьютерах. Это довольно легко можно сделать с помощью того же Invoke-Command. Например, имена компьютеров можно просто перечислить через запятую:

Invoke-Command -ScriptBlock {Restart-Service spooler} -ComputerName SRV4,SRV5

Поместить в переменную:

$servers = @(″SRV1″,″SRV2″,″SRV3″) Invoke-Command -ScriptBlock {Restart-Service spooler} -ComputerName $servers

Или взять из файла:

Invoke-Command -ScriptBlock {Restart-Service spooler} -ComputerName` (Get-Content .\servers.txt)

Примечание: у Invoke-Command есть параметр ThrottleLimit, ограничивающий максимальное количество компьютеров, которыми можно управлять одновременно. По умолчанию этот параметр равен 32. При необходимости его можно изменить, но учтите, что повышение этого параметра увеличит нагрузку на процессор и память вашего компьютера, поэтому эту операцию нужно выполнять с большой осторожностью.

Сессии

Каждый раз при выполнении Invoke-Command создается новая сессия, на создание которой тратится время и ресурсы. Чтобы этого избежать мы можем открыть одну сессию, в которой и выполнять все команды. Например, откроем сессию с именем SRV4 на компьютер SRV4 и поместим ее в переменную $session, а затем этой сессии выполним нашу задачу (остановим многострадальный spooler):

$session = New-PSSession -ComputerName SRV4 -Name SRV4 Invoke-Command -ScriptBlock {Get-Service spooler | Stop-Service}` -Session $session

Сессия будет активна до того момента, пока мы не выйдем из консоли PowerShell. Также сессию можно закрыть — Disconnect-PSSession или удалить — Remove-PSSession.

А теперь несколько интересных возможностей, появившихся в PowerShell 3.0. Если раньше при выходе из сессии или закрытии консоли сессия удалялась, то в PS 3.0 при закрытии сессия переходит в состояние disconnected. Мы можем открыть новый сеанс на этом же (или любом другом) компьютере и выполнить команду прямо в этой отключенной сессии. В качестве примера стартуем на компьютере SRV4 сервис печати, остановленный в прошлый раз:

Invoke-Command -ScriptBlock {Start-Service spooler}` -ComputerName SRV4 -Disconnected

Еще один вариант использования отключенных сессий — запуск длительных по времени задач. Для примера откроем сессию c именем LongJob на SRV4 и запустим в ней фоновое задание, которое будет выводить список сервисов с интервалом в 1 минуту:

$session = New-PSSession -ComputerName SRV4 -Name LongJob Invoke-Command -Session $session -ScriptBlock` {Get-Service | foreach {$_;sleep 60} } -AsJob

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

Receive-Job -Name Job2 Disconnect-PSSession $session

Идем на другой компьютер и открываем консоль, Подключаемся к сессии LongJob и с помощью командлета Receive-PSSession получаем результат выполнения задания:

Connect-PSSession -Name LongJob -ComputerName SRV4 Receive-PSSession -Name LongJob

Или еще вариант, без явного подключения к сессии с помощью Connect-PSSession:

$session = Get-PSSession -Name LongJob -ComputerName SRV4 $job = Receive-PSSession $session -OutTarget Job Receive-Job $job

Примечание: для того, чтобы результат остался в системе, Receive-Job надо использовать с параметром -Keep.

Неявное удаленное управление

Еще один, довольно нестандартный способ удаленного управления — неявное удаленное управление (Implicit remoting). Используя его можно, не создавая удаленной сессии, локально выполнять командлеты, находящиеся на удаленном компьютере.

Для примера берем обычную рабочую станцию, без установленных средств удаленного администрирования. Создаем удаленную сессию с контроллером домена SRV4 и импортируем в эту сессию модуль Active Directory:

$session = New-PSSession -ComputerName SRV4 Invoke-Command {Import-Module ActiveDirectory} -Session $session

Затем экспортируем из удаленной сессии командлеты Active Directory и помещаем их в локальный модуль RemoteAD:

Export-PSSession -Session $session -CommandName *-AD* -OutputModule RemoteAD` -AllowClobber

Эта команда создаст в папке WindowsPowerShell\Modules\RemoteAD новый модуль PowerShell. Загружены будут только командлеты с именами, соответствующими шаблону *-AD*. При этом сами командлеты не копируются на локальный компьютер. Локальный модуль служит своего рода ярлыком, а сами команды будут выполняться на удаленном контроллере домена.

После создания модуля удаленную сессию можно закрыть, она больше не понадобится.

Импортируем новый модуль в текущий сеанс (в PS 3.0 можно этот шаг пропустить):

Import-Module RemoteAD

А теперь внимание — мы не открываем удаленную сессию с контроллером домена, где расположены командлеты. Не нужно явно запускать этот сеанс — это можно сделать неявно, попытавшись выполнить удаленные командлеты:

New-ADUser -Name BillGates -Company Microsoft Get-ADUser BillGates

При этом будет восстановлено удаленное подключение к контроллеру домена, после чего команда будет передана на контроллер домена и там выполнена. Результат выполнения будет сериализован в XML и передан по сети на локальный компьютер, где будет выполнена десериализация в объекты, с которыми может работать PowerShell.

Удаленный сеанс будет активным до тех пор, пока вы не закроете консоль или не удалите модуль RemoteAD.

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

В заключение скажу, что на данный момент PowerShell Remoting является основным инструментом для удаленного управления операционными системами Windows. Поэтому знать о его возможностях и уметь ими пользоваться просто необходимо любому Windows-администратору.

www.itsm.pw

Windows PowerShell: Неявное удаленное взаимодействие

08/22/2016
Время чтения: 3 мин

В этой статье

Дон Джонс

Есть малоизвестная возможность Windows PowerShell 2.0, которая позволяет легко увеличить гибкость вашей среды. Допустим, что на всех клиентских компьютерах установлена Windows XP. — это достаточно распространенная ситуация, а контроллеры домена работают под управлением Windows Server 2003.

Windows PowerShell 2.0 можно установить на обоих ОС, но не удастся использовать некоторые из новых модулей командлетов PowerShell, например модуль Active Directory, входящий в состав Windows Server 2008 R2. Эти модули не работают в ранних версиях Windows.

Но это не создает проблем. Достаточно на одном из компьютеров установить Windows 7 или Windows Server 2008 R2 (модуль Active Directory будет работать на любой из этих ОС), например установить отдельный контроллер домена под управлением Windows Server 2008 R2, который предоставит и модуль Active Directory, и службу шлюза управления Active Directory для связи с этим модулем. Службу шлюза можно загрузить со страницы и установить ее на Windows Server 2008 и/или Windows Server 2003.

Включите удаленное взаимодействие (Remoting) и WinRM на новом контроллере домена, выполнив в Windows PowerShell команду Enable-PSRemoting. А дальше запустите Windows PowerShell 2.0 на своем клиентском компьютере под управлением Windows XP и подготовитесь к волшебным превращениям.

Создание модуля

Начните с создания сеанса удаленного взаимодействия на новом контроллере домена:

$session = New-PSSession -computerName my-new-dc

Вместо my-new-dc укажите правильное имя компьютера. Можно задать дополнительные параметры, такие как альтернативные удостоверения или порты WinRM. Чтобы получить справочную информацию, выполните команду help new-pssession.

Далее загрузите командлеты Active Directory на удаленный экземпляр Windows PowerShell:

Invoke-command { import-module activedirectory } -session $session

А вот здесь начинается крутизна: заставьте локальный экземпляр Windows PowerShell экспортировать командлеты Active Directory из удаленного сеанса в локальный модуль вашего клиентского компьютера:

Export-PSSession -session $session -commandname *-AD* -outputmodule RemAD -allowclobber

Эта команда создаст новый модуль PowerShell, размещенный в подпапке WindowsPowerShell\Modules\RemAD папки «Документы» (Documents). Будут загружены только командлеты с именами, соответствующими шаблону *-AD*. Вот почему в большинстве имен дополнительных командлетов используется определенный префикс, например «AD», — это позволяет загружать только нужные командлеты.

Командлеты не копируются на локальный компьютер, просто локальный модуль служит своего рода ярлыком. Командлеты выполняются на удаленном контроллере домена, но все выглядит так, как будто они работают локально.

Использование командлетов

Начнем с удаления сеанса с удаленным контроллером домена:

Remove-PSSession -session $session

Далее загрузите новый модуль:

Import-Module RemAD -prefix Rem

Эта команда загрузит новый модуль в память и добавит в нем в конец имени каждого командлета префикс «Rem». Этот префикс напоминает, что командлеты выполняются удаленно. Можно задать любой другой префикс, но я предпочитают «R» или «Rem», что отзначает Remote, то есть «удаленный».

Запросите справку удаленного командлета:

Help New-RemADUser

Вы получите ошибку, потому что не установлен сеанс удаленного взаимодействия между вашим компьютером и контроллером домена, где расположены командлеты. Не нужно явно запускать этот сеанс — это можно сделать неявно, попытавшись выполнить один из удаленных командлетов:

Get-RemADUser -filter "Name -like 'D*'"

При этом будет восстановлено удаленное подключение к контроллеру домена, после чего будет передана и выполнена команда на контроллере домена. Далее будет выполнена сериализация в XML всех пользователей, имя которых начинается на «D», и файл будет переправлен по сети на ваш компьютер. Здесь будет выполнена десериализация в объекты, с которыми можно работать с применением конвейера PowerShell. Вот теперь можно запросить справку, потому что удаленный сеанс активен:

Help New-RemADUser

Сеанс будет активным, пока вы не закроете экземпляр оболочки или не удалите модуль:

Remove-Module RemAD

Возьмите и поуправляйте чем-нибудь

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

Дон Джонс (Don Jones) — основатель компании Concentrated Technology. Дон регулярно отвечает на посвященные Windows PowerShell вопросы посетителей своего сайта ConcentratedTech.com. Он также пишет для Nexus.Realtimepublishers.com, поэтому многие из книг Дона доступны в бесплатной электронной форме.

Связанные материалы

technet.microsoft.com

Удаленный доступ по WMI и PowerShell для неадминистраторв

Это перевод статьи Ondrej Sevecek о настройке удаленного доступа WMI и PowerShell по протоколу WinRM для пользователей без прав администратора.

WinRM, также называемый WSMan, это технология удаленного управления, которая предоставляет для таких средств как WMI, PowerShell, Перенаправление событий (Event Forwarding) и даже Диспетчер сервера (Server Manager) транспорт по протоколу HTTP. WinRM принимает запросы по HTTP или HTTPS протоколу, которые затем передает зарегистрированным в нем провайдерам (плагинам). PowerShell, WMI и Перенаправление событий зарегистрированы в WinRM как соответствующие провайдеры.

Если бы вы были разработчиком клиент-серверного приложения, то вы могли бы создать свой провайдер (плагин) для WinRM, который можно было бы использовать для удаленного управления вашим приложением. Конечно можно и самому написать DCOM или HTTP веб-интерфейс, но WinRM предоставляет стандартный каркас приложения (фреймворк), что облегчает его администрирование.

WinRM поддерживает методы встроенной аутентификации Windows, такие как Kerberos, Negotiate (включая NTLM) и Schannel (сертификаты). Поскольку он использует обычный HTTP, то поддерживаются также методы аутентификации Basic и Digest.

Для удаленного доступа к инструментарию управления Windows (WMI, winmgmt) можно настроить специальный DCOM интерфейс на прием удаленных команд и запросов (WQL), или же использовать WinRM для этого. PowerShell, с другой стороны, не имеет своего собственного сервера, поэтому для приема удаленных команд используются специальные командлеты Enter-PSSession и Invoke-Command, которые передают запросы по WinRM протоколу. PowerShell принимает эти команды, обрабатывает их локально и возвращает ответ по протоколу WinRM.

Таким же образом работает Диспетчер сервера (Server Manager) и Перенаправление событий (Event Forwarding). Хотя у перенаправления событий, есть свой сервис Windows Event Collector (wecsvc), но Microsoft решила использовать WinRM для пересылки сообщений.

Во всех описанных случаях WinRM использует специальный провайдер (плаги

gamelton.com

Удаленное управление PowerShell

Локальная настройка PowerShell для удаленного управления

PS C:\> Enable-PSRemoting # Командлет сконфигурирует и запустит службу WinRM для удаленного управления PowerShell; добавит в исключение Windows Firewall порт для службы WinRM TCP 5985 WinRM Quick Configuration Running command "Set-WSManQuickConfig" to enable this machine for remote management through WinRM service. This includes: 1. Starting or restarting (if already started) the WinRM service 2. Setting the WinRM service type to auto start 3. Creating a listener to accept requests on any IP address 4. Enabling firewall exception for WS-Management traffic (for http only). Do you want to continue? [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y WinRM has been updated to receive requests. WinRM service type changed successfully. WinRM service started. WinRM has been updated for remote management. Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine. WinRM firewall exception enabled. Confirm Are you sure you want to perform this action? Performing operation "Registering session configuration" on Target "Session configuration "Microsoft.PowerShell32" is not found. Running command "Register-PSSessionConfiguration Microsoft.PowerShell32 -processorarchitecture x86 -force" to create "Microsoft.PowerShell32" session configuration. This will restart WinRM service.". [Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): y WARNING: Waiting for service 'Windows Remote Management (WS-Management) (winrm)' to finish stopping... WARNING: Waiting for service 'Windows Remote Management (WS-Management) (winrm)' to finish stopping... WARNING: Waiting for service 'Windows Remote Management (WS-Management) (winrm)' to finish stopping... PS C:\>

Настройка через Групповые политики Active Directory удаленного управления PowerShell

Для этого через групповые политики нужно будет настроить такие параметры:

Включить автоматическое конфигурирование службы WinRM
Добавить исключение в Windows Firewall для порта TCP 5985

Создаем Group Policy Object

[Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Remote Management (WinRM)/WinRM Service/]

Параметр Allow automatic configuration of listeners устанавливаем в Enabled и указываем с каких IP-адресов серверу WinRM разрешается принимать соединения (* - с любых адресов, пустое поле - не принимать соединения, рис.1).

[Сomputer Configuration/Policies/Windows Settings/Security Settings/Windows Firewall with Advanced Security/]

Добавляем новое правило: можно воспользоваться предустановленным параметром Predefined (рис.2) при этом снимаем галочку в окне настроек "Windows Remote Management - Compatibility Mode (HTTP-In)" и затем, если необходимо, добавляем правилу настройки Scope, чтобы указать с каких именно IP-адресов разрешается подключение (рис.3)

Управление удаленным хостом с помощью PowerShell

Терминальные сеансы PowerShell

Подключаемся по имени хоста внутри домена

PS C:\> whoami # узнаем под каким пользователем мы сейчас работаем domain\user01 PS C:\> Enter-PSSession -ComputerName remotehost33.domain.local -Credential domain\admin # устанавливаем соединение с удаленным хостом remotehost33, используя альтернативные учетные данные [remotehost33.domain.local]: PS C:\> # как видно из приглашения командной строки, мы уже управляем удаленным компьютером [remotehost33.domain.local]: PS C:\> whoami # узнаем под каким пользователем мы работаем в удаленном сеансе domain\admin [remotehost33.domain.local]: PS C:\> exit # завершаем удаленный сеанс PS C:\> # мы снова на локальном хосте

Подключаемся по IP-адресу

Здесь есть небольшой подвох. Для подключения через WinRM по IP необходимо чтобы удовлетворялись следующие условия:

транспортным протоколом является HTTPS или назначением является узел из списка TrustedHosts;
должны быть явно указанны учетные данные для соединения,

в противном случае подключающаяся сторона (клиент) откажет в соединении:

PS C:\> Enter-PSSession -ComputerName 10.14.1.100 -Credential domain\admin # Получаем ошибку, потому как IP-адрес, к которому мы коннектимся не добавлен в доверенные хосты и мы не используем ключ -UseSSL (необходима настройка сертификатов) Enter–PSSession : Connecting to remote server failed with the following error message : The WinRM client cannot process the request. Default authentication may be used with an IP address under the following conditions: the transport is HTTPS or the destination is in the TrustedHosts list, and explicit credentials are provided. Use winrm.cmd to configure TrustedHosts. Note that computers in the TrustedHosts list might not be authenticated. For more information on how to set TrustedHosts run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic. At line:1 char:16 + Enter–PSSession <<<< –ComputerName 10.14.1.100 –Credential domain\admin + CategoryInfo : InvalidArgument: (10.14.1.100:String) [Enter–PSSession], PSRemotingTransportException + FullyQualifiedErrorId : CreateRemoteRunspaceFailed PS C:\> Set-Item WSMan:\localhost\Client\TrustedHosts * # Таким образом мы сможем коннектиться к любым хостам (опасно, т.к. наши учетные данные могут утечь в сеть) PS C:\> Set-Item WSMan:\localhost\Client\TrustedHosts -Value "10.14.1.100,computer2,computer31" # Так можно добавить сразу несколько хостов в список TrustedHosts PS C:\> Set-Item WSMan:\localhost\Client\TrustedHosts -Value 10.14.1.100 # Мы выполним добавление только необходимого нам узла. Также не забываем, что если сетевой маршрут к хосту возможно прослушать сниффером, наши учетные данные могут быть перехвачены. Так что не стоит добавлять в TrustedHosts узлы из интернета WinRM Security Configuration. This command modifies the TrustedHosts list for the WinRM client. The computers in the TrustedHosts list might not be authenticated. The client might send credential information to these computers. Are you sure that you want to modify this list? [Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): y PS C:\> Enter-PSSession -ComputerName 10.14.1.100 -Credential domain\admin # Повторяем команду подключения, которая вначале нам выбивала ошибку [10.14.1.100]: PS C:\> # Как видно, мы успешно соединились по IP

Удаленный вызов

Мы также можем и не устанавливать терминальный сеанс с удаленным компьютером, а лишь только вызвать на нем нужный нам скрипт или команду и локально получить его вывод (удаленный вызов процедур). В этом нам поможет командлет Invoke-Command.

Например, давайте вызовем на локальном, а затем на удаленном компьютере с именем "remotehost33", командлет (Get-WMIObject -Class Win32_OperatingSystem).CSName , который выведает нам имя компьютера, и посмотрим что получится:

PS C:\> (Get-WMIObject -Class Win32_OperatingSystem).CSName LocalHost01 PS C:\> Invoke-Command -ComputerName remotehost33 -Credential domain\admin -ScriptBlock {(Get-WMIObject -Class Win32_OperatingSystem).CSName} RemoteHost33 PS C:\> Invoke-Command -ComputerName remotehost33, remotehost34, remoteserv02 -Credential domain\admin -ScriptBlock {(Get-WMIObject -Class Win32_OperatingSystem).CSName} # скрипт-блок будет выполнен на трех компьютерах, указанных через запятую. Если после запятой стоит дополнительно символ пробела, то скрипт-блок будет выполнятся поочередно. Если же между именами хостов стоит только запятая без пробелов, то скрипт-блок выполнится в обратной очередности

Работа с сессиями PowerShell

Данный тип подключения отличается от предыдущих тем, что удаленная сессия устанавливается сразу и не требует переподключения при каждом удаленном запросе. Естественно этот вариант будет работать быстрее, если необходимо выполнить цикл или некоторое число удаленных запросов, т.к. соответственно при каждом новом запросе не будет тратиться время на установление нового соединения с удаленной стороной.

PS C:\> New-PSSession -ComputerName remotehost33 -Credential domain\admin # создаем новую сессию Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 1 Session1 remotehost33 Opened Microsoft.PowerShell Available PS C:\> $ssn1 = Get-PSSession -Id 1 # объявляем переменную ssn1 и загоняем в нее нашу сессию с идентификатором №1 PS C:\> Invoke-Command -Session $ssn1 -ScriptBlock {(Get-WMIObject -Class Win32_OperatingSystem).CSName} # вызываем удаленную команду, используя вместо имени компьютера параметр -Session с указанием созданной нами переменной ssn1. Учетные данные здесь повторять нельзя, т.к. сессия уже открыта remotehost33 PS C:\> New-PSSession -ComputerName remotehost34,remotehost34 -Credential domain\admin # можно создавать несколько сессий с одним компьютером Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 2 Session2 remotehost34 Opened Microsoft.PowerShell Available 3 Session3 remotehost34 Opened Microsoft.PowerShell Available PS C:\> Get-PSSession # мы видим новые сессии, в добавок к существующей Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 1 Session1 remotehost33 Opened Microsoft.PowerShell Available 2 Session2 remotehost34 Opened Microsoft.PowerShell Available 3 Session3 remotehost34 Opened Microsoft.PowerShell Available PS C:\> Remove-PSSession -ComputerName remotehost34 # удаляем все установленные сессии с компьютером remotehost34 PS C:\> Get-PSSession # проверяем что получилось Id Name ComputerName State ConfigurationName Availability -- ---- ------------ ----- ----------------- ------------ 1 Session1 remotehost33 Opened Microsoft.PowerShell Available PS C:\> Enter-PSSession -Id 1 # помимо удаленного вызова, также можно заходить в установленную сессию терминально, указав ее идентификатор (как в этом примере), или указав переменную с ключем -Session (как я описал выше) [remotehost33]: PS C:\>

Комментарии:

vam.in.ua

Удаленный доступ к WinRM без прав администратора

По умолчанию для удаленного подключения к компьютеру с помощью PowerShell (PowerShell Remoting) нужны права администратора. В этой статье мы покажем, как с помощью группы безопасности, групповой политики и изменения дескриптора сессии PoSh, предоставить права на подключение через PowerShell Remoting (WinRM) для рядовых пользователей без прав администратора.

При попытке создать сессию PowerShell с удаленным компьютером из-под обычного пользователя (Enter-PSSession msk-server1) появляется ошибка доступа:

Enter-PSSession : Connecting to remote server msk-server1 failed with the following error message : Access is denied.

Удаленный доступ к WinRM и группа Remote Management Users

Проверим стандартные разрешения для сессии PoSh:

(Get-PSSessionConfiguration -Name Microsoft.PowerShell).Permission

Как мы видим, доступ разрешен для следующих встроенных групп:

BUILTIN\Administrators — AccessAllowed,
BUILTIN\Remote Management Users — AccessAllowed

Таким образом, чтобы пользователь мог удаленно подключаться через WinRM, ему достаточно состоять во встроенной локальной группе безопасности администраторов или Remote Management Users (группа создается в системе, начиная с версии PowerShell 4.0, имеющегося по умолчанию в Windows 8 / Windows Server 2012 и выше). Данная группа также предоставляется доступ к ресурсам WMI через управляющие протоколы (например, WS-Management)

Нужного пользователя можно включить в группу через оснастку управления компьютером:

или с помощью команды:

net localgroup "Remote Management Users" /add aapetrov2

В том случае, если подобный доступ нужно предоставить на множестве компьютеров, можно воспользоваться групповой политикой. Для этого назначьте GPO на нужные компьютеры, и политике Computer Configuration -> Windows Settings -> Security Settings -> Restricted Groups добавьте новую группу Remote Management Users и включим в нее учетные записи или группы, которым нужно предоставить доступ к WinRM.

После включения пользователя в группу Remote Management Users, он сможет создавать удаленную сессию PowerShell с помощью Enter-PSSession или запускать команды с помощью Invoke-Command. Права пользователя в данной сессии будут ограничены его правами на машине.

Проверьте, заработало ли удаленное подключение.

Дескриптор безопасности сессии PowerShell

Еще один способ быстро дать пользователю права на использование PowerShell Remoting без включения его в локальную группу безопасности Remote Management Users заключается в модификации дескриптора безопасности текущей сессии Microsoft.PowerShell на локальном компьютере. Этот способ позволит быстро временно (до следующей перезагрузки) предоставить отдельному пользователю права на удаленное подключение через PowerShell.

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

Set-PSSessionConfiguration -Name Microsoft.PowerShell -showSecurityDescriptorUI

В данном диалоговом окне нужно добавить пользователя или группу и предоставить ему права Execute (Invoke).

После сохранения изменений система запросит подтверждение на перезапуск службы WinRM.

В том случае, если нужно изменить дескриптор безопасности автоматизировано (без GUI), придется сначала внести изменения вручную, а потом получить текущий дескриптор доступа в формате SDDL.

(Get-PSSessionConfiguration -Name "Microsoft.PowerShell").SecurityDescriptorSDDL

В нашем примере, команда вернула дескриптор

O:NSG:BAD:P(A;;GA;;;BA)(A;;GXGR;;;S-1-5-21-2373142251-3438396318-2932294317-23761992)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)

Затем можно использовать данную SDDL строку для предоставления доступа к PowerShell на любом другом сервере.

$SDDL = “O:NSG:BAD:P(A;;GA;;;BA)(A;;GXGR;;;S-1-5-21-2373142251-3438396318-2932294317-23761992)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)”Set-PSSessionConfiguration -Name Microsoft.PowerShell -SecurityDescriptorSddl $SDDL

Удаленное управление Hyper-V также требует прав WinRM

В Windows 10 /Windows Server 2016 для удаленного подключения к серверу Hyper-V с помощью Hyper-V Manager стал использоваться протокол PowerShell Remoting. Таким образом, по умолчанию удаленные пользователи без прав администратор не смогут управлять сервером Hyper-V, даже при наличии разрешений в Hyper-V.

При попытке подключиться к серверу Hyper-V с компьютера Windows 10 под обычным пользователем появится ошибка.

An error occurred while attempting to connect to server “server1”, Check that the Virtual Machine Management service is running and that you are authorized to connect to the server

Чтобы разрешить удаленное подключение к консоли достаточно аналогично добавить пользователя Hyper-V в локальную группу Remote Management Users.

winitpro.ru

powershell - Удаленное управление Powershell - политика не позволяет делегировать учетные данные пользователя

Я новичок в powershell, и у меня возникают проблемы с использованием делегирования полномочий. У меня есть следующий script:

$session = New-PSSession myserver -Authentication CredSSP -Credential DOMAIN\Administrator Invoke-Command -Session $session -ScriptBlock { <Some PowerShell Command> }

Перед запуском, я сделал следующее:

Запустите Enable-PSRemoting на сервере myserver.
Запустите Enable-WSManCredSSP Server на myserver.
Запустите Restart-Service WinRM на сервере myserver.
Запустите Enable-WSManCredSSP Client –DelegateComputer myserver на клиенте.
Перезагрузите сервер и клиент.

Но как только я запустил script, я получаю следующее сообщение об ошибке:

[myserver] 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 Delega tion -> 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 "m yserver.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. + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportException + FullyQualifiedErrorId : PSSessionOpenFailed

Я проверил политики, упомянутые в сообщении об ошибке, но все кажется прекрасным. Что еще может блокировать меня?

задан ChrisB 07 авг. '13 в 23:55 источник поделиться

qaru.site

PowerShell Remoting — настройка и удаленное управление / СоХабр

Здесь минимум теории, в основном практическая часть. Описывается как настроить WinRM, как изменить профиль сетевого адаптера, дается скрипт по добавлению в TrustedHosts с фильтрацией, объясняется зачем нужны доверенные хосты, и рассматриваются поверхностно удаленные подключения так чтобы можно было сесть и сразу админить удаленные машины.

Наиболее простой путь сконфигурировать удаленное управление это выполнить Enable-PSRemoting в оболочке powershell с правами администратора. При этом произойдет следущее:

запустится служба WinRM (если запущена перезапустится)
служба WinRM перейдет в состояние — автоматический запуск при старте
будет создан прослушиватель WinRM для HTTP трафика на порту 5985 для всех локальных IP адресов
будет создано правило файрвола для прослушивателя WinRM. Внимание, этот пункт завершится с ошибкой если любая из сетевых карточек имеет тип сети «публичная», т.к. открывать порт на такой карточке не хорошо. Если у вас при конфигурировании вышла такая ошибка измените профиль это сетевушки командлетом Set-NetConnectionProfile и после этого запустите Enable-PSRemoting снова. Если вам нужна сетевая карточка с профилем «Публичная сеть» запустите Enable-PSRemoting с параметром -SkipNetworkProfileCheck в этом случае будут созданы правила файрвола только из локальной сети.

После этого нужно разрешить подключаться к удаленной машине с той машины с которой будет происходить управление. Сделано это в целях безопасности для того чтобы уменьшить риск взлома сессии удаленного управления или DNS с подстановкой себя вместо удаленной машины и предотвратить исполнение скриптов на машинах которые вы принудительно не разрешили.

для проверки куда можно подключаться используем:

get-item wsman:\localhost\Client\TrustedHosts для разрешения подключаться ко всемset-item wsman:localhost\client\trustedhosts -value * Если вы открываете доступ для всех указав * то WinRM будет подключаться ко ВСЕМ машинам без проверки. Помните, что вы открываете самого себя для потенциального взлома из локальной сети. Лучше указывать адреса хостов куда вам нужно подключится, тогда WinRM будет отклонять все остальные адреса или имена. Если машина с которой ведется управление находится в домене она будет доверять всем машинам этого домена. Если она не в домене, или в другом домене, то нужно указать в TrustedHosts адрес или имя машины на которую мы будем подключаться. Добавлять себя на машине к которой мы подключаемся не нужно.

в хелпе указаны команды, я их чуть чуть переделал в скрипт

###################################################################################### # добавляет NewHost в список TrustedHost с фильтрацией если такая строка уже есть # можно дергать из командной строки указывая параметр напрямую например # .\Add-TrustedHost.ps1 192.168.2.1 ###################################################################################### param ( $NewHost = '192.168.2.89' ) Write-Host "adding host: $NewHost" $prev = (get-item WSMan:\localhost\Client\TrustedHosts).value if ( ($prev.Contains( $NewHost )) -eq $false) { if ( $prev -eq '' ) { set-item WSMan:\localhost\Client\TrustedHosts -Value "$NewHost" } else { set-item WSMan:\localhost\Client\TrustedHosts -Value "$prev, $NewHost" } } Write-Host '' Write-Host 'Now TrustedHosts contains:' (get-item WSMan:\localhost\Client\TrustedHosts).value он проверяет на есть ли такая запись, если нет то добавляет в список. Вызывать можно из командной строки указав адрес или имя.

Есть разница указывать имя или адрес. Если в TrustedHosts будет только адрес то открыть сессию по имени не получится, и наоборот — если указать имя то прицепится по адресу не получится. Учитывайте это.

Часто встречается ссылка на команду

WinRM quickconfig это не тоже самое что Enable-PSRemotingв чем же разницаEnable-PSRemoting делает больше действий чем «winrm quickconfig». Командлет Set-WSManQuickConfig делает точно такие же действия как «winrm quickconfig». Enable-PSRemoting запускает Set-WSManQuickConfig когда ведет настройку системы

Set-WSManQuickConfig делает следущие действия:

запускат WinRM сервис
устанавливает автостарт службы WinRM в автоматический
создает прослушиватель
добавляет исключения файрвола

Enable-PSRemoting кроме этого делает еще следущее

включает все зарегистрированные конфигурации сессий PowerShell для получения инструкций от удаленных машин
регистрирует конфигурацию если она не зарегистрирована «Microsoft.PowerShell»
регистрирует конфигурацию если она не зарегистрирована «Microsoft.PowerShell32» на 64 битных машинах
убирает запрет «Deny Everyone» из дескриптора безопасности всех конфигураций сессий
перезапускает сервис WinRM

источникEnable-PSRemoting TechNetSet-WSManQuickConfig TechNetУдаленные подключения1. Сессии 1-to-1 открываются командойEnter-PSSession -ComputerName Test Вы получите оболочку на удаленной машине. Подключится можно к самому себе указав localhost. Альтернативные кредиталы указываются с параметром -Credential, выход происходит командлетом Exit-PSSession

Ограничения следующие:

нельзя сделать второй прыжок — только 1 сессия, внутри сессии подключиться дальше нельзя
вы не можете использовать команды имеющие графический интерфейс. Если вы это сделаете оболочка повиснет, нажмите Ctrl+C чтобы отвисло
вы не можете запускать команды имеющие свой собственый шел, например nslookup, netsh
вы можете запускать скрипты если политика запуска на удаленной машине позволяет их запускать
нельзя прицепится к интерактивной сессии, вы заходите как «network logon», как будто прицепились к сетевому диску. Поэтому не запустятся логон скрипты, и вы можете не получить домашнюю папку на удаленной машине (лишний довод чтобы не мапать хом фолдеры логон скриптами)
вы не сможете взаимодействовать с юзером на удаленной машине даже если он туда залогинен. Не получится показать ему окошко или попечатать чтонибудь ему.

этот способ лучше всего для простых операций, зашел, подергал сервер и отключился. Если нужно удержать переменные в скопе, нужна длительная операция (много часов или дней), нужно больше возможностей по администрированию то нужно использовать технику попродвинутее.Комментарий. объекты переданные по сети обрезаются и перестают быть живыми. У них удаляются методы, свойства остаются. Вытащить объект на свою машину, поколдовать и засунуть обратно не получится. Если нужно больше пишите, допишу отдельно.

2. Сессии 1-to-many

Invoke-Command определяем что будем исполнять так:$sb = { команды для удаленной машины разделенные точкой с запятой } передаем на удаленные машины Test1 и Test2Invoke-Command -ComputerName Test1, Test2 -ScriptBlock $sb за раз можно забросить на 32 машины. Если альтернативные кредиталы то используем параметр -Credential

Чтобы передать целиком скрипт вместо параметра -ScriptBlock пишем -FilePath, удаленной машине НЕ нужно иметь доступ к файлу, он будет разобран на запчасти, передан через HTTP и выполнен с той стороны.

Запомним что на той стороне будет новый скоп, так что ваш скрипт не получит значений из вашей консоли, а переменные скрипта могут оказаться на той стороне пустыми. Поэтому передавайте сразу целиком готовые инструкции и скрипты с параметрами. для полноценного использования Invoke-Command надо уметь превращать строки в скрипт блоки. Например у вас есть команды которые зависят от какогото списка, вам нужно сгенерировать строку, превратить ее в ScriptBlock и отправить на удаленный комп:$sb = [Scriptblock]::Create( $SomeString ) kuda78 В статье пропущен очень важный момент — передача параметров в скрипт на удаленной машине.

$deployRemote = { param( [string]$targetEnvName, [string]$targetUsername) $Global:ErrorActionPreference = «Stop» #… }

Invoke-Command -Session $session -ScriptBlock $deployRemote -ArgumentList ($targetEnvName, $targetUsername)

Да действительно пропущен. Сделал сознательно чтобы не загромождать обзор параметрами и описаниями. Спасибо. Параметр -ArgumentList работает как со скрипт блоками так и со сценариями

3. Сессии Это когда с той стороны создается копия пошика постоянно висящая в памяти, и в нее отправляются команды. Как результат к ней можно переподключится, ченить долгое запустить на исполнение, цепляться из разных скриптов или разными юзерами. Например у вас есть набор скриптов решающих одну задачу по частям, каждый из них поочереди может подключатся к одной удаленной сессии, видеть результаты работы предыдущих команд, иметь одни загруженные модули, общие переменные, общее окружение, до тех пор пока сессия не будет принудительно закрыта.

Создание сессии происходит командлетом New-PSSession, результат можно поместить в переменную

$DC01 = New-PSSession -ComputerName DC01 $Controllers = New-PSSession DC01, DC02, DC03 использовать можно такие же параметры подключения как в Invoke-Command

Как использовать: если 1-to-1

Enter-PSSession -Session $DC01 если 1-to-manyInvoke-Command -Sessions $Controllers -ScriptBlock {get-eventlog -logname security -newest 50} посмотреть какие сессии открыты можно с помощью Get-PSSession, закрыть Remove-PSSession закрыть вообще все сессииGet-PSSession | Remove-PSSession прицепится к сессии можно с помощью Connect-PSSession, отключиться через Disconnect-PSSession

Invoke-Command может создать сразу disconnected сессию, он отправляет команды на исполнение и отключатся, позже можно подключится и сгрузить результаты работы. Делается это параметром -Disconnected. Получение результатов через командлет Recieve-PSSession.

Сессии имеют очень много настроек, возможно даже создание сессий с обрезаным набором команд, модулей и т.п. Называется custom endpoints

sohabr.net