LDAP: упрощенный протокол доступа к каталогам

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

Служба каталогов — это просто база данных, но такая, в которой сделан ряд допол­ нительных предположений. Любой набор данных, характеристики которых подпадают под эти предположения, становится кандидатом на включение в базу данных. Основные предположения таковы:

• информационные объекты относительно невелики;

• база данных будет реплицироваться и кешироваться на множестве компьютеров;

• у информации есть атрибуты;

• данные извлекаются часто, но записываются редко;

• операции поиска выполняются очень часто.

Текущая стандартная система, предложенная организацией IETF для этих целей, на­ зывается LDAP (Lightweight Directory Access Protocol — упрощенный протокол доступа к каталогам). В спецификациях LDAP говорится не о самой базе данных, а лишь о том, как получить к ней доступ по сети. В то же время заданы схемы организации данных и осуществления поиска, поэтому подразумевается достаточно четкая модель данных.

Изначально LDAP задумывался как простой шлюзовой протокол, который позволял бы клиентам TCP/IP взаимодействовать с серверами каталогов Х.500, теперь уже уста­ ревшими. Со временем стало очевидно, что стандарт Х.500 изжил себя и в UNIX необ­ ходима стандартная служба каталогов. Все это привело к тому, что из LDAP получилась совершенно самостоятельная, полноценная система управления каталогами (возможно, буква “L” в названии стоит незаслуженно)4.

Как бы там ни было, но протокол LDAP получил широкое распространение, чему отчасти способствовало принятие его фирмой Microsoft в качестве основы для службы Active Directory. В среде UNIX и Linux стандартной реализацией стал пакет OpenLDAP

4 Вследствие сложной истории LDAP во многих книгах можно встретить подробные рассказы о Х.500 и OSI. Однако эта история не имеет никакого отношения к современному использованию LDAP. Просто забудьте о ней.

774 Часть II. Работа в сети

(openldap.org). Служба каталогов уровня предприятия 389 Directory Server (ранее из­ вестная как Fedora Directory Server и Netscape Directory Server) также является проектом с открытым исходным кодом, к которому можно получить доступ на сайте port389.org. Эта служба работает в системах Linux, Solaris и HP-UX.

Структура данных LDAP

Данные протокола LDAP принимают форму списков свойств, которые в мире LDAP называют “записями” (entry). Каждая запись состоит из набора именованных атрибутов (например, “uid”, “description”) и значений этих атрибутов. Пользователи, работающие в среде Windows, вероятно, заметят, что эта структура напоминает структуру записей в си­ стемном реестре. Как и в реестре Windows, отдельный атрибут может иметь несколько различных значений.

В качестве примера рассмотрим обычную (и упрощенную) строку файла /etc/passwd, выраженную в виде записи LDAP.

uid: ghopper

cn: Grace Hopper

userPassword: {crypt}$l$pZaGA2RL$MPDJoc0afuhHY6yk8HQFp0

loginShell: /bin/bash

uidNumber: 1202

gidNumber: 1202

homeDirectory: /home/ghopper

Здесь мы видим простой пример формата LDIF (LDAP Data Interchange Format — фор­ мат обмена данными LDAP), который применяется в большинстве инструментов, свя­ занных с LDAP, и в реализациях серверов. Причиной успеха этого формата является то обстоятельство, что LDAP можно без труда преобразовывать в простой текст и обратно.

Записи систематизируются по “отличительным именам” (имя атрибута: dn — distin­ guished name), которые формируют некоторую разновидность пути поиска. Например, запись dn для вышеупомянутого пользователя может выглядеть так.

dn: uid=ghopper, ou=People, dc=navy, dc=mil

Как и в DNS, самый значащий бит ставится справа. Здесь имя DNS navy.mil исполь­ зуется для построения верхних уровней иерархии LDAP. Оно разбивается на два компо­ нента домена: navy и mil, хотя это всего лишь одно из некоторых обычных соглашений.

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

Записи LDAP обычно составляются на основе использования атрибута objectClass (объектный класс). Классы объектов определяют атрибуты, которые может содержать за­ пись, причем некоторые из них могут требоваться для проверки достоверности. Каждому атрибуту назначается тип данных. Схема вложения и комбинирования классов объектов ничем не отличается от схемы, принятой в традиционном объектно-ориентированном программировании. Верхний уровень дерева класса объектов называется top; он озна­ чает лишь то, что запись должна иметь атрибут objectClass.

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

Глава 19. Совместное использование системных файлов 775

Таблица 19.2. Некоторые имена атрибутов, которые можно встретить в иерархиях LDAP

Атрибут Расшифровка Назначение



O Organization (организация) Часто идентифицирует запись верхнего уровня сайтаa

Ou Organization unit (организаци­ Логическое подразделение, например “marketing” онная единица) (отдел маркетинга)

Сn Common name (обычное имя) Наиболее естественное имя, с помощью которого можно передать смысл записи

Dc Domain component (компонент Используется в сайтах, в которых иерархия построена домена) на основе DNS

objectClass Object class (объектный класс) Схема, в соответствии с которой формируются атри­ буты данной записи

а Обычно не используется системами, в которых LDAP-иерархия построена на основе DNS.

Поиск по сайту: