Wmi подключение к удаленному компьютеру
для подключения к пространству имен WMI на удаленном компьютере может потребоваться изменить параметры брандмауэра Windows, контроля учетных записей (UAC), DCOM или модель CIM диспетчера объектов (CIMOM).
В этом разделе обсуждаются следующие разделы:
Параметры брандмауэра Windows
параметры wmi для Windows параметры брандмауэра позволяют использовать только подключения WMI, а не другие приложения DCOM.
Необходимо задать исключение в брандмауэре для инструментария WMI на удаленном целевом компьютере. Исключение для WMI позволяет инструментарию WMI принимать удаленные подключения и асинхронные обратные вызовы для Unsecapp.exe. Дополнительные сведения см. в разделе Настройка безопасности при асинхронном вызове.
Если клиентское приложение создает собственный приемник, этот приемник необходимо явно добавить в исключения брандмауэра, чтобы разрешить успешные обратные вызовы.
Исключение для WMI также работает, если Инструментарий WMI запущен с фиксированным портом с помощью команды Winmgmt/стандалонехост . Дополнительные сведения см. в разделе Настройка фиксированного порта для WMI.
вы можете включить или отключить трафик WMI через пользовательский интерфейс брандмауэра Windows.
Включение или отключение трафика WMI с помощью пользовательского интерфейса брандмауэра
- на панели управления щелкните безопасность , а затем — Windows брандмауэр.
- нажмите кнопку изменить Параметры а затем перейдите на вкладку исключения .
- в окне исключения установите флажок для инструментарий управления Windows (WMI) (WMI) , чтобы включить трафик wmi через брандмауэр. Чтобы отключить трафик WMI, снимите флажок.
Вы можете включить или отключить трафик WMI через брандмауэр в командной строке.
Включение или отключение трафика WMI в командной строке с помощью группы правил WMI
Используйте следующие команды в командной строке. Введите следующую команду, чтобы включить трафик WMI через брандмауэр.
netsh advfirewall firewall set Rule Group = "Инструментарий управления Windows (WMI)" новое включение = да
Введите следующую команду, чтобы отключить трафик WMI через брандмауэр.
netsh advfirewall firewall set Rule Group = "Инструментарий управления Windows (WMI)" новое включение = нет
Вместо использования одной команды группы правил WMI можно также использовать отдельные команды для каждой DCOM, службы WMI и приемника.
Включение трафика WMI с помощью отдельных правил для DCOM, WMI, приемника обратного вызова и исходящих подключений
Чтобы установить исключение брандмауэра для порта DCOM 135, используйте следующую команду.
netsh advfirewall Firewall добавить правило dir = in Name = "DCOM" Program =% systemroot% \ system32 \svchost.exe Service = RPCSS Action = Allow Protocol = TCP localPort = 135
Чтобы установить исключение брандмауэра для службы WMI, используйте следующую команду.
netsh advfirewall Firewall Add правило dir = in Name = "WMI" Program =% системный_корневой_каталог% \ system32 \svchost.exe Service = Winmgmt Action = Allow Protocol = TCP localPort = Any
Чтобы установить исключение брандмауэра для приемника, который получает обратные вызовы с удаленного компьютера, используйте следующую команду.
netsh advfirewall Firewall добавить правило dir = in имя = "Унсекапп" Program =% systemroot% \ system32 \ WBEM \unsecapp.exe действие = разрешить
Чтобы установить исключение брандмауэра для исходящих подключений к удаленному компьютеру, с которым локальный компьютер обменивается данными в асинхронном режиме, используйте следующую команду.
netsh advfirewall Firewall добавить правило DIR = OUT имя = "WMI _ out" программа =% SystemRoot% \ system32 \svchost.exe служба = Winmgmt Action = разрешить протокол = TCP localPort = Any
Чтобы отключить исключения брандмауэра по отдельности, используйте следующие команды.
Отключение трафика WMI с помощью отдельных правил для DCOM, WMI, приемника обратного вызова и исходящих подключений
Для отключения исключения DCOM.
netsh advfirewall Firewall Delete Rule Name = "DCOM"
Для отключения исключения службы WMI.
netsh advfirewall Firewall Delete Rule Name = "WMI"
Для отключения исключения приемника.
netsh advfirewall Firewall Delete Rule Name = "Унсекапп"
, Чтобы отключить исходящее исключение.
netsh advfirewall Firewall удаление правила Name = "WMI _ out"
Параметры контроля учетных записей
Управление учетными записями пользователей (UAC) — фильтрация маркеров может влиять на то, какие операции разрешены в пространствах имен WMI или какие данные возвращаются. В разделе UAC все учетные записи в локальной группе "Администраторы" выполняются с маркером доступаобычного пользователя, также известным как фильтрация маркера доступа UAC. Учетная запись администратора может выполнять скрипт с повышенными привилегиями — "Запуск от имени администратора".
При отсутствии подключения к встроенной учетной записи администратора UAC влияет на подключения к удаленному компьютеру по-разному в зависимости от того, находятся ли два компьютера в домене или рабочей группе. Дополнительные сведения об UAC и удаленных подключениях см. в разделе Управление учетными записями пользователей и инструментарий WMI.
Параметры DCOM
Дополнительные сведения о параметрах DCOM см. в разделе Защита удаленного WMI-подключения. Однако UAC влияет на подключения для недоменных учетных записей пользователей. При подключении к удаленному компьютеру с использованием недоменной учетной записи пользователя, входящей в локальную группу администраторов удаленного компьютера, необходимо явным образом предоставить учетной записи права удаленного доступа DCOM, активации и запуска.
Параметры CIMOM
Необходимо обновить параметры CIMOM, если удаленное подключение установлено между компьютерами, не имеющими отношения доверия. в противном случае асинхронное соединение завершится ошибкой. Этот параметр не следует изменять для компьютеров в том же домене или в доверенных доменах.
Чтобы разрешить анонимный обратный вызов, необходимо изменить следующую запись реестра:
HKey _ _ \ Программное обеспечение локального компьютера \ Microsoft \ WBEM \ CIMOM \ аллованонимаускаллбакк
Если значение аллованонимаускаллбакк равно 0, то служба WMI предотвращает анонимный обратный вызов клиента. Если значение равно 1, служба WMI разрешает клиенту анонимные обратные вызовы.
Инструментарий WMI можно использовать для управления и доступа к данным WMI на удаленных компьютерах. На удаленные подключения в WMI влияют параметры брандмауэра Windows и DCOM. Для контроля учетных записей (UAC) также могут потребоваться изменения некоторых параметров. Однако после настройки параметров вызов удаленной системы будет очень похож на локальный вызов WMI. Тем не менее, вы можете сделать его более сложным, используя разные учетные данные, альтернативные протоколы проверки подлинности и другие функции безопасности.
Настройка компьютера для удаленного подключения
Прежде чем получить доступ к удаленной системе с помощью инструментария WMI, может потребоваться проверить некоторые параметры безопасности, чтобы убедиться, что у вас есть доступ. В частности, внесены следующие изменения.
Windows содержит ряд функций безопасности, которые могут блокировать доступ к сценариям в удаленных системах. Таким образом, может потребоваться изменить параметры системы Active Directory и брандмауэра Windows перед вызовом инструментария WMI. Дополнительные сведения см. в разделе Настройка удаленного WMI-подключения и Устранение неполадок удаленного WMI-подключения.
Чтобы удаленное подключение работало, необходимо включить правильные параметры DCOM. Изменение параметров DCOM позволяет пользователям с ограниченными правами получать доступ к компьютеру для удаленного подключения. Дополнительные сведения см. в разделе Защита удаленного WMI-подключения.
Кроме того, в некоторых случаях может потребоваться запустить Инструментарий WMI, хотя фиксированный порт. Для этого также потребуется изменить параметры. Дополнительные сведения см. в разделе Настройка фиксированного порта для WMI.
Подключение к удаленному компьютеру
По сути, подключение к удаленной системе с помощью инструментария WMI состоит в том, что у вас есть соответствующие разрешения на доступ к системе и правильно настроено подключение. После получения этих двух элементов соединение само по себе является сравнительно простым. Например, если вы используете учетные данные безопасности по умолчанию, вы можете получить доступ к инструментарию WMI в удаленной системе, используя следующий код:
Используйте параметр -ComputerName , общий для большинства командлетов WMI, например Get-WmiObject.
Используйте моникер, содержащий имя удаленной системы в вызове GetObject.
Для текущей версии управляемого интерфейса WMI (Microsoft. Management. Infrastructure) используйте объект CimSession для представления подключения к удаленному узлу.
Для версии v1 управляемого интерфейса WMI (System. Management) используйте объект манажементскопе для представления подключения к удаленному узлу.
Используйте метод ивбемлокатор:: коннектсервер , чтобы указать имя удаленного компьютера в параметре стрнетворкресаурце .
Предыдущие примеры кода, вероятно, являются самым простым удаленным подключением, которое можно выполнять с помощью инструментария WMI. В частности, в примерах предполагается следующее:
- Вы являетесь администратором на удаленном компьютере. Из-за контроля учетных записей пользователяучетная запись в удаленной системе должна быть учетной записью домена в группе администраторов. Дополнительные сведения см. в разделе Управление учетными записями пользователей и инструментарий WMI.
- Пароль на текущем локальном компьютере не пуст. По сути, это требование безопасности Windows, которое необходимо войти в систему с паролем.
- Как локальные, так и удаленные компьютеры находятся в одном домене. Если необходимо использовать междоменные границы, необходимо указать дополнительные сведения или воспользоваться немного другой моделью программирования.
- Для доступа к удаленному компьютеру используется собственная учетная запись. Если вы пытались получить доступ к другой учетной записи, вам потребуется указать дополнительные учетные данные. (Обратите внимание, что попытка доступа к инструментарию WMI локально с учетными данными, отличными от текущей учетной записи, не разрешено)
- Оба компьютера работают под управлением IPv6. WMI поддерживает подключения к компьютерам с IPv6. Однако на локальном компьютере и компьютере _ B должен быть установлен протокол IPv6. На одном из компьютеров может также работать протокол IPv4. Дополнительные сведения см. в разделе Поддержка IPv6 и IPv4 в WMI.
- Ваш сценарий не обязан делегировать, т. е. ему не требуется доступ к дополнительным удаленным компьютерам через Целевой Удаленный компьютер. Дополнительные сведения см. в разделе делегирование с помощью WMI.
- Вы пытаетесь выполнить конкретный вызов, а не создавать удаленный процесс. Дополнительные сведения см. в статье Удаленное создание процессов с помощью WMI.
Учитывая эти ограничения, удаленный вызов WMI очень напоминает локальный вызов WMI. Единственное отличие заключается в том, что необходимо указать имя удаленной системы. Однако вы можете изменить многие из этих функций: использовать другие учетные данные или маршрутизацию вызова через другой компьютер или доступ к другому домену.
Вы можете создать удаленное подключение к инструментарию WMI с помощью VBScript, создав объект соединения. Этот объект содержит имя компьютера, пространство имен WMI, к которому необходимо подключиться, а также соответствующие учетные данные и уровни проверки подлинности.
Подключение к удаленной системе с помощью VBScript
Укажите сведения о соединении, такие как имя удаленного компьютера, учетные данные и уровень проверки подлинности для подключения.
При подключении к удаленному компьютеру с использованием тех же учетных данных (домен и имя пользователя), которые вошли в систему, можно указать сведения о соединении в моникере GetObject, как описано в следующем примере кода.
В общем случае следует указать пространство имен WMI для подключения к удаленному компьютеру. Это связано с тем, что пространство имен по умолчанию может не совпадать на разных компьютерах. Указание пространства имен гарантирует подключение к одному и тому же пространству имен на всех компьютерах.
Дополнительные сведения о константах VBScript и строках сценариев для использования моникера Connection см. в разделе Задание уровня безопасности процесса по умолчанию с помощью VBScript.
Если вы подключаетесь к удаленному компьютеру в другом домене или используете другое имя пользователя и пароль, необходимо использовать метод SWbemLocator. коннектсервер .
Как и в случае с моникером, вы используете коннектсервер для указания учетных данных, уровня проверки подлинности и пространства имен для удаленного подключения. В следующем примере кода описывается использование Коннектсервер для доступа к удаленному компьютеру с использованием учетной записи администратора и пароля.
При использовании функции коннектсервер для удаленных соединений настройте олицетворение и проверку подлинности для объекта безопасности, полученного при вызове SwbemServices. Security. Для указания уровня олицетворения можно использовать перечисление вбемимперсонатионлевеленум .
В следующем примере кода задается уровень олицетворения для предыдущего примера кода VBScript.
Обратите внимание, что для некоторых подключений требуется определенный уровень проверки подлинности. Дополнительные сведения см. в разделе Установка клиентских приложений безопасность и Защита клиентов скриптов.
После установки соединения можно продолжить доступ к данным WMI. Дополнительные сведения см. в разделе задачи WMI для скриптов и приложений.
Примеры
Более крупный пример на языке VBScript см. в разделе "примеры" на странице справочника по SWbemLocator. коннектсервер .
Следующий пример кода VBScript подключается к группе удаленных компьютеров в том же домене, создавая массив имен удаленных компьютеров, а затем отображая имена самонастраивающийся устройств — экземпляры Win32 _ пнпентити— на каждом компьютере. Для выполнения приведенного ниже сценария необходимы права администратора на удаленных компьютерах. Обратите внимание, что параметр " \ \ ", необходимый перед именем удаленного компьютера, добавляется скриптом после настройки уровня олицетворения. Дополнительные сведения о путях WMI см. в разделе Описание расположения объекта WMI.
Следующий пример кода VBScript позволяет подключиться к удаленному компьютеру с использованием других учетных данных. Например, удаленный компьютер в другом домене или подключение к удаленному компьютеру, для которого требуется другое имя пользователя и пароль. В этом случае используйте подключение SwbemServices. коннектсервер .
В наше время даже для собак придумали удаленное управление.
Возвращаясь к циклу «Конспект Админа», мне хотелось бы рассказать о вариантах запуска исполняемых программ на удаленных компьютерах. Эта статья будет интересна тем, у кого еще нет систем централизованного управления, но уже есть понимание утомительности ручного обхода рабочих станций и серверов. Либо тем, кому решения «под ключ» не интересны ввиду неспортивности.
В качестве того, зачем нужен такой запуск программ, можно привести недавнюю истерию с Петей\Не-Петей, когда все бросились проверять\отключать SMBv1 и загружать обновления. Да и провести инвентаризацию или установить срочный патч таким методом тоже можно.
Когда-то давно я устроился работать в организацию в период эпидемии Kido\Conficker. Наиболее простым способом выяснить, все ли хорошо в ИС компании, была славная утилита от Касперского под названием Kido Killer, которая проверяла наличие вируса и устраняла его. Запускать программу на доброй сотне машин руками было невесело, поэтому пришлось знакомиться с автоматизацией.
Если в операционных системах *nix для удаленного запуска, как правило, используется SSH, то у Windows способов запуска программ и скриптов воистину как песка в пустыне. Я разберу основные варианты, как общеизвестные, так и экзотические. Таких очевидных вещей как telnet-сервер касаться не буду, тем более Microsoft уже убрала его из современных ОС.
Psexec
Пожалуй, это первое, что приходит на ум, когда идет речь об удаленном запуске программ. Утилита от Марка Руссиновича используется еще со времен Windows NT и до сих пор применяется. Помимо основной функции, можно использовать ее и как Runas, и для запуска программ в пользовательской сессии терминального сервера. Psexec также позволяет задавать ядра процессора, на которых будет запускаться программа, и ее приоритет в системе.
В качестве примера посмотрим, установлено ли обновление, закрывающее нашумевшую уязвимость SMB на списке компьютеров:
В файле computers.txt находится список компьютеров. Для запуска по всему домену можно использовать \\*. В файле \\server\share\log.txt будут появляться имена рабочих станций или серверов без обновления. Если в домене существуют компьютеры с *nix на борту или нет доступа к административному сетевому ресурсу Admin$ ― команда на этой машине не выполнится, но обработка продолжится. Чтобы скрипт не зависал при каждой попытке подключения, можно задать тайм-аут с помощью ключа -n.
Если компьютер выключен ― мы об этом не узнаем. Поэтому лучше предварительно проверять доступность машин или собирать в файле информацию об успешном или неудачном выполнении.
К минусам Psexec можно отнести то, что она из-за своего удобства и популярности часто используется вирусописателями. Поэтому антивирусные системы могут обнаруживать утилиту как опасность вида remote admin.
По умолчанию процесс на удаленной машине выполняется от имени пользователя, запустившего Psexec. При необходимости логин и пароль можно задать явно или же использовать аккаунт SYSTEM.
Для управления системами Windows с помощью разных графических утилит часто используется WMI (Windows Management Instrumentation) ― реализация объектно-ориентированного стандарта управления WBEM. В качестве утилиты с графическим интерфейсом для работы с WMI можно использовать wbemtest.exe.
Для работы с WMI из консоли создана wmic.exe. Например, для проверки установленных обновлений вместо жутковатой конструкции из предыдущего примера можно использовать простую команду:
Использовать список компьютеров также можно командой /node:"@computers.txt".
Еще при помощи WMI можно запускать программы – синтаксис предельно прост:
К сожалению, в отличие от Psexec, получить вывод в консоли не получится ― придется выводить результаты команды в файл.
По умолчанию процесс на удаленной машине выполняется от имени пользователя, запустившего wmic. При необходимости логин и пароль можно задать явно.
Групповые политики и скрипты
Если предыдущие варианты не требовали доменной среды, то в этом случае потребуется домен. Поддерживаются скрипты при входе и выходе пользователя из системы, а также при ее включении и выключении. Поскольку каждый администратор Windows сталкивался с ними, я не буду подробно расписывать как ими пользоваться ― лишь напомню, где их искать.
Скрипты, выполняющиеся при старте и завершении системы.
Скрипты, выполняющиеся при входе и выходе пользователя из системы.
Скрипты, настраиваемые в пользовательском разделе, выполняются от имени пользователя, а в разделе компьютера ― под аккаунтом SYSTEM.
Назначенные задания
Довольно интересный способ, заслуживающий право на жизнь. Назначенные задания можно создавать из командной строки при помощи утилиты schtasks.exe, выполнять их, затем удалять. Подробнее с синтаксисом можно ознакомиться в документации, я же разберу пример использования назначенных заданий в доменной среде. Предположим, нам нужно выполнить команду как можно быстрее вне зависимости от того, выключен компьютер или нет. Для этого используются так называемые предпочтения групповых политик (Group Policy Preference).
Искать установку назначенных заданий следует в конфигурации компьютера или пользователя ― «Настройка ― Параметры панели управления ― Назначенные задания».
Создание нового назначенного задания.
Для выполнения команды или скрипта ASAP понадобится создать «Немедленную задачу (Windows 7 и выше)». Если вдруг в инфраструктуре остались машины под управлением Windows XP, то подойдет «Очередное задание (Windows XP)».
Стоит сделать несколько политик с соответствующими WMI-фильтрами или создать два разных назначенных задания в одной политике с нацеливанием ― например, при помощи того же WMI-фильтра. Это поможет избежать конфликтов в разнородной среде со старыми и новыми Windows.
Пример WMI-фильтра для применения политики только на компьютерах с Windows XP:
В остальном процедура создания назначенного задания тривиальна. Единственное, не забывайте отметить пункт «Применить один раз и не применять повторно», если задача не требует повторного запуска.
Запускаем немедленную задачу только один раз.
При использовании таких назначенных заданий программа запустится, как только компьютер получит обновление групповой политики. Это удобно: не нужно проверять доступность компьютеров в случае Psexec и wmic и заставлять пользователей перезагружать машины, как в случае скриптов групповых политик. При необходимости можно скопировать файл скрипта локально в разделе «Настройка ― Конфигурация Windows ― Файлы».
Назначенные задания позволяют явно задать имя пользователя для запуска программы, в том числе и для SYSTEM.
Через реестр
Модификация реестра на пользовательских машинах ― странный вариант, лишь на случай крайней необходимости. Можно использовать ветки Run или RunOnce. Подробнее о них ― в документации. Сама модификация реестра может проводиться через групповые политики или из командной строки ― например, такой командой:
В зависимости от ветки реестра, процесс будет выполняться или под пользователем, выполнившим вход в систему, или под аккаунтом SYSTEM.
Есть и другие способы, такие как правка ярлыков в папке «Автозагрузка» или добавление в ярлык к популярной программе && script.cmd, но эти методы уже из серии «можно, но не нужно».
Теперь перейдем к новым инструментам.
PowerShell, оправдывая свое название, может подключаться к удаленным компьютерам при помощи WMI, RPC и WS-Management (WSMan). Использование последнего метода требует предварительной настройки.
Командлеты, не требующие предварительной настройки, как правило, имеют параметр ComputerName, но не имеют параметра Session. Посмотреть список таких командлетов можно командой:
Для настройки WSMan в общем случае достаточно выполнить команду Enable-PSRemoting-Force. Она запустит службу удаленного управления WinRM и пропишет исключения в фаерволе ― в принципе, это можно сделать для всего домена при помощи групповых политик. Подробнее настройка описана в документации.
После того как все компьютеры будут готовы принимать запросы, мы сможем подключаться при помощи соответствующих командлетов PowerShell. Для проверки возможности подключения используется командлет Test-WSMan.
Проверка возможности подключения.
Для того чтобы выполнить определенную команду или скрипт, используется командлет Invoke-Command со следующим синтаксисом:
Где COMPUTER ― имя компьютера, COMMAND ―– имя команды, а USERNAME ― имя пользователя, если оно нужно.
Смотрим содержимое диска С удаленного компьютера.
Если же нам нужно получить полноценную консоль ― не автоматизации ради, а ради управления конкретным компьютером, ― то можно использовать командлет Enter-PSSession.
Работаем в консоли удаленного компьютера.
Напомню, что с помощью JEA можно ограничить доступные подобной сессии командлеты или дать доступ нужным без прав администратора.
Конечно, кроме встроенных средств и небольших утилит, существует множество программ для управления структурой. Помимо взрослых решений, для управления конфигурациями вроде Chef, Ansible и MS SCCM можно использовать и средства мониторинга вроде Zabbix, и даже консоль управления антивирусом Касперского.
В период гетерогенных структур хорошо бы иметь возможность унифицированного управления Windows и Linux. Это можно сделать и с помощью PowerShell, что само по себе достойно отдельной статьи ― стоит такую сделать или уже лишнее?
Кстати, поделитесь вашими способами скрытого и не очень запуска программ на удаленных компьютерах. Ну, за исключением эксплойтов.
Читайте также: