LDAP Linux HOWTO

В этом документе представлена информация об установке, настройке, запуске и обслуживании LDAP (Lightweight Directory Access Protocol) сервера на Linux. Также приводятся детали создания LDAP баз данных, способов обновления и удаления информации из базы данных, путей реализации роуминга и способов использования Netscape Address Book. В основном этот документ основывается на информационных страницах о LDAP Мичиганского Университета (University of Michigan) и OpenLDAP Administrator’s Guide.

Введение

Главная цель этого документа — установка и использование сервера каталогов LDAP на вашей Linux машине. Вы научитесь устанавливать, настраивать, запускать и обслуживать LDAP сервер. Далее вы научитесь способам помещения, извлечения и обновления информации в вашем каталоге с помощью клиентов LDAP и утилит. Демон для LDAP сервера каталогов называется slapd , и он запускается на многих различных UNIX платформах.

Также есть другой демон, который заботится о репликации между LDAP серверами. Он называется slurpd и, в данный момент, вам не следует о нем беспокоится. В этом документе вы запускаете slapd, который предоставляет службу каталогов только для вашего домена, без репликации, следовательно, без slurpd.

Такие простые настройки сервера хороши для начала, и, если вы захотите, позже их легко можно обновить до другой конфигурации. Представленная в этом документе информация представляет собой хорошее введение в использование протокола LDAP. Возможно, после прочтения этого документа вы почувствуете себя увереннее для расширения возможностей вашего сервера, и даже написания собственных клиентов, используя доступные C, C++ и Java Development Kits.

Что такое LDAP?

LDAP — клиент-серверный протокол для доступа к службе каталогов. Изначально он использовался как надстройка над X.500, но он также может быть использован с автономными и прочими видами служб каталогов.

Что такое служба каталогов?

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

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

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

Как работает LDAP?

Служба каталогов LDAP основана на клиент-серверной модели. Один или более серверов LDAP содержат данные составляющие дерево каталога LDAP, или базу данных LDAP. Клиент LDAP подключается к LDAP серверу и задает ему вопросы. Сервер выдает ответ или указатель места, где клиент может получить более подробную информацию (обычно, другой LDAP сервер). Не имеет значения, к какому LDAP серверу подключается клиент, он видит один и тот же каталог; имя представленное в одном LDAP сервере ссылается на тот же элемент что и другой LDAP сервер. Это важное свойство глобальной службы каталогов LDAP.

Механизмы баз данных LDAP, объекты и атрибуты

Slapd поставляется с тремя различными механизмами баз данных, которые вы можете выбрать. Это: LDBM — высокоскоростная дисковая база данных; SHELL — интерфейс базы данных к обычным UNIX командам и shell скриптам; и PASSWD — простая база данных на основе файла паролей.

В этом документе я предполагаю, что вы выбрали базу данных LDBM.

База данных LDBM работает, назначая компактный уникальный четырехбайтовый идентификатор каждому элементу базы данных. Она использует этот идентификатор для ссылок на записи из индексов. База данных состоит из одного главного файла индексов под названием id2entry, который устанавливает соответствие уникального индекса элемента (EID) текстовому представлению самого элемента. Также поддерживаются другие индексные файлы.

Для импортирования или экспортирования информации каталога между серверами каталогов основанных на LDAP или для описания набора вносимых в каталог изменений, обычно используется формат LDIF, т.е. LDAP Data Interchange Format. Файл LDIF хранит информацию об объектно-ориентированной иерархии элементов. Пакет LDAP, который вы собираетесь использовать, поставляется с утилитой конвертирования LDIF файлов в LDBM формат.

Типичный LDIF файл выглядит так:

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

В LDAP, класс объектов определяет набор атрибутов, которые используются для определения элемента. Стандарт LDAP определяет такие основные виды классов объектов:

Группа каталогов, включая неупорядоченный список индивидуальных объектов или групп объектов.

Местоположение, такое как имя страны и описание.

Организации в каталоге.

Люди в каталоге.

Элемент может принадлежать более чем одному классу. Например, элемент человека определен классом объектов person , но также могут быть определены атрибуты в классах объектов inetOrgPerson, groupOfNames и organization. Структура классов объектов сервера (его схема) определяет общий список требуемых и разрешенных атрибутов отдельного элемента.

Данные каталога представлены в виде пар атрибут-значение. Любая определенная часть информации ассоциируется с этим описательным атрибутом.

Например, атрибут commonName, или cn, используется для размещения имени человека. Человек по имени Jonas Salk может быть представлен в каталоге как

Каждый человек, введенный в каталог, определяется набором атрибутов в классе объектов person . Прочие атрибуты этого элемента могут включать:

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

Разрешенные атрибуты включают атрибуты, которые могут быть представлены в элементах класса объектов. Например, в классе объектов person, обязательны атрибуты cn и sn. Атрибуты description, telephoneNumber, seeAlso, и userpassword разрешены, но не обязательны.

Каждый атрибут имеет соответствующее синтаксическое определение. Синтаксическое определение описывает тип предоставляемой атрибутом информации:

bin «binary» двоичный

ces «case exact string» строка с соответствием регистра (регистр символов должен совпадать при сравнении)

cis «case ignore string» строка с игнорированием регистра (регистр символов игнорируется при сравнении)

tel строка с номером телефона (подобен cis но пробелы и тире `- ‘ игнорируются при сравнении)

dn «distinguished name» отличительное имя

Чтобы узнать, где в вашей системе лежат классы объектов и атрибуты, перейдите к первому параграфу Разд. Настройка LDAP сервера >.

Новые версии этого документа

В этот документ могут вноситься исправления и обновления на основе обратной связи с читателями. Новые версии этого HOWTO следует искать на:

Домашняя страница перевода http://mvd.h1.ru/tr/

Мнения и предложения

Если у вас есть какие-либо сомнения по поводу приведенной в этом документе информации, пожалуйста, свяжитесь со мной по следующему email адресу:

Также дайте мне знать, если у вас есть комментарии и/или предложения!

История издания

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

v1.0: 20 Июня 1999, Первоначальная версия

v1.01: 15 Февраля 2000, дополнен следующими секциями:

Утилиты миграции LDAP

Аутентификация с помощью LDAP

Графические утилиты LDAP

v1.02: 13 Сентября 2000, коррекция опечаток и дополнения в следующих секциях:

v1.03: 28 Сентября 2000, представлен OpenLDAP 2.0, который охватывает LDAPv3, определенный в RFC2251.

v1.04: 28 Февраля 2001, исправления опечаток и обновления в следующих секциях:

Аутентификация с помощью LDAP

v1.05: 22 Июня 2001, исправления длинных строк, которые вызывали несовместимость с PDF версией этого документа.

Благодарности

Этот Howto — результат моей интернатуры в TUDelft University — Нидерланды. Я хотел бы поблагодарить людей, которые помогали мне в написании этого документа: Rene van Leuken и Wim Tiwon. Огромное им спасибо. Они такие же поклонники Linux, как и я.

Также я хотел бы поблагодарить Thomas Bendler, автора Немецкого варианта Ldap-Howto — Joshua Go, за его дополнения к моему документу, великих добровольцев из проекта LDP и Hugo van der Kooij, за его подсказки по секции Роуминг.

Авторские права и отречение

Авторские права на LDAP Linux HOWTO Copyrighted 1999 принадлежат Luiz Ernesto Pinheiro Malere. Документ может свободно распространяться. Он не может модифицироваться. Если у вас есть какие-либо предложения, пожалуйста, пришлите мне email сообщение (если предложение приемлемо, я обновлю документ).

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

За содержимое этого документа не может возлагаться никакая ответственность. Я не ответственен за последствия приведенных в этом документе шагов.

Если у вас есть вопросы, пожалуйста, свяжитесь с координатором HOWTO по адресу

Источник

Понимание LDAP-протокола, иерархии данных и компонентов записей

Введение

LDAP, или Lightweight Directory Access Protocol, является открытым протоколом, используемым для хранения и получения данных из каталога с иерархической структурой. Обычно используемый для хранения информации об организации, ее активах и пользователях, LDAP является гибким решением для определения любого типа сущностей и их свойств.

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

Что такое «служба каталогов»?

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

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

Что такое LDAP?

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

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

Основные компоненты данных LDAP

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

Атрибуты

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

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

При обращении к атрибуту и его данным (когда он не задан), две стороны соединяются знаком равенства:

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

Записи

Атрибуты сами по себе не очень полезны. Чтобы иметь смысл, они должны быть связаны с чем-то. В LDAP вы используете атрибуты в пределах записи (entry). Запись, по сути, представляет собой набор атрибутов под именем, используемый для описания чего-либо.

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

Пример записи, отображаемой в LDIF (LDAP Data Interchange Format), будет выглядеть примерно так:

Приведенный выше пример может быть валидной записью в системе LDAP.

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

Например, если можно иметь записи как для пользователя, так и для объекта инвентаризации, как кто-то сможет отличить их друг от друга? Один из способов отличить записи разных типов — это создание отношений и групп. Это в значительной степени зависит от того, где находится запись при ее создании. Все записи добавляются в систему LDAP в виде веток на деревьях, называемых Data Information Trees, или DIT-ы.

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

Таким образом, у вас может быть запись для «people» и запись для «inventoryItems». Ваши фактические записи данных могут быть созданы как дочерние записи приведенных выше, чтобы лучше различать их тип. Ваши организационные записи могут быть произвольно определены, чтобы наилучшим образом представить ваши данные.

В примере записи в разделе выше мы видим одно указание на DIT, в строке dn :

Эта строка называется distinguished name («dn», «отличительное имя») записи (подробнее об этом позже) и используется для идентификации записи. Она функционирует как полный путь до «корня» DIT. В данном случае у нас есть запись под названием sn=Ellingwood , которую мы создаем. Прямым родителем является запись с именем ou=people , которая, вероятно, используется в качестве контейнера для записей, описывающих людей. Родители этой записи произошли от доменного имени digitalocean.com , которое выступает как корень нашей DIT.

Определение компонентов данных LDAP

В последнем разделе мы обсудили, как представлены данные в системе LDAP. Однако мы также должны поговорить о том, как определяются компоненты, которые хранят данные. Например, мы упомянули, что данные должны соответствовать типу, определённому для каждого атрибута. Откуда берутся эти определения? Давайте начнем с самого низа (с точки зрения сложности), и пройдём весь путь вверх.

Определения атрибутов

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

Например, это определение для атрибута name :

name — это имя атрибута. Номер в первой строке — это глобально уникальный OID (object id, идентификатор объекта), присвоенный атрибуту, чтобы отличить его от всех остальных атрибутов. Остальная часть записи определяет, как можно сравнить запись во время поиска, и имеет указатель, поясняющий, где найти информацию по требуемому типу данных атрибута.

Одной из важных частей определения атрибута является то, может ли атрибут быть задан в записи более одного раза. Например, в определении может быть определено, что фамилия может быть определена в записи только один раз, но атрибут «niece» позволительно указывать несколько раз в одной записи. Атрибуты по умолчанию многозначны и должны содержать флаг SINGLE-VALUE , если их можно задавать в записи только один раз.

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

Определения классов объектов

Атрибуты собираются в сущностях, называемых ObjectClass (классы объектов). ObjectClasses — это просто группировка связанных атрибутов, которая была бы полезна при описании конкретной вещи. Например, «person» — это objectClass.

Записи имеют возможность использовать атрибуты objectClass путем задания специального атрибут с названием objectClass , задающий objectClass, который вы хотите использовать. На самом деле, objectClass — это единственный атрибут, который можно задать в записи, не указывая более objectClass.

Таким образом, если Вы создаете запись для описания человека, то objectClass person (или любой из более специфических объектов objectClasses, производных от person — об этом мы поговорим позже) позволяет использовать все атрибуты внутри этого objectClass:

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

• cn: Общее имя (Common name)
• description: Понятное человеку описание записи
• seeAlso: Ссылка на связанные записи
• sn: Фамилия (Surename)
• telephoneNumber: Номер телефона
• userPassword: Пароль пользователя

Атрибут objectClass может использоваться несколько раз, если вам нужны атрибуты из разных классов объектов, но есть правила, которые диктуют, что разрешено. При этом objectClasses-ы бывают нескольких «типов»:

Два основных типа ObjectClasses — это структурный (structural) и дополнительный (auxiliary). Запись должна должна иметь ровно один структурный класс, но может иметь ноль или более вспомогательных классов, используемых для дополнения списка атрибутов, доступных этому классу. Структурный ObjectClasses используется для создания и определения записи, а вспомогательные ObjectClasses-ы добавляют дополнительную функциональность через дополнительные атрибуты.

Определения ObjectClass определяют, являются ли предоставляемые атрибуты обязательными (обозначаются спецификацией MUST ) или необязательными (обозначаются спецификацией MAY ). Несколько ObjectClasses могут предоставлять одни и те же атрибуты, а категоризация атрибута MAY или MUST может варьироваться от objectClass-а к objectClass-у.

В качестве примера, объект Класс person определяется так:

Это определяется как структурный объектClass, что означает, что он может быть использован для создания записи. Созданная запись должна содержать заданными атрибуты surname и commonname , и может, при желании, содержать аттрибуты userPassword , telephoneNumber , seeAlso , или description .

Схемы

Определения ObjectClass и определения атрибутов, в свою очередь, сгруппированы в конструкции, известной как schema (схема). В отличие от традиционных реляционных баз данных, схемы в LDAP представляют собой просто наборы взаимосвязанных ObjectClasses и атрибутов. Один DIT может иметь много различных схем, так что он может создавать нужные ему записи и атрибуты.

Схемы часто включают дополнительные определения атрибутов и могут требовать атрибутов, определенных в других схемах. Например, объектный класс person , о котором мы говорили выше, требует, чтобы атрибут surname или sn был установлен для любых записей, использующих объектный класс person . Если они не определены в самом LDAP-сервере, схема, содержащая эти определения, может быть использована для добавления этих определений в словарь сервера.

Формат схемы, по сути, является просто комбинацией вышеперечисленных записей, например:

Организация данных

Мы рассмотрели общие элементы, которые используются для построения записей в LDAP системе и поговорили о том, как эти «строительные блоки» определяются в системе. Однако мы еще не много говорили о том, как организована и структурирована сама информация в LDAP DIT.

Размещение записей в DIT

DIT — это просто иерархия, описывающая взаимосвязь существующих записей. После создания, каждая новая запись должна «подключаться» к существующему DIT, помещая себя в качестве дочерней по отношению к какой-либо существующей записи. Это создает древовидную структуру, которая используется для определения отношений и присвоения значения.

Верхний DIT — это самая широкая категория, под которой каждый последующий узел является чьим-то потомком. Обычно самая верхняя часть записи просто используется как метка, называющая организацию, для которой DIT используется. Эти записи могут быть иметь любой объектный класс, но обычно они строятся с использованием доменных компонентов ( dc=example,dc=com для управляющей информации LDAP, связанной с example.com ), местоположений ( l=new_york,c=us для организации или сегмента в Нью-Йорке), или подразделений организации ( ou=marketing,o=Example_Co ).

Записи, используемые для организации (используемые как папки) часто используют объектный класс organizationalUnit , что позволяет использовать простую описательную метку атрибута с названием ou= . Такого рода записи часто используются для общих категорий в записи DIT верхнего уровня (пример часто используемых — ou=people , ou=groups и ou=inventory ). LDAP оптимизирован для поиска информации по дереву в направлении «вправо-влево», а не «вверх-вниз», поэтому зачастую лучше поддерживать иерархию DIT не глубокой, с обобщенными организационными ветвями, и дальнейшим указанием на различия через задание определенных атрибутов.

Именование (Naming) и ссылочные записи (Referencing Entries) в DIT

Мы ссылаемся на записи по их атрибутам. Это означает, что каждая запись должна иметь однозначный атрибут или группу атрибутов на своем уровне в иерархии DIT. Этот атрибут или группа атрибутов называется относительное отличительное имя или RDN (от relative distinguished name), и несет ту же функцию, что и имя файла в каталоге.

Чтобы однозначно ссылаться на запись, вы используете её RDN в сочетании со всеми RDN её родительских записей. Эта цепочка RDN ведет назад, вверх по иерархии DIT и указывает однозначный путь к соответствующему элементу. Мы называем эту цепочку RDN различимым именем или DN (от distinguished name). Вы должны указать DN для записи во время создания, чтобы система LDAP знала, где разместить новую запись, и могла убедиться, что RDN записи уже не используется другой записью.

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

Например, запись для человека по имени Джон Смит может быть помещена под запись «People» в организации example.com . Так как в организации может быть несколько Джонов Смитов, идентификатор пользователя может быть лучшим выбором для RDN записи. Запись может быть указана вот так:

Нам пришлось использовать объектный класс inetOrgPerson , чтобы получить доступ к атрибуту uid в данном случае (кроме того, мы ещё имеем доступ ко всем атрибутам, определенным в объектном классе person , причина этого будет понятна в следующем разделе).

Наследование в LDAP

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

Наследование объектных классов

Каждый objectClass — это класс, который описывает характеристики объектов данного типа.

Однако, в отличие от простого наследования, объекты в LDAP могут быть, и часто являются, экземплярами нескольких классов (некоторые языки программирования предоставляют аналогичную функциональность посредством множественного наследования). Это возможно потому, что LDAP под классом понимает просто набор атрибутов, которые он ДОЛЖЕН (MUST) или МОЖЕТ (MAY) иметь. Это позволяет указать для записи несколько классов (хотя только один структурный объектный класс может и должен присутствовать), в результате чего объект просто имеет доступ к объединенной коллекции атрибутов со строжайшими определениями MUST или MAY, имеющими приоритет.

По своему определению, объектный класс может иметь указывать на родительский объектный класс, от которого он наследует свои атрибуты. Это делается с помощью определения SUP , за которым следует название объектного класса, от которого происходит наследование. Например, определение объектного класса organizationalPerson начинается следующим образом:

Родительским объектом является объектный класс, следующий за идентификатором SUP . Класс-родитель должен быть того же типа, как и определяемый объектный класс (например, STRUCTURAL или AUXILIARY ). Дочерний объектный класс автоматически наследует атрибуты и требования атрибутов родителя.

При назначении объектного класса конкретной записи, Вам нужно только указать самого последнего потомка цепочки наследования, чтобы иметь доступ ко всему набору атрибутов. В предыдущем разделе мы использовали это для указания inetOrgPerson в качестве единственного objectClass для нашей записи John Smith, в то же время получив доступ к атрибутам, определенным в объектных классах person и organizationalPerson . Иерархия наследования inetOrgPerson выглядит следующим образом:

Почти все деревья наследования каждого объектного класса заканчиваются специальным объектным классом, называемым «top». Это абстрактный объектный класс, единственное предназначение которого заключается в том, чтобы можно было выполнить требование задавания объектного класса. Он используется для указания вершины цепочки наследования.

Наследование атрибутов

Точно так же, сами атрибуты могут указать родительский атрибут в своем определении. В этом случае атрибут наследует свойства, которые были установлены в родительском атрибуте.

Это часто используется для создания более специфических версий общего атрибута. Например, атрибут фамилия (surname) имеет тот же тип, что и имя, и может использовать все те же методы для сравнения и проверки на равенство. Он может унаследовать эти качества, чтобы получить обобщенную форму атрибута «имя» (name). На деле, конкретное определение фамилии может содержать чуть больше, чем указатель на родительский атрибут.

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

Вариации протокола LDAP

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

Стоит упомянуть, что вы можете увидеть некоторые варианты в обычном формате:

• ldap://: Это основной протокол LDAP, позволяющий получить структурированный доступ к службе каталогов.
• ldaps://: Этот вариант используется для доступа к LDAP поверх SSL/TLS. Обычно трафик LDAP не шифруется, но большинство реализаций LDAP поддерживают подобный вариант доступа. Такой способ шифрования LDAP-соединений на самом деле устарел, и вместо него рекомендуется использовать шифрование STARTTLS. Если вы работаете с LDAP через незащищенную сеть, настоятельно рекомендуется шифрование.
• ldapi://: Это используется для указания LDAP через IPC. Это часто используется для безопасного соединения с локальной LDAP-системой в административных целях. Он связывается через внутренние сокеты вместо того, чтобы использовать открытый сетевой порт.

Все три формата используют протокол LDAP, но последние два указывают на дополнительную информацию о том, как он используется.

Заключение

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

Источник