работа по специальности на тему «Синхронизация с ldap» (стр. 3 из 4)

AD поддерживает следующие форматы именования объектов: универсальные имена типа UNC, URL и LDAP URL. Версия LDAP формата именования X.500 используется внутри Active Directory.

Каждый объект имеет различающееся имя (Distinguished name, DN). Например, объект принтера с именем HPLaser3 в подразделении «Маркетинг» и в домене foo.org будет иметь следующее различающееся имя: CN=HPLaser3,OU=Маркетинг,DC=foo,DC=org, где «CN» — это общее имя, «OU» — раздел, «DC» — класс объекта домена (рис 1). Различающиеся имена могут иметь намного больше частей, чем четыре части в этом примере. У объектов также есть канонические имена. Это различающиеся имена, записанные в обратном порядке, без идентификаторов и с использованием косых черт в качестве разделителей: foo.org/Маркетинг/HPLaser3. Чтобы определить объект внутри его контейнера, используется относительное различающееся имя: CN=HPLaser3. У каждого объекта также есть глобально уникальный идентификатор (GUID) — уникальная и неизменная 128-битная строка, которая используется в AD для поиска и репликации. Определённые объекты также имеют имя участника-пользователя (UPN, в соответствии с RFC 822) в формате объект@домен.

Рис 1. Структура каталога Active Directory.

1.3 Структура проекта.

Разрабатываемое программное служит для воссоздания модели структуры каталога Active Directory. Это сервисное приложение, функционирующее на контроллере домена, осуществляющее мониторинг каталога Active Directory. Данная реализация мониторинга подразумевает использование службы журналирования Windows. По мере поступления информации об изменениях в каталоге, сервисное приложение осуществляет синхронизацию воссоздаваемой модели посредством передачи данных через внешний программный интерфейс (Рис 2).

Рис 2. Структура проекта.

Программный интерфейс представляет собой документированный способ взаимодействия сервисного приложения для работы с внешними, возможно находящимися на удаленном компьютере, приложениями, непосредственно хранящими в себе и предоставляющими информацию из модели каталога.

Достоинствами данной реализации являются универсальность использования сервисного приложения посредством его прикладного интерфейса, а также быстродействие при работе с моделью каталога, обусловленное тем, что по сути база данных хранится на локальном компьютере и не передается по сети. Также подобная реализация обеспечивает снижение нагрузки на контроллер домена и на локальную сеть, предоставляя атомарность операции обновления структуры каталога.

2 Практическая часть.

2.1 Постановка задачи.

Целью этой работы является воссоздание модели каталога Active Directory. Это включает в себя следующие задачи:

· Рассмотреть и применить способы программного взаимодействия с каталогом Active Directory;

· Создание программного средства – монитора, обеспечивающего поддержку актуальности модели;

· Обеспечение атомарности обновления структуры каталога.

2.2 API для Active Directory.

Имеется множество каталогов сетевых ресурсов, например, LDAP-каталоги, Active Directory, Banyan StreetTalk, Microsoft Windows NT Directory Service, Novell Directory Service, и каталогов конкретных приложений, таких как Lotus Notes, cc:Mail или Microsoft Exchange. Все эти службы каталогов имеют свои интерфейсы программирования, что усложняет как администрирование каталогов (поскольку управление каждым каталогом выполняется отдельно), так и создание корпоративных приложений, обращающихся к используемым в организации каталогам.

Решение проблемы компания Microsoft видит в применении Active Directory Service Interface (ADSI) — набора СОМ-интерфейсов программирования, при помощи которого пользователи и независимые поставщики программного обеспечения (ISV) могут применять единый хорошо проработанный интерфейс для регистрации в различных службах каталогов, доступа к ним и управления этими службами.

Одним из наиболее распространенных и открытых интерфейсов доступа к базам данных является Open Data Base Connectivity (ODBC). Этот интерфейс поддерживается практически всеми реляционными базами данных. ADSI можно рассматривать как "ODBC для служб каталогов". ADSI позволяет создавать механизмы (называемые поставщиками ADSI, ADSI-providers) доступа к информации конкретного типа каталога. Прикладные программы, написанные с использованием ADSI, будут работать с любыми службами каталогов, для которых имеется поставщик ADSI. Так обеспечивается открытое, универсальное решение проблемы использования различных каталогов.

В основе ADSI лежит модель СОМ-объектов, что упрощает написание сценариев доступа к каталогу. Например, администратор может создать сценарий для присвоения значений некоторым элементам Active Directory. Разработчики программных продуктов могут использовать данный API, например, для анализа элементов каталога. Для низкоуровневого программирования на C/C++ Active Directory также имеет стандартный LDAP API, который определяется как набор вызовов С-функций и описан в RFC 1823. Интерфейсы ADSI являются одним из компонентов Open Directory Service Interfaces (ODSI, Интерфейсы службы открытого каталога), входящих в Windows Open Services Architecture (WOSA, Архитектура открытых служб Windows).

Рис 3. Открытое решение с использованием ADSI.

ADSI для различных служб каталогов, a Windows 2000 Server имеет поставщика ADSI для Active Directory. Данная модель используется для доступа к каталогу AD в сервисном приложении.

2.3 Синхронизация с Active Directory.

В стандартном наборе служб ОС Windows существует служба журналирования – EventLog. Она предоставляет возможность различными приложениям документировать события, происходящие в ходе их работы. Например, служба Winlogon оповещает о аварийном завершении процесса explorer (проводник), записывая данное событие в журнал «Приложения» (Рис 4).

Рис 4. Журнал событий Windows.

Каждое приложение может создать отдельно свою категорию в журнале, как, например, делает это Internet Explorer.

Категория безопасность, доступная только для чтения, служит для записи системных событий, например входа локального пользователя, создание новой учетной записи или её изменения. Идея метода синхронизации заключается в том, чтобы следить за изменениями в журнале безопасности, так как операции, влияющие на структуру каталога, имеют свое отражение в категории «Безопаность». Заметим, что записанные в журнале события несут в себе ряд параметров, по которым можно узнать, что именно произошло с отдельной частью каталога. Схема принципа слежения отображена на рисунке 5.

Рис 5. Схема осуществления мониторинга.

Монитор подписывается на сообщения в журнале безопасности, предоставляя службе EventLog ожидаемое событие, тем самым мы избавляемся от необходимости проверки журнала на новые сообщения в бесконечном цикле, что дает прирост производительности приложению и обеспечивает синхронность поступления нового события и реагирования на него.

Когда монитор получает новою запись из журнала, он анализирует код события, выявляя таким образом, к какой подкатегории событий относится последнее. В случае, если событие относится к изменению каталога, анализируются дополнительная информация о событии, с помощью чего записывается информация о том, какое конкретно действие с каталогом было произведено, и, если дана информация, над каким объектом каталога. После произведения анализа, сервис посредством ADSI API обращается к каталогу AD с запросом на измененный объект, либо при отсутствии информации, на определенную категорию каталога. Полученные от каталога данные возвращаются подписчику через WinSock. Таким образом, обеспечивается максимально возможная атомарность обновлений структуры каталога.

2.4 Программный интерфейс службы мониторинга.

По мере получения данных от службы журналирования служба мониторинга должна предоставлять необходимую информацию подписчику. Под подписчиком мы понимаем некое внешнее приложение, пользующееся информацией службы мониторинга. В нашем случае таким приложением будет являться программное средство для воссоздания модели службы каталога.

Обмен информацией между сервисом и приложением осуществляется при помощи сетевого интерфейса WinSock. Сервисное приложение играет роль сервера в соединении. Для того, чтобы получать информацию от сервиса приложению-подписчику необходимо осуществить соединение с контроллером домена по протоколу ТСР на порт 4446. В дальнейшем сервер будет посылать обновления структуры каталогов приложению автоматически при поступлении нового события от журнала. Данные представляются в текстовом виде в соответствии с протоколом LDAP. (Рис 6)

Рис 6. Передача данных по протоколу LDAP.

Так как обмен информацией между приложением и сервисом предусмотрен с использованием сокетов, а сервисное приложение работает из-под системной учетной записи, необходимо учесть аспекты безопасности функционирования сервиса. Полагается, что сервер единовременно может обслужить только один запрос от клиента, причем этот запрос должен умещаться в одном пакете TCP. С целью исключения ошибок переполнения буфера в сервисном приложении резервируется отдельный регион памяти длиной 64 Кб (под размер пакета ТСР), куда впоследствии могут принимаются данные от приложения-клиента. Тем самым обеспечивается целостность программы-монитора и предотвращение атак на контроллер домена с использованием теоретической уязвимости в ней.