КУРСОВАЯ РАБОТА
по специальности
на тему «Синхронизация с LDAP»
Выполнил:
студент 358 группы
Шишкин Артём Игоревич
Научный руководитель:
к.т.н., доцент кафедры ИБ
Широких Андрей Валерьевич
Дата сдачи:________________
Оценка:___________________
Тюмень, 2009 г.
Оглавление
Аннотация. 3
Введение. 4
1. Теоретическая часть. 6
1.1 LDAP. 6
1.2 Active Directory. 9
2 Практическая часть. 17
2.1 Постановка задачи. 17
2.2 API для Active Directory. 17
2.4 Программный интерфейс службы мониторинга. 21
3. Заключение. 23
Список использованной литературы. 24
Аннотация.
В рамках данной темы разработано программное средство, предназначенное для воссоздания структуры каталога LDAP службы Active Directory на заданном контроллере домена. Воссозданная модель позволяет производить анализ структуры Active Directory без непосредственного влияния на сервер – контроллер домена.
Программа представляет собой сервисное приложение, осуществляющее мониторинг событий, связанных с изменением в структуре службы каталогов, и предоставляющее внешний программный интерфейс для непосредственной передачи полученной информации.
Основными чертами приложения являются:
· Синхронность предоставления информации с изменением структуры каталога, что обеспечивает актуальность воссоздаваемой модели;
· Атомарность передаваемых данных, что позволяет избежать лишней нагрузки и на сервер, и на канал, если внешний программный интерфейс находится не на локальном компьютере;
· Независимость от конкретной реализации протокола LDAP, что обуславливает возможность работы с сетью с несколькими контроллерами домена без проблем с синхронизацией записей между ними.
|
|
Введение.
В настоящее время практически любая корпоративная сеть, состоящая из большого числа компьютеров, имеет доменную структуру. И чаще всего она основана на использовании технологии Microsoft под названием Active Directory. С помощью данной технологии работа системных администраторов облегчается в разы, поскольку непосредственное обслуживание компьютера становится необходимым только при проблемах с его аппаратной частью, все программные настройки можно осуществлять удаленно и для нескольких машин одновременно.
Сервера, которые возлагают на себя ответственность за функционирование сети с доменной структурой являются контроллерами домена. Вся информация о домене и большая часть операций с его членами осуществляется через контроллер. Следовательно, существует объективная нагрузка на такие сервера, причем тем она больше, чем больше компьютеров в сети. Сама по себе технология Active Directory является видом другой технологии – LDAP, то есть представляет собой каталог с данными об объектах домена. Зачастую приходится работать с каталогом непосредственно, делая различные запросы об объектах, например, для получения статистических данных. Но так как даже пустой домен имеет довольное большое количество записей в каталоге, операция выборки создает ощутимую нагрузку на контроллер домена и на сеть, создавая большой объем трафика. Это может стать проблемой безопасности, создавая атаку класса DoS (Denial of service – отказ в обслуживании).
С целью предотвращения проблем с безопасностью сети имеет смысл воссоздать модель каталога Active Directory и работать с ней, осуществляя те же самые запросы, не влияя на функционирование сервера и локальной сети.
|
|
Итак, актуальность данной работы подчеркивается распространенностью применения технологии Active Directory.
Целью этой работы является воссоздание модели каталога Active Directory для последующей безопасной работы с ним.
Для достижения данной цели необходимо решить следующие задачи:
· Исследование принципов работы протокола LDAP и его разновидности – Active Directory;
· Создание программного средства – монитора, обеспечивающего поддержку актуальности модели;
· Обеспечение атомарности обновления структуры каталога.
Теоретическая часть.
LDAP.
По мере того как почтовые сервисы приобретали популярность, у пользователей стали возникать проблемы с поиском людей и их почтовых адресов. Очевидной стала необходимость в больших специализированных базах данных, которые бы хранили тысячи, а то и миллионы записей, а также в механизмах доступа к этим данным по сети, включая надежную аутентификацию.
Задача заключалась в создании централизованных адресных книг для целых корпораций с развитой сетью отделений, а также с международными филиалами, подключаемыми по интернету. Ко всему, было принято решение сделать этот каталог платформонезависимым. Поэтому IBM, Lotus, Microsoft и Netscape договорились о применении единого метода доступа — LDAP — для доступа к адресной информации. К этому соглашению приложили усилия и многие другие гранды сетевого компьютинга, к примеру Sun и Novell.
LDAP расшифровывается как Lightweight Directory Access Protocol — то есть "легковесный протокол доступа к каталогам". Эта самая "легковесность" LDAP наводит на мысль, что где-то должен существовать и его "тяжеловесный" собрат. И действительно: в качестве прототипа выступал полновесный протокол доступа к каталогам DAP, известный также как X.500 или "Проект "Белые Страницы”" (White Pages Project).
|
|
Этот протокол был разработан консорциумом OSI и ориентирован на локальные корпоративные сети и большие мэйнфреймы. Адаптацию этого сложного и редко используемого всуе протокола к нуждам современного интернета и персональным компьютерам выполнили хакеры Мичиганского университета, которые вообще известны креативными поделками.
На сегодня существует три версии LDAP. Причем первая не в счет — в ней сразу же были найдены серьезные проблемы. Вторая, и самая распространенная, версия LDAP2 зафиксирована в документах RFC 1777, 1778 и 1779. Наиболее современной на момент написания этой статьи была версия LDAPv3, окончательно утвержденная в 1997 г. В этой версии, с одной стороны, лучше поддерживается X.500, а с другой — больше внимания уделено не-X.500-серверам.
Каталог LDAP, аналогично файловой системе UNIX, построен в виде дерева: корневой узел содержит ссылки на записи, некоторые из которых могут указывать на другие каталоги. Обычно всей организации соответствует корневой каталог. В качестве подкаталогов выступают отделы, филиалы или любые другие имеющие обобщающий смысл атрибуты. Подкаталоги могут быть автоматически реплицированы в обоих направлениях — любая из сторон может инициировать процесс синхронизации подкаталога. Типичное применение автоматических обновлений — синхронизация между главным каталогом компании и каталогами подразделений.
Возможность построения сетей каталогов — это основа для постепенного развертывания служб LDAP: можно начать с одного минимально настроенного сервера и постепенно расширять его функциональность.
Собственно LDAP реализуется в виде клиента и сервера. Сервер LDAP хранит и индексирует записи определенного формата. В качестве полей выступают имя пользователя, его физический и электронный адреса, телефоны и т.д. Администрирование сервера производится по правилам среды: для Linux это файлы настройки и командная строка, для Windows и Mac OS — графические приложения. В последнее время для администрирования, в том числе удаленного, все чаще применяется веб-интерфейс. Серверы, согласно X.500, могут объединяться в сеть, так что пользователь в поисках нужной информации может переходить от одного сервера к другому.
Кроме того, для повышения производительности существуют и LDAP-прокси серверы, эффективно кэширующие частые запросы.
Клиентом чаще всего выступает почтовый клиент. Он содержит форму запроса к удаленному серверу, наподобие той, что используется для поиска в ICQ. Обычно клиентское ПО реализует не все возможности (которых очень много), а какое-то их подмножество. В той или иной мере LDAP поддерживают все современные почтовые клиенты, такие как Outlook Express, Eudora, Netscape, OS X Mail и т.д. Часто доступ к LDAP-серверу, особенно глобальному, можно получить через веб-интерфейс.
Быстро получить окно поиска на заданном сервере обычно можно, введя в окне браузера URL вида ldap://server[:port]. Через косую черту вы можете сразу указать параметры поиска (конечно же, обычно эту строку будет формировать какое-то приложение). Так, ввод в браузер ldap://192.168.0.80/cn=Antonchuk,dc=comizdat,dc=com непосредственно отобразит информацию о главном редакторе К+П. Этот тип URL поддерживается Internet Explorer и Firefox (Netscape) — но не поддерживается, например, в Opera.
Как уже было сказано, LDAP, помимо системы обслуживания запросов, изначально включает и систему аутентификации. Администратор задает привилегии пользователей и определяет записи, к которым тот или иной из них может осуществлять доступ. Списки правил доступа (ACL, Access Control List) позволяют настроить доступ любым образом: в типичном случае пользователь имеет право изменять собственную частную информацию, а все остальные — просматривать ее. Однако можно, например, защитить отдельные поля частной записи от просмотра или модификации.
Собственно, существуют и общественные LDAP-серверы, доступные для поиска всему миру (к примеру, BigFoot или Infospace) — но все-таки основное применение протокол находит на уровне больших и средних корпораций. Не прекращаются попытки создать методы объединения отдельных серверов с целью создания "глобального каталожества". Но до реального воплощения пока далеко.
По сути, LDAP — не реляционная база данных. Структура базы LDAP скорее напоминает XML, где запись представляет собой комбинацию атрибут: значение. Поскольку существует возможность определять новые типы полей, то в LDAP можно сохранить любую текстовую или бинарную информацию. Это обуславливает большую гибкость для описания новых полей и структур, но в общем случае поиск по неиндексированному полю — операция довольно медленная. Всякая запись в каталоге LDAP состоит из одного или нескольких атрибутов и обладает уникальным именем (DN — англ. Distinguished Name). Уникальное имя может выглядеть, например, следующим образом: «cn=Иван Петров, ou=Сотрудники, dc=example, dc=com». Уникальное имя состоит из одного или нескольких относительных уникальных имен (RDN — англ. Relative Distinguished Name), разделённых запятой. Относительное уникальное имя имеет вид ИмяАтрибута=значение. На одном уровне каталога не может существовать двух записей с одинаковыми относительными уникальными именами. В силу такой структуры уникального имени записи в каталоге LDAP можно легко представить в виде дерева.
Запись может состоять только из тех атрибутов, которые определены в описании класса записи (object class), которые, в свою очередь, объединены в схемы (schema). В схеме определено, какие атрибуты являются для данного класса обязательными, а какие — необязательными. Также схема определяет тип и правила сравнения атрибутов. Каждый атрибут записи может хранить несколько значений.
1.2 Active Directory.
Active Directory — LDAP-совместимая реализация интеллектуальной службы каталогов корпорации Microsoft для операционных систем семейства Windows NT. Active Directory позволяет администраторам использовать групповые политики GPO для обеспечения единообразия настройки пользовательской рабочей среды, развёртывать ПО на множестве компьютеров, устанавливать обновления ОС, прикладного и серверного ПО на всех компьютерах в сети. Active Directory хранит данные и настройки среды в централизованной базе данных. Сети Active Directory могут быть различного размера: от нескольких сотен до нескольких миллионов объектов.
Представление Active Directory состоялось в 1996 году, продукт был впервые выпущен с Windows 2000 Server, а затем был модифицирован и улучшен при выпуске сначала Windows Server 2003, затем Windows Server 2003 R2.
В отличие от версий Windows до Windows 2000, которые использовали в основном протокол NetBIOS для сетевого взаимодействия, служба Active Directory интегрирована с DNS и TCP/IP.
Active Directory имеет иерархическую структуру, состоящую из объектов. Объекты разделяются на три основные категории: ресурсы, службы и люди - учётные записи пользователей и групп пользователей. Active Directory предоставляет информацию об объектах, позволяет организовывать объекты, управлять доступом к ним, а также устанавливает правила безопасности.
Каждый объект представляет отдельную сущность — пользователя, компьютер, принтер, приложение или общую сетевую папку — и его атрибуты. Объекты могут также быть контейнерами для других объектов. Объект уникально идентифицируется своим именем и имеет набор атрибутов — характеристик и данных, которые объект может содержать, — которые зависят от типа объекта. Атрибуты являются составляющей базовой структуры объекта и определяются в схеме. Схема определяет, какие типы объектов могут существовать в AD.
Сама схема состоит из двух типов объектов: объекты классов схемы и объекты атрибутов схемы. Один объект класса схемы определяет один тип объекта Active Directory (например, объект «Пользователь»), а один объект атрибута схемы определяет атрибут, который объект может иметь.
Каждый объект атрибута может быть использован в нескольких разных объектах классов схемы. Эти объекты называются объектами схемы, или метаданными, и позволяют изменять и дополнять схему, когда это необходимо. Однако каждый объект схемы является частью определений объектов Active Directory, поэтому деактивация или изменение этих объектов может иметь серьёзные последствия, так как в результате этих действий будет изменена структура AD. Изменение объекта схемы автоматически распространяется в Active Directory. Будучи однажды созданным, объект схемы не может быть удалён, он может быть только деактивирован. Обычно все изменения схемы тщательно планируются.
Контейнер — аналогичен объекту в том смысле, что он также имеет атрибуты и принадлежит пространству имен, но в отличие от объекта, контейнер не обозначает ничего конкретного: он может содержать группу объектов или другие контейнеры.
Верхним уровнем структуры является лес — совокупность всех объектов, атрибутов и правил (синтаксиса атрибутов) в Active Directory. Лес содержит одно или несколько деревьев, связанных транзитивными отношениями доверия. Дерево содержит один или несколько доменов, также связанных в иерархию транзитивными отношениями доверия. Домены идентифицируются своими структурами имён DNS — пространствами имён.
Объекты в домене могут быть сгруппированы в контейнеры — подразделения. Подразделения позволяют создавать иерархию внутри домена, упрощают его администрирование и позволяют моделировать организационную и/или географическую структуры компании в Active Directory. Подразделения могут содержать другие подразделения. Корпорация Майкрософт рекомендует использовать как можно меньше доменов в Active Directory, а для структурирования AD и политик использовать подразделения. Часто групповые политики применяются именно к подразделениям. Групповые политики сами являются объектами. Подразделение является самым низким уровнем, на котором могут делегироваться административные полномочия.
Другим способом деления AD являются «сайты», которые являются способом физической (а не логической) группировки на основе подсетей IP. Сайты подразделяются на имеющие подключения по низкоскоростным каналам (например по каналам глобальных сетей, с помощью виртуальных частных сетей) и по высокоскоростным каналам (например через локальную сеть). Сайт может содержать один или несколько доменов, а домен может содержать один или несколько сайтов. При проектировании Active Directory важно учитывать сетевой трафик, создающийся при синхронизации данных AD между сайтами.
Ключевым решением при проектировании AD является решение о разделении информационной инфраструктуры на иерархические домены и подразделения верхнего уровня. Типичными моделями, используемыми для такого разделения, являются модели разделения по функциональным подразделениям компании, по географическому положению и по ролям в информационной инфраструктуре компании. Часто используются комбинации этих моделей.
Физически информация AD хранится на одном или нескольких равнозначных контроллерах доменов, заменивших использовавшиеся в Windows NT основной и резервные контроллеры домена. Каждый контроллер домена хранит копию данных AD, предназначенную для чтения и записи. Изменения, сделанные на одном контроллере, синхронизируются на все контроллеры домена при репликации. Серверы, на которых сама служба Active Directory не установлена, но которые при этом входят в домен AD, называются рядовыми серверами.
Репликация AD выполняется по запросу. Служба KCC создаёт топологию репликации, которая использует сайты, определённые в системе, для управления трафиком. Внутрисайтовая репликация выполняется часто и автоматически с помощью средства проверки согласованности (уведомлением партнёров по репликации об изменениях). Репликация между сайтами может быть настроена для каждого канала сайта (в зависимости от качества канала) — различная «оценка» (или «стоимость») может быть назначена каждому каналу (например DS3, T1, ISDN и т. д.), и трафик репликации будет ограничен, передаваться по расписанию и маршрутизироваться в соответствии с назначенной оценкой канала. Данные репликации могут транзитивно передаваться через несколько сайтов через мосты связи сайтов, если «оценка» низка, хотя AD автоматически назначает более низкую оценку для связей «сайт-сайт», чем для транзитивных соединений. Репликация сайт-сайт выполняется серверами-плацдармами в каждом сайте, которые затем реплицируют изменения на каждый контроллер домена своего сайта. Внутридоменная репликация проходит по протоколу RPC по IP, междоменная — может использовать также протокол SMTP.
Если структура Active Directory содержит несколько доменов, для решения задачи поиска объектов используется глобальный каталог: контроллер домена, содержащий все объекты леса, но с ограниченным набором атрибутов (неполная реплика). Каталог хранится на указанных серверах глобального каталога и обслуживает междоменные запросы.
Возможность операций с одним главным компьютером позволяет обрабатывать запросы, когда репликация с несколькими главными компьютерами недопустима. Есть пять типов таких операций: эмуляция главного контроллера домена (PDC-эмулятор), главный компьютер относительного идентификатора (мастер относительных идентификаторов или RID-мастер), главный компьютер инфраструктуры (мастер инфраструктуры), главный компьютер схемы (мастер схемы) и главный компьютер именования домена (мастер именования доменов). Первые три роли уникальны в рамках домена, последние две — уникальны в рамках всего леса.
Базу AD можно разделить на три логические хранилища или «раздела». «Схема» является шаблоном для AD и определяет все типы объектов, их классы и атрибуты, синтаксис атрибутов (все деревья находятся в одном лесу, потому что у них одна схема). «Конфигурация» является структурой леса и деревьев AD. «Домен» хранит всю информацию об объектах, созданных в этом домене. Первые два хранилища реплицируются на все контроллеры доменов в лесу, третий раздел полностью реплицируется между репликами контроллеров в рамках каждого домена и частично — на сервера глобального каталога.
База данных AD (хранилище каталогов) в Windows 2000 использует расширяемую подсистему хранения Microsoft Jet Blue, которая позволяет для каждого контроллера домена иметь базу размером до 16 терабайт и 1 миллиард объектов (теоретическое ограничение, практические тесты выполнялись только с приблизительно 100 миллионами объектов). Файл базы называется NTDS.DIT и имеет две основные таблицы — таблицу данных и таблицу связей. В Windows Server 2003 добавлена ещё одна таблица для обеспечения уникальности экземпляров дескрипторов безопасности.
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. Структура проекта.
Программный интерфейс представляет собой документированный способ взаимодействия сервисного приложения для работы с внешними, возможно находящимися на удаленном компьютере, приложениями, непосредственно хранящими в себе и предоставляющими информацию из модели каталога.
Достоинствами данной реализации являются универсальность использования сервисного приложения посредством его прикладного интерфейса, а также быстродействие при работе с моделью каталога, обусловленное тем, что по сути база данных хранится на локальном компьютере и не передается по сети. Также подобная реализация обеспечивает снижение нагрузки на контроллер домена и на локальную сеть, предоставляя атомарность операции обновления структуры каталога.
Практическая часть.
Постановка задачи.
Целью этой работы является воссоздание модели каталога Active Directory. Это включает в себя следующие задачи:
· Рассмотреть и применить способы программного взаимодействия с каталогом Active Directory;
· Создание программного средства – монитора, обеспечивающего поддержку актуальности модели;
· Обеспечение атомарности обновления структуры каталога.
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 Кб (под размер пакета ТСР), куда впоследствии могут принимаются данные от приложения-клиента. Тем самым обеспечивается целостность программы-монитора и предотвращение атак на контроллер домена с использованием теоретической уязвимости в ней.
Заключение.
При разработке данного проекта все задачи были выполнены, основная цель была достигнута. Разработан программный модуль, по сути являющийся «шпионом» за структурой каталога Active Directory, который в свою очередь может иметь множество применений. Также на базе данного модуля можно осуществлять мониторинг и для других частей операционной системы Windows, оперативно реагируя на те или иные события системы.
В ходе разработки мною были изучены принципы работы службы каталогов, протокола LDAP. Рассмотрены различные приемы системного программирования под ОС Windows.
В дальнейшем планируется формализация модели воссоздаваемой службы каталогов, например, реализация на основе СУБД MSSQL. Также планируется осуществить некоторые доработки в работе монитора, как то обеспечение хранения изменений каталога в условии отсутствия подписчика, также обеспечение частичной оптимизации посредством логического анализа поступающих от службы журналирования параметров событий.
Список использованной литературы.
1. М. Руссинович, Д. Соломон «Windows Internals Fifth Edition», 2009 г.
2. Д. М. Харт «Системное программирование в среде Windows», 2005 г.
3. RFC 1777 «Протокол LDAP version 2 (DRAFT STANDARD)»
4. RFC 1823 «LDAP Application Program Interface»
5. RFC 2052 «Указание местоположения служб (DNS SRV records)»
6. RFC 2136 «Динамическое обновление Domain Name System (DNS UPDATE, Dynamic DNS)»
7. RFC 2251 «Протокол LDAP version 3»
8. Арсений Чеботарёв, «LDAP: каталог для всех», Комиздат 2005 г.
9. MSDN Magazine 2008
10. В. Гилёв «Active Directory для осваивающих», 2004 г.