Управление сетями Windows с помощью сценариев. Часть 9. Общие сведения об удаленных сценариях

• Управление сетями Windows с помощью сценариев. Часть 11. Дополнительные приемы работы со сценариями
• Управление сетями Windows с помощью сценариев. Часть 12. Свойства класса WMI
• Управление сетями Windows с помощью сценариев. Часть 13. Удобный сценарий возврата всех значений
• Управление сетями Windows с помощью сценариев. Часть 14. Дополнительные сведения о сценариях WMI

Давайте вспомним, что мы уже узнали об удаленном написании сценариев с использованием WMI:

• В части 6 этой серии мы попытались изменить наш сценарий ChangeIPAddress.vbs, чтобы мы могли использовать его для удаленного изменения IP-адреса компьютера. Попутно мы узнали, что нам нужно использовать групповую политику, чтобы включить исключение удаленного администрирования в брандмауэре Windows на целевом компьютере, иначе сценарий не будет работать. В конце концов мы заставили скрипт работать, но он также истек по тайм-ауту и выдал ошибку.
• Затем в части 7 мы обнаружили, что можем «обойти» ошибку, добавив On Error Resume Next в наш скрипт. Но срок действия сценария все еще истек, т.е. потребовалось много времени для завершения работы. Я проконсультировался с некоторыми гуру сценариев, и мы придумали предварительное объяснение ошибки, но чтобы увидеть, является ли проблема более общей, мы создали новый сценарий с именем ChangeGateway.vbs, и когда мы запустили этот сценарий удаленно, он сработал.
• Наконец, в части 8 читатель предложил простую возможную причину нашей ошибки: изменение IP-адреса удаленного компьютера разрывает соединение с компьютером, в результате чего сценарий завершается с ошибкой по тайм-ауту. Это звучало правдоподобно, поэтому мы попытались использовать Network Monitor 3.0, чтобы увидеть, что происходит, когда мы запускаем скрипт, и, конечно же, похоже, что наш анализ трассировки сети подтвердил, что читатель был прав. Оценка один для наших читателей!

Однако пришло время сделать шаг назад и изучить некоторые технические детали удаленного написания сценариев, прежде чем мы двинемся дальше. Это все хорошо и хорошо — прыгать и пробовать что-то, но иногда мы упираемся в стену, когда делаем это. Однако изучение основ часто может помочь нам избежать (или обойти, или, возможно, перепрыгнуть) стену. Итак, давайте начнем делать это сейчас.

Оформите предзаказ на копию Microsoft Windows Vista Resource Kit уже сегодня!

Два типа удаленных сценариев

На самом деле существует два вида удаленного скриптинга. Первый вид — это когда мы запускаем сценарий на компьютере A, и сценарий нацелен на компьютер B, чтобы выполнить над ним какое-то действие. В нашей более ранней попытке удаленного сценария с использованием нашего сценария ChangeIPAddress.vbs мы изменили строку:

улКомпьютер = "."

к этому:

стрКомпьютер = «xp2»

Если мы воспользуемся первой строкой выше и запустим сценарий на компьютере А, сценарий нацелится на компьютер А (локальный компьютер или «.») и изменит IP-адрес компьютера А. Однако если мы воспользуемся второй строкой выше и запустим сценарий на компьютере A, сценарий нацелится на компьютер B (компьютер с NetBIOS-именем «xp2») и изменит IP-адрес B.

Но есть второй тип удаленного скриптинга, и он работает следующим образом. Я администратор, который вошел в систему на компьютере A, и у меня есть сценарий, который я хочу использовать, чтобы сделать что-то на компьютере B. Но вместо того, чтобы пытаться запустить мой сценарий на моем компьютере (A) и сделать так, чтобы сценарий был нацелен на компьютер B, Я хочу запустить свой сценарий непосредственно на компьютере B. Поэтому каким-то образом мне нужно передать свой сценарий с моего компьютера (A) на целевой компьютер (B), а затем запустить его там. Как я могу это сделать? Если у меня есть среда Active Directory, я могу попробовать запустить сценарий как сценарий входа в систему на удаленном компьютере. Мы рассмотрим, как это сделать, в следующей статье, а пока просто запомните, что существует два типа удаленного скриптинга:

• Запуск скрипта на локальном компьютере и нацеливание на удаленный компьютер
• Запуск скрипта непосредственно на удаленном компьютере

Давайте по-другому выразим разницу между этими двумя парадигмами удаленного скриптинга:

• Первый тип удаленного сценария предполагает подключение к удаленному компьютеру и последующий запуск сценария.
• Второй тип предполагает развертывание сценария на удаленном компьютере и последующий запуск сценария.

Улавливаете разницу?

Общие сведения о подключении к удаленным сценариям

Теперь давайте сосредоточимся на первом типе удаленного скриптинга (который мы пытались сделать в последних нескольких статьях). Что означает, что сценарий, работающий на вашем локальном компьютере, подключается к удаленному компьютеру и запускается на нем? Это означает три вещи:

• Сетевое подключение
• Личность пользователя
• Подходящие разрешения

1. Сетевое подключение

Чтобы сценарий мог что-то сделать на удаленном компьютере, ему прежде всего необходимо установить сетевое соединение с удаленным компьютером. Какие проблемы могут помешать подключению к сети?

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

Во-вторых, это может быть проблема с брандмауэром. В предыдущей статье мы видели, что для того, чтобы наши сценарии WMI запускались на удаленном компьютере, нам нужно было открыть исключение удаленного администрирования в брандмауэре Windows на удаленном компьютере. Теперь, если вы откроете апплет брандмауэра Windows из панели управления и выберете вкладку «Исключения», вы не найдете флажок «Удаленное администрирование», который можно установить, чтобы открыть это исключение. Причина этого, конечно, в том, что этот апплет панели управления предназначен в первую очередь для домашних пользователей, которые могут использовать его для настройки своего брандмауэра. В бизнес-среде, где используется Active Directory, предпочтительным способом управления брандмауэром Windows является использование групповой политики. В предыдущей статье мы видели, что параметр групповой политики, который нам нужно было настроить, был следующим:

Конфигурация компьютераАдминистративные шаблоныСетьСетевые подключенияБрандмауэр WindowsПрофиль доменаБрандмауэр Windows: Разрешить входящее исключение удаленного администрирования

Когда вы нацеливаете эту политику на удаленный компьютер, она открывает на этом компьютере два TCP-порта: 445 и 135.

• TCP-порт 445 — это порт для входящего трафика Server Message Block (SMB), и если этот порт закрыт на брандмауэре удаленного компьютера, вы не только не сможете подключиться к нему с помощью WMI, вы также не сможете подключитесь к нему с помощью стандартных инструментов консоли MMC, таких как Управление компьютером. А когда порт закрыт и вы пытаетесь запустить сценарии на удаленной машине, вы можете получить загадочные ошибки, такие как «Произошла системная ошибка 53. Сетевой путь не найден» и так далее.
• TCP-порт 135 — это порт для входящего трафика Distributed COM (DCOM). В частности, порт 135 является портом прослушивания для диспетчера управления службами DCOM (SCM), который предоставляет службы на основе RPC для создания экземпляров COM-объектов и т.п.

Суть в том, что оба TCP-порта 135 и 445 должны быть открыты на брандмауэре удаленного компьютера, если запросы WMI, выполняемые с локального компьютера, должны успешно использовать RCP для подключения к службе WMI на удаленном компьютере и для успешного создания экземпляра. Объекты DCOM на удаленном компьютере.

2. Идентификация пользователя

Когда вы запускаете сценарий на удаленном компьютере и он может установить сетевое соединение с удаленным компьютером, сценарий может выполнять действия на удаленном компьютере. Но действия, которые он может выполнять, зависят от удостоверения, с которым сценарий запущен на удаленном компьютере. Допустим, например, что я захожу на компьютер A, используя обычную учетную запись пользователя домена. Затем я запускаю сценарий ChangeIPAddress.vbs и назначаю его целевым удаленному компьютеру B. Сценарий использует RPC для подключения к службе WMI на компьютере B и пытается изменить IP-адрес компьютера B. Но сценарий терпит неудачу. Почему? Ну и кто пытается выполнить это действие на удаленном компьютере? Вы — и на своем локальном компьютере А вы являетесь пользователем домена, и когда вы запускаете сценарий по умолчанию, он олицетворяет вашу личность, т. е. сценарий пытается выполнять свои действия, используя вашу личность (вашу учетную запись пользователя домена). Таким образом, когда сценарий пытается изменить IP-адрес удаленного компьютера, фактически это делаете вы, пользователь домена. И это не удастся, поскольку для изменения IP-адреса требуются учетные данные локального администратора.

Итак, вы сидите за компьютером А, вошли в систему как пользователь домена и все еще хотите использовать свой скрипт для изменения IP-адреса компьютера Б. Как вы можете это сделать?

Что ж, вы можете жестко запрограммировать в нашем скрипте пароль для локальной учетной записи администратора на удаленном компьютере. Другими словами, в нашем скрипте ChangeIPAddress.vbs мы могли бы заменить это:

Установите objWMIService = GetObject("winmgmts:\" & strComputer & " ootcimv2")

с этим:

strUser = «Администратор»
strPassword = «Pa$$w0rd»
Установить objWMIService = GetObject("winmgmts:\" & strComputer & " ootcimv2", strUser, strPassword)

Проблема в том, что это небезопасно — пароль учетной записи локального администратора для удаленного компьютера находится прямо здесь, в виде простого текста в вашем скрипте, и все его видят!

Как насчет того, чтобы избавиться от первых двух строк выше и передать значения для strUser и strPassword сценарию в качестве аргументов при запуске сценария? Это лучше, чем жестко запрограммировать эти значения в сценарии, но если у кого-то запущен сетевой сниффер (например, Network Monitor 3.0), то он может вынюхать эту учетную информацию, и вы снова скомпрометируете свой удаленный компьютер.

Как насчет того, чтобы повысить уровень командной строки с помощью runas /user:Administrator cmd.exe, а затем запустить сценарий из командной строки с повышенными правами без указания каких-либо других учетных данных? Это, вероятно, лучшее решение для удаленного написания сценариев, когда вам нужно убедиться, что сценарий имеет соответствующую идентификацию (обычно это локальный администратор на целевом компьютере), хотя это немного хлопотно. Конечно, вы также можете просто войти на свою рабочую станцию в качестве учетной записи администратора домена, просто открыть командную строку и запустить сценарий.

3. Подходящие разрешения

Итак, вы запускаете свой сценарий на компьютере A, и предполагается, что сценарий выполняет какое-то действие на удаленном компьютере B. Сценарий установил сетевое соединение со службой WMI на компьютере B, и сценарий пытается выполнить свои действия, используя правильное удостоверение (обычно учетные данные локального администратора) на компьютере B. Что еще может привести к сбою сценария в этот момент? Недостаточно разрешений! Если сценарий пытается выполнить какое-либо действие, контролируемое ACL (например, изменение объекта файловой системы, создание объекта в Active Directory или активацию объекта DCOM), а у вас (ваша личность, олицетворяемая сценарием) нет подходящие разрешения для выполнения этого действия, сценарий завершится ошибкой. К сожалению, это часто самая сложная часть удаленного написания сценариев, поскольку на платформах Windows существуют разрешения NTFS, разрешения DCOM и множество других типов разрешений. Кроме того, у вас могут быть правильные разрешения, но не правильные привилегии, то есть права пользователя на выполнение некоторых действий. Например, предположим, что вы хотите использовать сценарий для очистки журнала событий на удаленном компьютере, но ваша личность не имеет SeSecurityPrivilege на этом удаленном компьютере. Угадай, что? Ваш скрипт не сработает.

Об удаленном написании сценариев можно многое узнать, не так ли? Мы продолжим с более подробной информацией в нашей следующей статье.

• Управление сетями Windows с помощью скриптов. Часть 10. Приемы удаленного скриптинга
• Управление сетями Windows с помощью сценариев. Часть 11. Дополнительные приемы работы со сценариями
• Управление сетями Windows с помощью сценариев. Часть 12. Свойства класса WMI
• Управление сетями Windows с помощью сценариев. Часть 13. Удобный сценарий возврата всех значений
• Управление сетями Windows с помощью сценариев. Часть 14. Дополнительные сведения о сценариях WMI