Сведения об удаленных требованиях

Статья
06/21/2023

КРАТКОЕ ОПИСАНИЕ

Описание требований к системе и конфигурации для выполнения удаленных команд в 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 automatic.

Удаленное управление 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 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 для запуска Windows PowerShell с параметром "Запуск от имени администратора":

Нажмите кнопку Пуск, выберите Пункты Все программы, Стандартные, а затем — папку Windows PowerShell.
Щелкните правой кнопкой мыши Windows PowerShell и выберите команду "Запуск от имени администратора".

Чтобы запустить Windows PowerShell с параметром "Запуск от имени администратора", выполните следующие действия:

Нажмите кнопку Пуск, выберите пункт Все программы, а затем — папку Windows PowerShell.
Щелкните правой кнопкой мыши Windows PowerShell и выберите команду "Запуск от имени администратора".

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

При запуске Windows 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