Десятиминутное руководство по 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 поощряет иерархические структуры в виде дерева, но он их не требует. Очень важно об этом помнить при написании программ, чтобы не сделать неверных предположений относительно иерархии данных на сервере.



Содержание раздела