В предыдущей статье из этого цикла мы рассмотрели два трюка для написания удаленных сценариев, один из них был получен от нашего читателя, а другой был взят из недавно опубликованной книги Windows Vista Resource Kit. В этой статье мы рассмотрим еще некоторые трюки, связанные с написанием удаленных сценариев. Первый из этих трюков был также получен от еще одного из наших читателей. А второй – это пример из реального мира, в котором показано, как использовать командную строку управления инструментарием Windows Management Instrumentation Command-line (WMIC).
Первый трюк был получен от читателя по имени Стивен Беард (Steven Beard) из Великобритании (UK). Стив предлагает еще один способ, с помощью которого можно вызвать команду «runas» (выполнить от имени) из сценария, а также, как это может быть полезно для корпоративной среды. Давайте послушаем, что предлагает Стивен:
Привет, я был очень внимательным читателем всех ваших статей, мне очень понравился ваш раздел, касающийся написания vb сценариев. Я использовал vb сценарии на протяжении многих лет для администрирования моего домена windows domain, но я никогда в действительности не понимал WMI достаточно четко, только для того, чтобы реализовать свои нужды.
Однако, ваша последняя статья относительно функции runas (выполнить от имени) была очень хорошей, и я использовал ее, но немного другим образом, смотрите ниже:
Set WshShell = CreateObject("Wscript.Shell")
Set WshEnv = WshShell.Environment("PRocess")
WshShell.Run "runas.exe /user:" & "domain\user" & " " & Chr(34) & "cscript c:\PCQuery.vbs" & Chr(34)
Wscript.Sleep 800
WshShell.AppActivate WshEnv("SystemRoot") & "\system32\runas.exe"
Wscript.Sleep 200
WshShell.SendKeys "PASSWORD" & "~"
Wscript.Sleep 500
Set WshShell = Nothing
Set WshEn = Nothing
В целом, я просто обернул все мои сценарии, которыми необходимы права администратора, с помощью сценария, представленного выше, который использует runas (выполнить от имени), а затем ждет и использует sendkeys для отправки паролей.
У этого сценария была та же самая проблема, что и у сценария, который прислал вам другой читатель. Пароли посылались через всю сеть незашифрованными, что натолкнуло меня на мысль, написать вам это письмо.
Я использую шифровальщик сценариев (script encoder), который пропускает сценарий через шифровальщик хеширует его его же собственным алгоритмом (encryption algorithm), и в итоги вы получаете вместо файла с расширением .vbs файл с расширением .vbe.
Я уверен, что это достаточно легко взломать, но это лучше, чем голый текст.
Поэтому мне показалось, что это будет очень интересно вашим читателям.
Поддерживаю вашу работу и с нетерпением ожидаю выхода вашей новой статьи.
Для моего второго трюка я буду использовать VBScript, чтобы вытащить зайца из шляпы. Просто шутка!
Вторая подсказа родилась в результате появления реальной проблемы. Однажды читатель обратился ко мне, казалось бы, с очень простым вопросом: «Как можно получить список всех учетных записей локальных администраторов на удаленном компьютере?» Сценарий был таким, что у пользователя было несколько дюжин рабочих станций с операционной системой Windows XP, которые были частью рабочей группы, и у пользователей были права локального администратора на их компьютерах (т.к. учетные записи их локальных пользователей были также членами группы локальных администраторов на компьютере). Случилось так, что сеть была переведена на домен Active Directory domain, и пользователи получили новые учетные записи (user account), которые были членами глобальной группы Domain Users (пользователи домена). Тогда, в один прекрасный день, администратор обратил внимание на то, что у пользователя оказалось больше прав, чем ему было присвоено, и он обнаружил, что старые учетные записи локальных администраторов (local admin account) не были удалены с их компьютеров, и эти пользователи спокойно заходили на свои компьютеры с помощью этих учетных записей локальных администраторов, когда прав их доменных пользователей (domain user) не хватала для управления рабочей станцией. Администратор понял, что это может привести к серьезным проблемам, т.к. (a) это шло вразрез с политикой безопасности компании (company security policy), и (b) позволяло пользователям входить на свои рабочие станции с правами администратора, что могло привести к более высоким затратам на поддержку, т.к. они могли что-нибудь сломать на своей рабочей станции, т.к. локальный администратор может что угодно делать на компьютере.
Теперь, чтобы сделать это еще более сложным, встроенная локальная группа администраторов (Administrators local group) на их рабочих станция была переименована, а встроенная учетная запись локального администратора (Administrator) была также переименована. Проверка второй рабочей станции выявило, что встроенная локальная группа администраторов (Administrators local group) и встроенная учетная запись локального администратора (Administrator local user account) также была переименована, но назывались они по-другому, чем на первой рабочей станции! Такая вот головоломка! Чтобы разобраться с этим всем, пришлось бы входить отдельно на каждую рабочую станцию и разбираться со всеми учетными записями пользователей и всеми группами, чтобы выявить локальных администраторов на каждой машине, или же попытаться найти еще один способ выяснения всей этой информации. Может быть сценарий?
Вы можете написать сценарий для решения этой проблемы, но вместо этого давайте попробуем кое-что другое и используем командную строку управления инструментарием Windows Management Instrumentation Command-line (WMIC). WMIC – это инструмент (в действительности интерпретатор команд), который позволяет вам запросить WMI информацию напрямую из командной строки (command line) не запуская при этом сценарий. WMIC можно использовать двумя способами: интерактивно (поочередно запуская команды из командной строки) или в командных файлах (batch file).
Например, предположим, что встроенная локальная группа администраторов (Administrators) и локальная учетная запись администратора (Administrator) были переименованы на вашем компьютере. В этом случае я могу интерактивно использовать WMIC для отображения списка всех членов встроенной группы локальных администраторов (Administrators local group), открыв командную строку и набрав следующую команду:
C:\Documents and Settings\myself>wmic path win32_groupuser where (groupcomponent="win32_group.name=\"administrators\",domain=\"%computername%\"")
GroupComponent PartComponent
win32_group.domain="XP191",name="administrators" \\XP191\root\cimv2:Win32_UserAccount.Domain="XP191",Name="Administrator"
win32_group.domain="XP191",name="administrators" \\XP191\root\cimv2:Win32_UserAccount.Domain="XP191",Name="sjones"
win32_group.domain="XP191",name="administrators" \\XP191\root\cimv2:Win32_UserAccount.Domain="XP191",Name="gsmith"
win32_group.domain="XP191",name="administrators" \\XP191\root\cimv2:Win32_Group.Domain="TEST",Name="Domain Admins"
Посмотрев на вторую колонку, мы можем увидеть, что в группе локальных администраторов на этом компьютере есть три учетных записи пользователя: Administrator, sjones и gsmith. В дополнение к этому глобальная группа Domain Admins (администраторы домена) также является членом группы локальных администраторов на этой системе.
Теперь, как насчет того, если встроенная группа локальных администраторов (Administrators local group) на этом компьютере был переименована? Запустив следующую команду, мы получим следующий результат:
C:\Documents and Settings\myself>wmic path win32_groupuser where (groupcomponent=»win32_group.name=\»administrators\»,domain=\»%computername%\»»)
No Instance(s) Available. (нет доступных ссылок)
Почему не выполнилась команда? Очевидно, что это произошло из-за того, что название группы было жестко прописано в команде. Но если встроенная группа локальных администраторов была переименована, то как узнать это новое название? Ответ прост, хотя группа и была переименована, она все равно осталось все той же самой группой. Другими словами ее идентификатор безопасности (security identifier или SID) не изменился и остался прежним S-1-5-32-544 (смотри статью KB 243330 для получения списка известных SID).
Так как же мы можем определить название группы, если мы знаем ее SID? Мы снова можем использовать WMIC с такой вот командой:
C:\Documents and Settings\myself>wmic group where (sid = «S-1-5-32-544» and localaccount = true) get name
Name
JustAnotherGroup
Ага! Встроенная группа администраторов (Administrators) на этом компьютере был переименована на JustAnotherGroup! Очень хитро!
В любом случае, теперь, когда мы знаем название группы, мы можем узнать все члены этой группы:
C:\Documents and Settings\myself>wmic path win32_groupuser where (groupcomponent="win32_group.name=\"justanothergroup\",domain=\"%computername%\"")
GroupComponent PartComponent
win32_group.domain="XP191",name="justanothergroup" \\XP191\root\cimv2:Win32_UserAccount.Domain="XP191",Name="JustAnotherUser"
win32_group.domain="XP191",name="justanothergroup" \\XP191\root\cimv2:Win32_UserAccount.Domain="XP191",Name="sjones"
win32_group.domain="XP191",name="justanothergroup" \\XP191\root\cimv2:Win32_UserAccount.Domain="XP191",Name="gsmith"
win32_group.domain="XP191",name="justanothergroup" \\XP191\root\cimv2:Win32_Group.Domain="TEST",Name="Domain Admins"
И мы можем увидеть с помощью командной строки, что на этом компьютере присутствует три локальных администратора: sjones, gsmith и JustAnotherUser. И конечно, глобальная группа Domain Admins (администраторы домена) является членом группы JustAnotherGroup.
Это все великолепно работает, за исключением того, что мы не хотим заходить на каждую рабочую станцию и вручную запускать все эти WMIC команды. Можем ли мы сделать все это из одного места? Конечно! WMIC можно запустить на удаленных компьютерах с помощью ключа /node:»<computername>», при этом вы должны включить исключение Remote Administration exception на нужных компьютерах (вы можете сделать это с помощью политики группы Group Policy, как объяснялось в части 6 этой серии). Итак, предположив, что вы сделали это, давайте откроем командную строку на нашем центральном сервере (нашем контроллере домена) и запустим те же самые две команды WMIC, но в этот раз для удаленного компьютера под названием XP191. Сначала мы получаем название встроенной группы локальных администраторов на удаленном компьютере:
C:\Documents and Settings\Administrator>wmic /node:»xp191″ group where (sid = «S-1-5-32-544» and localaccount = true) get name
Name
JustAnotherGroup
Теперь мы используем полученный результат для получения списка членов этой группы:
C:\Documents and Settings\Administrator>wmic /node:"xp191" path win32_groupuser where (groupcomponent = "win32_group.name=\"justanothergroup\",domain=\"xp191\"")
GroupComponent PartComponent
win32_group.domain="xp191",name="justanothergroup" \\XP191\root\cimv2:Win32_UserAccount.Domain="XP191",Name="JustAnotherAccount"
win32_group.domain="xp191",name="justanothergroup" \\XP191\root\cimv2:Win32_UserAccount.Domain="XP191",Name="sjones"
win32_group.domain="xp191",name="justanothergroup" \\XP191\root\cimv2:Win32_UserAccount.Domain="XP191",Name="gsmith"
win32_group.domain="xp191",name="justanothergroup" \\XP191\root\cimv2:Win32_Group.Domain="TEST",Name="Domain Admins"
Результат таков, какой мы и ожидали. Теперь мы запросто можем написать командный файл (batch file), который обратиться ко всем рабочим станциям в вашей сети и сохранит результат в текстовом файле, который вы затем сможете проанализировать.
WMIC очень забавен, но немного загадочен. Мы узнаем о нем больше в следующих статьях из этого цикла.
www.windowsnetworking.com
Tags: domain, redirect, Windows Vista, Windows XP