Active Directory — теория построения::Журнал СА 1.2004
www.samag.ru
Льготная подписка для студентов      
Поиск   
              
 www.samag.ru    Web  0 товаров , сумма 0 руб.
E-mail
Пароль  
 Запомнить меня
Регистрация | Забыли пароль?
О журнале
Журнал «БИТ»
Подписка
Где купить
Авторам
Рекламодателям
Магазин
Архив номеров
Вакансии
Контакты
   

Jobsora

ЭКСПЕРТНАЯ СЕССИЯ 2019


  Опросы

Какие курсы вы бы выбрали для себя?  

Очные
Онлайновые
Платные
Бесплатные
Я и так все знаю

 Читать далее...

1001 и 1 книга  
28.05.2019г.
Просмотров: 1894
Комментарии: 2
Анализ вредоносных программ

 Читать далее...

28.05.2019г.
Просмотров: 1936
Комментарии: 1
Микросервисы и контейнеры Docker

 Читать далее...

28.05.2019г.
Просмотров: 1498
Комментарии: 0
Django 2 в примерах

 Читать далее...

28.05.2019г.
Просмотров: 1098
Комментарии: 0
Введение в анализ алгоритмов

 Читать далее...

27.03.2019г.
Просмотров: 1668
Комментарии: 1
Arduino Uno и Raspberry Pi 3: от схемотехники к интернету вещей

 Читать далее...

Друзья сайта  

Форум системных администраторов  

sysadmins.ru

Электронка - 2020!

 Active Directory — теория построения

Архив номеров / 2004 / Выпуск №1 (14) / 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 обладает следующими особенностями:

  • Масштабируемость. В отличие от большинства других баз данных, которые являются реляционными, база данных Active Directory является иерархической. В базах данных взаимосвязи между записями определяются при помощи ключей, которые хранятся совместно с данными. В иерархической базе данных взаимосвязи между записями имеют характер «родитель-потомок»: каждая запись, за исключением корневой, обладает родительской записью. У каждой родительской записи может быть один или несколько потомков. Иерархическая база данных позволяет хранить большое количество объектов, при этом быстро получать доступ к необходимым объектам.
  • Поддержка открытых стандартов. Active Directory объединяет в себе концепцию пространства имен интернета со службой каталогов Windows NT, что позволяет объединить и управлять различными пространствами имен в разноразрядных аппаратных и программных средах. Для управления пространством имен Active Directory используется библиотека интерфейса службы активного каталога (Active Directory Service Interface – ADSI).
  • Поддержка стандартных форматов имен. Active Directory поддерживает несколько общих форматов имен. Этот факт позволяет приложениям и пользователям получать доступ к каталогу, применяя наиболее удобный для них формат:

Таблица 1

Формат Описание
UPN Формат основного имя пользователя (User Principial Name, UPN) описан в RFC 822. UPN известны как адреса электронной почты. AD обеспечивает «дружественные» имена в этом формате, таким образом, в качестве имя для входа в сеть пользователь может использовать как имя учетной записи SAM, так и имя в формате RFC 822, например NIvanov@company.com
LDAP URL Имена LDAP (см. RFC 1779, 2247), имеющие более сложную структуру по сравнению с URL именами, которые построены на основе протокола X.500. Имена URL LDAP состоят из следующих частей: CN, OU, DN.

CN расшифровывается как Common Name (общее имя), OU означает организационную единицу (Organization Unit) и  DN означает контроллер домена (Distinguished Nаme – отличительное имя). Часть отличительного имени «DC=» делает возможным подключения каталогов X.500 к пространству имен DNS.

Пример, LDAP://www.domain.ru/CN=NIvanov, OU=Support, OU=Developers или LDAP:// CN=NIvanov, OU=Support, OU=Developers, DN=ru, DN=domain, DN=www
UNC UNC или канонический вид (Active Directory Canonical Name, ADCN), который имеет стандартный вид computer.domain.com/folder1/subfolder2. В AD данный формат является путем в иерархической структуре к объекту (см. RFC 1123)

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 частей:

  • Имя DNS-узла. Крайняя левая метка – это полноценное имя DNS-узла, идентифицирующее учетную запись компьютера, хранящуюся в Active Directory. Кроме того, это имя локальной учетной записи компьютера в диспетчере безопасности учетных записей (Security Account Manager, SAM) на рабочей станции или рядовом сервере (не контроллер домена). По умолчанию имя DNS-узла также используется в качестве NetBIOS-имени. Это делается для совместимости с доменами на основе Windows NT 3.51 и Windows NT 4, а также для совместимости с рабочими станциями под управлением 9х.
  • Основное имя DNS-имени домена. По умолчанию – это домен Windows, к которому относится данный компьютер (см. рис. 1).

Рисунок 1. Порядок построения имен FQDN

Рисунок 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

Порт Описание
389 Порт для открытых запросов LDAP
636 Порт для запросов LDAP c использованием протокола SSL
3268 Порт для открытых запросов GC
3269 Порт для запросов GC c использованием протокола SSL

Пример 4

temp=""

Set gc = GetObject("GC:")

For each child in gc

   temp=temp+child.name

Next

msgbox temp

Рисунок 2

Архитектура службы каталогов Active Directory

Чтобы понять, как хранятся и обрабатываются данные в Active Directory, необходимо представлять себе, как взаимодействуют отдельные компоненты этой службы каталогов. Службу каталогов можно представить в виде многоуровневой структуры. Существует три уровня служб и несколько интерфейсов и протоколов, которые образуют полный спектр служб каталогов (см. рис. 2). Три уровня служб содержат все данные для нахождения записей в базе данных каталога. Выше уровня служб находятся протоколы и API-интерфейсы, которые обеспечивают взаимодействие между клиентами и службами каталогов или при репликации – между службами каталогами.

Рисунок 3. Архитектура служб Active Directory

Рисунок 3. Архитектура служб Active Directory

Далее перечислены основные службы-компоненты Active Directory:

  • агент системы каталогов (directory system agent, DSA) формирует иерархию каталога на основе отношений родитель-потомок и обеспечивает интерфейс прикладного программирования (application programming interfece, API) для запросов на доступ к каталогу;
  • уровень базы данных является промежуточным уровнем – уровнем абстракций между базой данных и приложениями;
  • ядро базы данных (Extensible Storage Engine, ESE), работающее непосредственно с записями хранилища каталогов, различает объекты по атрибуту относительно составного каталога.
  • хранилище данных (файл базы данных Ntds.dit). С этим файлом может работать только ядро базы данных. Обращаться напрямую к этому файлу можно только с помощью программы Ntdsutil, которая находится в папке Support/Tools на диске с операционной системой Windows 2000 Server.

Клиенты получают доступ к Active Directory по одному из перечисленных механизмов:

  1. LDAP/ADSI. Клиенты, поддерживающие протокол LDAP, используют его для доступа к агенту системы каталогов. Интерфейсы службы каталогов Active Directory (Active Directory Service Interface – ADSI) служат для абстрагирования от LDAP интерфейса прикладного программирования (API), представляя COM-интерфейсы для взаимодействия с Active Directory. Однако нужно помнить, что в Active Directory используется только LDAP;
  2. MAPI. При обмене сообщениями и коллективной работе клиенты MS Outlook подключаются к агенту системы каталогов по механизму вызова удаленных процедур MAPI через интерфейс средства доступа к адресной книге.
  3. SAM. Клиенты MS Windows NT 4.0 и ранее Windows 9x подключаются к агенту системы каталогов (DSA) через SAM;
  4. REPL. В процессе репликации каталогов агент системы каталогов (DSA) Active Directory взаимодействует через RPC-интерфейс.

Объектная модель ADSI

Наглядная схема объектной модели ADSI приведена на рисунке.

Рисунок 4. Объектная модель 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

Название Протокол Описание
LDAP Provider "LDAP:" Администрирование Active Directory, Microsoft Exchange Server
WinNT Provide "WinNT:" Администрирование Windows NT, Windows 200x, Windows XP
NDS Provider "NDS:" Администрирование Novell NetWare Directory Service
NVCOMPAT "NVCOMPAT:" Администрирование Novell NetWare 3.1
IIS "IIS: Протокол IIS предназначен для управления WWW и FTP узлами по протоколу HTTP

Для определения всех доступных протоколов на вашем компьютере необходимо использовать службу ADS:

Пример 5   

      Set obj=GetObject("ADs:")

           For Each provider IN obj

           temp = temp + provider.name + chr(13)

           Next

      MsgBox temp

Рисунок 5

Из всех перечисленных провайдеров будут рассмотрены только LDAP и WINNT.

Провайдер ADSI LDAP выполняется на клиенте ADSI и обеспечивает доступ к Active Directory.

Кроме служб каталогов Active Directory Windows 2000, LDAP-провайдер обеспечивает доступ к:

  • Netscape Directory Server;
  • Microsoft Exchange Server 5.x и выше;
  • Microsoft Commercial Internet System (MCIS) Address Book Server.

Программное управление 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 и сразу станет ясно какой формат имен необходимо использовать.

Итак, знание теории и вытекающих из нее нюансов, поможет сэкономит время при создании и отладке продукта.


Комментарии отсутствуют

Добавить комментарий

Комментарии могут оставлять только зарегистрированные пользователи

               Copyright © Системный администратор

Яндекс.Метрика
Tel.: (499) 277-12-41
Fax: (499) 277-12-45
E-mail: sa@samag.ru