Добавить компьютер назначения к значениям параметра конфигурации trustedhosts

Обновлено: 04.07.2024

для выполнения сценариев служба удаленного управления Windows (winrm) и для выполнения операций с данными с помощью программы командной строки winrm служба удаленного управления Windows (winrm) должны быть установлены и настроены.

Эти элементы также зависят от конфигурации WinRM.

  • Windows средство командной строки удаленной оболочки (Winrs). .
  • удаленное взаимодействие Windows PowerShell 2,0.

Где установлен WinRM

служба WinRM автоматически устанавливается со всеми поддерживаемыми версиями Windows операционной системы.

Настройка WinRM и IPMI

Эти компоненты поставщика службы удаленного управления (IPMI) и SNMP-интерфейса WMI устанавливаются вместе с операционной системой.

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

Чтобы проверить состояние параметров конфигурации, введите следующую команду.

Быстрая настройка по умолчанию

Можно включить протокол WS-Management на локальном компьютере и настроить конфигурацию по умолчанию для удаленного управления с помощью команды winrm quickconfig .

winrm quickconfig Команда (или сокращенная версия winrm qc ) выполняет эти операции.

winrm quickconfig Команда создает исключение брандмауэра только для текущего профиля пользователя. Если профиль брандмауэра изменился по какой-либо причине, следует запустить, winrm quickconfig чтобы включить исключение брандмауэра для нового профиля; в противном случае исключение может быть не включено.

Чтобы получить сведения о настройке конфигурации, введите winrm help config в командной строке.

Настройка WinRM с параметрами по умолчанию

Введите winrm quickconfig в командной строке.

Если вы не используете учетную запись администратора локального компьютера, необходимо выбрать пункт Запуск от имени администратора в меню " Пуск " или использовать команду runas в командной строке.

Когда средство выводит на экран команду сделать эти изменения [ y/n ] ?, введите y.

Если настройка прошла успешно, отображаются следующие выходные данные.

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

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

Параметры по умолчанию прослушивателя и протокола WS-Management

winrm quickconfig создает следующие параметры по умолчанию для прослушивателя. Можно создать более одного прослушивателя. Для получения дополнительных сведений введите winrm help config в командной строке.

Адрес

Задает адрес, для которого был создан данный прослушиватель.

Транспортировка

Задает TCP-порт, для которого создается данный прослушиватель.

Hostname (Имя узла)

Указывает имя узла компьютера, на котором запущена служба WinRM. Значением должно быть полное доменное имя, строка литерала IPv4 или IPv6 или символ-шаблон.

Активировано

Указывает, включен или отключен прослушиватель. По умолчанию используется значение True.

URLPrefix

CertificateThumbprint

Указывает отпечаток сертификата службы. Это значение представляет собой строку шестнадцатеричных значений из двух цифр, найденных в поле отпечатка сертификата. Эта строка содержит хэш SHA-1 сертификата. Сертификаты используются при проверке подлинности на основе сертификата клиента. Сертификаты могут быть сопоставлены только с локальными учетными записями пользователей и не работают с учетными записями домена.

ListeningOn

Указывает адреса IPv4 и IPv6, используемые прослушивателем. Например: "111.0.0.1, 111.222.333.444. 1, 1000:2000:2c: 3: C19:9ec8: a715:5e24, 3FFE: 8311: FFFF: f70f: 0:5EFE: 111.222.333.444, FE80:: 5EFE: 111.222.333.444% 8, FE80:: C19:9ec8: a715:5e24% 6".

Параметры протокола по умолчанию

Многие параметры конфигурации, такие как максенвелопесизекб или соаптрацеенаблед, определяют взаимодействие клиентских и серверных компонентов WinRM с протоколом WS-Management. В следующем списке описаны доступные параметры конфигурации.

MaxEnvelopeSizekb

Указывает максимальный объем данных протокола доступа к объектам (в килобайтах). Значение по умолчанию — 150 КБ.

Поведение не поддерживается, если для максенвелопесизекб задано значение больше 1039440.

макстимеаутмс

Указывает максимальное время ожидания (в миллисекундах), которое может использоваться для любого запроса, кроме запросов на включение внесенных изменений. Значение по умолчанию — 60000.

MaxBatchItems

Задает максимальное количество элементов, которое может быть использовано в ответе Pull. Значение по умолчанию — 32000.

MaxProviderRequests

Задает максимальное количество одновременных запросов, допускаемое службой. Значение по умолчанию — 25.

WinRM 2,0: Этот параметр является устаревшим и имеет значение только для чтения.

Параметры конфигурации клиента WinRM по умолчанию

Клиентская версия WinRM имеет следующие параметры конфигурации по умолчанию.

нетворкделаймс

Задает дополнительное время ожидания клиента в миллисекундах для поправки на сетевую задержку. Значение по умолчанию — 5000 миллисекунд.

URLPrefix

алловуненкриптед

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

Basic

Позволяет клиентскому компьютеру использовать обычную проверку подлинности. При использовании обычной проверки подлинности имя пользователя и пароль передаются серверу или прокси-серверу открытым текстом. Эта схема является наименее безопасным методом проверки подлинности. Значение по умолчанию равно True.

Digest (дайджест)

Сертификат

Позволяет клиенту использовать проверку подлинности на основе сертификата клиента. Проверка подлинности на основе сертификатов — это схема, в которой сервер проверяет подлинность клиента, идентифицируемого сертификатом X509. Значение по умолчанию равно True.

Kerberos

Позволяет клиентскому компьютеру использовать проверку подлинности Kerberos. Проверка подлинности Kerberos подразумевает взаимную проверку подлинности клиента и сервера с использованием сертификатов Kerberos. Значение по умолчанию равно True.

Согласование

Позволяет клиенту использовать проверку подлинности согласованием. При проверке подлинности с согласованием клиент отправляет серверу запрос на проверку подлинности. Сервер определяет, какой протокол использовать — Kerberos или NTLM. Протокол Kerberos выбирается для проверки подлинности учетной записи домена, а NTLM — для учетных записей локального компьютера. Имя пользователя должно быть указано в \ _ формате имени пользователя домена для пользователя домена. Имя пользователя должно быть указано в _ формате "имя \ пользователя сервера _ " для локального пользователя на компьютере сервера. Значение по умолчанию равно True.

CredSSP

Позволяет клиенту использовать проверку подлинности с помощью поставщика поддержки безопасности учетных данных (CredSSP). CredSSP позволяет приложению делегировать учетные данные пользователя с клиентского компьютера на целевой сервер. По умолчанию False.

дефаултпортс

TrustedHosts

Указывает список доверенных удаленных компьютеров. В этот список необходимо добавить другие компьютеры в Рабочей группе или компьютерах в другом домене.

Если для Трустедхост указан IPv6-адрес, адрес должен быть заключен в квадратные скобки, как показано в следующей команде WinRM Utility: winrm set winrm/config/client '@' .

Чтобы получить дополнительные сведения о добавлении компьютеров в список TrustedHosts, введите winrm help config .

Параметры конфигурации по умолчанию для службы WinRM

Версия службы WinRM имеет следующие параметры конфигурации по умолчанию.

RootSDDL

Указывает дескриптор безопасности, управляющий удаленным доступом к прослушивателю. Значение по умолчанию — "О:НСГ: BAD: P (A;; Общедоступный;;; BA) (A;; GR;;; ER) С:П (AU; FA; Общедоступный;;; WD) (AU; SA; ГВГКС;;; WD) ".

максконкуррентоператионс

Максимальное количество одновременных операций. Значение по умолчанию — 100.

WinRM 2,0: Параметр Максконкуррентоператионс является устаревшим и имеет значение только для чтения. Этот параметр заменен на свойств maxconcurrentoperationsperuser.

Свойств maxconcurrentoperationsperuser

Указывает максимальное количество одновременных операций, которые любой пользователь может удаленно открыть в одной системе. Значение по умолчанию — 1500.

енумератионтимеаутмс

MaxConnections

Указывает максимальное количество активных запросов, которые служба может обрабатывать одновременно. Значение по умолчанию — 300.

WinRM 2,0: Значение по умолчанию — 25.

макспаккетретриевалтимесекондс

Указывает максимальное время в секундах, необходимое службе WinRM для получения пакета. Значение по умолчанию — 120 секунд.

алловуненкриптед

Позволяет клиентскому компьютеру запрашивать передачу данных в незашифрованном виде. По умолчанию False.

Basic

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

Сертификат

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

Kerberos

Позволяет службе WinRM использовать проверку подлинности Kerberos. Значение по умолчанию равно True.

Согласование

Позволяет службе WinRM использовать проверку подлинности Negotiate. Значение по умолчанию равно True.

CredSSP

Позволяет службе WinRM использовать проверку подлинности с помощью поставщика поддержки безопасности учетных данных (CredSSP). По умолчанию False.

CbtHardeningLevel

Задает политику относительно требований к токенам привязки канала в запросах проверки подлинности. Значение по умолчанию — ослабление.

дефаултпортс

IPv4Filter и IPv6Filter

Указывает адреса IPv4 или IPv6, которые могут использоваться прослушивателями. Значения по умолчанию: IPv4Filter = * и IPv6Filter = * .

IPv4: Литеральная строка IPv4 состоит из четырех десятичных чисел с точками в диапазоне от 0 до 255. Например: 192.168.0.0.

IPv6: Строка литерала IPv6 заключена в квадратные скобки и содержит шестнадцатеричные числа, разделенные двоеточиями. Например:: [ : 1 ] или [ 3FFE: FFFF:: 6ECB: 0101 ] .

енаблекомпатибилитихттплистенер

енаблекомпатибилитихттпслистенер

Параметры конфигурации по умолчанию для Winrs

winrm quickconfig также настраивает параметры по умолчанию для WinRS .

AllowRemoteShellAccess

Разрешает доступ к удаленным оболочкам. Если для этого параметра задано значение false, то новые подключения удаленной оболочки будут отклонены сервером. Значение по умолчанию равно True.

IdleTimeout

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

WinRM 2,0: Значение по умолчанию — 180000. Минимальное значение — 60000. Установка этого значения ниже 60000 не влияет на время ожидания.

MaxConcurrentUsers

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

MaxShellRunTime

Указывает максимальное время в миллисекундах, в течение которого разрешено выполнение удаленной команды или сценария. Значение по умолчанию — 28800000.

WinRM 2,0: Параметр Максшеллрунтиме имеет значение только для чтения. Изменение значения Максшеллрунтиме не повлияет на удаленные оболочки.

MaxProcessesPerShell

Задает максимальное количество процессов, которое разрешается запускать любой операции оболочки. 0 означает неограниченное количество процессов. Значение по умолчанию — 15.

MaxMemoryPerShellMB

Указывает максимальный объем памяти, выделяемой на оболочку, включая дочерние процессы оболочки. Значение по умолчанию — 150 МБ.

MaxShellsPerUser

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

Настройка WinRM с групповая политика

используйте редактор групповая политика для настройки Windows удаленной оболочки и WinRM для компьютеров в вашей организации.

Настройка с помощью групповая политика

  1. Откройте окно командной строки с правами администратора.
  2. В командной строке введите gpedit.msc . Откроется окно Редактор объектов групповой политики .
  3. найдите служба удаленного управления Windows и Windows удаленную оболочку групповая политика объектов (GPO) в разделе конфигурация компьютера \ административные шаблоны \ Windows компоненты.
  4. На вкладке Расширенная выберите параметр, чтобы просмотреть описание. Дважды щелкните параметр, чтобы изменить его.

Windows Порты брандмауэра и WinRM 2,0

Если компьютер обновлен до WinRM 2,0, ранее настроенные прослушиватели переносятся и по-прежнему получают трафик.

Заметки об установке и настройке WinRM

Если на компьютере установлен клиент брандмауэра ISA2004, это может привести к тому, что клиент веб-служб для управления (WS-Management) перестает отвечать на запросы. Чтобы избежать этой проблемы, установите брандмауэр ISA2004 с пакетом обновления 1 (SP1).

Заметки об установке драйвера и поставщика IPMI

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

Если в BIOS системы отображаются ресурсы контроллера управления основной платой (BMC) , то ACPI (Самонастраивающийся) обнаруживает оборудование BMC и автоматически устанавливает драйвер IPMI. Поддержка самонастраивающийся может отсутствовать во всех BMC. Если контроллер BMC обнаруживается самонастраивающийся, то перед установкой компонента управления оборудованием в диспетчер устройств появляется неизвестное устройство. При установке драйвера в диспетчер устройств появляется новый компонент, поддерживающий универсальное IPMI-устройство, совместимое с Microsoft ACPI.

Если система не обнаруживает BMC и не устанавливает драйвер автоматически, но во время установки был обнаружен контроллер BMC, необходимо создать устройство BMC. Для этого введите в командной строке следующую команду: Rundll32 ipmisetp.dll, AddTheDevice . После выполнения этой команды создается устройство IPMI, которое отображается в диспетчер устройств. Если удалить компонент управления оборудованием, устройство будет удалено.

Поставщик IPMI помещает классы оборудования в корневое пространство имен \ оборудования WMI. Дополнительные сведения о классах оборудования см. в разделе поставщик IPMI. Дополнительные сведения о пространствах имен WMI см. в разделе Архитектура WMI.

Примечания по конфигурации подключаемого модуля WMI

начиная с Windows 8 и Windows Server 2012 подключаемые модули WMI имеют собственные конфигурации безопасности. Чтобы пользователь с обычным или энергопотреблением (не администратором) мог использовать подключаемый модуль WMI, необходимо включить доступ для этого пользователя после настройки прослушивателя . Во-первых, необходимо настроить пользователя для удаленного доступа к WMI с помощью одного из этих действий.

Когда появится пользовательский интерфейс, добавьте пользователя.

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

Большинство классов WMI для управления находятся в корневом пространстве имен \ CIMV2 .

Включение удаленного управления

Для того, чтобы управлять удаленным компьютером, необходимо на этом компьютере удаленное взаимодействие разрешить. Исключение составляет Windows Server 2012, где все возможности удаленного управления включены по умолчанию. Для всех остальных операционных систем надо:

1. Стартовать службу WinRM и поставить ее на автозапуск;
2. Создать прослушиватель (listener), который будет слушать запросы на управление;
3. Включить на файерволе правило, разрешающее трафик WS-Management.

Для настройки одного компьютера проще всего использовать командлет Enable-PSRemoting . Он произведет все необходимые действия, а также зарегистрирует конфигурации сессии по умолчанию. Для того, чтобы подавить запросы на подтверждение, можно добавить параметр -force . Консоль необходимо запустить с правами администратора, иначе будет выдана ошибка.

запуск Enable-PSRemoting на локальном компьютере

В доменной среде для настройки PS Remoting можно воспользоваться групповыми политиками.

В разделе Computer Configuration\Policies\Windows Settings\System Services включим политику «Windows Remote Management (WS-Management)». Она задает режим запуска для службы WinRM.

настройка автозапуска для службы WinRM

настройка прослушивателей для HTTP

Затем идем в раздел Computer Configuration\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Inbound Rules и создаем новое правило. Выбираем пункт Predefined (Предопределенные правила) и в списке выбираем Windows Remote Management.

настройка исключений файервола для HTTP

выбор портов для HTTP

Настройка доверия между компьютерами

При удаленном подключении в PowerShell используется взаимная аутентификация между компьютерами. Это означает, что перед установлением соединения удаленная машина должна подтвердить свою подлинность. Проще говоря, если вы подключаетесь к компьютеру с именем SRV1, то перед установкой соединения он (SRV1) должен вам доказать, что это действительно он, иначе подключение не будет установлено.

Если компьютеры являются членами одного домена, или находятся в разных, но доверяющих друг другу доменах, то взаимная аутентификация будет выполнена доменными службами. Главное, чтобы имя компьютера разрешалось в IP-адрес и соответствовало имени компьютера в Active Directory.

Если же один или оба компьютера не входят в домен, то для взаимной аутентификации есть два варианта: добавить удаленную машину в список доверенных узлов (Trusted Hosts) или использовать SSL.

Trusted Hosts

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

Set-Item WSMan:\localhost\Client\TrustedHosts -Value *

Чтобы добавить имя компьютера в уже имеющийся список доверенных узлов, необходимо сначала сохранить текущее значение в переменной, а затем присвоить значение разделенному запятыми списку, который включает текущее и новое значения. Например, чтобы добавить компьютер SRV2 в имеющийся список доверенных узлов, воспользуйтесь следующей командой:

Ну и посмотреть список доверенных узлов можно командой:

добавление компьютеров в TrustedHosts с помощью powerShell

Также для добавления в TrustedHosts можно воспользоваться групповой политикой. В разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Client включаем политику «Trusted Hosts» и добавляем имена или IP-адреса компов через запятую. Поддерживаются подстановочные символы.

добавление компьютеров в TrustedHosts с помощью групповых политик

Примечание: если TrustedHosts сконфигурированы через GPO, то из PS изменить их не удастся. То же касается и всех остальных настроек PS Remoting.

SSL

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

makecert -a sha1 -r -pe -n ″CN=wks8″ -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localmachine -sky exchange -sp ″Microsoft RSA SChannel Cryptographic Provider″ -sy 12 -m 12 ″C:\myssl.cer″

Эта команда создаст SSL-сертификат сроком на год и поместит его в хранилище сертификатов локального компьютера. Обратите внимание, что сертификат должен быть выдан на то же имя, которое вы будете указывать в команде подключения.

создание самоподписанного сертификата

После получения сертификат должен быть добавлен в Trusted Root Authority (доверенные корневые центры сертификации). Для этого открываем сертификат и жмем на кнопку «Установить сертификат».

сведения о сертификате

Запускается мастер импорта сертификатов. Указываем расположение хранилища «Локальный компьютер».

выбор хранилища для сертификата

В качестве хранилища выбираем «Доверенные корневые центры сертификации».

помещение сертификата в доверенные корневые центры сертификации

Теперь наш сертификат является доверенным. Еще раз открываем его, и на вкладке «Состав» находим отпечаток сертификата (CertificateThumbprint). Копируем его в буфер обмена.

отпечаток сертификата

В поле CertificateThumbrint вставляем отпечаток сертификата, скопированный в предыдущем пункте.

создание прослушивателя для HTTPS

Исключения файерволла Windows (если он включен) для нового прослушивателя необходимо настраивать вручную, автоматически они не создадутся. Поэтому создадим новое правило для входящего трафика по портам TCP 5986 и 443:

Также для создания правила можно воспользоваться графической оснасткой или утилитой командной строки netsh, кому что больше нравится.

создание правила на файерволе для HTTPS

Далее идем на компьютер SRV1, с которого будем подключаться. Поскольку я использую самоподписанный сертификат, то его придется добавить к доверенным корневым сертификатам и на клиенте. Копируем файл сертификата myssl.cer на SRV1 и устанавливаем командой:

certutil -addstore root C:\myssl.cer

Вот и все, настройка закончена. Теперь можно подключаться. Откроем интерактивную сессию на wks8 командой:

Enter-PSSession -ComputerName wks8 -Credential wks8\kirill -UseSSL

Обратите внимание, что при подключении по SSL необходимо вводить учетные данные, а также указывать тип подключения. Дальше все как обычно.

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

Отключение проверки

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

В принципе это правильно, но при необходимости проверки можно отменить. Для этого в свойствах сессии есть два параметра:

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

$ option = New-PSSessionOption -SkipCACheck -SkipCNCheck
Enter-PSSession -ComputerName wks8 -SessionOption $option -Credential wks8\kirill -UseSSL

Правда в этом случае теряется смысл SSL-сертификатов, и тогда уж проще пользоваться Thrusted Hosts. Но возможность такая есть, и знать о ней надо.

Дополнительные настройки

создание прослушивателей на портах 80 и 443

создание прослушивателей на портах 80 и 443 с помощью GPO

Порты по умолчанию можно изменить и указать слушать любой нестандартный порт, например порт 8080:

Set-Item WSMan:\localhost\listener\listener*\port -Value 8080

изменение дефолтного порта

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

На этом все. Во второй части статьи рассмотрим конфигурации удаленных сессий, создание конечных точек (endpoint), ну и что нибудь еще по мелочи 🙂

Удаленное управление компьютерами, не входящими в домен

Мы знаем, что удаленное подключение к компьютерам домена посредством PowerShell происходит практически прозрачно. Все, что нам нужно сделать, это, к примеру:

Однако, если мы попытаемся подключиться к компьютеру рабочей группы (для начала по IP-адресу), мы увидим что-то вроде:

Для чего это нужно.

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

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

В качестве второго варианта нам предлагается взять ответственность на себя и явным образом вписать все имена и IP-адреса компьютеров в TrustedHosts, что приведет к тому, что при подключении к этим компьютерам их подлинность проверяться никоим образом не будет.

Certificate

Для начала нужно установить сертификат, которому бы доверял компьютер, с которого мы будем подключаться. Если компьютер, с которого мы хотим подключиться является членом домена и в домене развернута роль Certificate Services, то можно выдать сертификат компьютеру рабочей группы через службы сертификатов. В этом случае вопрос доверия выдвнному сертификату не возникнет. Или же можно создать самоподписанный сертификат с использованием какой-либо утилиты для создания сертификатов (например, makecert) или командлета New-SelfSignedCertificate.

Итак, создаем сертификат:

Что мы тут сделали.

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

В параметре -TextExtension мы указываем значения для нескольких полей сертификата.

В отсутствие Subject Alternative Name, единстенным именем, по котому мы могли бы обратиться к компьютеру было бы имя, заданное в поле Subject.

Как видно из примера, мы использовали DNS и IPAddress. Причем никто не будет против, если имя, указанное в поле Subject мы укажем и здесь тоже.

В случае успешного завершения работы командлета будет выведено два значения: Thumbprint и Subject. Значение отпечатка (Thumbprint) нам понадобится на следующем шаге.

Listener

Вообще, мы предполагаем, что PowerShell Remoting уже включен, но если же вдруг это не так, мы можем его включить при помощи командлета:

Если же вступать в диалог с командлетом Enable-PSRemoting и отвечать на задаваемые вопросы не хочется, можно запустить его с параметром -Force.

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

Именно этот сертификат будет предъявляться подключающимся при установлении SSL-сессии. Если мы не сохранили отпечаток созданного сертификата, мы можем его получить при помощи команды:

Теперь создадим прослушиватель:

Если мы запускаем эту команду в консоли PowerShell, мы можем получить что-то вроде:

Происходит это потому, что синтаксис утилиты winrm рассчитан на обычную командную строку и он не учитывает, что у PowerShell может быть свое мнение на использование разных специальных символов.

Для того, чтобы для запуска единственной команды не переключаться в cmd, нам нужно попросить PowerShell не парсить всю введенную команду а передать все как есть утилите winrm на выполнение. Сделать мы это можем вставив следующий набор символов после имени утилиты:

Firewall

Trust Issues

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

Для того, чтобы доменный компьютер начал с большей степенью доверия относиться к созданному нами сертификату, его потребуется экспортировать из хранилища сертификатов Personal компьютера рабочей группы и импортировать в хранилище Trusted Root Certification Authorities доменного компьютера.

Экспортировать сертификат можно как при помощи Microsoft Management Console (она же mmc), так и посредством PowerShell. Так как закрытый ключ в данном случае нам не нужен, мы воспользуемся командлетом Export-Certificate.

Теперь нам нужно скопировать полученный файл на доменный компьютер (предположим, что мы скопировали его в то же место, корень диска C:) и импортировать находящийся в нем сертификат в хранилище Trusted Root Certification Authorities.

Опять же, это можно сделать как через mmc (уже на доменном компьютере), так и через PowerShell:

Enter-PSSession

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

Теперь подключиться к компьютеру рабочей группы должно увеньчаться успехом:

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

TrustedHosts

Теперь рассмотрим второй вариант, который заключается в том, что вы добавляете имена и IP-адреса всех компьютеров рабочих групп, к которым вы будете подключаться, в TrustedHosts. Результатом этого действия станет то, что ваш компьютер будет относиться к ним с определенной долей доверия и не будет пытаться проверить их подлинность.

Получить текущее значение TrustedHosts можно так:

По умолчанию какое-либо содержимое отсутствует, но если вы ранее что-то уже задавали, то новые значения нужно будет добавить к уже существующим. Опять же, так как мы хотим иметь возможность подключиться с использованием различной идентификационной информации (IP-адрес, имя, FQDN), в TrustedHosts мы добавим все три значения.

Если мы не хотим, чтобы после введения вышеприведенной команды нам приходилось подтверждать свое действие, мы можем добавить к ней параметр -Force:

Теперь мы можем подключиться к удаленному компьютеру используя прослушиватель (listener) по умолчанию. Для этого мы используем те же самые команды, за исключением параметра -UseSSL:

Server Manager

Стоит сказать, что управлять рабочими станциями через Server Manager у нас не получится, но для серверов, по тем или иным причинам не входящим в домен, это вполне себе полезная возможность.

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

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

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

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

Если вы открываете доступ для всех указав * то WinRM будет подключаться ко ВСЕМ машинам без проверки. Помните, что вы открываете самого себя для потенциального взлома из локальной сети. Лучше указывать адреса хостов куда вам нужно подключится, тогда WinRM будет отклонять все остальные адреса или имена. Если машина с которой ведется управление находится в домене она будет доверять всем машинам этого домена. Если она не в домене, или в другом домене, то нужно указать в TrustedHosts адрес или имя машины на которую мы будем подключаться. Добавлять себя на машине к которой мы подключаемся не нужно.

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

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

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

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

это не тоже самое что Enable-PSRemoting

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


Удаленные подключения
1. Сессии 1-to-1
открываются командой

Вы получите оболочку на удаленной машине. Подключится можно к самому себе указав localhost. Альтернативные кредиталы указываются с параметром -Credential, выход происходит командлетом Exit-PSSession

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

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

определяем что будем исполнять так:

передаем на удаленные машины Test1 и Test2

за раз можно забросить на 32 машины. Если альтернативные кредиталы то используем параметр -Credential

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

kuda78
В статье пропущен очень важный момент — передача параметров в скрипт на удаленной машине.

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

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

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

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

использовать можно такие же параметры подключения как в Invoke-Command

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

посмотреть какие сессии открыты можно с помощью Get-PSSession, закрыть Remove-PSSession
закрыть вообще все сессии

прицепится к сессии можно с помощью Connect-PSSession, отключиться через Disconnect-PSSession

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

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

Читайте также: