about_Remote_Requirements
Краткое описание
Описание требований к системе и конфигурации для выполнения удаленных команд в PowerShell.
Подробное описание
В этом разделе описываются требования к системе, требования к пользователям и ресурсам для установки удаленных подключений и выполнения удаленных команд в PowerShell. Он также содержит инструкции по настройке удаленных операций.
Примечание
Многие командлеты (включая Get-Serviceкомандлеты , Get-Process, Get-WMIObject, Get-EventLogиGet-WinEvent) получают объекты с удаленных компьютеров с помощью методов Microsoft платформа .NET Framework для получения объектов. Они не используют инфраструктуру удаленного взаимодействия PowerShell. Требования в этом документе не применяются к этим командлетам.
Чтобы найти командлеты, которые имеют параметр ComputerName , но не используют удаленное взаимодействие PowerShell, прочитайте описание параметра ComputerName командлетов.
Требования к системе
Для запуска удаленных сеансов в Windows PowerShell 3.0 локальные и удаленные компьютеры должны иметь следующие компоненты:
- Windows PowerShell 3.0 или более поздней версии
- Microsoft платформа .NET Framework 4 или более поздней версии
- Удаленное управление Windows 3.0
Для запуска удаленных сеансов в Windows PowerShell 2.0 локальные и удаленные компьютеры должны иметь следующие компоненты:
- Windows PowerShell 2.0 или более поздней версии
- Microsoft платформа .NET Framework 2.0 или более поздней версии
- Удаленное управление Windows 2.0
Вы можете создавать удаленные сеансы между компьютерами под управлением Windows PowerShell 2.0 и Windows PowerShell 3.0. Однако функции, которые выполняются только в Windows PowerShell 3.0, такие как возможность отключения и повторного подключения к сеансам, доступны только в том случае, если оба компьютера работают Windows PowerShell 3.0.
Чтобы найти номер версии установленной версии PowerShell, используйте автоматическую $PSVersionTable переменную.
Удаленное управление Windows (WinRM) 3.0 и Microsoft платформа .NET Framework 4 включены в Windows 8, Windows Server 2012 и более новые выпуски операционной системы Windows. WinRM 3.0 входит в Windows Management Framework 3.0 для старых операционных систем. Если на компьютере нет требуемой версии WinRM или microsoft платформа .NET Framework, установка завершится сбоем.
Разрешения пользователя
Для создания удаленных сеансов и выполнения удаленных команд текущий пользователь по умолчанию должен быть членом группы администраторов на удаленном компьютере или предоставить учетные данные администратора. В противном случае произойдет сбой команды.
Разрешения, необходимые для создания сеансов и выполнения команд на удаленном компьютере (или в удаленном сеансе на локальном компьютере), устанавливаются конфигурацией сеанса (также известной как конечная точка) на удаленном компьютере, к которому подключается сеанс. В частности, дескриптор безопасности в конфигурации сеанса определяет, кто имеет доступ к конфигурации сеанса и кто может использовать его для подключения.
Дескрипторы безопасности в конфигурациях сеансов по умолчанию , Microsoft.PowerShell, Microsoft.PowerShell32 и Microsoft.PowerShell.Workflow, разрешают доступ только членам группы администраторов .
Если у текущего пользователя нет разрешения на использование конфигурации сеанса, команда для выполнения команды (которая использует временный сеанс) или создания постоянного сеанса на удаленном компьютере завершается ошибкой. Пользователь может использовать параметр ConfigurationName командлетов, создающих сеансы, чтобы выбрать другую конфигурацию сеанса, если она доступна.
Члены группы "Администраторы " на компьютере могут определить, кто имеет разрешение на удаленное подключение к компьютеру, изменив дескрипторы безопасности в конфигурациях сеансов по умолчанию и создав новые конфигурации сеанса с различными дескрипторами безопасности.
Дополнительные сведения о конфигурациях сеансов см. в разделе about_Session_Configurations.
Сетевые расположения Windows
Начиная с Windows PowerShell 3.0, Enable-PSRemoting командлет может включить удаленное взаимодействие в клиентских и серверных версиях Windows в частных, доменных и общедоступных сетях.
В серверных версиях Windows с частными и доменными сетями Enable-PSRemoting командлет создает правила брандмауэра, разрешающие неограниченный удаленный доступ. Он также создает правило брандмауэра для общедоступных сетей, которое разрешает удаленный доступ только с компьютеров в той же локальной подсети. Это правило брандмауэра локальной подсети по умолчанию включено на серверных версиях Windows в общедоступных сетях, но Enable-PSRemoting повторно применяет правило в случае изменения или удаления.
В клиентских версиях Windows с частными и доменными сетями Enable-PSRemoting командлет по умолчанию создает правила брандмауэра, разрешающие неограниченный удаленный доступ.
Чтобы включить удаленное взаимодействие в клиентских версиях Windows с общедоступными сетями, используйте параметр SkipNetworkProfileCheck командлета Enable-PSRemoting . Он создает правило брандмауэра, которое разрешает удаленный доступ только с компьютеров в той же локальной подсети.
Чтобы снять ограничение локальной подсети в общедоступных сетях и разрешить удаленный доступ из всех расположений в клиентских и серверных версиях Windows, используйте Set-NetFirewallRule командлет в модуле NetSecurity . Выполните следующую команду:
Set-NetFirewallRule -Name "WINRM-HTTP-In-TCP-PUBLIC" -RemoteAddress Any
Примечание
Имя правила брандмауэра может отличаться для разных версий Windows. Используйте Get-NetFirewallRule для просмотра списка правил. Перед включением правила брандмауэра просмотрите параметры безопасности в правиле, чтобы убедиться, что конфигурация подходит для вашей среды.
В Windows PowerShell 2.0 в серверных версиях Windows создаются правила брандмауэра, Enable-PSRemoting разрешающие удаленный доступ во всех сетях.
В Windows PowerShell 2.0 в клиентских версиях Windows Enable-PSRemoting правила брандмауэра создаются только в частных и доменных сетях. Если сетевое расположение является общедоступным, Enable-PSRemoting происходит сбой.
Запуск от имени администратора
Для следующих операций удаленного взаимодействия требуются права администратора:
Установка удаленного подключения к локальному компьютеру. Это обычно называется сценарием замыкания на себя.
Управление конфигурациями сеансов на локальном компьютере.
Просмотр и изменение параметров WS-Management на локальном компьютере. Это параметры в узле LocalHost диска WSMAN: .
Для выполнения этих задач необходимо запустить PowerShell с параметром "Запуск от имени администратора", даже если вы являетесь членом группы "Администраторы " на локальном компьютере.
В Windows 7 и Windows Server 2008 R2, чтобы запустить PowerShell с параметром Запуск от имени администратора :
- Нажмите кнопку Пуск, выберите Пункты Все программы, Стандартные и выберите папку PowerShell.
- Щелкните правой кнопкой мыши PowerShell и выберите запуск от имени администратора.
Чтобы запустить Windows PowerShell с параметром Запуск от имени администратора, выполните следующие действия.
- Нажмите кнопку Пуск, выберите пункт Все программы, а затем — папку PowerShell.
- Щелкните правой кнопкой мыши PowerShell и выберите запуск от имени администратора.
Параметр Запуск от имени администратора также доступен в других записях Windows Обозреватель для PowerShell, включая ярлыки. Просто щелкните элемент правой кнопкой мыши и выберите запуск от имени администратора.
При запуске PowerShell из другой программы, например Cmd.exe, используйте параметр Запуск от имени администратора , чтобы запустить программу.
Настройка удаленного взаимодействия на компьютере
Компьютеры под управлением всех поддерживаемых версий Windows могут устанавливать удаленные подключения и выполнять удаленные команды в PowerShell без какой-либо настройки. Однако для получения подключений и разрешения пользователям создавать локальные и удаленные сеансы PowerShell, управляемые пользователем (PSSessions) и выполнять команды на локальном компьютере, необходимо включить удаленное взаимодействие PowerShell на компьютере.
Windows Server 2012 и более новых выпусках Windows Server по умолчанию включены для удаленного взаимодействия PowerShell. Если параметры изменены, можно восстановить параметры по умолчанию, выполнив Enable-PSRemoting командлет .
Во всех остальных поддерживаемых версиях Windows необходимо выполнить Enable-PSRemoting командлет , чтобы включить удаленное взаимодействие PowerShell.
Функции удаленного взаимодействия PowerShell поддерживаются службой WinRM, которая является реализацией протокола веб-служб для управления (WS-Management) майкрософт. При включении удаленного взаимодействия PowerShell вы изменяете конфигурацию по умолчанию WS-Management и добавляете конфигурацию системы, которая позволяет пользователям подключаться к WS-Management.
Чтобы настроить PowerShell для получения удаленных команд, выполните следующие действия.
- Запустите PowerShell с параметром Запуск от имени администратора .
- В командной строке введите следующий текст:
Enable-PSRemoting.
Чтобы убедиться, что удаленное взаимодействие настроено правильно, выполните тестовую команду, например следующую команду, которая создает удаленный сеанс на локальном компьютере.
New-PSSession
Если удаленное взаимодействие настроено правильно, команда создаст сеанс на локальном компьютере и вернет объект, представляющий сеанс. Выходные данные должны выглядеть примерно так:
Id Name ComputerName State ConfigurationName
-- ---- ------------ ----- -----
1 Session1 localhost Opened Microsoft.PowerShell
Если команда завершается сбоем, дополнительные сведения см . в разделе about_Remote_Troubleshooting.
Общие сведения о политиках
При удаленной работе используются два экземпляра PowerShell: один на локальном компьютере, а второй — на удаленном компьютере. В результате на работу влияют политики Windows и политики PowerShell на локальных и удаленных компьютерах.
Как правило, перед подключением и установкой подключения политики на локальном компьютере действуют. При использовании подключения политики на удаленном компьютере действуют.
Ограничения обычной проверки подлинности в Linux и macOS
При подключении из системы Linux или macOS к Windows обычная проверка подлинности по протоколу HTTP не поддерживается. Обычную проверку подлинности можно использовать по протоколу HTTPS, установив сертификат на целевом сервере. Сертификат должен иметь имя cn, соответствующее имени узла, срок действия которого не истек или не отозван. Самозаверяющий сертификат можно использовать для тестирования.
Дополнительные сведения см. в разделе Практическое руководство. Настройка WINRM для HTTPS .
Следующая команда, выполняемая из командной строки с повышенными привилегиями, настроит прослушиватель HTTPS в Windows с установленным сертификатом.
$hostinfo = '@{Hostname="<DNS_NAME>"; CertificateThumbprint="<THUMBPRINT>"}'
winrm create winrm/config/Listener?Address=*+Transport=HTTPS $hostinfo
На стороне Linux или macOS выберите Базовый для проверки подлинности и -UseSSl.
Примечание
Обычную проверку подлинности нельзя использовать с учетными записями домена; Требуется локальная учетная запись, и учетная запись должна находиться в группе Администраторы .
# The specified local user must have administrator rights on the target machine.
# Specify the unqualified username.
$cred = Get-Credential username
$session = New-PSSession -Computer <hostname> -Credential $cred `
-Authentication Basic -UseSSL
Альтернативой обычной проверке подлинности по протоколу HTTPS является Negotiate. Это приводит к проверке подлинности NTLM между клиентом и сервером, а полезные данные шифруются по протоколу HTTP.
Ниже показано использование Negotiate с New-PSSession:
# The specified user must have administrator rights on the target machine.
$cred = Get-Credential username@hostname
$session = New-PSSession -Computer <hostname> -Credential $cred `
-Authentication Negotiate
Примечание
Для Windows Server требуется дополнительный параметр реестра, позволяющий администраторам, кроме встроенного администратора, подключаться с помощью NTLM. См. параметр реестра LocalAccountTokenFilterPolicy в разделе Согласование проверки подлинности в разделе Проверка подлинности для удаленного Connections