Управление сетями Windows с помощью сценариев(Часть 9)

Published on Февраль 19, 2009 by   ·   Комментариев нет

Е

Пришло время немного отступить назад и поговорить о некоторых технических деталях при удаленном выполнении сценариев (remote scripting) перед тем, как мы продолжим дальше. Неплохо было подпрыгнуть и попробовать сразу все, но при этом мы ударимся о стену. Но изучение основ часто может уберечь нас от удара о стену (или позволяет нам обойти эту стену или перепрыгнут ее). Давайте начнем это делать прямо сейчас.

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

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


    strComputer = "."
    на строку:
    strComputer = "xp2"

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

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

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

Давайте выясним различия между этими двумя методами следующим способом:

  • Первый тип удаленного выполнения сценариев (remote scripting) включает в себя подключение (connecting) к удаленному компьютеру, а затем выполнение сценария.
  • Второй тип включает в себя установку (deploying) сценария на удаленной машине, а затем запуск сценария.

Увидели различие?

Понятие подключения при удаленном выполнении сценария

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

  • Сетевое подключение (Network connectivity)
  • Идентификация пользователя (User identity)
  • Наличие необходимы прав (Suitable permissions)

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

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

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

Во-вторых, это могут быть проблемы с брандмауэром (firewall). В предыдущей статье мы видели, что для того чтобы наш WMI сценарий смог выполниться на удаленном компьютере, мы должны добавить исключение для Remote Administration (удаленное администрирование) в брандмауэре Windows Firewall на удаленном компьютере. Теперь, если вы запустите апплет брандмауэра Windows Firewall из панели управления Control Panel и выберите закладку Exceptions (исключения), вы не увидите там поле Remote Administration, которое вы можете выбрать для добавления. Причина этого заключается в том, что такой апплет используется для домашних пользователей для настройки брандмауэра (firewall). В бизнес среде, в которой используется Active Directory, предпочтительный способ для управления брандмауэром Windows Firewall – это использование политик групп Group Policy. Мы предыдущих статьях мы видели, что настройки политики групп Group Policy setting, которые нам нужно настроить, были следующими:

Computer Configuration\Administrative Templates\Network\NetworkConnections\Windows Firewall\Domain Profile\Windows Firewall: Allow inbound remote administration exception (разрешить внешнее удаленное администрирование)

Если вы примените эту политику для удаленного компьютера, то откроется два TCP порта на этом компьютере: 445 и 135.

  • TCP порт 445 – это порт для входящего трафика блока серверных сообщения (Server Message Block или SMB), и если этот порт закрыт на брандмауэре удаленного компьютера, то вы не только не сможете подключиться к нему с помощью WMI, вы также не сможете подключиться к нему с помощью средств стандартной консоли MMC console, например, Computer Management. И если порт закрыт, а вы пытаетесь выполнить сценарий на удаленной машине, то вы может получить ошибку вроде такой “System error 53 has occurred. The network path was not found” (возникла системная ошибка. Не найден сетевой путь.) и так далее.
  • TCP порт 135 – это порт для входящего трафика Distributed COM (DCOM). А именно, порт 135 – это порт, по которому слушает менеджер управления службами DCOM Service Control Manager (SCM), который обеспечивает работу служб, связанных с RPC, по установке COM объектом в всего такого.

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

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

Когда вы запускаете сценарий для выполнения на удаленном компьютере (remote computer) и он может установить сетевое соединение с удаленным компьютером, тогда сценарий может выполнить какие-либо действия на этом удаленном компьютере. Но действия, которые вы можете выполнить, зависят от личности (identity), от имени которой сценарий запускается на удаленном компьютере (remote computer). Предположим, например, что я захожу на компьютер A, используя учетную запись обычного пользователя домена (domain user account). Когда я запускаю сценарий ChangeIPAddress.vbs, его мишенью является удаленный компьютер B. Сценарий использует RPC для подключения к службе WMI service на компьютере B и он пытается изменить IP на компьютере B. Но выполнение сценария останавливается. Почему? Кто пытается выполнить действие на удаленном компьютере? Вы – поэтому сценарий будет выполняться на удаленном компьютере от вашего имени (вашей учетной записи в домене domain user account). Поэтому, когда сценарий попытается изменить IP адрес удаленного компьютера, то он будет делать это от имени пользователя домена. Поэтому работа сценария будет завершена, т.к. изменение IP адреса требует наличие прав локального администратора на удаленном компьютере, которыми вы не обладаете.

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

Вы можете жестко прописать в коде вашего сценария пароль для учетной записи локального администратора (Administrator account) для удаленного компьютера. Другими словами, в нашем сценарии ChangeIPAddress.vbs мы можем заменить такую строку:


Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2")

На такую:


    strUser = "Administrator"
    strPassword = “Pa$$w0rd”
    Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\cimv2", strUser, strPassword)

Проблема заключается в том, что это небезопасно—пароль для учетной записи локального администратора (local Administrator account) для удаленной машины прописан прямым текстом в вашем сценарии для всеобщего обозрения!

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

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

3. Необходимые права

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

Есть еще что выучить об удаленном выполнении сценариев (remote scripting), не так ли? Мы продолжим изучение в следующей статье.

www.windowsnetworking.com


Смотрите также:

Tags:

Readers Comments (Комментариев нет)




Да человек я, человек! =)




Exchange 2007

Проведение мониторинга Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 3)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ... [+]

Практическое рассмотрение перехода с Exchange 2003 на Exchange 2007 (часть 1)

Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 2)

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть ... [+]

Мониторинг Exchange 2007 с помощью диспетчера System Center Operations Manager 2007 (часть 2)

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ... [+]

Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 5)

Если вы пропустили предыдущие части этой серии статей, перейдите по ссылкам: Подробное рассмотрение подготовки Active Directory для Exchange 2007 (часть 1) ... [+]

Установка и настройка Exchange 2007 из командной строки (Часть 3)

If you missed the previous parts in this article series please read: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (часть 1)

Инструмент ExRCA Текущий выпуск инструмента предоставляется только в целях тестирования и оснащен 5 опциями: Тест подключения Outlook 2007 Autodiscover Тест подключения Outlook 2003 RPC ... [+]

Развертывание сервера Exchange 2007 Edge Transport (часть 5)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Развертывание сервера Exchange 2007 Edge Transport (часть 1) Развертывание ... [+]

Установка и настройка Exchange 2007 из командной строки (часть 2)

Если вы пропустили первую статью данного цикла, пожалуйста, перейдите по ссылке: Exchange 2007 Install and Configuration from the command line (Part ... [+]

Использование интегрированных сценариев Using Exchange Server 2007 – часть 2: генерирование отчетов агента Transport AntiSpam Agent

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Использование интегрированных сценариев Using Exchange Server 2007 – часть ... [+]