Работа протокола Lightweight Directory Access Protocol

Размещено на http://www.allbest.ru/

Работа протокола Lightweight Directory Access Protocol



Содержание

Введение

1. Обзор LDAP

2. LDAP и базы данных

2.1 Оптимизация на чтение

2.2 Представление организации данных

2.3 Синхронизация и репликация данных

2.4 Использование LDAP - резюме

3. Информационная модель LDAP

3.1 Структура дерева объектов

3.2 Атрибуты

3.3 Объектные классы

3.4 Описание дерева и добавление данных

3.5 Навигация по дереву

4. Отсылки и репликация LDAP

4.1 Отсылки LDAP

4.2 Репликация LDAP

5. Обзор элементов LDAP

5.1 Наборы схемы данных LDAP

5.2 Объектные классы LDAP

5.3 Определение объектного класса

5.4 Атрибуты LDAP

5.5 Правила соответствия

5.6 Определения правила соответствия

5.7 Операционные атрибуты и объекты LDAP

Заключение

Список литературы



Введение

Конец 70-х?--?начало 80-х ITU (International Telecommunication Union) начал работу над почтовыми стандартами серии X.400. Для этого стандарта требовался каталог имён (и другой информации), который мог бы быть доступен по сети в иерархической манере, схожей с DNS.

Эта потребность в глобальном сетевом каталоге сподвигла ITU к разработке стандартов серии X.500 и, в частности X.519, которые определяют DAP (Directory Access Protocol), протокол для доступа к сетевой службе каталогов.

Перенесёмся в начало 90-х. IETF осознала необходимость доступа к глобальным службам каталогов (первоначально, во многом, по тем же самым причинам хранения адресов электронной почты, что и ITU), но не поднимая при этом всех этих ужасных перенагруженных протоколов (OSI), и начала работу над Lightweight Directory Access Protocol (LDAP). LDAP разрабатывался так, чтобы обеспечить почти столько же функциональности, что и оригинальный стандарт X.519, но с использованием стека протоколов TCP/IP, при этом оставляя возможность взаимодействия с каталогами, основанными на X.500. Действительно, взаимодействие с X.500 (DAP) и его отображение всё ещё является частью серии RFC о LDAP от IETF.

Большинство вопросов в спецификациях LDAP, вызывающих серьёзную головную боль, как раз связаны с обратной совместимостью с X.500 и концепцией глобальной службы каталогов. Самый показательный из них?--?соглашение об именовании корневой записи.

Целью данной курсовой работы является: в подробностях изучить работу протокола LDAP и взаимодействие его со службами каталогов.



1. Обзор LDAP

LDAP (англ. Lightweight Directory Access Protocol -- "облегчённый протокол доступа к каталогам") -- протокол прикладного уровня для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP. Это всего лишь протокол, определяющий методы, посредством которых осуществляется доступ к данным каталога. Он также определяет и описывает, как данные представлены в службе каталогов.

LDAP определяет четыре модели, которые мы перечислим и кратко обсудим, а затем Вы можете спокойно забыть о них, поскольку для понимания LDAP они мало что дают.

1. Информационная модель: мы склонны использовать термин модель данных, на наш взгляд он более интуитивный и понятный. Модель данных (или информационная модель) определяет, каким образом информация или данные представлены в системе LDAP.

2. Модель именования: определяет все вещи наподобие 'dc=example,dc=com', с которыми сталкиваются в системах LDAP.

3. Функциональная модель: при чтении, поиске, записи или модификации LDAP используется функциональная модель.

4. Модель безопасности: может контролировать, причём весьма детально, кто, что и с какими именно данными может сделать. Эта модель также включает в себя защиту данных при передаче по сети, такую как TLS/SSL.

Сфера стандартов LDAP показана на схеме 1. Обозначенные красным вещи (1, 2, 3, 4) определены в протоколе (различных RFC, определяющих LDAP). Происходящее же в "чёрных ящиках" (или, в данном случае, в зелёных, жёлтых и сиреневых ящиках), а также показанное чёрной стрелкой обращение к базам данных (5) выходит за рамки стандартов.

схема 1

Четыре важных момента:

1. LDAP не определяет, каким образом данные хранятся, только каким образом к ним осуществляется доступ.

2. Когда Вы общаетесь с сервером LDAP, Вы понятия не имеете, откуда поступают данные: на самом деле одна из ключевых задач стандарта?--?скрывать такой уровень детализации. Теоретически, данные могут поступать из одной или нескольких локальных баз данных, либо одной или нескольких служб X.500.

3. Две концепции,?--?доступ к службе LDAP и эксплуатация службы LDAP,?--?должны быть чётко разделены.

4. Ряд коммерческих продуктов баз данных предоставляет LDAP-представление (LDAP-обёртку или LDAP-абстракцию) реляционной базы данных или базы данных другого типа.



2. LDAP и базы данных

LDAP характеризуется как сервис "один раз записал?--?много раз прочитал". Другими словами, от данных, обычно хранящихся в каталоге LDAP, не ожидается, чтобы они менялись при каждом доступе. Для иллюстрации: LDAP НЕ подходит для ведения учета банковских операций, так как они, по своей природе, изменяются почти при каждом доступе (сделке). С другой стороны, LDAP как нельзя лучше подходит для учёта различных аспектов деятельности банка, меняющихся значительно реже: отделений, часов работы, сотрудников и т.д.

2.1 Оптимизация на чтение

Во фразе "один раз записал?--?много раз прочитал" до конца не ясно, насколько много это много?

Где проходит грань разумного использования между LDAP и классическими, ориентированными на транзакции реляционными базами данных, к примеру, SQLite, MySQL, PostGreSQL? Если обновление происходит при каждом втором доступе, будет ли разумно использовать в таком приложении LDAP, или нужно, чтобы обновления происходили раз в тысячу или в миллион обращений?

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

Простого ответа на этот вопрос нет, однако следующие замечания могут оказаться полезными:

1. Увеличение нагрузки при операциях записи происходит из-за обновления индексов. Чем больше индексов (для ускорения поиска), тем, по возможности, реже должны выполняться обновления каталога.

2. Репликация LDAP генерирует несколько транзакций для каждого обновления, таким образом, желательно снизить практическую нагрузку, связанную с обновлениями (1000:1 или больше).

3. Если объём данных велик (скажем, больше 100 000 записей), то даже при небольшом количестве индексов время обновления может быть значительным.

4. Если объём данных относительно невелик (скажем, меньше 1000 записей), индексов немного и отсутствует репликация, мы не видим рационального объяснения, почему Вы не можете использовать LDAP в форме, приближенной к транзакционной системе, то есть каждые 5-10 доступов на чтение чередуются циклом записи.

5. Мы полагаем, что настоящий ответ на этот вопрос (с уважением к памяти ушедшего от нас Douglas Noel Adams): соотношение количества чтений к количеству записей составляет 42.

2.2 Представление организации данных

Применяемые для доступа к каталогам LDAP примитивы используют модель данных, которая абстрагирована от её физической организации. Эти примитивы обеспечивают представление данных в виде объектной модели и не заботятся об актуальной структуре данных.

В этом резкий контраст со, скажем, SQL, поскольку в SQL-запросах, используемых для получения данных, присутствует полное и детальное представление структур данных, их организация в таблицы, объединения и т.д.

2.3 Синхронизация и репликация данных

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

Главный LDAP-сервер и подчинённые ему серверы используют простой асинхронный процесс репликации данных. В связи с этим во время цикла репликации возможна рассинхронизация данных в главной и подчинённой системах. Во время этого периода времени запрос к главному и подчинённому серверам может дать разные результаты. Если вследствие такого расхождения мир с треском расколется пополам, значит, для подобного приложения LDAP не подойдёт. Если же Bob Smith на несколько секунд будет числиться в бухгалтерии на одном LDAP-сервере, а на другом?--?в отделе продаж, вряд ли это кого-то сильно огорчит. В эту категорию попадает удивительно большое количество приложений.

2.4 Использование LDAP - резюме

Так в чём же преимущества LDAP, и почему каждый здравомыслящий человек будет их использовать?

Прежде чем попытаться ответить на этот вопрос, давайте абстрагируемся от тактических соображений производительности. В целом, реляционные СУБД всё ещё значительно быстрее реализаций LDAP. По мере разработки служб каталогов второго поколения - это положение меняется, и, хотя реляционные СУБД всегда будут оставаться быстрее LDAP, разрыв значительно сократился вплоть до точки, в которой различия становятся уже практически несущественными, если, конечно, Вы сравниваете подобное с подобным.

Так почему же нужно использовать LDAP? Вот наш список ключевых характеристик, которые делают высокий уровень боли терпимым:

1. LDAP предоставляет стандартизированные как удалённый, так и локальный методы доступа к данным.

2. Поскольку в LDAP используются стандартизированные методы доступа к данным, клиенты и серверы могут разрабатываться отдельно или быть получены из разных источников.

3. LDAP предоставляет метод, посредством которого данные могут быть перемещены в несколько мест, не затрагивая при этом внешнего доступа к этим данным.

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

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



3. Информационная модель LDAP

Каталоги LDAP используют модель данных, которая представляет данные как иерархию объектов. Это не означает, что LDAP является объектно-ориентированной базой данных.

3.1 Структура дерева объектов

В этом разделе определяется сущность LDAP. Если Вы поймёте этот раздел и различные термины и отношения, с ним связанные, Вы поймёте LDAP.

В LDAP-системе данные представлены как иерархия объектов, каждый из которых называется записью. Полученная в результате древовидная структура называется Информационным деревом каталога (Directory Information Tree, DIT). Верхнюю часть данного дерева обычно называют корнем (root), (а также базой (base) или суффиксом (suffix)).

У каждой записи есть одна родительская запись и ноль или более дочерних записей. Каждая дочерняя запись является одноуровневой по отношению к другим дочерним записям своей родительской записи.

Каждая запись состоит из одного или нескольких объектных классов (objectClass). Объектные классы содержат ноль или более атрибутов (attribute). Атрибуты имеют имена и обычно содержат данные.

Характеристики объектных классов и их атрибутов описываются определениями ASN.1.

Но суть LDAP именно в этом.

Представленная ниже схема 2 иллюстрирует эти отношения:

схема 2

Информационная модель LDAP DIT

Подытожим:

1. Каждая запись состоит из одного или нескольких объектных классов.

2. У каждого объектного класса есть имя.

3. У каждого атрибута есть имя, он является членом объектного класса и обычно содержит данные.

3.2 Атрибуты

Каждый атрибут имеет имя и обычно содержит данные. Атрибуты всегда связаны с одним или несколькими объектными классами. У атрибутов есть ряд интересных особенностей:

1. Все атрибуты являются членами одного или нескольких объектных классов.

2. Каждый атрибут определяет тип данных, которые он может содержать.

3. Атрибуты могут быть необязательными или обязательными, согласно определениям ASN.1 того объектного класса, членами которого они являются. Атрибут может быть необязательным в одном объектном классе и обязательным в другом.

4. У атрибутов может быть single (одно) или multi (несколько) значений. Single означает, что только одно значение данных может быть задано для этого атрибута. Multi означает, что для данного атрибута может быть задано одно или несколько значений данных. Если атрибут описывает, скажем, адрес электронной почты, у него может быть одно, два или 500 значений?--?это один из ряда методов работы с почтовыми псевдонимами, применяемых при построении каталога.

5. У атрибутов есть имена и, иногда, псевдонимы или аббревиатуры, например, commonName является членом объектного класса, называемого person, и имеет сокращённое имя cn. Для ссылки на этот атрибут может использоваться как commonName, так и cn.

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

Предположим, у Вас есть классический каталог "белые страницы", содержащий имена, номера телефонов, адреса, любимые напитки (существует стандартный атрибут favoritedrink). Чтобы однозначно идентифицировать конкретную запись, Вы можете выбрать имя человека (атрибут commonName или cn). Если имя, например: "Bob Smith", не является уникальным в данном каталоге LDAP, то при поиске "Bob Smith" будут возвращены все записи в каталоге, содержащие имя "Bob Smith", и пользователю нужно будет выбирать, какая ему больше нравится. При чтении и поиске это может оказаться приемлемо или даже желательно, поскольку люди часто используют такую широко известную информацию, как имя человека.

При сохранении или обновлении записи недопустимо, чтобы "Bob Smith" был не абсолютно уникальным?--?какую из возвращённых записей нам следует обновить? В таком случае может потребоваться выбрать другой атрибут, являющийся абсолютно уникальным. Вполне допустимо использовать более одного атрибута для доступа к данным в зависимости от контекста, например, имя человека при чтении и поиске, а при сохранении?--?телефонный номер. Кроме того, как упоминалось выше, допустимо использовать более одного атрибута для определения уникальности записи (cn+favoritedrink)

Атрибуты, выбранные для хранения данных, составляющих уникальность записи, называются атрибутами именования или относительным уникальным именем (Relative Distinguished Name, RDN).

3.3 Объектные классы

Объектные классы являются, по существу, пакетами атрибутов. Существует огромное число предопределённых объектных классов, в каждом из которых полным-полно атрибутов для почти всех возможных применений каталогов LDAP. Однако, само собой разумеется, что среди всех этих предопределённых объектных классов, нет того, который Вам просто необходим. У объектных классов есть ещё две характеристики:

1. Объектный класс определяет, должен ли входящий в него атрибут присутствовать в записи (обязательный атрибут), или он может присутствовать (необязательный атрибут).

2. Объектный класс может быть частью иерархии, в этом случае он наследует все характеристики своих родительских объектных классов.

Вот неполный список наиболее часто используемых объектных классов и их атрибутов.



3.4 Описание дерева и добавление данных

В конце концов, мы хотим поместить немного данных в наш каталог и использовать-таки эту замороченную штуку.

Описание древовидной структуры и первоначальное наполнение данными осуществляется путем добавления записей, начиная от корневой записи DIT и двигаясь вниз по иерархии. Таким образом, родительская запись всегда должна быть добавлена перед тем, как пытаться добавить дочерние записи. Добавление записей может происходить разными путями, один из которых?--?использовать файлы формата LDAP Data Interchange Files (LDIF), который полностью описан в одной из последующих глав. Файлы LDIF?--?это текстовые файлы, описывающие древовидную иерархию?--?информационное дерево каталога, и данные, добавляемые в каждый атрибут. Ниже приведён простой пример LDIF-файла, описывающий корневое DN (dc=example,dc=com) и добавляющий одну дочернюю запись в ветку people.

Примечания:

1. На данном этапе не так важно досконально разбираться во всех значениях этого LDIF-файла. На данном этапе достаточно знать, что LDIF-файлы могут использоваться для создания DIT и выглядят примерно так, как приведено ниже.

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

version: 1

## указание версии не является строго необходимым (и некоторые реализации его отклоняют),

## но, в общем случае, это хорошая практика

## Определяем DIT ROOT/BASE/SUFFIX ####

## используется формат RFC 2377 (доменные имена)

## dcObject - это ВСПОМОГАТЕЛЬНЫЙ объектный класс и, кроме него, запись

## ДОЛЖНА иметь СТРУКТУРНЫЙ объектный класс (в данном случае, organization)

# это последовательность ЗАПИСИ и ей предшествует ПУСТАЯ СТРОКА

dn: dc=example,dc=com

dc: example

description: Лучшая компания в целом свете

objectClass: dcObject

objectClass: organization

o: Example, Inc.

## ПЕРВЫЙ уровень иерархии - люди (people)

# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой

dn: ou=people, dc=example,dc=com

ou: people

description: Все люди в организации

objectClass: organizationalUnit

## ВТОРОЙ уровень иерархии - записи людей

# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой

dn: cn=Joe Schmo,ou=people,dc=example,dc=com

objectclass: inetOrgPerson

cn: Joe Schmo

sn: Schmo

uid: jschmo

mail: joe@example.com

mail: j.schmo@example.com

ou: sales

Важное замечание: Строки в приведённом выше LDIF-файле, начинающиеся с 'dn:', по существу сообщают LDAP-серверу, каким образом структурировать или располагать запись в DIT. В общем случае не важно, значение какого атрибута используется для этой цели, при условии уникальности 'dn:'. В последней записи приведённого примера для этой цели было выбрано cn=Joe Schmo. Точно также могло быть выбрано, скажем, uid=jschmo. При LDAP-поиске может применяться любая комбинация атрибутов и запись будет найдена независимо от того, какое значение было использовано в 'dn:' при её создании. Однако, если запись планируется использовать для аутентификации пользователя, скажем, для входа в систему или организации технологии единого входа (Single Sign-On), значение 'dn:' становится чрезвычайно важным и определяет идентификатор входа в систему. Иногда он называется DN принципала (Principal DN), хотя этот термин не используется в определениях стандартов LDAP.

Приведённый выше LDIF определяет следующую структуру (схема 3):

схема 3

После того, как DIT определён и запущен в работу, в дальнейшем информацию в него можно добавлять с помощью LDIF, LDAP-браузера, web-интерфейса или другого программного интерфейса.

Используя LDIF-файлы, данные также можно экспортировать в качестве резервной копии или для других целей.



3.5 Навигация по дереву

После того, как мы поместили данные в наше дерево, обычно самое время начать с ними работать.

Для этого мы должны посылать команды нашему LDAP-серверу, а чтобы сделать это, мы должны быть в состоянии сообщить LDAP-серверу, где находятся данные или хотя бы где они примерно находятся.

Ранее мы определили, что у атрибутов есть имена, и что на каждом уровне иерархии один или несколько атрибутов должны содержать данные, каким-то образом уникально идентифицирующие каждую запись.

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

Такие пути причудливо называются уникальными или отличительными именами (Distinguished Names, DN). Каждый атрибут с уникальными данными, являющийся частью этого DN, называется относительным уникальным именем (Relative Distinguished Name, RDN). Другими словами, DN является суммой всех своих RDN.

Следующая схема 4 иллюстрирует DN и RDN:

схема 4



4. Отсылки и репликация LDAP

Одним из наиболее мощных аспектов LDAP (и X.500) является вложенная в них способность делегировать ответственность за поддержание части каталога другому серверу, сохраняя при этом общую картину каталога как единого целого. Таким образом, можно создать в каталоге компании делегирование ответственности той части всего каталога, в которой описан конкретный отдел, LDAP-серверу этого отдела. В этом аспекте LDAP почти полностью отражает концепцию делегирования DNS.

В отличие от системы DNS, в стандартах не предусмотрена возможность сообщить LDAP-серверу, проследовать по отсылке, LDAP-клиенту оставлена возможность напрямую обращаться к новому серверу, используя возвращённую отсылку. Равным образом, поскольку в стандарте не определена организация данных LDAP, возможность перехода LDAP-сервера по ссылке не противоречит стандартам и некоторые LDAP-серверы выполняют эту функцию автоматически, используя процесс, обычно называемый сцеплением (chaining).

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

Важно, однако, подчеркнуть разницу между LDAP и транзакционными базами данных. При выполнении обновления в главном каталоге LDAP, для обновления подчинённых копий каталога может потребоваться некоторое время?--?главный и подчинённый каталоги могут быть рассинхронизированы в течение какого-то периода времени.

В контексте LDAP, временное отсутствие синхронизации DIT считается несущественным. В случае же транзакционной базы данных, даже временное отсутствие синхронизации считается катастрофическим.



4.1 Отсылки LDAP

Схема 5 демонстрирует поисковый запрос с базовым DN dn:cn=thingie,o=widgets,dc=example,dc=com к LDAP-системе с отсылками, который полностью удовлетворяется первым LDAP-сервером (LDAP1):

Схема 5?--?Запрос, удовлетворяемый только от LDAP1

Схема 6 демонстрирует поисковый запрос с базовым DN dn:cn=cheri,ou=uk,o=grommets,dc=example,dc=com к LDAP-системе с отсылками, ответ на который возвращается в результате серии отсылок к серверам LDAP2 и LDAP3, а LDAP-клиенты всегда следуют по отсылкам:

Схема 6?--?Запрос, генерирующий отсылки к LDAP2 и LDAP3

Примечания: Все клиентские запросы начинаются с обращения к глобальному каталогу LDAP1.

На сервере LDAP1 запросы любых данных, содержащие widgets в качестве RDN в DN, удовлетворяются непосредственно из LDAP1, например:

dn: cn=thingie,o=widget,dc=example,dc=com

На сервере LDAP1 запросы любых данных, содержащие grommets в качестве RDN в DN, генерируют отсылку на сервер LDAP2, например:

dn: cn=cheri,ou=uk,o=grommets,dc=example,dc=com

На сервере LDAP2 запросы любых данных, содержащие uk в качестве RDN в DN, генерируют отсылку на сервер LDAP3, например:

dn: cn=cheri,ou=uk,o=grommets,dc=example,dc=com

Если LDAP-сервер сконфигурирован на выполнение сцепления, то LDAP-клиенту будет отправлен один единственный ответ. Сцепление контролируется конфигурацией LDAP-сервера и значениями в поисковых запросах.

1. На рисунках показано явное сцепление с использованием объектного класса referral. Серверы OpenLDAP могут быть настроены так, чтобы возвращать общую отсылку в случае, если запрашиваемый DN не был найден во время операции поиска.

4.2 Репликация LDAP

Функции репликации позволяют копировать обновления LDAP DIT на одну или несколько LDAP-систем в целях резервирования или повышения производительности. В этом контексте стоит подчеркнуть, что репликация работает на уровне DIT, а не на уровне LDAP-сервера, поскольку на одном LDAP-сервере может обслуживаться несколько DIT. Репликация происходит периодически, в течение промежутка времени, известного как время цикла репликации. В общем случае, существуют методы уменьшения времени цикла репликации с помощью настроек, но обычно они приводят к снижению производительности или увеличению нагрузки на сеть. Исторически для выполнения репликации в OpenLDAP использовался отдельный демон (slurpd), но, начиная с версии 2.3, стратегия репликации коренным образом изменилась, были достигнуты серьёзные улучшения в гибкости и возможностях настройки времени цикла репликации. Существует два возможных типа конфигураций репликации, у каждого из которых есть несколько вариантов.

1. Главный-подчиненный (Master-Slave): В конфигурации главный-подчинённый обновляется одно единственное DIT, и эти обновления реплицируются или копируются на один или несколько указанных LDAP-серверов, на которых запущены подчинённые DIT. Подчинённые серверы оперируют с доступной только для чтения копией главного DIT. Пользователи, которые выполняют только чтение, будут превосходно себя чувствовать, работая с серверами, содержащими подчинённые DIT, а пользователи, которым нужно вносить изменения в каталог, должны обращаться к серверу, содержащему главное DIT. При определённых условиях конфигурация главный-подчинённый позволяет существенно сбалансировать нагрузку. Однако у неё есть два очевидных недостатка:

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

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

2. Несколько главных (Multi-Master): В конфигурации с несколькими главными серверами могут обновляться несколько главных DIT, запущенных на одном или нескольких серверах, и результаты обновлений распространяются на другие главные серверы.

2.1. Конкуренция значений. Если выполняется два обновления одного и того же атрибута в одно и то же время и при этом атрибуту назначаются разные значения, то, в зависимости от типа атрибута, результирующая запись может быть в неправильном или непригодном для использования состоянии.

2.2. Конкуренция удаления. Если один пользователь добавляет дочернюю запись в то же самое время, когда другой пользователь удаляет оригинальную запись, то удалённая запись вновь появится.

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

Схема 7 ?--?Конфигурации репликации

Примечания:RO = только чтение, RW = чтение-запись

1. В случае LDAP1 клиент взаимодействует с подчинённой системой, доступной только для чтения.

2. В случае LDAP2 клиент взаимодействует с главной системой, которая реплицируется на две подчинённые.

3. LDAP3 является системой с несколькими главными серверами и для выполнения операций чтения или записи клиенты могут обращаться к любому серверу.



5. Обзор элементов LDAP

Всё в LDAP иерархично, в том числе объектные классы и атрибуты. Наборы схемы важны, но не особо интересны, они представляют собой упаковку, в которой грубо сгруппированы между собой объектные классы и атрибуты.

Ниже определены важные правила, относящиеся к каждой из этих "фенечек":

1. Наборы схемы?--?это просто упаковочные единицы. Если требуется более точное определение, то это сборники "фенечек", а также метод быстрого указания на множество элементов, позволяющий не останавливаться на каждом элементе в отдельности:

1.1. Все объектные классы и атрибуты определяются внутри набора схемы.

1.2. Все наборы схемы, включающие используемые в какой-либо реализации LDAP объектные классы и атрибуты, должны быть известны LDAP-серверу.

1.3. Атрибут, определённый в одном наборе схемы, может использоваться в объектном классе, определённом в другом наборе схемы?--?стиль Pick'n Mix.

2. В объектных классах сгруппированы наборы атрибутов:

2.1. Объектные классы определяются внутри наборов схемы.

2.2. Объектные классы могут быть организованы в иерархию, в этом случае они наследуют все свойства своих родительских или вышестоящих объектных классов.

2.3. Объектные классы могут быть структурными (STRUCTURAL), в этом случае они могут использоваться для создания записей, вспомогательными (AUXILIARY), в этом случае они могут быть добавлены в любую подходящую запись, или абстрактными (ABSTRACT) ?--?несуществующая "фенечка".

2.4. Если объектный класс является частью иерархии, он должен быть того же типа, что и любой из вышестоящих объектных классов.

2.5. Объектные классы предназначены для подключения атрибутов.

2.6. Объектные классы определяют, является ли атрибут обязательным, то есть должен присутствовать в записи, либо необязательным, то есть может присутствовать в записи с данным объектным классом.

2.7. Объектные классы определяются с помощью нотации ASN.1.

3. Атрибуты обычно содержат данные:

3.1. Каждый атрибут определён в наборе схемы данных.

3.2. Каждый атрибут входит в один или несколько объектных классов.

3.3. Чтобы использовать атрибут в записи, в определение этой записи должен быть включен его объектный класс, и этот объектный класс должен быть включен в набор схемы данных. В свою очередь, этот набор схемы должен быть известен LDAP-серверу.

3.4. Характеристики атрибута определяются с помощью нотации ASN.1.

3.5. Атрибут может появляться лишь однажды в любом экземпляре содержащего его объектного класса, либо может появляться более одного раза в любом экземпляре содержащего его объектного класса . Значение по умолчанию?--?MULTI-VALUE.

3.6. Определение атрибута может быть частью иерархии, в этом случае оно наследует все свойства своих родителей.

3.7. Определение атрибута включает его тип или синтаксис, например, строка или число. Кроме того, с помощью, так называемых правил соответствия (matchingRules), указывается то, как атрибут будет вести себя в определённых условиях, например, будет ли при операциях сравнения учитываться регистр символов или нет.

4. В записях в пределах DIT сгруппированы наборы объектных классов:

4.1. Записи должны содержать один и только один структурный объектный класс. У структурного объектного класса может быть вышестоящий объектный класс, тоже являющийся структурным.

4.2. Записи могут содержать любое количество вспомогательных объектных классов.

4.3. У записи могут быть дочерние записи, располагающиеся ниже неё в иерархии адресов.

4.4. У записи могут быть родительские записи, располагающиеся выше неё в иерархии адресов.

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

Схема 8, иллюстрирующая некоторые из этих отношений:

Схема 8

5.1 Наборы схемы данных LDAP

Наборы схемы данных LDAP?--?не более чем удобная упаковка для содержания во многом схожих объектных классов и атрибутов.

Возможно, когда-то существовал единственный набор схемы данных, содержащий всё необходимое для LDAP-реализаций, но теперь это не так.

Основное правило: Каждый используемый в реализации LDAP атрибут или объектный класс, включая их вышестоящие объектные классы или атрибуты, должен быть определен в наборе схемы, и этот набор схемы должен быть известен серверу LDAP.

Схема 9, иллюстрирующая использование наборов как упаковочных единиц:

Схема 9

5.2 Объектные классы LDAP

Объектный класс?--?это коллекция атрибутов. У него следующие характеристики:

1. Объектный класс определяется внутри набора схемы.

2. Объектный класс может быть частью иерархии объектных классов, в этом случае он наследует все свойства своего родительского объектного класса.

3. Объектный класс имеет глобальное уникальное имя или идентификатор.

4. Объектный класс, поскольку является контейнером атрибутов, также сам по себе атрибут и может фигурировать в операциях поиска.

5. Объектный класс определяет составляющие его атрибуты, а также то, должны ли они присутствовать, либо могут присутствовать в записи.

6. В записи LDAP должны присутствовать один или несколько объектных классов.

7. В записи LDAP должен присутствовать один и только один структурный объектный класс.

8. Все объектные классы, поддерживаемые сервером LDAP, формируют коллекцию под названием objectclasses, просмотреть которую можно через subschema.

5.3 Определение объектного класса

Объектный класс определяется с помощью нотации ASN.1. Далее рассмотрим определение простого стандартного объектного класса country, взятого из набора схемы core.schema, поставляемого с дистрибутивами OpenLDAP. организация дерево данные каталог

objectclass ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL

MUST c

MAY ( searchGuide $ description ) )

Давайте разберём это определение:

Ключевое слово objectclass указывает, что это определение объектного класса.

2.5.6.2 NAME 'country' определяет глобально уникальное имя данного объектного класса, состоящее из двух частей: NAME 'country' просто позволяет обращаться к этому объектному классу с помощью некоего полупонятного текста?--?в данном случае английское слово country. Глобально уникальная часть определяется с помощью 2.5.6.2, так называемого OID (ObjectIdentifier, идентификатора объекта). OID 2.5.6.2, похоже, третий из объектных классов, когда-либо определённых X.500 (это следует из того факта, что 2.5.6 определяет совместные объектные классы itu-iso x.500, а последняя 2?--?порядковый номер в пределах этого семейства OID). Не важно, какая организация присваивает этот номер, но он должен быть УНИКАЛЬНЫМ. Получение корпоративного OID (формально Private Enterprise Number (PEN)), позволяющего определять свои собственные атрибуты и объектные классы,?--?простая и бесплатная процедура, которую предоставляет IANA. Повторно использовать существующие OID?--?очень скверная штука (VERY BAD THING™).

SUP 'top' указывает, что у этого объектного класса есть РОДИТЕЛЬСКИЙ объектный класс, то есть он является частью иерархии. В данном случае родительским объектным классом будет top?--?специальный объектный класс, который ограничивает все объектные классы. Объектный класс может иметь один или несколько родительских объектных классов.

Ключевое слово STRUCTURAL указывает, что этот объектный класс содержит атрибуты и может формировать запись в DIT. В записи может быть только один структурный объектный класс, но структурный объектный класс может быть частью иерархии. Объектные классы также могут быть абстрактными, что указывает на несуществующий объектный класс, используемый для удобства. Наиболее часто используемый абстрактный объектный класс?--?это top, просто ограничивающий иерархию объектных классов. Наконец, объектный класс может быть вспомогательным, что говорит о том, что он содержит атрибуты и может использоваться для формирования записи с любым структурным объектным классом, но самостоятельно формировать запись в DIT не может. Во всех записях должен один структурный объектный класс.

DESC?--?это необязательное значение, предоставляющее текстовое описание порядка использования или содержимого объектного класса. Оно предназначено для чтения людьми и другого применения не имеет. Вот на что стало бы похоже country, если бы в него включили осмысленный оператор DESC:

objectclass ( 2.5.6.2 NAME 'country' SUP top STRUCTURAL

DESC '2 character iso 3611 assigned country code'

MUST c

MAY ( searchGuide $ description ) )

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

MUST c. MUST указывает, что атрибуты из следующего за этим оператором списка являются обязательными. В данном случае атрибут должен присутствовать, иначе не создастся экземпляр объектного класса и, если это структурный объектный класс, запись не будет создана. Единичные значения записываются как было показано, несколько атрибутов заключаются в круглые скобки и разделяются знаком $ (доллар), вот так: ( attr1 $ attr2 $ attrn). Если у объектного класса нет обязательных (MUST) атрибутов, эта секция не включается.

MAY ( searchGuide $ description ) MAY указывает, что атрибуты из следующего за этим оператором списка являются необязательными и для создания экземпляра объектного класса их присутствие не требуется. Несколько значений записываются как было показано, а для единичного атрибута круглые скобки не нужны. Если у объектного класса нет необязательных (MAY) атрибутов, эта секция не включается.

Вот как определяется объектный класс top:

objectclass ( 2.5.6.0 NAME 'top' ABSTRACT

MUST objectClass )

Здесь демонстрируется использование оператора ABSTRACT в объектном классе. Поскольку top всегда находится в вершине иерархии, очевидно, что в его определении не может быть оператора SUP. OID также из присвоенных группе стандартизации X.500.

Авторы в многих документах настаивают, чтобы объектный класс top включался в файлы LDIF?--?на самом деле это не всегда необходимо.

Вот как определяется объектный класс dcObject:

objectclass ( 1.3.6.1.4.1.1466.344 NAME 'dcObject'

DESC 'RFC2247: domain component object'

SUP top AUXILIARY MUST dc )

Данный пример демонстрирует использование оператора AUXILIARY. Невозможно создать запись только на основе вспомогательного объектного класса. В этом примере OID показывает использование private enterprise OID. Следующий фрагмент демонстрирует довольно типичное определение базового DN с использованием dcObject:

dn: dc=example,dc=com

dc: example.com

objectclass: dcObject

objectclass: organization

o: Example, Inc.

Данная запись создаётся объектным классом objectclass: organization. dcObject идёт прицепом к этому объектному классу.

В следующем примере определяется объектный класс pilotOrganization и демонстрируется, что у объектного класса может быть один или несколько вышестоящих объектных классов, в этом случае потомки наследуют свойства ВСЕХ родителей:

objectClasses: ( 0.9.2342.19200300.100.4.20 NAME 'pilotOrganization'

SUP ( organization $ organizationalUnit ) STRUCTURAL

MAY buildingName )

5.4 Атрибуты LDAP

Атрибуты обычно содержат данные и имеют следующие характеристики:

1. Каждый атрибут определён в наборе схемы данных.

2. Каждый атрибут входит в один или несколько объектных классов.

3. objectclass также является атрибутом и может использоваться в операциях поиска.

4. Чтобы использовать атрибут в записи, в определение этой записи должен быть включен его объектный класс, и этот объектный класс должен быть включен в набор схемы данных. В свою очередь, этот набор схемы должен быть известен LDAP-серверу.

5. Характеристики атрибута определяются с помощью нотации ASN.1.

6. Атрибут может появляться лишь однажды в любом экземпляре содержащего его объектного класса, либо может появляться более одного раза в любом экземпляре содержащего его объектного класса.

7. Определение атрибута может быть частью иерархии, в этом случае оно наследует все свойства своих родителей.

8. Определение атрибута включает его тип или синтаксис.

9. Атрибуты, поддерживаемые сервером LDAP, формируют коллекцию под названием attributetypes, просмотреть которую можно через subschema.

5.5 Правила соответствия

Правила соответствия?--?часть так называемых операционных характеристик сервера LDAP.

Правила соответствия определяют методы сравнения, доступные в сервере LDAP:

1. Правила соответствия обычно встроены в сервер LDAP и не требуют явного указания.

2. Правила соответствия формируют коллекцию под названием matchingrules, просмотреть которую можно через subschema.

3. Правило соответствия определяется для каждого атрибута с помощью операторов EQUALITY, SUBSTR и ORDERING по мере необходимости?--?то есть определяются только те свойства, которые требуются.

5.6 Определения правила соответствия

Большинство правил соответствия встроены, и почти никогда не придётся определять их, но, как и у всего в LDAP, у них есть синтаксис определения. Вот пример определения правила соответствия caseIgnoreMatch:

matchingRule ( 2.5.13.2 NAME 'caseIgnoreMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

matchingrule указывает начало определения правила соответствия.

2.5.13.2 NAME 'caseIgnoreMatch' указывает глобально уникальное имя для данного правила соответствия и всегда состоит из двух частей: NAME 'caseIgnoreMatch' позволяет обращаться к этому правилу соответствия с помощью некоего полупонятного текста, и OID 2.5.13.2 указывает, что данное правило соответствия определено группой стандартизации X.500. Описание правила:

"Правило Case Ignore Match сравнивает совпадение предоставленной строки со значением атрибута типов PrintableString, NumericString, TeletexString, BMPString, UniversalString или DirectoryString без учета регистра символов строки.

Правило возвращает TRUE, если строки имеют одинаковую длину и соответствующие символы идентичны, кроме возможного расхождения регистра символов.

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 указывает, что данное правило соответствия применяется к определённым типам, в данном случае к DirectoryString.

5.7 Операционные атрибуты и объекты LDAP

Есть куча встроенных в LDAP-сервер атрибутов и объектных классов, управляющих тем, как этот сервер функционирует. Такие атрибуты и объектные классы обычно называются операционными.

Эти операционные элементы располагаются в rootDSE и при обычных операциях не видны.

В схеме 10 показаны отношения между DIT и входящими в них записями, а также RootDSE (Root Directory System Entry) и входящими в него объектами:

Схема 10

rootDSE можно просмотреть с помощью подходящего LDAP-браузера, указав пустой базовый DN, либо с помощью следующей команды:

ldapsearch -H ldap://ldap.mydomain.com -x -s base -b "" +

# обратите внимание, что + указывает вернуть операционные атрибуты

Вывод команды будет примерно таким, как показан ниже (в OpenLDAP 2.4.8), значения в скобках?--?это добавленные нами объяснения, они не возвращаются сервером:

dn:

structuralObjectClass: OpenLDAProotDSE

configContext: cn=config

namingContexts: dc=example,dc=com

namingContexts: dc=example,dc=net

monitorContext: cn=Monitor

supportedControl: 1.3.6.1.4.1.4203.1.9.1.1 (Contentsync RFC 4530)

supportedControl: 2.16.840.1.113730.3.4.18 (ProxiedAuthv2 RFC 4370)

supportedControl: 2.16.840.1.113730.3.4.2 (ManageDSAIT RFC3377)

supportedControl: 1.3.6.1.4.1.4203.1.10.1 (SubEntries RFC3673)

supportedControl: 1.2.840.113556.1.4.319 (pagedResults RFC2696)

supportedControl: 1.2.826.0.1.3344810.2.3 (MatchedValues RFC3876)

supportedControl: 1.3.6.1.1.13.2 (Post Read RFC4527)

supportedControl: 1.3.6.1.1.13.1 (Pre-Read RFC4527))

supportedControl: 1.3.6.1.1.12 (Assertion RFC4528)

supportedExtension: 1.3.6.1.4.1.4203.1.11.1 (ModifyPassword RFC3088)

supportedExtension: 1.3.6.1.4.1.4203.1.11.3 (WhoAmI RFC4532)

supportedExtension: 1.3.6.1.1.8 (Cancel RFC3909)

supportedFeatures: 1.3.6.1.1.14 (Modify-Increment RFC4525)

supportedFeatures: 1.3.6.1.4.1.4203.1.5.1 (OperationalAttrs RFC3674)

supportedFeatures: 1.3.6.1.4.1.4203.1.5.2 (ObjectClassAttrs RFC4529)

supportedFeatures: 1.3.6.1.4.1.4203.1.5.3 (TrueFalse RFC4526)

supportedFeatures: 1.3.6.1.4.1.4203.1.5.4 (LanguageTag RFC3866)

supportedFeatures: 1.3.6.1.4.1.4203.1.5.5 (LanguageRange RFC3866)

supportedLDAPVersion: 3

supportedSASLMechanisms: NTLM

supportedSASLMechanisms: GSSAPI

supportedSASLMechanisms: DIGEST-MD5

supportedSASLMechanisms: CRAM-MD5

entryDN:

subschemaSubentry: cn=Subschema

В этом листинге показано, что данный LDAP-сервер поддерживает два DIT?--?указаны как значения атрибутов namingContexts, это было сконфигурировано с помощью описанной здесь процедуры. Атрибут configContext: cn=config указывает на использование OLC (cn=config).

Существует возможность добавить LDAP-серверу расширения. При использовании OLC (cn=config) это можно сделать с помощью атрибута olcRootDSE, а при использовании slapd.conf?--?с помощью директивы rootDSE.



Заключение

В ходе эволюции LDAP станут решаться вопросы сближения со службами каталогов X.500, что будет способствовать созданию глобального каталога Internet. Метакаталоги, которые управляют интеграцией и потоками данных между серверами каталогов, -- еще один шаг к объединению серверов X.500 и LDAP. Многие поставщики продуктов стандарта LDAP, в том числе Sun, Novell и Microsoft, реализуют в них средства для создания метакаталогов, и, похоже, в этом проявляется тенденция развития приложений на базе LDAP.

Управление LDAP-данными, и в первую очередь, методы их хранения и извлечения, можно было бы значительно усовершенствовать за счет соответствующей интеграции стандартов XML и LDAP.

Современные тенденции развития LDAP свидетельствуют о высокой вероятности того, что эта спецификация будет принята в качестве стандарта для развернутых в Internet инфраструктур управления данными, ориентированных на генерирование запросов, индексирование, кэширование и обеспечение безопасности.



Список литературы

1. Олифер В.Г., Олифер Н.А.: Компьютерные сети. Принципы, технологии, протоколы. Учебник для вузов - 2014

2. М. Грубер: Понимание SQL - 2010

3. Шварц Б., Зайцев П., Ткаченко В. и др. - MySQL. Оптимизация производительности (2-е издание) - 2010

4. В. Н. Ручкин, В. А. Фулин Архитектура компьютерных сетей - 2011

5. Г. Хелд:Технологии передачи данных - 2008

6. Ватаманюк А.И.: Создание, обслуживание и администрирование сетей на 100% - 2009

7. Вишневский В.Г: Теоретические основы построения компьютерных сетей - 2005

8. Парк Дж., Маккей С., Райт Э.: Передача данных в системах контроля и управления - 2009

9. Кучерявый Л.Е., Гильченок Л.З., Иванов А.Ю.: Пакетная сеть связи общего пользования - 2004

10. Д.Кренке: Теория и практика построения баз данных - 2005

11. Маклаков С.В. BPWin, ERWin. CASE - средства разработки информационных систем. - М.: Диалог-МИФИ, 2007.

Размещено на Allbest.ru

...