 |
|
|
|
Разработка сценария регистрации пользователей в сети. Часть1
Разработка сценария регистрации пользователей в сети Часть1 На протяжении года в своих статьях я рассказывал о том, как автоматизировать различные процессы в сети, упростить администрирование. Решение поставленной задачи нетривиально и состоит из нескольких частей. Одной из них является сценарий регистрации пользователей в сети. Этот вопрос был частично рассмотрен в одной из предыдущих статей [1]. Она носила концептуальный характер, однако на форуме читатели дали понять, что концепция – это хорошо, но необходимо привести конкретный пример – скрипт. Пришла пора сложить недостающие кусочки мозаики в одно целое и подробно рассказать о теоретических и практических аспектах его создания, особенностях внедрения. Назовем основные из них:
Прежде чем приступить к созданию скрипта, необходимо сказать несколько слов о языке программирования, с помощью которого он будет создан. KIXTart Для создания сценариев регистрации пользователей существует множество языков, однако остановим свой выбор на языке KIXTart. Он является стандартным языком программирования сценариев компании Microsoft. Его дистрибутив можно найти в Microsoft Resource Kit или бесплатно загрузить последнюю версию из сети Интернет (http://kixtart.org). Замечание. Сценарии, созданные вами ранее на VBScript, Jscript могут быть легко переписаны под KIXtart. Все примеры в этой статье написаны на языке KIXTart. Думаю, что нет необходимости описывать преимущества этого языка перед VBScript или каким-нибудь другим языком. Стоит лишь отметить, что KIXtart разрабатывался исключительно для создания сценариев, с помощью которых пользователи регистрировались бы в сети. KIXTart версии 4.21 поддерживает около 100 функций, столько же макросов-функций и обладает следующими возможностями:
Решение задачи инвентаризации Введение Решение этой задачи состоит из нескольких частей – сбора, записи на носитель в определенном формате и обработки информации. Две первые подзадачи можно реализовать с помощью сценария загрузки, третья реализуется с помощью дополнительного программного обеспечения. Собираемая информация касается программного и аппаратного обеспечения, характеристик учетной записи пользователя, регистрирующегося в сети. Собираемые данные можно условно разделить на две части. К первой части относится информация об аппаратном и программном обеспечении. Данные об аппаратном обеспечении черпаются из WMI, а о программном – из реестра либо с помощью WMI, либо с помощью KIXTart. Вторая часть – информация, характеризующая положение рабочей станции в сети. К ней также относятся свойства учетной записи текущего пользователя. Эта половина реализуется с помощью макросов, встроенных в KIXTart, и чтения полей Active Directory. Для решения задачи инвентаризации нам необходимо осветить следующие темы.
Вопреки ожиданиям читателя я начну описывать решение задачи инвентаризации с конца, т.е. с формирования файла отчета. Это позволит избежать лишних вопросов и недопонимания излагаемого материала при иллюстрировании теории наглядными примерами. Формирование файла отчета. Теория Отчеты о работе сценария регистрации пользователей в сети рекомендуется формировать в формате XML. Основная причина, по которой стоит обратить внимание на XML, заключается в том, что он используется как базами данных, так и интернет-приложениями при работе с браузером. При использовании XML на рабочую станцию пользователя отдельно передаются данные и отдельно правила интерпретации этих данных для отображения с помощью, например, Jscript или VBScript. В нашем случае XML-файл будет содержать только данные. Как и HTML, XML является независимым от платформы стандартом. С полным вариантом спецификации XML можно ознакомиться на http://www.w3c.org/xml. Внешне XML-документ очень похож на HTML-документ, т.к. XML-элементы также описываются с помощью ключевых слов – тегов. Однако, в отличие от HTML, в XML пользователь может создавать собственные элементы. Теги XML определяют структурированную информацию. Синтаксис элементов (тегов), составляющих структуру XML-файла, в общем виде можно представить следующим образом:
<Element> [attr1=”val1” [attr2=”val2”…]] </Element> Приведем несколько основных правил, которыми необходимо руководствоваться при создании XML-документов:
Любой файл в формате XML, как уже говорилось, имеет обязательный заголовок и заглавный тег, в котором расположены все остальные теги. Приведем структуру XML-файла в общем виде: <?xml version=”1.0” encoding=”windows-1251” ?> <main_element> <Element1> [attr1=”val1” [attr2=”val2”…]] </Element1> <Element2> [attr1=”val1” [attr2=”val2”…]] </Element2> …………………………. </main_element> Пример XML-файла, соответствующего приведенному шаблону, смотрите на http://www.samag.ru/source. Замечание. Этот шаблон включает в себя только информацию, необходимую для успешной обработки файла отчета. Он не содержит упоминания о стилях, о возможности вставки в XML-файл программного кода. Полную версию шаблону можете найти на сайте http://www.w3c.org/xml. Формирование файла отчета. Практика Процесс формирования отчета состоит из двух частей: накопления данных в переменную и запись значения переменной в XML-файл. Накопление данных в переменной Как отмечалось в теоретической части, XML-файл должен иметь заголовок, в котором описана версия используемого языка и указана кодировка. Если не указывать кодировку, то при наличии, например, русских символов созданный файл не будет открываться и обрабатываться ни одним браузером. Данные рекомендуется накапливать в любую переменную строкового типа. Замечание. Чтобы при просмотре записанного в любом из тестовых редакторов (например, NOTEPAD.EXE) файла данные были поделены на строки, добавьте в конце строки следующий код: "chr(13)+chr(10)" В теоретической части была приведена структура XML-файла. Приведем листинг, позволяющий сформировать файл в формате XML (пример смотрите далее по тексту). Напомню, что в названии файла и главного тега должно быть использовано имя рабочей станции, а не учетной записи пользователя. Это связано с тем, что с одной рабочей станции в сети может зарегистрироваться только один пользователь, в то время как один и тот же пользователь с помощью своей учетной записи может зарегистрироваться на нескольких рабочих станциях. Таким образом, чтобы системный администратор получил исчерпывающую информацию о каждой из рабочих станций, зарегистрированных в сети, о свойствах учетных записей пользователей и др., в имени файла и главного тега рекомендуется использовать имя рабочей станции, которое возвращает макрос @wksta. В синтаксисе XML-файла есть одно ограничение – тег не может начинаться с цифр, поэтому, если в вашей сети рабочие станции имеют цифровые имена, например, 1130pc, 2310nb (pc – Personal Computer, nb - Notebook), то главный тег рекомендуется предварять каким-нибудь символом, например символом подчеркивания – «_». Необходимо напомнить еще об одном важном правиле: в названии тегов необходимо учитывать регистр. Теперь, когда рассмотрены все теоретические аспекты, приведем пример: $en=chr(13)+chr(10) " переход на новую строку ; накопление переменной $t="" $t=$t+"<_@wksta>"+$en $t=$t+"" @ProductType "+$en $t=$t+"< Parameter2> "+var1+ ""+$en …… $t=$t+"" ; формирование XML-файла $filename=@wksta+".xml" $fso = CreateObject("Scripting.FileSystemObject") $MyFile = $fso.CreateTextFile($filename, True, TRUE) $MyFile.WriteLine($t) $MyFile.Close WMI. Теория Основы WMI Чтение информации об аппаратной конфигурации рабочей станции рекомендуется обеспечивать стандартными средствами Microsoft Windows. Одним из таких средств является Microsoft Windows Management Instrument (WMI). WMI, разработанный в 1998 году, предоставляет разработчикам программного обеспечения и администраторам сети стандартизированные способы наблюдения и управления как локальными, так и удаленными ресурсами сети. Исполняемым файлом, обеспечивающим функционирование WMI, является файл winmgmt.exe, находящийся в каталоге c:WINNTsystem32wbemMicrosoft Windows 200x. Механизм работы WMI следующий:
Способы доступа к объектам WMI На практике доступ к объектам WMI получают одним из способов, проиллюстрированных в следующих шаблонах: A) $strComputer="" $strNameSpace="" $strClass="" $objElements = GetObject( "winmgmts:{ImpersonationLevel=Impersonate}!//" & $strComputer & "/ " &$strNameSpace & ": " & $strClass) For each $Element in $objElements $Temp=$Element.Value Next Б) $strComputer="" $strNameSpace="" $strClass="" $objWMIService = GetObject( "winmgmts:{ImpersonationLevel=Impersonate}!//" & $strComputer & "/ " & $strNameSpace) $colItems = $objWMIService.InstancesOf($strClass ) For Each $Element in $colItems $Temp=$Element.Value Next В) $strComputer="" $strNameSpace="" $strClass="" $objWMIService = GetObject("winmgmts:{ImpersonationLevel=Impersonate }!// " & $strComputer & "/ " & $strNameSpace) $colItems = objWMIService.ExecQuery("SELECT поле_1, поле_2, …, поле_n FROM" & $strClass ) For Each $Element in$colItems $Temp=$Element.Value Next В приведенных примерах значением переменной $str Computer является имя удаленного компьютера. Если компьютер локальный, то вместо имени указывается символ «.» (точка): $strComputer=”.” Переменная $strNameSpace содержит пространство имен. $strClass – переменная, включающая в себя название класса. Например, для Win32 Provider одним из классов является Win32_BIOS, соответственно переменная $strNameSpace принимает значение RootCimv2. Инструкция {ImpersonationLevel=Impersonate}! заставляет выполнить сценарий с привилегиями пользователя, вызывающего сценарий, а не с привилегиями пользователя, который в настоящий момент зарегистрирован на рабочей станции. Таким образом, осуществляется подстановка, которая полезна при выполнении сценариев удаленного доступа на таких ОС, как Microsoft Windows 200x, где эта инструкция является выражением подстановки по умолчанию, поэтому для этого семейства ее можно опустить. Варианты доступа A и Б к объектной модели WMI отличаются лишь формой записи. В варианте B обращение к классу строится с помощью SQL-запроса, что позволяет экономить трафик. В общем случае запрос SQL выглядит следующим образом: SELECT поле_1, поле_2, …, поле_n FROM strClass В поле SELECT указываются поля, по которым идет выборка. Поля перечисляются через запятую, «пробелы» после запятой обязательны. Если выборка должна идти по всем полям, то вместо названий полей указывается символ «*». В поле FROM указывается один из ранее перечисленных поставщиков: SELECT * FROM $strClass. В зависимости от способа доступа к хранилищу размер пересылаемых данных разный. Таблица 1
Вывод: видно, что на практике лучше всего использовать вариант В. Несмотря на то что код получится несколько громоздким, уменьшится сетевой трафик, сократится время работы сценария. WMI. Практика Для сбора информации различного характера необходимо использовать Win32 Provider, которому соответствует пространство имен RootCimv2. Win32 Provider соответствует массив, состоящий из двух частей: идентификатора и названия ресурса, которые разделены знаком подчеркивания. Идентификатором всегда является «WIN32». С объектной моделью WMI можно ознакомиться с помощью утилиты WMI Object Browser, входящей в пакет WMI Tools. Набор утилит WMI Tools можно найти на сайте компании Microsoft: http://msdn.microsoft.com/developer/sdk/wmisdk/default.asp.
Рисунок 1 На практике для доступа к WMI-объектам рекомендуется использовать нечто среднее между шаблонами, приведенными в теоретической части: $strComputer="" $strNameSpace=" RootCimv2" $strClass="Win32_Value" $objWMIService = GetObject( " winmgmts: // " & $strComputer & "/ " & $strNameSpace) $colItems = objWMIService.ExecQuery("SELECT поле_1, поле_2, …, поле_n FROM" & $strClass ) For Each $Element in $colItems $Temp=$Element.Value Next Приведем пример чтения информации BIOS материнской платы с помощью WMI на Kixtart на основе обобщенного варианта 3 рабочей станции ComputerName. Массив данных, в котором содержится информация о материнской плате, называется WIN32_BIOS: $PC = @WKSTA $en=chr(10) $objWMIService = GetObject( "winmgmts://" + $pc+"/Root/Cimv2") $colItems = $objWMIService.ExecQuery( "Select * from Win32_BIOS") For Each $objItem in $colItems ? " BIOS Name : " + $objItem.Name ? " Version : " + $objItem.Version ? " Manufacturer : " + $objItem.Manufacturer ? " SMBIOS Version : " + $objItem.SMBIOSBIOSVersion Next Необходимо отметить, что все переменные, которые использованы в данном примере, – строковые (см. рис. 1). Если переменная является числом, то ее необходимо преобразовать в строковую переменную с помощью функции Сstr(). Если переменная представляет собой массив, то необходимо прочитать элементы массива и преобразовать их в строки в том случае, если элементы массива не являются строковыми переменными. Результатом выполнения данной программы будет сообщение вида:
Рисунок 2 Поскольку вышеприведенный механизм используется многократно, то рекомендуется оптимизировать программный код, сформировав из имен классов массив: $wmi_array="Win32_BIOS","Win32_Processor",……" $ж=… for $a=0 to $ж $objWMIService = GetObject( "winmgmts://@wksta/root/cimv2" ) $colItems = $objWMIService.ExecQuery( "Select * from "+ $wmi_array[$ж]) For Each $objItem in $colItems select case $a=0 $mb1=$objItem.Name $mb2=$objItem.Manufacturer $mb3=$objItem.SMBIOSBIOSVersion $mb4=$objItem.Version $lx1="<mb> <bios> $mb1 </bios>" $lx2="<manufacture> $mb2 </manufacture>" $lx3="<version> $mb3 </version> " $lx4="<data_release> $mb4 </data_release> </mb> " $t="$t $lx220 $en $lx222 $en $lx224 $en $lx226 $en" case $a=1 $cpu_arhitect="x86","MIPS","ALPHA", "Power PC" $cpu_socket="","Other","Unknown","Daughter Board","ZIF Socket","Replacement/Piggy Back","None","LIF Socket","Slot 1", "Slot 2", "370 Pin Socket", "Slot A", "Slot M","","","Socket 478" $i=$objItem.Architecture $ii=$cpu_arhitect[$i] $cpu1=$objItem.Name + ", " + $objItem.MaxClockSpeed + " Mhz" $cpu2=$objItem.Version + ", Level " + $objItem.Level $i=$objItem.UpgradeMethod $ii=$cpu_socket[$i] $cp1=$objItem.ExtClock+"Mhz" $cp2=$objItem.L2CacheSize+"Kb" $lx5="<cpu> <processor> $cpu1 </processor>" $lx6="<version> $cpu2 </version> " $lx7="<socket> $ii </socket>" $lx8="<external_clock> $cp1 </external_clock>" $lx9="<l2_cache> $cp2 </l2_cache> </cpu> " $t="$t $lx230 $en $lx232 $en $lx234 $en $lx236 $en $lx238 $en" case $a=2 ………………………… End Select Next Реестр. Теория Истоки реестра Реестр – это иерархическая база данных, содержащая настройки аппаратного и программного обеспечения компьютера. Для обеспечения высокой скорости доступа к записям реестра информация в нем хранится в двоичном формате, а сам реестр состоит из нескольких файлов. В Microsoft Windows 3.x все настройки программного обеспечения располагались в конфигурационных файлах, имеющих расширение INI. Настройки программного обеспечения и операционной системы располагались в двух файлах: SYSTEM.INI и WIN.INI. Однако размер INI-файлов не мог превышать 64 Кб, поэтому, чтобы обойти это ограничение, для каждой программы создавался свой INI-файл. Со временем из-за большого количества конфигурационных файлов производительность операционной системы значительно понизилась. В 1993 году была создана операционная система Microsoft Windows NT, в которой множество INI-файлов было заменено единой базой данных – реестром. С точки зрения файловой системы реестр представляет собой файл с расширением DAT. Для Windows NT/200x реестр хранится в файле NTUSER.DAT, который находится в каталоге %Windir%Profiles. В Windows 9x реестр состоит из двух файлов: USER.DAT и SYSTEM.DAT, которые хранятся в каталоге %Windir%. USER.DAT содержит настройки индивидуального пользователя, а SYSTEM.DAT – настройки компьютера. Реестры Windows 9x, NT, 2000 несовместимы друг с другом, однако идея построения реестров едина. Ветви реестра Реестр состоит из разделов верхнего уровня, называемых кустами (или ульями, в оригинале hives):
Структура реестра такова: в каждом из разделов находятся ключи, в которых содержатся параметры, имеющие определенные значения. Рассмотрим подробнее назначение каждого из разделов реестра. В разделе HKLM находится информация об аппаратном, программном обеспечении, а также сведения о системе безопасности. Раздел HKCR представляет собой виртуальную ссылку на раздел HKLMSoftwareClasses и является одним из самых больших разделов реестра. В нем находится информация обо всех расширениях файлов, определениях типов, ярлыках, привязке, классах идентификаторов и т. д. Раздел HKU содержит настройки пользователя по умолчанию, в которые входят описания переменных среды, цветовых схем, шрифтов, сетевых настроек и т. д. Во время регистрации нового пользователя на рабочей станции на жестком диске для него создается новый профиль. Настройки, содержащиеся в профиле, копируются из раздела HKU. Изменения в разделах HKU и HKLM можно сделать с помощью утилиты REGEDT32.EXE в том случае, если у вас ОС Windows 2000, и REGEDIT.EXE – если Windows XP. Пользователь, от имени которого запускаются эти утилиты, должен обладать правами администратора. Раздел HKCU содержит сведения о текущем пользователе и имеет название, соответствующее значению идентификатора безопасности (SID) данного пользователя. Каждый раз при перезагрузке компьютера этот раздел создается заново. Раздел HKCC является ссылкой на текущий профиль оборудования, хранящейся в HKLM. С помощью профиля оборудования определяют список устройств, драйвера которых будут подгружены в данном сеансе работы пользователя. Профили изначально предназначены для переносных компьютеров. Раздел HKDD (HKEY_DYN_DATA) не хранится в реестре, а динамически создается при загрузке операционной системы. В нем содержатся сведения о самонастраивающихся устройствах (Plug-and-Play). Как и любая база данных, реестр поддерживает несколько типов данных, которые перечислены в таблице: Таблица 2
Реестр. Практика Отображаемый в «Add and Remove Programs» cписок установленных программ на рабочей станции формируется на основе информации из ветви реестра HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionUninstall. Рассмотрим подробнее структуру, содержащуюся в папке Uninstall. При установке любой программы на жесткий диск компьютера в Windows 2000 или Windows XP в ней создается подпапка. Ее имя совпадает либо с GUID, либо с названием программы. Внутри этой папки создается ряд записей, содержащих информацию об установленном продукте.
Рисунок 3 Необходимо отметить, что в подразделе «Add and Remove Programs» панели «Control Panel» список установленного программного обеспечения формируется на основе значений, содержащихся в переменной «DisplayName» для каждого приложения. При выборе кнопки «Remove» операционная система выполняет команду, являющуюся значением переменной «UninstallString». В том случае, если значение этого параметра неверно, вы никогда не сможете удалить это приложение через «Control Panel». Однако вернемся к папкам. Для того чтобы считать из реестра названия установленных программ, сначала необходимо получить доступ к подпапкам – узнать их названия, которые содержатся в папке «Uninstall». Для этого следует использовать функцию EnumKey(): $path="HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionUninstall" do $loop = ENUMKEY($path, $Index) ? $loop until $loop="" Результат работы примера приведен на рис. 4.
Рисунок 4 Зная имена папок, для каждой из них можно считать значения параметра «DisplayName». Следует отметить, что не все установленные приложения содержат этот параметр в соответствующей папке, поэтому в «Control Panel» отображаются не все установленные программы. Для обеспечения полноты предоставляемой информации в том случае, если запись «DisplayName» отсутствует, будет считываться название папки. В приведенном примере в переменную t будут записываться данные, предназначенные для XML-файла: $en=chr(10)+chr(13) $t=$t+" <Installed_Programs> " $i=1 $path="HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" do $loop = ENUMKEY($path, $Index) $name=readvalue($path+" \"+$loop,"DisplayName") if $name<>"" $t=$t+" <Program"+$I +"> " +$name+ " </Program"+$I +"> "$en ? " <Program"+$i +"> " +$name+ " </Program"+$I +"> " Else if $loop<>"" $t=$t+" <Program"+$I +"> " +$loop + " </Program"+$I +"> "$en ? " <Program"+$I +"> " +$loop + " </Program"+$I +"> " endif endif $Index = $Index + 1 $i=$Index+1 until $loop="" $t=$t+" </Installed_Programs> " MessageBox($t, "",0,0) Active Directory. Теория Active Directory Active Directory (AD) – это служба каталогов, которая является иерархической базой данных, обеспечивающей централизованное управление сетью. Active Directory хранит в себе информацию об объектах сети и обеспечивает доступ к этой информации пользователям, компьютерам и приложениям. Active Directory обладает следующими особенностями:
Объектная модель ADSI Наглядная схема объектной модели ADSI приведена на рис. 5. Схема условно поделена на три части. Используя клиента – язык программирования, скрипт получает доступ к COM-объектам. Объекты могут быть двух видов – классами и подклассами. Обращение к подклассам осуществляется через классы, однако на схеме этого не показано, чтобы не загромождать рисунок. С помощью COM-объекта через протокол LDAP или WinNT сценарий загрузки получает доступ к выбранному элементу объектной модели. Пространство имен условно обозначено треугольником; квадратами обозначены классы, а кружками подклассы. Методы доступа к каждому из перечисленных протоколов отличаются, однако можно привести пример, который наглядно иллюстрирует приведенную схему: $obj=GetObject("Protocol://ClassName") For each $SubClass in $ClassName ? $SubClass.Property Next
Рисунок 5 Провайдеры ADSI Интерфейс ADSI поддерживает следующие провайдеры, с помощью которых осуществляется программное администрирование (см. таблицу 4). Для определения всех доступных в сети провайдеров необходимо использовать службу ADS: $obj=GetObject("ADs:") For Each $provider IN $obj $t=$t + $provider.name + chr(13) Next MessageBox($t, "",0,0)
Таблица 3
Из всех перечисленных провайдеров будут рассмотрены только: LDAP и WINNT. Провайдер ADSI LDAP выполняется на клиенте ADSI и обеспечивает доступ к Active Directory. Кроме служб каталогов Active Directory Windows 2000, LDAP-провайдер обеспечивает доступ к:
Для реализации программного управления Active Directory часто используется именно этот провайдер. Запрос провайдеру LDAP составляется в формате LDAP URL (см. RFC 1779, RFC 2247): LDAP://HostName[:PortNumber][/DistinguishedName] Провайдер WinNT ADSI поддерживает доступ к каталогам Microsoft Window 4.0/3.x, обеспечивает связь с PDC и BDC. Провайдер WinNT в основном используется для работы с принтерами. Причина проста: в отличие от провайдера LDAP, провайдер WinNT рассматривает принтер не как сетевое, а как локальное устройство. Только с помощью провайдера WinNT можно управлять состоянием и очередями принтеров. Совместное использование обоих провайдеров позволит осуществлять мониторинг и управление сетевыми принтерами домена [2]. Порядок построения запроса для провайдера WinNT в формате UNC следующий: WinNT:[//DomainName[/ComputerName[/ObjectName[,className]]]] Объектная модель провайдера LDAP Для программного управления Active Directory с помощью провайдера LDAP необходимо использовать его объектную модель. Объектная модель представляет собой совокупность объектов, которые взаимосвязаны друг с другом и образуют между собой иерархическую структуру. Каждый из этих объектов имеет набор свойств, характерный исключительно для объектов данного типа. Существует несколько видов (идентификаторов) объектов: CN, DС, OU. Расшифровка и назначение каждого объекта смотрите в таблице. Таблица 4
Имена LDAP URL (см. RFC 1779, RFC 2247) построены на основе протокола X.500 и используются для связывания с объектами. Идентификаторы объектов DC, OU, CN образуют полное составное имя (Distinguished Name, DN), а имя самого объекта – относительное составное имя (Relative Distinguished Name, RDN). Полное составное имя объекта включает в себя имя объекта и всех его родителей, начиная с корня домена.
Рисунок 6 Существует две формы доступа к ADSI: развернутая и сокращенная. Рассмотрим принципы построения путей к ресурсу обоими способами на примере домена domain.com (см. рис. 5).
В качестве шаблона может служить выражение вида: $obj=GetObject("LDAP://DC=Domain_name1/DC=Domain_name2/DC=Domain_name3/OU=OU_Name_Level1/OU=OU_Name_Level2…/OU=OU_Name_Level/CN=CN_Name") где DC=Domain_name1/DC=Domain_name2/DC=Domain_name3 образуют полное имя контроллера домена, элементы OU=OU_Name_Level1/OU=OU_Name_Level2…/OU=OU_Name_Level представляют собой вложенные друг в друга элементы. В развернутой форме доступа объект CN является «дном колодца» в иерархии. Пример: запрос к объекту CN=User3 выглядит следующим образом (см. рис. 5): $obj = GetObject ("LDAP://DC=RU/DC=Domain1/OU=Group1/OU=Group4/CN=User3")
$obj=GetObject("LDAP://CN=CN_Name,OU=OU_Name_Level…,OU=OU_Name_Level2 ,OU=OU_Name_Level1/DC=…") Соответственно запрос к объекту CN=User3 с помощью сокращенной формы доступа выглядит следующим образом: $obj=GetObject("LDAP://CN=User3,OU=Group4,OU=Group3,DC=Domain1, dc=RU") Active Directory. Практика Объектная модель AD Управление объектами Active Directory невозможно без знания объектной модели. Существует несколько программ, предназначенных для нее. Рассмотрим лишь две из них: Active Directory Viewer (Microsoft) и LDAP Browser 2.5.3 (Softerra). Active Directory Viewer (ADV) является графической утилитой, позволяющей выполнять операции чтения, модифицирования, осуществлять поиск в любых совместимых каталогах, таких как Active Directory, Exchange Server, Netscape Directory, Netware Directory. Active Directory Viewer входит в состав SDK для Active Directory Services Interface, который можно бесплатно загрузить с сайта Microsoft: http://www.microsoft.com/ntserver/nts/downloads/other/adsi25. После установки SDK for ADSI утилита Active Directory Viewer (AdsVw.exe) будет находиться в c:Program FilesMicrosoftADSI Resource Kit, Samples and UtilitiesADsVw. Программа работает в двух режимах: ObjectViewer и Query.
Рисунок 7 Для просмотра объектной модели провайдера необходимо использовать режим ObjectViewer. Режим Query используется для осуществления поиска объектов в выбранной объектной модели. В данной статье режим Query рассматриваться не будет. Просмотр и редактирование объектной модели программой ADV в режиме ObjectViewer. После выбора режима ObjectViewer появится диалоговое окно.
Рисунок 8 Для получения доступа к каталогу необходимо указать путь и параметры учетной записи, обладающей правами администратора (имя и пароль). Путь к каталогу должен быть построен в соответствии со следующим шаблоном: <Provider_Name:>//<Server_Name>/<Full_Domain_Name> Обратите внимание на две особенности шаблона, в нем не должно быть пробелов, «слэши» должны быть прямыми – «/». Невыполнение хотя бы одного из перечисленных условий приведет к ошибке в соединении с каталогом. Для доступа к серверу server домена domain.ru с помощью протокола LDAP используется следующий запрос: LDAP://server/DC=domain,DC=ru После соединения с каталогом на экране будет отображена его иерархическая структура.
Рисунок 9 В левой части экрана отображается иерархическая структура каталога. В правой части – характеристики объекта, на котором установлен курсор. Список свойств объекта и соответствующих им значений приведен в «Properties» и «Property Value». LDAP Browser 2.5.3 является бесплатной программой (http://www.ldapadministrator.com). По своим возможностям программа превосходит Active Directory Viewer. В процессе создания соединения с каталогом могут быть заданы фильтры, параметры административной учетной записи, порт TCP, по которому осуществляется соединение, и другие параметры. Общий вид программы приведен на рис. 10.
Рисунок 10 Причины использования провайдера LDAP
Поиск объектов осуществляется с помощью OLE Distributed Query (DB) интерфейса, который вызывается прямо из службы активного каталога (Active Directory Service Interface – ADSI). Он осуществляется на основании запроса и его параметров. В качестве его параметров могут быть: уровень поиска, диапазон поиска, ограничение по размеру, сортировка и т. д. Форма запроса (Distributed Query) заимствована из Microsoft SQL Server. Запрос строится по следующему шаблону: SELECT поле 11,поле 21...поле n1 FROM путь WHERE objectClass="тип_объекта" где «путь» – путь к интересующему объекту AD в формате LDAP URL. На практике поиск объектов осуществляется следующим образом: $DomainName="Domain" $objConnection = CreateObject("ADODB.Connection") $objCommand = CreateObject("ADODB.Command") $objConnection.Provider = "ADsDSOObject" $objConnection.Open "Active Directory Provider" $objCommand.ActiveConnection = $objConnection $objCommand.CommandText = "SELECT printerName, serverName FROM " _ & " "LDAP://"& $DomainName & "" WHERE objectClass="printQueue"" $objCommand.Properties("Cache Results") = False $objRecordSet = $objCommand.Execute $objRecordSet.MoveFirst Do Until $objRecordSet.EOF $temp=$temp & "Printer Name: " & $objRecordSet.Fields("printerName").Value & " Server Name: " & $objRecordSet.Fields("serverName").Value & chr(13) $objRecordSet.MoveNext Loop Messagebox($tem,"",0,0) В приведенном примере осуществляется поиск всех зарегистрированных в AD принтеров. У найденных принтеров происходит чтение двух полей: название принтера и сервера печати. Поиск объектов с помощью провайдера LDAP осуществляется по следующему шаблону:
В том случае если искомые объекты найдены, происходит чтение указанных в запросе полей. Результат выводится на экран. Объектами могут быть строки и массивы. Следует отметить, что вместо названия свойства, которое необходимо прочитать, можно указать порядковый номер поля, под которым оно обозначено в запросе. Нумерация полей начинается с 0. Таким образом, основываясь на приведенном примере, вместо $objRecordSet.Fields(«server Name»).Value можно записать $objRecordSet.Fields(1).Value. В файле отчета, по мнению автора статьи, следует размещать следующую информацию о пользователе: имя, отчество, подразделение, должность и телефон. Набор этих параметров может меняться в зависимости от специфики фирмы, в которой функционирует скрипт. Приведем пример, выполняющий чтение этих полей: $objRoot = GetObject("LDAP://RootDSE") $strDefaultDomainNC = $objRoot.Get("DefaultNamingContext") $strGetArg=@userid ; определение имени пользователя. $strADSQuery = "SELECT department, physicaldeliveryofficename, telephonenumber, title FROM "LDAP:// " + $strDefaultDomainNC + "" WHERE samAccountName = "" + $strGetArg + """ $objADOConn = createObject("ADODB.Connection") $objADOConn.Provider = "ADsDSOObject" $objADoConn.Open ("Active Directory Provider") $objADOCommand = CreateObject("ADODB.Command") $objADOCommand.ActiveConnection = $objADOConn $objADOCommand.CommandText = $strADSQuery $objQueryResultSet = $objADOCommand.Execute $objRoot_m1=$objQueryResultSet.Fields("department") $objRoot_m2=$objQueryResultSet.Fields("physicaldeliveryofficename") $objRoot_m3=$objQueryResultSet.Fields("telephonenumber") $objRoot_m4=$objQueryResultSet.Fields("title") Как видно из примера, имя пользователя определяется с помощью встроенного в KIXTart макроса @userid. Определение значения необходимых полей осуществляется с помощью процедуры поиска объекта, в данном случае учетной записи, и чтения необходимых свойств. Стоит отметить, что этой проблемы быть не должно, поскольку Windows по умолчанию использует кодировку cp1251. Однако при взаимодействии KIXTart с Windows кодировка «съезжает». С решением этой проблемы, пусть не самым изящным, но эффективным, читатель только что ознакомился. Обратите внимание, несмотря на то что значения, прочитанные из AD, имеют тип данных либо «строка», либо «массив», при попытке записать их в файл отчета выдается ошибка несоответствия типа. По непонятным причинам функции преобразования типов данных не дают желаемого результата. Предлагается следующее решение возникшей задачи, которое состоит их двух этапов. На первом этапе данные из AD записываются в INI-файлы с помощью функции WriteProfileString(). Затем осуществляется считывание этих данных из INI-файлов и их запись в накапливаемую переменную, содержание которой представляет собой записываемую информацию в XML-файл. Таким образом, осуществляется смена кодировки, в которой записывается информация: $ini_file="@wksta.ini" $user_name="user" $user1=writeprofilestring("$ini_file", $user_name,"department",$objRoot_m1) $user2=writeprofilestring("$ini_file", $user_name,"location",$objRoot_m2) $user3=writeprofilestring("$ini_file", $user_name,"telephone",$objRoot_m3) $user4=writeprofilestring("$ini_file", $user_name,"title",$objRoot_m4) $user5=writeprofilestring("$ini_file", $user_name,"User ID","@userID") $user6=writeprofilestring("$ini_file", $user_name,"Full Name","@fullname") $objRoot1=readprofilestring("$ini_file", $user_name,"department") $objRoot2=readprofilestring("$ini_file", $user_name,"location") $objRoot3=readprofilestring("$ini_file", $user_name,"telephone") $objRoot4=readprofilestring("$ini_file", $user_name,"title") $t=$t+" $objRoot1 " $t=$t+" $objRoot2 " $t=$t+" $objRoot3 " $t=$t+" $objRoot4 " …… del "$ini_file" В следующей статье будут рассмотрены вопросы автоматического подключения сетевых ресурсов, визуализации скрипта, внедрение его в эксплуатацию. Литература:
|
ИВАН КОРОБКО
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
