winrm vbs что это
о служба удаленного управления Windows
Компоненты WinRM и управление оборудованием
Ниже приведен список компонентов и функций, предоставляемых службой WinRM и функцией мониторинга оборудования.
Этот API-интерфейс сценариев позволяет получать данные с удаленных компьютеров с помощью сценариев, выполняющих операции WS-Management протоколов.
WinRM. cmd
это средство командной строки для управления системой реализуется в файле Visual Basic scripting Edition (Winrm.vbs), написанном с помощью API-интерфейса для сценариев WinRM. Это средство позволяет администратору настраивать WinRM и получать данные или управлять ресурсами. Дополнительные сведения см. в справке в Интернете, предоставляемой командной строкой WinRM /?.
Winrs.exe
Это средство командной строки позволяет администраторам удаленно выполнять большинство Cmd.exeных команд с помощью протокола WS-Management. Дополнительные сведения см. в справке в Интернете, предоставляемой командной строкой WinRS /?.
Драйвер IPMI и поставщик WMI
Управление оборудованием с помощью поставщика IPMI и драйвера позволяет контролировать и диагностировать аппаратное обеспечение удаленного сервера через контроллеры BMC, если операционная система не запущена или не развернута.
Дополнительные сведения см. в разделе поставщик IPMI.
Служба WMI продолжит работать параллельно с WinRM и предоставляет запрошенные данные или элементы управления через подключаемый модуль WMI. Вы можете продолжить получать данные из стандартных классов WMI, таких как _ процесс Win32, а также данных, предоставленных IPMI. Дополнительные сведения о настройке и установке, необходимые для WinRM, см. в разделе Введение в Управление оборудованием.
Протокол WS-Management, основанный на протоколе SOAP, разработан для систем, предназначенный для выявления и обмена данными управления. Цель спецификации протокола WS-Management заключается в обеспечении взаимодействия и согласованности систем предприятия, имеющих компьютеры, работающие на различных операционных системах разных поставщиков.
WS-Management протокол основан на следующих стандартных спецификациях веб-служб: HTTPS, SOAP по HTTP (WS-I Profile), SOAP 1,2, WS-Addressing, WS-передачи, WS-enumeration и WS-Eventing. Дополнительные сведения о текущем черновике спецификации см. на странице индекс спецификаций управления.
Работа с WinRM
В следующей таблице перечислены разделы, содержащие сведения о протоколе WS-Management, WinRM и WMI, а также об указании ресурсов управления, таких как дисковые накопители или процессы.
Русские Блоги
Используйте winrm.vbs, чтобы обойти белый список приложений и выполнить любой неподписанный код
Заявление о переводе
Перевод только для справки, конкретное содержание и значение оригинального текста имеют преимущественную силу.
Обойти техническое описание
winrm.vbs (сценарий подписи Windows в System32) может использовать и выполнять XSL, контролируемый злоумышленниками, и XSL не подлежитenlightened script hostMsgstr «В результате выполнения произвольного кода без знака.
Если для winrm.vbs указан параметр «-format: pretty» или «-format: text», он удалит WsmPty.xsl или WsmTxt.xsl из каталога, в котором находится cscript.exe. Это означает, что если злоумышленник скопирует cscript.exe в расположение вредоносного XSL, контролируемого злоумышленником, будет выполнен любой неподписанный код. Эта проблема на самом деле связана сCasey Smithизтехнология wmic.exeТочно так же.
Рабочий процесс вооружения выглядит следующим образом:
Вот пример «злонамеренного» XSL, который может быть помещен в каталог, контролируемый злоумышленником (в этом примере он находится в C: BypassDirWsmPty.xsl):
Правильное вооружение WsmPty.xsl может включать в себя встроенныйDotNetToJScript полезная нагрузка, которая приводит к выполнению произвольного неподписанного кода.
Методология открытия
Это открытие произошло случайно в природе. Проводил с КейсиТехнология обхода WSL.exe на основе XSL Вскоре после моего исследования я случайно просмотрел встроенные файлы VBS и JScript на предмет дополнительных методов обхода. Моя мотивация для просмотра этих типов файловMatt NelsonВдохновленный, он изначально использовал егоИнжекционная технология Purprn.vbsСтимулировал мой интерес. При чтении исходного кода winrm.vbs строки «WsmPty.xsl» и «WsmTxt.xsl» привлекли мое внимание, потому что, как продемонстрировал Кейси в своем блоге, приложения, использующие XSL, скорее всего, Внедрить содержимое сценария WSH в файл XSL для реализации произвольного выполнения кода. Конечно, winrm.vbs не является исключением.
В более широком смысле, я часто очень активно нахожу подписанные сценарии и двоичные файлы, которые позволяют выполнять произвольный, неподписанный код, потому что они не только обходят белый список приложений, но и с меньшей вероятностью обнаруживаются продуктами безопасности (по крайней мере, когда они Это не будет обнаружено, пока это не выпущено). Я всегда на охоте!
Стратегии обнаружения и уклонения
Для того чтобы этот метод позволил установить надежное обнаружение, важно определить минимальный набор компонентов, необходимых для выполнения этого метода.
WsmPty.xsl или WsmTxt.xsl, контролируемые злоумышленником, должны быть удалены.
winrm.vbs жестко кодирует WsmPty.xsl и WsmTxt.xsl и явно связывает их с параметрами «pretty» и «text». Кажется, нет никакого способа указать winrm.vbs использовать другой XSL-файл, а не текущий рабочий каталог исполняемого файла, используя полезную нагрузку XSL (то есть cscript.exe в большинстве случаев). С точки зрения обнаружения значение хэша файла WsmPty.xsl или WsmTxt.xsl отличается от значения хэша в системе 32 и должно рассматриваться как подозрительное. К счастью, значение хеш-функции легальных XSL-файлов редко изменяется.
Кроме того, легальные файлы WsmPty.xsl и WsmTxt.xsl имеют подпись каталога. Любое отклонение от этих хэшей приведет к тому, что файл больше не будет подписан. Другими словами, следует подозревать любой WsmPty.xsl или WsmTxt.xsl, который не подписан на диске. Обратите внимание, что проверка подписи каталога требует запуска службы «cryptsvc».
Подписанный winrm.vbs должен быть выполнен. Если злоумышленник хочет изменить содержимое winrm.vbs, значение этого метода обхода будет недействительным.
Обнаружение сборки, основанное на существовании winrm.vbs в командной строке, является относительно слабым, поскольку злоумышленники могут переименовать winrm.vbs в имя файла по своему выбору.
Чтобы использовать XSL-файлы, необходимо указать «format» с параметром «pretty» или «text».
Разрешить следующие нечувствительные изменения параметра для «формат»:
Хотя обнаружение того, что «формат» создан, будет фиксировать все изменения, могут возникнуть проблемы с обнаружением. Легальное использование параметра «формат» будет зависеть от организации. Однако, за исключением cscript.exe и winrm.vbs в System32, он вряд ли будет вызван по закону откуда-либо еще.
Ожидается, что winrm.vbs будет выполнен из cscript.exe. В скрипте есть логика для проверки.
Обратите внимание на обнаружение робастности
Стратегии смягчения и предотвращения
Эту технику можно предотвратить, включив контроль приложений Windows Defense (WDAC) с целостностью кода режима пользователя (UMCI). Уязвимая версия скрипта должна быть заблокирована хешами, потому что нет другого надежного способа предотвратить уязвимые подписанные скрипты. Однако сложно идентифицировать все уязвимые версии сценария, поскольку защитник вряд ли сможет зафиксировать все значения хеш-функции всех уязвимых версий Winrm.vbs во всех возможных версиях Windows.Эта статьяНедействительность сценария черного списка вводится более подробно.
Что касается смягчения, Microsoft может исправить проблему в сценарии и выпустить новую подпись каталога. Это сделает ранее уязвимую версию скрипта неподписанной. Следовательно, если WDAC используется для принудительного подписывания скрипта, ранее уязвимая версия winrm.vbs не будет выполняться. Тем не менее, эта схема только не позволяет администраторам выполнять уязвимую версию winrm.vbs. Злоумышленник, работающий от имени администратора, может установить предыдущую подпись каталога, тем самым восстанавливая возможность запуска уязвимой версии winrm.vbs.
Обе вышеупомянутые схемы предотвращения / смягчения полагаются на реализацию WDAC. Учитывая, что в большинстве организаций WDAC не будет включен, даже с фиксированным winrm.vbs, он не сможет помешать злоумышленнику поместить уязвимую версию winrm.vbs на диск и выполнить операцию. Наконец, действительно нет надежного профилактического решения, даже если исправлен winrm.vbs.
WSH/XSL Script
Это не первый раз и, конечно, не последний раз, когда XSL и WSH подвергались нападениям со стороны злоумышленников. В идеале злоумышленник должен видеть, была ли полезная нагрузка выполнена с диска или полностью в памяти. Powershell имеет это использованиежурнал сценария Готовые возможности. Однако WSH не имеет такого эквивалента. сИнтерфейс антивирусного сканированияВведение (AMSI), если вы хотите использовать ETW, возможно захватить контент WSH.
AMSI Optics можно приобрести у поставщика Microsoft-Antimalware-Scan-Interface ETW. Если вы хотите попытаться захватить события AMSI, одной из лучших библиотек, которые вы можете использовать, является KrabsETW. Однако для простоты вы можете использовать logman.exe для захвата трассировки ETL. Например, следующая команда запустит и остановит трассировку ETW и сохранит события, связанные с AMSI, в AMSITrace.etl:
Хотя механизм ETW выходит за рамки данной статьи, вам может быть интересно, как я узнал о провайдере ETW Microsoft-Antimalware-Scan-Interface и откуда появилось ключевое слово «Event1».
Используя команду logman query provider для запроса зарегистрированных провайдеров, я знаю имя провайдера ETW. «Событие1» соответствует ключевому слову, которое захватывает контекст AMSI. Чтобы найти ключевое слово, я использовалperview.exeДамп список ETW в XML. Список также дает вам представление о событиях, которые могут быть собраны через поставщика.
После захвата трассировки вы увидите содержимое выполненной полезной нагрузки.
Понимание оптики и масштабов тестирования на основе ETW выходит за рамки этой статьи, но надеюсь, что этот пример вдохновит вас на дальнейшее изучение.
график
Как SpecterOps стремится к улучшениюпрозрачностьТочно так же мы признаем скорость, с которой злоумышленник публично применяет новые методы нападения. Вот почему перед выпуском новой технологии атаки мы будем регулярно уведомлять соответствующих поставщиков о проблеме, предоставлять достаточное время для ее устранения и уведомлять выбранных надежных поставщиков о том, что обнаружение может быть доставлено Их клиенты.
Поскольку эта технология влияет на контроль приложений защиты Windows (доступные функции безопасности, предоставляемые через MSRC), об этой проблеме было сообщено в Microsoft. График раскрытия выглядит следующим образом:
создание сценариев в служба удаленного управления Windows
API скриптов в WinRM и СОПУТСТВУЮЩИЙ API COM для C++ предназначены для точного отражения операций протокола WS-Management.
API скриптов WinRM в служба удаленного управления Windows поддерживает все операции WS-Management протоколов, кроме одного. Он не допускает подписки на события. Чтобы подписываться на события из журнала системных событий BMC, необходимо использовать программы командной строки wecutil или wevtutil. Дополнительные сведения см. в статье Events (Visual Basic) (События в Visual Basic).
API-интерфейс сценариев WinRM вызывается Winrm.vbs, программой командной строки, написанной в Visual Basic scripting Edition (VBScript). В Winrm.vbs приводятся примеры использования API-интерфейса сценариев WinRM.
Использование WSman по сравнению с использованием сценариев WMI
WMI подключается к удаленным компьютерам через DCOM, что требует настройки, описанной в разделе Подключение к WMI на удаленном компьютере. WinRM не использует DCOM для подключения к удаленному компьютеру. Вместо этого протокол WS-Management отправляет сообщения SOAP, а служба использует один порт для HTTP и порт для транспорта HTTPS.
Сценарий WinRM не возвращает объекты, а потоки XML-текста. дополнительные сведения см. в разделе служба удаленного управления Windows и инструментарий WMI.
Отображение выходных данных XML из скриптов WinRM
API сценариев WinRM получает и получает XML-строки, описывающие ресурсы. Результирующий XML-код представлен в виде текстового потока и требует, чтобы преобразование XML было представлено каким-либо другим способом.
Следующий сценарий WinRM создает необработанные выходные данные в формате XML.
Следующий блок текста показывает выходные XML-данные сценария WinRM.
Скрипты могут использовать преобразование XML, чтобы сделать эти выходные данные более удобочитаемыми. Дополнительные сведения см. в разделе вывод XML-данных из скриптов WinRM.
Следующая версия скрипта форматирует XML-код в виде выходного человека.
Преобразование «XSL» создает следующие выходные данные.
Сценарий WinRM и выходные данные WinRM. cmd
Выходные данные сценария WinRM кодируются в Юникоде. При создании FileSystemObject и записи файла из скрипта полученный файл будет иметь кодировку Unicode. Однако при перенаправлении выходных данных в файл используется кодировка ANSI. При перенаправлении выходных данных в XML-файл и наличии в выходных данных символов Юникода XML-код будет недопустимым. Имейте в виду, что программа командной строки WinRM выводит значение ANSI.
установка и настройка для служба удаленного управления Windows
для выполнения сценариев служба удаленного управления Windows (winrm) и для выполнения операций с данными с помощью программы командной строки winrm служба удаленного управления Windows (winrm) должны быть установлены и настроены.
Эти элементы также зависят от конфигурации WinRM.
Где установлен WinRM
служба WinRM автоматически устанавливается со всеми поддерживаемыми версиями Windows операционной системы.
Настройка WinRM и IPMI
Эти компоненты поставщика службы удаленного управления (IPMI) и SNMP-интерфейса WMI устанавливаются вместе с операционной системой.
Используйте Winrm команду, чтобы нахождение прослушивателей и адресов, введя в командной строке следующую команду.
Чтобы проверить состояние параметров конфигурации, введите следующую команду.
Быстрая настройка по умолчанию
winrm quickconfig Команда (или сокращенная версия winrm qc ) выполняет эти операции.
winrm quickconfig Команда создает исключение брандмауэра только для текущего профиля пользователя. Если профиль брандмауэра изменился по какой-либо причине, следует запустить, winrm quickconfig чтобы включить исключение брандмауэра для нового профиля; в противном случае исключение может быть не включено.
Чтобы получить сведения о настройке конфигурации, введите winrm help config в командной строке.
Настройка WinRM с параметрами по умолчанию
Введите winrm quickconfig в командной строке.
Если вы не используете учетную запись администратора локального компьютера, необходимо выбрать пункт Запуск от имени администратора в меню » Пуск » или использовать команду runas в командной строке.
Если настройка прошла успешно, отображаются следующие выходные данные.
Используйте параметры по умолчанию для клиентских и серверных компонентов WinRM или настройте их. Например, может потребоваться добавить определенные удаленные компьютеры в список TrustedHosts конфигурации клиента.
Если невозможно установить взаимную проверку подлинности, следует настроить список надежных узлов. Kerberos допускает взаимную проверку подлинности, но не может использоваться — только в доменах рабочих групп. При настройке доверенных узлов для Рабочей группы рекомендуется сделать список максимально ограниченным.
Параметры по умолчанию прослушивателя и протокола WS-Management
Чтобы получить конфигурацию прослушивателя, введите winrm enumerate winrm/config/listener в командной строке. Прослушиватели определяются транспортом (HTTP или HTTPS) и адресом IPv4 или IPv6.
winrm quickconfig создает следующие параметры по умолчанию для прослушивателя. Можно создать более одного прослушивателя. Для получения дополнительных сведений введите winrm help config в командной строке.
Адрес
Задает адрес, для которого был создан данный прослушиватель.
Транспортировка
Задает TCP-порт, для которого создается данный прослушиватель.
WinRM 2,0: HTTP-порт по умолчанию — 5985.
Hostname (Имя узла)
Указывает имя узла компьютера, на котором запущена служба WinRM. Значением должно быть полное доменное имя, строка литерала IPv4 или IPv6 или символ-шаблон.
Активировано
Указывает, включен или отключен прослушиватель. По умолчанию используется значение True.
URLPrefix
Указывает URL-префикс для приема запросов HTTP или HTTPS. Это строка, содержащая только символы a – z, A – Z, 9-0, символ подчеркивания ( _ ) и косую черту (/). Строка не должна начинаться с косой черты или заканчиваться ей (/). Например, если имя компьютера — самплемачине, то клиент WinRM будет указывать https://SampleMachine/ в адресе назначения. Префикс URL-адреса по умолчанию — WSMan.
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
Указывает URL-префикс для приема запросов HTTP или HTTPS. Префикс URL-адреса по умолчанию — WSMan.
алловуненкриптед
Позволяет клиентскому компьютеру запрашивать передачу данных в незашифрованном виде. По умолчанию клиентский компьютер требует зашифрованный сетевой трафик, а этот параметр имеет значение false.
Basic
Позволяет клиентскому компьютеру использовать обычную проверку подлинности. При использовании обычной проверки подлинности имя пользователя и пароль передаются серверу или прокси-серверу открытым текстом. Эта схема является наименее безопасным методом проверки подлинности. Значение по умолчанию равно True.
Digest (дайджест)
Позволяет клиентскому компьютеру использовать дайджест-проверку подлинности. Дайджест-проверка подлинности проводится по принципу «запрос-ответ». В качестве запроса поступает строка данных, указанная сервером. Инициировать запрос дайджест-проверки подлинности может только клиентский компьютер. Клиентский компьютер отправляет запрос на сервер для проверки подлинности и получает строку токена с сервера. Затем клиентский компьютер отправляет запрос ресурса, включая имя пользователя и криптографический хэш пароля, в сочетании со строкой токена. Дайджест-проверка подлинности поддерживается для HTTP и для HTTPS. Клиентские скрипты и приложения оболочки WinRM могут указывать дайджест-проверку подлинности, но служба WinRM не принимает дайджест-проверку подлинности. Значение по умолчанию равно True.
Дайджест-проверка подлинности по протоколу HTTP не считается безопасной.
Сертификат
Позволяет клиенту использовать проверку подлинности на основе сертификата клиента. Проверка подлинности на основе сертификатов — это схема, в которой сервер проверяет подлинность клиента, идентифицируемого сертификатом X509. Значение по умолчанию равно True.
Kerberos
Позволяет клиентскому компьютеру использовать проверку подлинности Kerberos. Проверка подлинности Kerberos подразумевает взаимную проверку подлинности клиента и сервера с использованием сертификатов Kerberos. Значение по умолчанию равно True.
Согласование
Позволяет клиенту использовать проверку подлинности согласованием. При проверке подлинности с согласованием клиент отправляет серверу запрос на проверку подлинности. Сервер определяет, какой протокол использовать — Kerberos или NTLM. Протокол Kerberos выбирается для проверки подлинности учетной записи домена, а NTLM — для учетных записей локального компьютера. Имя пользователя должно быть указано в \ _ формате имени пользователя домена для пользователя домена. Имя пользователя должно быть указано в _ формате «имя \ пользователя сервера _ » для локального пользователя на компьютере сервера. Значение по умолчанию равно True.
CredSSP
Позволяет клиенту использовать проверку подлинности с помощью поставщика поддержки безопасности учетных данных (CredSSP). CredSSP позволяет приложению делегировать учетные данные пользователя с клиентского компьютера на целевой сервер. По умолчанию False.
дефаултпортс
Указывает порты, которые клиент будет использовать для HTTP или HTTPS.
WinRM 2,0: HTTP-порт по умолчанию — 5985, а HTTPS-порт по умолчанию — 5986.
TrustedHosts
Указывает список доверенных удаленных компьютеров. В этот список необходимо добавить другие компьютеры в Рабочей группе или компьютерах в другом домене.
Компьютеры в списке TrustedHosts не проходят проверку подлинности. Клиент может отправить учетные данные на эти компьютеры.
Параметры конфигурации по умолчанию для службы WinRM
Версия службы WinRM имеет следующие параметры конфигурации по умолчанию.
RootSDDL
Указывает дескриптор безопасности, управляющий удаленным доступом к прослушивателю. Значение по умолчанию — «О:НСГ: BAD: P (A;; Общедоступный;;; BA) (A;; GR;;; ER) С:П (AU; FA; Общедоступный;;; WD) (AU; SA; ГВГКС;;; WD) «.
максконкуррентоператионс
Максимальное количество одновременных операций. Значение по умолчанию — 100.
WinRM 2,0: Параметр Максконкуррентоператионс является устаревшим и имеет значение только для чтения. Этот параметр заменен на свойств maxconcurrentoperationsperuser.
Свойств maxconcurrentoperationsperuser
Указывает максимальное количество одновременных операций, которые любой пользователь может удаленно открыть в одной системе. Значение по умолчанию — 1500.
енумератионтимеаутмс
Указывает время ожидания простоя в миллисекундах между сообщениями о вытягиваниех. Значение по умолчанию — 60000.
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
Задает политику относительно требований к токенам привязки канала в запросах проверки подлинности. Значение по умолчанию — ослабление.
дефаултпортс
Указывает порты, которые служба WinRM будет использовать как для HTTP, так и для HTTPS.
WinRM 2,0: HTTP-порт по умолчанию — 5985, а HTTPS-порт по умолчанию — 5986.
IPv4Filter и IPv6Filter
IPv4: Литеральная строка IPv4 состоит из четырех десятичных чисел с точками в диапазоне от 0 до 255. Например: 192.168.0.0.
енаблекомпатибилитихттплистенер
Указывает, включен ли прослушиватель совместимости HTTP. Если этот параметр имеет значение true, прослушиватель будет прослушивать порт 80 в дополнение к порту 5985. По умолчанию False.
енаблекомпатибилитихттпслистенер
Указывает, включен ли HTTPS-прослушиватель совместимости. Если этот параметр имеет значение true, прослушиватель будет прослушивать порт 443 в дополнение к порту 5986. По умолчанию False.
Параметры конфигурации по умолчанию для 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 для компьютеров в вашей организации.
Настройка с помощью групповая политика
Windows Порты брандмауэра и WinRM 2,0
Начиная с WinRM 2,0, порты прослушивателя по умолчанию, настроенные, Winrm quickconfig — это порт 5985 для транспорта HTTP и порт 5986 для HTTPS. Прослушиватели WinRM можно настроить для любого произвольного порта.
Если компьютер обновлен до WinRM 2,0, ранее настроенные прослушиватели переносятся и по-прежнему получают трафик.
Заметки об установке и настройке WinRM
Служба WinRM не зависит от других служб, кроме WinHttp. если служба iis Admin установлена на том же компьютере, могут отображаться сообщения, указывающие, что WinRM невозможно загрузить до службы IIS (IIS). Однако WinRM не зависит от IIS, — так как эти сообщения возникают из-за того, что служба IIS запускается до службы HTTP. Для WinRM требуется WinHTTP.dll регистрация.
Если на компьютере установлен клиент брандмауэра ISA2004, это может привести к тому, что клиент веб-служб для управления (WS-Management) перестает отвечать на запросы. Чтобы избежать этой проблемы, установите брандмауэр ISA2004 с пакетом обновления 1 (SP1).
Если для двух служб прослушивателя с разными IP-адресами настроен один и тот же номер порта и имя компьютера, служба WinRM прослушивает или получает сообщения только по одному адресу. Это обусловлено тем, что префиксы URL-адресов, используемые протоколом WS-Management, одинаковы.
Заметки об установке драйвера и поставщика IPMI
Драйвер может не обнаружить наличие драйверов IPMI, которые не относятся к корпорации Майкрософт. Если драйвер не запускается, может потребоваться отключить его.
Поставщик IPMI помещает классы оборудования в корневое пространство имен \ оборудования WMI. Дополнительные сведения о классах оборудования см. в разделе поставщик IPMI. Дополнительные сведения о пространствах имен WMI см. в разделе Архитектура WMI.
Примечания по конфигурации подключаемого модуля WMI
Когда появится пользовательский интерфейс, добавьте пользователя.