 |
|
|
|
Active Directory — теория построения
Active Directory – теория построения В своей работе системному администратору часто приходится выполнять рутинные действия, которые отнимают много времени и требуют повышенного внимания. Управление Active Directory является одной из приоритетных задач системного администратора. Программное администрирование Active Directory позволит сэкономить время и свести к минимуму влияние человеческого фактора. Используя провайдеры LDAP и WinNT, системный администратор сможет с помощью сценария загрузки управлять подключением сетевых ресурсов; создавать скрипты, которые позволят автоматизировать рутинные операции. Умелое сочетание возможностей провайдеров WinNT и LDAP дает превосходный результат. Как показывает опыт, без теоретических знаний о механизме работы Active Directory и ADSI, базируясь на приведенных в Интернете примерах, очень трудно понять что к чему. В данной статье предпринята попытка поставить все точки над «и», не оторвав при этом теорию от практики (программирования Active Directory). Программное управление с помощью VBScript Как отмечалось ранее, для управления ADSI могут быть использованы VB/VBScript, JScript, C/C++. Для программного управления – компьютером, выполняющим роль контроллера домена, на котором установлена Active Directory, следует использовать стандартные средства, предлагаемые компанией Microsoft. Одним из таких стандартных средств является VBScript. Использование этого языка программирования дает огромные преимущества. Скрипты, написанные на VBScript помогут системному администратору не только управлять Active Directory, но и создавать сценарии загрузки для входа в сеть. По сравнению с С/С++, программный код на VBScript в несколько раз меньше, а по функциям равнозначен. Использование WHS (Windows Hosting Script) и WMI (Windows Management Instrument) совместно с программированием Active Directory позволит решать сложные задачи администрирования. И WSH, и WMI также являются стандартными средствами и поддерживают VBScript. Программирование WMI рассмотрено в статье «Решение задач инвентаризации в сети» в журнале «Системный администратор» №12(13) за 2003 год. Использование VBScript позволяет создавать скрипты – текстовые файлы с расширением VBS, которые используются как сценарии загрузки при регистрации пользователей в сети, в виде сайтов на основе ASP. ASP-страница является синтезом HTML и VBScript. В отличие от HTML-страниц, ASP-страницы поддерживают OLE-объекты. Это позволяет использовать в ASP-страницах программирование WMI, WSH, ADSI. Создавая сценарии на любом языке программирования, необходимо пристально следить за тем, чтобы конечный продукт было легко внедрять и эксплуатировать. Сценарий загрузки не должен содержать явных записей в программном коде. Например, название текущего домена, если речь идет о программировании ADSI, необходимо определять программно, а не прописывать явным образом. Те параметры, которые невозможно определить с помощью сценария, например месторасположение папки, в которой должны размещаться файлы отчетов, должны быть прописаны в конфигурационном файле. Таким образом, в тексте скрипта явным образом будет прописан только один параметр – путь к конфигурационному файлу. Используя в скриптах массивы для передачи данных, при определении массива задавайте заведомо большее количество элементов в массиве, чем это необходимо, например Array(1000). После занесения данных в массив переопределите размер массива с помощью функции ReDim Preserve Array(i), где i – новый размер массива. При использовании цикла For определяйте границы массивов с помощью функций Lbound(Array) – нижняя граница массива, Ubound(Array) – верхняя граница (см. Пример 1а). Существует второй способ работы с массивами, который в основном используется в программировании ADSI – использование конструкции FOR EACH element IN array (см. Пример 1б). Пример 1а Пример 1б i= Lbound(Array) For Each i in Array For i To Ubound(Array) element=Array(i) element=Array(i) next ……………………… Next Продолжая развивать тему операций с массивами, необходимо уделить внимание механизму упорядочивания массивов и поиску среди элементов массива заданного выражения. Наиболее простым методом упорядочивания массивов является пузырьковый метод. Суть метода заключается в том, что при несоблюдении условия упорядочивания массива смежные элементы меняются местами. Тем самым элементы массива становятся друг за другом в заданном порядке – происходит упорядочивание. Пример 2 Dim Array(100) …………………… For j=0 to Ubound(Array) For i=0 to Ubound(Array) If StrComp(Array_sort(i),Array_sort(i+1),0)=1 Then temp=Array(i) Array (i)=Array(i+1) Array(i+1)=temp End if Next Next Осуществление процедуры поиска в независимости от регистра символов является задачей, решать которую приходится очень часто. Для обеспечения процедуры поиска формируется массив, среди элементов которого происходит поиск. Для того чтобы сделать функцию поиска нечувствительной к регистру символов, необходимо использовать функцию, преобразующую все символы строки в большие или в маленькие. Это касается как элементов массива, так и искомой строки. Для преобразования строки в маленькие буквы используют функцию Lcase(string), для преобразования в большие – Ucase(string). Пример 3 Dim Array(100) ……………….. Dim SearchString="string" For i=0 to Ubound(Array) if Instr(Lcase(Array(i)),LCase(SearchString)) then MsgBox "Строка найдена" else MsgBox "Строка не найдена" End if Next Active Directory Active Directory (AD) – это служба каталогов, которая является иерархической базой данных, обеспечивающей централизованное управление сетью. Active Directory хранит в себе информацию об объектах сети и обеспечивает доступ к этой информации пользователям, компьютерам и приложениям. Active Directory обладает следующими особенностями:
Таблица 1
DNS и Active Directory Для иерархического именования доменов и компьютеров в Active Directory используется система DNS, поэтому объекты доменов и компьютеров являются как частью иерархии доменов DNS, так и иерархией доменов Active Directory. Несмотря на то, что имена в обеих системах идентичны, они относятся к различным пространствам имен. Взаимодействие DNS-имен доменов и их IP-адресов в Active Directory реализовано в согласии с общепринятыми соглашениями об именовании в DNS. Доменная система именования (Domain Name System, DNS) представляет собой базу данных, реализующую иерархическую систему именования для идентификации хостов. Основная функция DNS (см. RFC 1034 и RFC 1035) заключается в прямом и обратном разрешении имен компьютеров в IP-адреса. База данных DNS – это древовидная структура, называемая пространством имен доменов (domain space name). В Windows 2000 полное доменное имя (Fully Qualified Domain Name, FQDN) компьютера состоит из 2 частей:
Рисунок 1. Порядок построения имен FQDN Кроме DNS-имен компьютеров, контроллеры домена Active Directory идентифицируются по видам предоставляемых ими служб: серверы протокола LDAP (Lightweight Directory Access Protocol); контроллеры доменов; сервер глобального каталога GC (Global Catalog). Получив указание на имя домена и службу, сервер DNS способен найти контроллер со службой искомого типа в данном домене. Глобальный каталог (Global Catalog, GC) – это контроллер домена, в котором существуют три доступных для записи каталога: домена, схемы и конфигурации. Каталог автоматически создается при репликации Active Directory. Все разделы каталогов на сервере глобального каталога хранятся в одной базе данных каталога (Ntds.dit). Глобальный каталог хранит сведения обо всех лесах, поэтому его можно использовать для поиска любых объектов в лесу без переадресации на другие серверы. Если запрос на поиск послан по порту 389 (стандартный порт протокола LDAP), то в случае неудачного поиска запрос будет последовательно передаваться другим контроллерам домена. В том случае, если обращение идет по стандартному порту глобального каталога (GC) 3268, поиск ведется по всем разделам леса. Для безопасного доступа к службам следует использовать порты, использующие SSL: Таблица 2
Пример 4 temp="" Set gc = GetObject("GC:") For each child in gc temp=temp+child.name Next msgbox temp
Архитектура службы каталогов Active Directory Чтобы понять, как хранятся и обрабатываются данные в Active Directory, необходимо представлять себе, как взаимодействуют отдельные компоненты этой службы каталогов. Службу каталогов можно представить в виде многоуровневой структуры. Существует три уровня служб и несколько интерфейсов и протоколов, которые образуют полный спектр служб каталогов (см. рис. 2). Три уровня служб содержат все данные для нахождения записей в базе данных каталога. Выше уровня служб находятся протоколы и API-интерфейсы, которые обеспечивают взаимодействие между клиентами и службами каталогов или при репликации – между службами каталогами.
Рисунок 3. Архитектура служб Active Directory Далее перечислены основные службы-компоненты Active Directory:
Клиенты получают доступ к Active Directory по одному из перечисленных механизмов:
Объектная модель ADSI Наглядная схема объектной модели ADSI приведена на рисунке.
Рисунок 4. Объектная модель ADSI Схема условно поделена на три части. Используя клиента – язык программирования, скрипт получает доступ к COM-объектам. Объекты могут быть двух видов – классы и подклассы. Обращение к подклассам осуществляется через классы, однако на схеме это не показано, чтобы не загромождать рисунок. С помощью COM-объекта через протокол LDAP или WinNT сценарий загрузки получает доступ к выбранному элементу объектной модели. Пространство имен условно обозначено треугольником; квадратами обозначены классы, а кружками – подклассы. Методы доступа к каждому из перечисленных протоколов отличаются, однако можно привести пример, который наглядно демонстрирует приведенную схему: Пример 5: Set obj=GetObject("Protocol://ClassName") For each SubClass in ClassName temp=SubClass.Property Next Провайдеры ADSI Интерфейс ADSI поддерживает следующие провайдеры, с помощью которых осуществляется программное администрирование: Таблица 3
Для определения всех доступных протоколов на вашем компьютере необходимо использовать службу ADS: Пример 5 Set obj=GetObject("ADs:") For Each provider IN obj temp = temp + provider.name + chr(13) Next MsgBox temp
Из всех перечисленных провайдеров будут рассмотрены только 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 можно управлять состоянием и очередями принтеров. Совместное использование обоих провайдеров позволит осуществлять мониторинг и управление сетевыми принтерами домена (см. статью «Управление сетевыми принтерами» в журнале «Системный администратор» №10(11) за 2003 г.). Порядок построения запроса для провайдера WinNT в формате UNC следующий: WinNT:[//DomainName[/ComputerName[/ObjectName[,className]]]] Заключение Получив фундаментальные знания о построении Active Directory, поддерживаемых форматов имен и провайдером, принципах программирования скриптов, можно приступать к изучению объектных моделей провайдером. Как ни странно, даже исчерпывающие знания объектной модели, умение применять на практике различные методы, обеспечиваемые провайдерами, не позволяют успешно программировать ADSI. По собственному опыту могу сказать, что не зная основы (теории), которая сначала кажется лишней, невозможно добиться корректной работы скрипта в 100% случаях. Приведу один маленький, но очень наглядный пример: в статье «Управление сетевыми принтерами» в журнале «Системный администратор» №10 за 2003 г. рассказано о том, как с помощью небольшого сайта, написанном на ASP, управлять сетевыми принтерами домена. Не секрет, что сначала создаются наработки – небольшие сценарии, затем состыковывая эти небольшие отрывки между собой, получают решение какой-либо задачи. Заготовки были написаны на VBS, а сайт написан на ASP, который хоть и поддерживает VBS, все же накладывает свой отпечаток. После завершения создания сайта было замечено, что он довольно часто выдает ошибку связанную с тем, что невозможно найти базу, хотя все отрывки на VBS были оттестированы и признаны работающими корректно. Сначала грешили на репликацию двух контроллеров домена. Однако, оказалось, что проблема была в том, что имя сервера печати в провайдере LDAP необходимо было указывать в полном формате, т.е. не server, а server.domain.com. Несмотря на то, что VBS к формату имени равнодушен, для ASP это оказалось принципиальным. Посмотрите таблицу 1 и сразу станет ясно какой формат имен необходимо использовать. Итак, знание теории и вытекающих из нее нюансов, поможет сэкономит время при создании и отладке продукта. |
ИВАН КОРОБКО
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
