ldap что это такое
/привет/мир/etc
Непериодические заметки о программировании
четверг, 31 октября 2013 г.
Что такое LDAP и с чем его едят
Как правило, служба каталогов
Для взаимодействия со службами каталогов X.500 широко используется протокол LDAP (Lightweight Directory Access Protocol), специфицированный в RFC4510. LDAP работает поверх TCP/IP и является легковесной альтернативой протокола DAP (Directory Access Protocol), весьма требовательного к вычислительным ресурсам.
LDAP реализует протокол взаимодействия со службой каталогов и задает модель данных, соответствующую X.500. Эта модель данных такова:
Запустим Softerra LDAP Browser и откроем одну из публичных служб каталогов, параметры соединения с которыми предустановлены по умолчанию. (Настроив соединение с MS Active Directory или OpenLDAP в вашей корпоративной сети, вы можете исследовать структуру и содержимое корпоративного каталога.)
Можно рассматривать DN как абсолютный путь к файлу (по аналогии с файловой системой) или как первичный ключ записи в таблице (по аналогии с реляционной БД).
В рассматриваемом DN o=CMRI,o=CMU,dc=cmu,dc=edu два верхних уровня названы по доменным именам Internet. А уровнем ниже текущей записи располагаются записи, идентифицируемые значением атрибута ou (см. картинку выше). Здесь имена атрибутов, идентифицирующие записи разных уровней, имеют следующие значения:
dc аббревиатура от domain component o аббревиатура от organization ou аббревиатура от organizational unit
Для поиска записей в LDAP-каталоге задаются три компонента:
Например, поиск по условию
На заметку: cуществуют специальные базовые DN для запроса информации о возможностях сервера, для доступа к схеме (schema) и данным мониторинга.
В Softerra LDAP Browser по Ctrl+F3 вызывается окно поиска, в котором удобно экспериментировать с параметрами поиска LDAP:
В фильтре можно использовать следующие проверки для атрибутов (атрибут ou взят для примера):
= использует фонетические сравнение. Расширенная проверка для сравнения образца со значением атрибута использует реализованное LDAP-сервером правило, идентификатор которого указан после двоеточия. Примеры выражений для проверки наличия подстроки (звездочка означает 0 или более символов):
Проверки в фильтре можно комбинировать при помощи логических операторов:
Чтобы хорошо освоить синтаксис фильтра, попробуйте разные проверки и их логические комбинации.
Как уже упоминалось, служба каталогов позволяет не только извлекать, но также добавлять и модифицировать записи. Softerra LDAP Browser поддерживает только просмотр данных в каталоге, поэтому для внесения изменений в каталог необходим другой инструмент (например, платный Softerra LDAP Administrator).
Для работы с LDAP практически из любого языка программирования можно воспользоваться существующими библиотекми для этого языка. В будущих статьях, посвященных LDAP, я рассмотрю работу с MS Active Directory в Oracle PL/SQL и в языке программирования Python.
Понимание LDAP-протокола, иерархии данных и компонентов записей
Введение
LDAP, или Lightweight Directory Access Protocol, является открытым протоколом, используемым для хранения и получения данных из каталога с иерархической структурой. Обычно используемый для хранения информации об организации, ее активах и пользователях, LDAP является гибким решением для определения любого типа сущностей и их свойств.
Для многих пользователей LDAP может показаться сложным для понимания, поскольку он опирается на своеобразную терминологию, имеет иногда необычные сокращения, и часто используется как компонент более крупной системы, состоящей из взаимодействующих частей. В этом тексте мы познакомим вас с некоторыми основами LDAP, чтобы у вас была хорошая основа для работы с технологией.
Что такое «служба каталогов»?
Служба каталогов используется для хранения, организации и представления данных в формате «ключ-значение». Обычно каталоги оптимизированы для поиска, поиска и операций чтения поверх операций записи, поэтому они очень хорошо работают с данными, на которые часто ссылаются, но редко меняются.
Данные, хранящиеся в службе каталогов, часто носят описательный характер и используются для определения качеств сущности. Примером физического объекта, который был бы хорошо представлен в службе каталога, является адресная книга. Каждое лицо может быть представлено записью в справочнике, с парами ключ-значение, описывающими его контактную информацию, место работы и т. д. Службы каталога полезны во многих сценариях, где вы хотите сделать доступной качественную описательную информацию.
Что такое LDAP?
LDAP, или облегчённый протокол доступа к каталогам, является коммуникационным протоколом, который определяет методы, в которых служба каталога может быть доступна. Говоря более широко, LDAP формирует способ, которым данные внутри службы директории должны быть представлены пользователям, определяет требования к компонентам, используемым для создания записей данных внутри службы директории, и описывает способ, которым различные примитивные элементы используются для составления записей.
Поскольку LDAP является открытым протоколом, существует множество различных реализаций. Проект OpenLDAP является одним из наиболее хорошо поддерживаемых вариантов с открытым исходным кодом.
Основные компоненты данных LDAP
Выше мы обсуждали, как LDAP является протоколом, используемым для связи с базой данных директорий с целью запроса, добавления или изменения информации. Однако это простое определение искажает сложность систем, поддерживающих этот протокол. То, как LDAP отображает данные для пользователей, очень зависит от взаимодействия и отношений между некоторыми определенными структурными компонентами.
Атрибуты
Сама информация в LDAP-системе в основном хранится в элементах, называемых атрибутами. Атрибуты, в основном, являются парами ключ-значение. В отличие от некоторых других систем, ключи имеют предопределённые имена, которые продиктованы выбранным для данной записи объектными классами (об этом мы поговорим чуть позже). Более того, данные в атрибуте должны соответствовать типу, определённому в исходном определении атрибута.
При обращении к атрибуту и его данным (когда он не задан), две стороны соединяются знаком равенства:
Значения атрибутов содержат большую часть фактических данных, которые вы хотите хранить, и к которым вы хотите получить доступ в системе LDAP. Остальные элементы внутри LDAP используются для определения структуры, организации и т.д.
Записи
Атрибуты сами по себе не очень полезны. Чтобы иметь смысл, они должны быть связаны с чем-то. В LDAP вы используете атрибуты в пределах записи (entry). Запись, по сути, представляет собой набор атрибутов под именем, используемый для описания чего-либо.
Например, вы можете иметь запись для пользователя в вашей системе, или для каждого предмета инвентаризации. Это примерно аналогично строке в системе реляционной базы данных, или одной странице в адресной книге (атрибуты здесь будут представлять различные поля в каждой из этих моделей). В то время как атрибут определяет качество или характеристику чего-либо, запись описывает сам предмет, просто собирая эти атрибуты под именем.
Пример записи, отображаемой в LDIF (LDAP Data Interchange Format), будет выглядеть примерно так:
Приведенный выше пример может быть валидной записью в системе LDAP.
Начав знакомиться с LDAP, легко понять, что данные, определяемые атрибутами, представляют собой лишь часть доступной информации об объекте. Остальное — это расположение записи в системе LDAP и связи, проистекающие из этого.
Например, если можно иметь записи как для пользователя, так и для объекта инвентаризации, как кто-то сможет отличить их друг от друга? Один из способов отличить записи разных типов — это создание отношений и групп. Это в значительной степени зависит от того, где находится запись при ее создании. Все записи добавляются в систему LDAP в виде веток на деревьях, называемых Data Information Trees, или DIT-ы.
DIT представляет собой организационную структуру, похожую на файловую систему, где каждая запись (кроме записи верхнего уровня) имеет ровно одну родительскую запись и под ней может находиться любое количество дочерних записей. Поскольку записи в LDAP-дереве могут представлять практически все, некоторые записи будут использоваться в основном для организационных целей, подобно каталогам внутри файловой системы.
Таким образом, у вас может быть запись для «people» и запись для «inventoryItems». Ваши фактические записи данных могут быть созданы как дочерние записи приведенных выше, чтобы лучше различать их тип. Ваши организационные записи могут быть произвольно определены, чтобы наилучшим образом представить ваши данные.
В примере записи в разделе выше мы видим одно указание на DIT, в строке dn :
Определение компонентов данных LDAP
В последнем разделе мы обсудили, как представлены данные в системе LDAP. Однако мы также должны поговорить о том, как определяются компоненты, которые хранят данные. Например, мы упомянули, что данные должны соответствовать типу, определённому для каждого атрибута. Откуда берутся эти определения? Давайте начнем с самого низа (с точки зрения сложности), и пройдём весь путь вверх.
Определения атрибутов
Атрибуты определяются с использованием достаточно сложного синтаксиса. Они должны указывать имя атрибута, любые другие имена/названия, которые могут быть использованы для ссылки на атрибут, тип данных, а также множество других метаданных. Эти метаданные могут описывать атрибут, указывая LDAP, как сортировать или сравнивать значение атрибута, и пояснять, как он соотносится с другими атрибутами.
Например, это определение для атрибута name :
name — это имя атрибута. Номер в первой строке — это глобально уникальный OID (object id, идентификатор объекта), присвоенный атрибуту, чтобы отличить его от всех остальных атрибутов. Остальная часть записи определяет, как можно сравнить запись во время поиска, и имеет указатель, поясняющий, где найти информацию по требуемому типу данных атрибута.
Определения атрибутов намного сложнее, чем использование и установка атрибутов. К счастью, в большинстве случаев Вам не придётся определять собственные атрибуты, так как наиболее распространённые из них включены в большинство реализаций LDAP, а другие легко импортируются.
Определения классов объектов
Атрибуты собираются в сущностях, называемых ObjectClass (классы объектов). ObjectClasses — это просто группировка связанных атрибутов, которая была бы полезна при описании конкретной вещи. Например, «person» — это objectClass.
Таким образом, если Вы создаете запись для описания человека, то objectClass person (или любой из более специфических объектов objectClasses, производных от person — об этом мы поговорим позже) позволяет использовать все атрибуты внутри этого objectClass:
После этого у вас появляется возможность установить внутри записи следующие аттрибуты:
Атрибут objectClass может использоваться несколько раз, если вам нужны атрибуты из разных классов объектов, но есть правила, которые диктуют, что разрешено. При этом objectClasses-ы бывают нескольких «типов»:
Два основных типа ObjectClasses — это структурный (structural) и дополнительный (auxiliary). Запись должна должна иметь ровно один структурный класс, но может иметь ноль или более вспомогательных классов, используемых для дополнения списка атрибутов, доступных этому классу. Структурный ObjectClasses используется для создания и определения записи, а вспомогательные ObjectClasses-ы добавляют дополнительную функциональность через дополнительные атрибуты.
Определения ObjectClass определяют, являются ли предоставляемые атрибуты обязательными (обозначаются спецификацией MUST ) или необязательными (обозначаются спецификацией MAY ). Несколько ObjectClasses могут предоставлять одни и те же атрибуты, а категоризация атрибута MAY или MUST может варьироваться от objectClass-а к objectClass-у.
В качестве примера, объект Класс person определяется так:
Схемы
Определения ObjectClass и определения атрибутов, в свою очередь, сгруппированы в конструкции, известной как schema (схема). В отличие от традиционных реляционных баз данных, схемы в LDAP представляют собой просто наборы взаимосвязанных ObjectClasses и атрибутов. Один DIT может иметь много различных схем, так что он может создавать нужные ему записи и атрибуты.
Формат схемы, по сути, является просто комбинацией вышеперечисленных записей, например:
Организация данных
Мы рассмотрели общие элементы, которые используются для построения записей в 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 ).
Именование (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 запятой.
Наследование в LDAP
По большей части то, как данные в LDAP-системе соотносятся друг с другом, зависит от иерархии, наследования и вложенности. Изначально LDAP для многих людей кажется непривычным, поскольку в его дизайн реализованы некоторые объектно-ориентированные концепции. В основном это связано с использованием классов, о чем мы уже говорили ранее, и с возможностью наследования, о котором мы поговорим сейчас.
Наследование объектных классов
Каждый objectClass — это класс, который описывает характеристики объектов данного типа.
Однако, в отличие от простого наследования, объекты в LDAP могут быть, и часто являются, экземплярами нескольких классов (некоторые языки программирования предоставляют аналогичную функциональность посредством множественного наследования). Это возможно потому, что LDAP под классом понимает просто набор атрибутов, которые он ДОЛЖЕН (MUST) или МОЖЕТ (MAY) иметь. Это позволяет указать для записи несколько классов (хотя только один структурный объектный класс может и должен присутствовать), в результате чего объект просто имеет доступ к объединенной коллекции атрибутов со строжайшими определениями MUST или MAY, имеющими приоритет.
Почти все деревья наследования каждого объектного класса заканчиваются специальным объектным классом, называемым «top». Это абстрактный объектный класс, единственное предназначение которого заключается в том, чтобы можно было выполнить требование задавания объектного класса. Он используется для указания вершины цепочки наследования.
Наследование атрибутов
Точно так же, сами атрибуты могут указать родительский атрибут в своем определении. В этом случае атрибут наследует свойства, которые были установлены в родительском атрибуте.
Это часто используется для создания более специфических версий общего атрибута. Например, атрибут фамилия (surname) имеет тот же тип, что и имя, и может использовать все те же методы для сравнения и проверки на равенство. Он может унаследовать эти качества, чтобы получить обобщенную форму атрибута «имя» (name). На деле, конкретное определение фамилии может содержать чуть больше, чем указатель на родительский атрибут.
Вариации протокола LDAP
В начале мы упоминали, что LDAP на самом деле является лишь протоколом, определяющим интерфейс связи для работы со службами каталогов. Обычно он известен как LDAP, или протокол ldap.
Стоит упомянуть, что вы можете увидеть некоторые варианты в обычном формате:
Все три формата используют протокол LDAP, но последние два указывают на дополнительную информацию о том, как он используется.
Заключение
Вы должны достаточно хорошо понимать протокол LDAP и то, как реализации LDAP представляют данные для пользователей. Понимание того, как элементы системы связаны друг с другом, и где они получают свои свойства, делает управление и использование LDAP-систем более простым и предсказуемым.
Основы протокола LDAP: иерархия данных и компоненты записей
LDAP (или Lightweight Directory Access Protocol) – открытый протокол, используемый для хранения и извлечения данных из иерархической структуры каталогов. Обычно используется для хранения информации об организации и ее активах и пользователях. LDAP – это гибкое решение для определения любого объекта и его качеств.
Для многих пользователей LDAP – очень сложный инструмент, поскольку он использует специальную терминологию, некоторые необычные сокращения и часто реализуется как компонент более крупной системы взаимодействующих частей. В этом мануале вы ознакомитесь с основами LDAP.
Что такое служба каталогов?
Служба каталогов используется для хранения, организации и представления данных в формате «ключ-значение». Как правило, каталоги оптимизированы для операций поиска и чтения, а не записи, поэтому они очень хорошо работают с данными, на которые часто ссылаются, но меняют редко.
Данные, хранящиеся в службе каталогов, часто носят описательный характер и используются для определения свойств объекта. Примером физического объекта, который легко представить в службе каталогов, является адресная книга. Каждый человек будет представлен записью в каталоге с парами ключ-значение, описывающими его контактную информацию, занятость и т. д. Службы каталогов полезны во многих сценариях и позволяют сделать описательную информацию доступной.
Что такое LDAP?
LDAP (или lightweight directory access protocol) – это протокол, который определяет методы, с помощью которых можно получить доступ к службе каталогов. В более широком смысле LDAP формирует способ отображения данных в службе каталогов для пользователей, определяет требования к компонентам, используемым для создания записей данных, и описывает способ использования разных примитивных элементов для составления записей.
Поскольку LDAP является открытым протоколом, существует множество различных его реализаций. Проект OpenLDAP является одним из наиболее хорошо поддерживаемых вариантов LDAP с открытым исходным кодом.
Основные компоненты данных LDAP
Как говорилось ранее, LDAP является протоколом, используемым для связи с базой данных для запроса, добавления или изменения информации. Однако это простое определение не отражает сложности систем, поддерживающих этот протокол. Способ, которым LDAP отображает данные пользователей, очень сильно зависит от взаимодействия и отношения между определенными структурными компонентами.
Атрибуты
Сами данные в системе LDAP в основном хранятся в элементах, называемых атрибутами. Атрибуты – это в основном пары ключ-значение. В отличие от некоторых других систем, ключи – это предопределенные имена, которые продиктованы объектными классами записи (мы обсудим это немного позже). Кроме того, данные в атрибуте должны соответствовать типу, указанному в первоначальном определении атрибута.
Атрибут состоит из имени атрибута и значения, которые разделяются двоеточием и пробелом. Например, атрибут mail, который определяет адрес электронной почты, будет выглядеть так:
Когда речь идет об атрибуте и его данных, обе части соединяются знаком равенства:
Значения атрибутов содержат большинство фактических данных, которые нужно сохранить в системе LDAP. Другие элементы в LDAP используются для определения структуры, организации и т. д.
Записи
Атрибуты сами по себе бессмысленны. Чтобы иметь смысл, они должны быть связаны с чем-то. В LDAP атрибуты находятся внутри записи. Запись представляет собой набор атрибутов под описательным именем.
Например, в вашей системе может быть запись пользователя или запись для каждого элемента в инвентаре. Эти записи похожи на строки в реляционной базе данных или на странице в адресной книге (здесь атрибуты будут представлять различные поля). Хотя атрибут определяет качество или характеристику чего-либо, запись описывает сам элемент, просто собирая эти атрибуты в единое целое.
Запись, отображаемая в LDIF (LDAP Data Interchange Format), будет выглядеть примерно так:
dn: sn=Amber,ou=people,dc=8host,dc=com
objectclass: person
sn: Amber
cn: Justin Amber
Вышеприведенный пример может быть допустимой записью в системе LDAP.
Возможно, вы уже заметили, что данные, определенные атрибутами, представляют собой часть доступной информации об объекте. Остальное – это размещение записи в системе LDAP и отношения, которые она подразумевает.
Например, если возможно иметь записи для пользователя и для элемента инвентаря, как их отличить? Один из способов различать записи разных типов – это установить отношения и группы. Это по сути функция, где помещается запись при ее создании. Все записи добавляются в систему LDAP в виде веток в деревьях, называемых информационными деревьями каталога, или DIT.
DIT представляет собой организационную структуру, похожую на файловую систему, где каждая запись (отличная от записи верхнего уровня) имеет ровно одну родительскую запись и может содержать любое количество дочерних записей под ней. Поскольку записи в дереве LDAP могут представлять собой что угодно, некоторые записи будут использоваться в основном для организационных целей, аналогично каталогам в файловой системе.
Таким образом, у вас может быть запись people и отдельная запись inventoryItems. А фактические записи данных могут быть дочерними по отношению к ним, что позволит различать их тип. Ваши организационные записи можно произвольно определить для наилучшего представления ваших данных.
В примере, приведенном в предыдущем разделе, мы видим один признак DIT в строке dn:
Эта строка называется различительным именем записи (подробнее об этом позже) и используется для идентификации записи. Она функционирует как полный путь назад к root DIT. В этом случае есть запись sn=Amber. Прямым родителем является запись по имени ou=people, которая, вероятно, используется в качестве контейнера для записей, описывающих людей. Родители этой записи происходят из домена 8host.com, который функционирует как root DIT.
Компоненты данных LDAP
В последнем разделе мы обсудили, как данные представлены в системе LDAP. Однако также нужно поговорить о том, как определяются компоненты, хранящие данные. Например, ранее мы упоминали, что данные должны соответствовать типу, определенному для каждого атрибута. Откуда берутся эти определения? Давайте начнем с самых простых компонентов.
Определения атрибутов
Атрибуты определяются с помощью довольно запутанного синтаксиса. Они должны содержать имя атрибута, любые другие имена, которые могут использоваться для ссылки на атрибут, тип данных, а также множество других метаданных. Эти метаданные могут описывать атрибут, помогать сортировать или сравнивать значения атрибута и описывать, как он относится к другим атрибутам.
Например, это определение атрибута name:
attributetype ( 2.5.4.41 NAME ‘name’ DESC ‘RFC4519: common supertype of name attributes’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 <32768>)
‘name’ – это имя атрибута. Число в первой строке – это глобальный уникальный идентификатор OID (Object ID), присвоенный атрибуту, чтобы отличать его от остальных атрибутов. Остальная часть записи определяет, как ее можно сравнивать во время поиска, и указывает, где найти информацию о типе данных атрибута.
Важной частью определения атрибута является то, может ли атрибут быть определен в записи более чем один раз. Например, фамилия может быть определена только один раз для каждой записи, но атрибут родства (например niece) может присутствовать в одной записи несколько раз. Атрибуты по умолчанию многозначны; если атрибут можно установить только один раз для каждой записи, он должен содержать флаг SINGLE-VALUE.
Определения атрибутов намного сложнее, чем использование и установка атрибутов. К счастью, по большей части вам не придется определять свои собственные атрибуты, потому что наиболее распространенные из них включены в большинство реализаций LDAP, а другие можно легко импортировать.
Определения ObjectClass
Атрибуты собираются внутри объектов, называемых objectClasses. ObjectClasses – это просто группы связанных атрибутов, которые были бы полезны при описании конкретной вещи. Например, «person» является objectClass.
Записи получают возможность использовать атрибуты objectClass, устанавливая специальный атрибут objectClass, который нужно использовать. Фактически, objectClass – единственный атрибут, который вы можете установить в записи без указания дополнительного objectClass.
Поэтому, если вы создаете запись для описания человека, в том числе objectClass person, вы можете использовать в нем все атрибуты:
Тогда у вас будет возможность установить эти атрибуты внутри записи:
Атрибут objectClass можно использовать несколько раз, если вам нужны атрибуты из разных objectClasses, но есть правила, их использования.
Два основных типа ObjectClasses – это структурный и вспомогательный. Запись должна иметь ровно один структурный класс, но может иметь ноль или больше вспомогательных классов, используемых для расширения атрибутов класса. Структурный objectClass используется для создания и определения записи, в то время как вспомогательные objectClasses вносят дополнительную функциональность через новые атрибуты.
Определения ObjectClass указывают, требуются ли предлагаемые атрибуты (указывается спецификацией MUST) или их использовать необязательно (обозначается спецификацией MAY). Несколько objectClasses могут предоставлять одинаковые атрибуты, а атрибут MAY или MUST может отличаться.
Например, objectClass person определяется так:
Он определяется как структурный objectClass, что означает, что его можно использовать для создания записи. Созданная запись должна указывать атрибуты surname и commonname и может указывать атрибуты userPassword, telephoneNumber, seeAlso или description.
Схемы
Определения ObjectClass и определения атрибутов, в свою очередь, группируются в схемы. В отличие от традиционных реляционных баз данных, схемы в LDAP – это просто коллекции связанных объектов и атрибутов. Один DIT может иметь множество разных схем, чтобы создавать записи и атрибуты, которые ему нужны.
Схемы часто включают дополнительные определения атрибутов и могут потребовать атрибуты, определенные в других схемах. Например, objectClass person, о котором мы говорили ранее, требует, чтобы атрибут surname или sn были установлены во всех записях, которые используют objectClass person. Если они не определены на LDAP-сервере, схема, содержащая эти определения, может использоваться для добавления этих определений в словарь.
Формат схемы в основном представляет собой комбинацию указанных выше записей, например:
Организация данных
Мы рассмотрели общие элементы, которые используются для создания записей в системе LDAP, и узнали о том, как эти блоки определяются в системе. Теперь нужно посмотреть, как в LDAP DIT организована и структурирована информация.
Размещение записей в DIT
DIT – это просто иерархия, описывающая взаимосвязь существующих записей. При создании каждая новая запись должна «подключаться» к существующему DIT, помещая себя как дочерний элемент существующей записи. Это создает древовидную структуру, которая используется для определения отношений и присвоения значения.
Вершина DIT – это самая широкая категория, которая так или иначе является родительской для всех узлов. Как правило, самая верхняя запись просто используется как метка, указывающая организацию, для которой используется DIT. Эти записи могут быть представлены любыми объектными классами, но обычно они создаются с помощью компонентов домена (dc=example,dc=com для example.com), расположения (l=new_york,c=us) или организационных сегментов (ou=marketing,o=Example_Co).
Записи организации (папки) часто используют организационный объект objectClass, который позволяет применять простую описательную метку атрибута ou=. Они часто используются для общих категорий в записи DIT верхнего уровня (например, ou=people, ou=groups, ou=inventory). LDAP оптимизирован для поиска информации по дереву, а не вверх и вниз внутри дерева, поэтому лучше всего держать иерархию DIT не очень глубокой, с общими организационными ветвями и последующим подразделением, указанных с помощью определенных атрибутов.
Именование и ссылки на записи в DIT
Мы ссылаемся на записи по их атрибутам. Это означает, что каждая запись должна иметь атрибут или группу атрибутов, которые однозначны на своем уровне в иерархии DIT. Этот атрибут или группа атрибутов называется относительным отличительным именем записи (или RDN) и функционирует как имя файла.
Чтобы однозначно сослаться на запись, используйте RDN записи в сочетании со всеми RDN-элементами своих родительских записей. Эта цепочка RDN возвращает к вершине иерархии DIT и обеспечивает однозначный путь к рассматриваемой записи. Эта цепочка называется отличительным именем записи (или DN). DN для записи указывается во время создания, чтобы система LDAP знала, где разместить новую запись (тогда RDN записи не будет использоваться другой записью).
Аналогично вы можете представить RDN как относительное имя файла или каталога в файловой системе. DN же больше похож на абсолютный путь. Важным отличием является то, что LDAP DN содержат наиболее специфическое значение в левой части, а пути к файлам – наоборот, в правой части. В DN значения RDN разделяются запятой.
Например, запись для человека по имени John Smith может быть помещена под записью «People» для организации example.com. Поскольку в организации может быть несколько человек по имени John Smith, ID пользователя может быть лучшим выбором для RDN записи. Запись может быть указана следующим образом:
dn: uid=jsmith1,ou=People,dc=example,dc=com
objectClass: inetOrgPerson
cn: John Smith
sn: Smith
uid: jsmith1
Здесь нужно использовать objectClass inetOrgPerson, чтобы получить доступ к атрибуту uid в этом экземпляре (у вас все еще есть доступ ко всем атрибутам, определенным в объекте personClass).
Наследование LDAP
В основном отношения данных в LDAP-системе определяются иерархиями, наследованием и вложенностью. LDAP изначально кажется сложным средством, потому что он реализует некоторые объектно-ориентированные концепции в своей структуре. Это главным образом связано с использованием классов и наследования, о чем мы поговорим сейчас.
Наследование objectClass
Каждый objectClass – это класс, который описывает характеристики объектов этого типа.
Однако, в отличие от простого наследования, объекты в LDAP могут быть и часто являются экземплярами нескольких классов (некоторые языки программирования предоставляют аналогичную функциональность посредством множественного наследования). Это возможно, потому что концепция LDAP класса – это просто набор атрибутов, которые он должен или может иметь (MUST или MAY). Это позволяет указать для записи несколько классов (хотя может и должен присутствовать только один objectClass STRUCTURAL), в результате чего объект просто имеет доступ к объединенной коллекции атрибутов с наивысшим объявлением MUST или MAY.
В своем определении objectClass может идентифицировать родительский objectClass, из которого можно наследовать его атрибуты. Это делается с помощью SUP, за которым следует objectClass для наследования. Например, objectClass organizationalPerson начинается следующим образом:
Родительский objectClass следует за идентификатором SUP. Родитель должен использовать тип objectClass определяемого objectClass (например, STRUCTURAL или AUXILIARY). Дочерний objectClass автоматически наследует атрибуты и требования родительского.
При назначении objectClass нужно указать только конкретного потомка цепочки наследования, чтобы получить доступ ко всем атрибутам. В последнем разделе мы использовали это, чтобы указать inetOrgPerson как единственный objectClass для записи John Smith, все еще имея доступ к атрибутам, определенным в классах person и organizationPerson. Иерархия наследования inetOrgPerson выглядит следующим образом:
Почти все деревья наследования objectClass заканчиваются специальным objectClass под названием «top». Это абстрактный objectClass, единственная цель которого – потребовать, чтобы объект objectClass был установлен. Он используется для обозначения верхушки цепочки наследования.
Наследование атрибутов
Аналогичным образом, сами атрибуты во время их определения могут отображать родительский атрибут. Затем атрибут наследует свойства, которые были установлены в родительском атрибуте.
Это часто используется для создания более конкретных версий общего атрибута. Например, surname является типом имени и может использовать все те же методы для сравнения и проверки равенства. Атрибут может наследовать эти качества, чтобы получить общую форму атрибута name. Фактически определение surname может содержать немного больше, чем указатель на родительский атрибут.
Наследование атрибута surname, которое мы обсуждали здесь, помогает людям различать фамилию и более общее имя, но помимо значения между фамилией и именем системы LDAP мало различий.
Варианты протокола LDAP
В начале мануала мы упоминали, что LDAP фактически является протоколом, который определяет интерфейс связи для работы со службами каталогов.
Стоит отметить некоторые варианты LDAP в обычном формате:
Все три формата используют протокол LDAP, но последние два указывают дополнительную информацию о том, как именно он используется.
Заключение
Теперь вы знакомы с основами протокола LDAP и понимаете, как реализации LDAP представляют данные для пользователей. Зная, как элементы системы связаны друг с другом и где они берут свои свойства, вы сможете лучше разобраться с управлением и использованием систем LDAP.