Е
Пришло время немного отступить назад и поговорить о некоторых технических деталях при удаленном выполнении сценариев (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), с помощью которого мы пытались выполнить наш сценарий в течение нескольких последних статей. Что значит для сценария, быть запущенным на вашем компьютере, подключиться к удаленному компьютеру и выполнить на нем некоторую работу? Это означает следующее:
Для того, чтобы сценарий что-то выполнил на удаленном компьютере, ему необходимо сначала установить сетевое соединение с этим удаленным компьютером. Проблемы какого типа могут помешать установлению сетевого соединения?
Во-первых, это могут быть проблемы с преобразованием имени компьютера в 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 и 135 и 445 должны быть открыты на брандмауэре удаленного компьютера, чтобы запросы WMI могли успешно запускаться на удаленном компьютере и использовать RCP для подключения к службе WMI service на удаленном компьютере (remote computer) и успешной обработке объектов DCOM на удаленном компьютере.
Когда вы запускаете сценарий для выполнения на удаленном компьютере (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) и просто открыть командную строку и запустить сценарий.
Итак, вы запускаете ваш сценарий на компьютере 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: domain