Десятиминутное руководство по LDAP

Десятиминутное руководство по LDAP

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

LDAP (Lightweight Directory Access Protocol, облегченный протокол доступа к сетям) - это одна из самых значительных служб каталогов, существующих в настоящее время. Вероятно, со временем системные администраторы будут работать с LDAP-серверами и клиентами в различном контексте. Это руководство представляет собой введение в номенклатуру LDAP и концепции, необходимые для использования материала из главы 6 «Службы каталогов».

Все действия в LDAP производятся над структурой данных, называемой элементом (entry). Схему, показанную на Рисунок В.1, имеет смысл хорошо себе представлять, когда будут рассматриваться составляющие элемента.

Элемент состоит из нескольких компонентов, называемых атрибута ми (attributes), в которых хранятся данные для этого элемента. В терминах баз данных они похожи на поля записи. В главе б Perl используется для хранения списка машин из каталога LDAP. У каждого элемента, соответствующего машине, есть такие атрибуты, как имя, модель, местоположение, владелец и т. д.

Помимо имени атрибут состоит из типа (type) и набора значений (values), соответствующих этому типу. Если вы храните информацию о сотрудниках, то у элемента может быть атрибут phone (телефон) типа telephoneNumber. Значениями этого атрибута будут номера телефонов сотрудников. Тип имеет также синтаксис, определяющий, какие данные можно использовать (строки, числа и т. д.), как они сортируются и как их применять при поиске (чувствительность к регистру).

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

Рассмотрим детальнее атрибут objectClass, поскольку он иллюстрирует некоторые важные качества LDAP и позволяет избавиться от жаргона, с которым мы раньше не встречались. Рассматривая атрибут оbjectClass, нужно обратить внимание на следующее:

LDAP объектно-ориентирован

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

Вот пример: атрибут objectClass элемента может содержать строку residentialPerson. В RFC2256 с устрашающим названием «A Summary of the X. 500(96) User Schema for use with LDAPv3» класс : е
sidentialPerson определяется так:

residentialPerson

( 2.5.6.10 NAME 'residentialPerson1 SUP person STRUCTURAL MUST 1 MAY ( businessCategory $ x121Address $ registeredAddress $ destinationlndicator $ preferredDeliveryMethod $ telexNumfcer $ teletexTerminalldentifier $ telephoneNumber $ internationaliSDNNumber $

facsimileTelephoneNumber $ preferredDeliver\Methoo $ street S postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ st $ I ) )

В определении сказано, что элемент класса residentialPerscr должен иметь атрибут 1 (сокращение от locality) и может иметь целый набор других атрибутов (registeredAoaress, costOticeBox и т.д.).
Ключевая часть спецификации - это строка SUP пгкаог. Это означает, что родительским классом (тем, от которого наследует свои атрибуты) является класс person. Данное определение выглядит так:

person

( 2.5.6.6 NAME persun SUP lup STRUCTURAL MUST v s- $ MAY ( ussrPassworri $ te]ephoneNL;mhcr $ secvMso $ ciesc- .pr.ur ) )

Значит, элемент класса residentialPerson должен иметь атрибуты (surname - фамилия), ел (common name - имя) и ; (locality - местоположение) и может иметь атрибуты, перечисленные в разделах MAY
из этих двух отрывков из RFC. Кроме того, известно, что oersun - это вершина иерархии объектов для residentialPerson, поскольку его родительским классом является специальный абстрактный класс top.

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

LDAP происходит из мира баз данных

Второе качество, которое можно увидеть ъ objectClass, - это корни LDAP, уходящие в базы данных. Набор классов объектов, определяющих атрибуты элементов, на сервере LDAP называются схемой
(schema). RFC, процитированный выше, - это один пример спецификации схемы LDAP. В данной книге мы не будем касаться того, что имеет отношение к схеме. Как и в случае с проектированием ба-
зы данных, проектированию схемы можно посвятить целую книгу, но вы должны быть, по крайней мере, знакомы с термином «схема», т. к. он всплывет позже.

LDAP не ограничен хранением информации строго в структуре дерева

Последнее, что нужно сказать об objectClass для того, чтобы перейти от рассмотрения одного элемента к более общей картине, относится к следующему: на вершине иерархии объектов в предыдущем примере находился класс top, но существует еще один квази-суперкласс, заслуживающий упоминания, класс alias. Если alias указан, то этот элемент действительно является псевдонимом для другого элемента (определяемого атрибутом aUaseaObjectNacie данного элемента). LDAP поощряет иерархические структуры в виде дерева, но он их не требует. Очень важно об этом помнить при написании программ, чтобы не сделать неверных предположений относительно иерархии данных на сервере.

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

До сих пор мы говорили только об одном элементе, но спрос на каталоги, содержащие только один элемент, очень мал. Как только мы станем рассматривать каталоги, содержащие много элементов, перед нами тотчас встанет вопрос, с которого начиналось данное приложение: как найти что-либо?

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

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

RDN состоит из одной или нескольких пар «имя-значение атрибута» (name-value). Например, cn=Jay Sekora (где en- это «common name», или имя) вполне может быть относительным отличительным именем, Имя атрибута - сп, а его значение - Jay Sckora.

Ни в спецификации LDAP, ни в спецификации Х.500 не указано, из каких атрибутов должно состоять RDN. Единственное, что требуется, уникальность RDN на каждом уровне в иерархии каталогов. Такое oграничение существует из-за того, что LDAP ничего не знает о «третьем элементе четвертой ветви дерева каталогов» и должен полагаться на уникальные имена на каждом уровне, чтобы различать на нем элементы. Посмотрим, как это ограничение действует на практике.

Возьмем, к примеру, еще одно значение RDN: cn=Ronert Smith. Вероятно, это не лучший выбор для RDN, поскольку даже в средней организации, скорее всего, существует не один Роберт Смит. Если в организации работает много людей, а иерархия LDAP довольно плоская, то подобные пересечения имен вполне вероятны. Более правильный элемент состоит из двух атрибутов, например cn=Rcbert Sriith + i=B(Атрибуты в RDN объединяются при помощи знака «плюс».)

Но с исправленным RDN, к которому добавлен атрибут 1 (местоположение), по-прежнему будут проблемы. Вероятно, мы отложили конфликт имен, но не исключили полностью вероятность его возникновения. Более того, если Смит переедет, нам придется изменить и КВл элемента и местоположение (атрибут 1) в этом элементе. Вероятно, самое лучшее относительное имя, которое можно использовать, уникальный и неизменный идентификатор данного человека. В частности, можно выбрать электронный адрес человека, тогда RDN изменится на uid = rsrnith. Этот пример должен дать читателю представление о принимаемых в схемах решениях.

Проницательные читатели заметят, что мы на самом деле не расширили сферу обзора, а по-прежнему возимся с единственным элементом. Обсуждение RDN было прелюдией, а вот и настоящий переход: элементы организованы в виде древоподобной структуры, известной как информационное дерево каталогов (Directory Information Tree, DIT), или просто дерево каталогов. Лучше применять последний термин, поскольку в Х.500 аббревиатура DIT обычно служит для обозначения одного общего дерева, похожего на глобальную иерархию DNS или MIB, о которой речь пойдет позже, при обсуждении SNMP.

А теперь снова вернемся к отличительным именам. Каждый элемент из дерева каталогов можно найти по его отличительному имени (DN), состоящему из относительного имени элемента (RDN), за которым следуют все RDN (разделяемые запятыми или точками с запятой), найденные при движении от него вверх к корневому элементу. Если перемещаться в направлении, указанном стрелками (Рисунок В.2), и запоминать при движении относительные имена, то можно создать DN для каждого выделенного элемента.

Для первого элемента получилось бы такое DN (отличительное имя):

cn=Robert Smith. l-n:ain campus. ou=CCS, o=Hogwarts School, c=US

Для второго:

uid=rsmith, ou=syste-ins, ou=people, dc=ccs, dc-hogwarts, dc=edu

ou - это сокращение от «organizational unit» (подразделение организации), о - сокращение от «organization» (организация), dc - «domain component» (компонент домена, подобный DNS), а с - сокращение от «country» (страна) (не имеет ничего общего с Улицей Сезам).

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

Pat Hinds

288 St. Bucky Avenue

Anywhere, MA 02104

USA

начинается с частного (человек) и заканчивается самым общим компонентом (страна). То же имеет место и в DN. В примерах DN такой порядок хорошо заметен.

Вершина дерева каталогов называется суффиксом каталога, т. к. это последняя составляющая каждого отличительного имени из данного дерева каталогов. При создании иерархической инфраструктуры с использованием нескольких делегированных LDAP-серверов суффиксы очень важны. Применяя концепцию LDAPvS, известную под названием referral, можно добавить элемент в дерево каталогов, в котором говорится: «За всеми элементами с этим суффиксом обращайтесь к тому серверу». Направления указываются при помощи LDAP URL, которые очень похожи на обычные URL. Единственное их отличие - это ссылка на определенное имя или другую информацию, имеющую отношение к LDAP. Вот пример такой ссылки из RFC2255, определяющего формат LDAP URL:

ldap://lcap. ltd. unich. edJ/o=U-nversity%20o*%20Micr:3an.