LDAP: каталог для всех

Арсений Чеботарёв, "Комиздат"

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

Пролог

Первый раз я вплотную столкнулся с LDAP при работе с почтовым сервером exim. Как известно, этот сервер является попыткой народа из Кембриджа бросить вызов старому и нудному как сто пней sendmail’у. В качестве полезного и приятного удобства exim предоставляет возможность черпать любые списки (например, почтовых адресов, серверов или хостов) независимо из различных источников: из самого файла настройки (включая вычисляемые регулярные выражения), из выходного потока внешних программ, из баз данных. И, в том числе, из служб каталогов. И если с основным перечнем все более или менее понятно, то эти самые каталоги оказались пробелом в моих познаниях — и как любой истинный искатель приключений я ломанулся на поиски инфы. Ниже — краткий конспект моих поисков.

Общедоступная теория

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

Вообще-то, в мире UNIX всегда существовали методы и утилиты поиска, типа finger или whois, но они хорошо работали, в основном, в масштабах одного сервера — и для новых реалий не подходили.

Задача заключалась в создании централизованных адресных книг для целых корпораций с развитой сетью отделений, а также с международными филиалами, подключаемыми по интернету. Ко всему, было принято решение сделать этот каталог платформонезависимым. Поэтому IBM, Lotus, Microsoft и Netscape договорились о применении единого метода доступа — LDAP — для доступа к адресной информации. К этому соглашению приложили усилия и многие другие гранды сетевого компьютинга, к примеру Sun и Novell.

LDAP расшифровывается как Lightweight Directory Access Protocol — то есть "легковесный протокол доступа к каталогам". Эта самая "легковесность" LDAP наводит на мысль, что где-то должен существовать и его "тяжеловесный" собрат. И действительно: в качестве прототипа выступал полновесный протокол доступа к каталогам DAP, известный также как X.500 или "Проект "Белые Страницы”" (White Pages Project).

Этот протокол был разработан консорциумом OSI и ориентирован на локальные корпоративные сети и большие мэйнфреймы. Адаптацию этого сложного и редко используемого всуе протокола к нуждам современного интернета и персональным компьютерам выполнили хакеры Мичиганского университета, которые вообще известны креативными поделками. В последнее время LDAP используется для доступа и к не-X.500-совместимым серверам каталогов, а к информиции, отличной от адресных книг.

На сегодня существует три версии LDAP. Причем первая не в счет — в ней сразу же были найдены серьезные проблемы. Вторая, и самая распространенная, версия LDAP2 зафиксирована в документах RFC 1777, 1778 и 1779. Наиболее современной на момент написания этой статьи была версия LDAPv3, окончательно «устаканенная» в 1997 г. В этой версии, с одной стороны, лучше поддерживается X.500, а с другой — больше внимания уделено не-X.500-серверам.

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

Возможность построения сетей каталогов — это основа для постепенного развертывания служб LDAP: можно начать с одного минимально настроенного сервера и постепенно расширять его функциональность.

Собственно LDAP реализуется в виде клиента и сервера. Сервер LDAP хранит и индексирует записи определенного формата. В качестве полей выступают имя пользователя, его физический и электронный адреса, телефоны и т.д. Администрирование сервера производится по правилам среды: для Linux это файлы настройки и командная строка, для Windows и Mac OS — графические приложения. В последнее время для администрирования, в том числе удаленного, все чаще применяется веб-интерфейс. Серверы, согласно X.500, могут объединяться в сеть, так что пользователь в поисках нужной информации может переходить от одного сервера к другому.

Кроме того, для повышения производительности существуют и LDAP-прокси серверы, эффективно кэширующие частые запросы.

Клиентом чаще всего выступает почтовый клиент. Он содержит форму запроса к удаленному серверу, наподобие той, что используется для поиска в ICQ. Обычно клиентское ПО реализует не все возможности (которых очень много), а какое-то их подмножество. В той или иной мере LDAP поддерживают все современные почтовые клиенты, такие как Outlook Express, Eudora, Netscape, OS X Mail и т.д. Часто доступ к LDAP-серверу, особенно глобальному, можно получить через веб-интерфейс.

Быстро получить окно поиска на заданном сервере обычно можно, введя в окне браузера URL вида ldap://server[:port]. К примеру, в нашей локальной сети это будет ldap://192.168.0.99. Через косую черту вы можете сразу указать параметры поиска (конечно же, обычно эту строку будет формировать какое-то приложение). Так, ввод в браузер ldap://192.168.0.99/cn=Antonchuk,dc=comizdat,dc=com непосредственно отобразит информацию о главном редакторе К+П. Этот тип URL поддерживается Internet Explorer и Firefox (Netscape) — но не поддерживается, например, в Opera.

Как уже было сказано, LDAP, помимо системы обслуживания запросов, изначально включает и систему аутентификации. Администратор задает привилегии пользователей и определяет записи, к которым тот или иной из них может осуществлять доступ. Списки правил доступа (ACL, Access Control List) позволяют настроить доступ любым образом: в типичном случае пользователь имеет право изменять собственную частную информацию, а все остальные — просматривать ее. Однако можно, например, защитить отдельные поля частной записи от просмотра или модификации.

Собственно, существуют и общественные LDAP-серверы, доступные для поиска всему миру (к примеру, BigFoot или Infospace) — но все-таки основное применение протокол находит на уровне больших и средних корпораций. Не прекращаются попытки создать методы объединения отдельных серверов с целью создания "глобального каталожества". Но до реального воплощения пока далеко.

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

В этом смысле LDAP в некоторых сферах может поконкурировать с методом доступа SQL, поскольку работает напрямую через TCP/IP и хорошо адаптирован к работе в сети. Однако учтите, что LDAP ориентирован на быстрый поиск и доступ (чтение) данных — но внесение изменений не является настолько же быстрой и эффективной операцией. Так что этот протокол ориентирован, скорее, на статические данные: адреса, телефоны, пароли, сетевые ресурсы — и не подойдет для информации, которая склонна быстро меняться.

По сути, LDAP — не реляционная база данных. Структура базы LDAP скорее напоминает XML, где запись представляет собой комбинацию атрибут: значение. Поскольку существует возможность определять новые типы полей, то в LDAP можно сохранить любую текстовую или бинарную информацию. Это обуславливает большую гибкость для описания новых полей и структур, но в общем случае поиск по неиндексированному полю — операция довольно медленная.

С чего начать? Можно с инсталляции

Конечно, теория — это круто, но без практики она никому не нужна. Итак, на повестке дня — установка LDAP-сервера. Конечно, первое, с чем нужно определиться, это платформа. Обычно это Linux или FreeBSD, но LDAP-серверы доступны и на других платформах, в частности на MS Windows и Mac OS X.

Рассмотрим только канонический случай, то есть установку под Linux. Как принято в мире открытых систем, если кто-то реализует протокол, то код этот будет использоваться и в дальнейшем как референсный. Поэтому в качестве стандарта де-факто используется код, написанный в Мичиганском университете.

Вполне естественно, что открытая версия LDAP называется OpenLDAP. Последний релиз и документацию вы можете найти на www.openldap.org — на момент подготовки  статьи последняя версия имела номер 2.2.17.

Собственно, всем заведуют две утилиты:

• slapd — демон LDAP запросов;
• slurpd — демон репликации.

Дополнительно OpenLDAP предоставляет библиотеки для встраивания LDAP в ваши приложения (приведен также пример клиентского приложения). Библиотека классов для работы с LDAP называется JLDAP — и она тоже доступна как часть дистрибутива OpenLDAP.

Рассмотрим установку OpenLDAP из исходников, поскольку только этот метод гарантирует последнее обновление и, кроме прочего, добавит вам извилин.

Прежде чем устанавливать OpenLDAP, следует обзавестись движком базы данных Sleepycat Berkeley DB — без этого вы не сможете сконфигурировать и скомпилировать OpenLDAP. Для версии OpenLDAP 2.2.17 нужно установить версию Sleepycat 4.2 (текущая подверсия — 4.2.52, закачать ее можно по адресу www.sleepycat.com/download/db/index.shtml либо с КП-диска). Для полной уверенности в правильной работе Sleepycat примените два патча, полученные с сайта: скопируйте текстовые файлы патчей в корневой каталог приложения и выполните команды:

patch -p0< patch[2].4.2.52.1.txt
patch -p0< patch[2].4.2.52.1.txt

Полную инструкцию по компиляции BDB под POSIX/UNIX вы можете найти по адресу www.sleepycat.com/docs/ref/build_unix/intro.html.

После установки DB можно приступать инсталляции. На момент написания файл архива назывался openldap-stable-20040923.tgz (его тоже можно найти на КП-диске). Если вы не хотите вдаваться в параметры компиляции, тогда просто выполните следующие команды:

cd /usr/src/
tar xfz openldap-stable-20040923.tgz
cd openldap-2.2.17
./configure
make depend
make
make test
make install

На всякий случай...

На этапе configure может возникнут проблема, известная как BerkleyDB version incompatible. Связана она с тем, что символические ссылки по-прежнему указывают на старую версию. В этом случае следуйте указаниям совета, найденного мною на www.fatofthelan.com:

• убейте симлинк db.h в /usr/include и замените его реальным файлом db.h из /usr/local/BerkekeyDB.4.2/include/;
• в /etc/ld.so.conf добавьте строку /usr/local/BerkekeyDB.4.2/lib и запустите ldconfig;
• запустите конфигурацию таким вот образом:

env CPFLAGS=-I/usr/local/BerkeleyDB.4.2/include; export CPFLAGS; LDFLAGS=-L/usr/local/BerkeleyDB.4.2/lib; export LDFLAGS; ./configure

У меня на Mandrake 9.2, на котором до этого стоял DBD 4.1, после этих махинаций все стало пучком.

После удачной компиляции прохождение make test доставит вам полнейшее удовольствие — благодаря людям из Мичигана, все проходит с полным аншлагом. Тесты, как вы можете убедиться, включают не только запросы и операции с данными, но и репликации, в том числе каскадные. Другое дело, что не один месяц пройдет, пока вы поймете значение всех этих тестов.

Настройки

Если вы покончили с компиляцией, то следующий шаг — конфигурация файла настроек (обычно расположенного по адресу /usr/local/etc/ldap/slapd.conf). В этом файле содержатся три типа разделов: глобальные настройки, настройки для узла (backend) и настроки для отдельной базы данных. Каждая более детальная настройка может отменять более общие параметры — то есть настройки по зоне отменяют глобальные настройки и т.д.).

По умолчанию в настройках стоят достаточно работоспособные параметры, в частности настройки каталогов (каталоги должны быть уже созданы на этапе инсталляции) и типа доступа к базе данных. Единственное, что может нуждаться в изменении, это суффиксы для вашего домена: параметры suffix и rootdn.

Обратите также внимание на параметр rootpw secret. Это вовсе не указание сделать пароль администратора LDAP секретнымJ — это и так понятно — просто пароль по умолчанию пишется как secret. Его-то вы и должны вводить при внесении данных с помощью ldapadd. Понятно, что вы захотите его поменять на что-то более впечатляющее, вроде R5>(hg#!).

После конфигурации вы можете запустить и проверить самый элементарный поиск по базе данных LDAP:

 /usr/local/libexec/slapd
 ldapsearch -x -b '' -s base

'(objectclass=*)' namingContexts

Результат должен быть таким, как показано на рисунке ниже: система отвечает на запрос, хотя и говорит, что записи не найдены. Это естественно — откуда бы им там взяться?

Добавляем данные, собственно

Добавление записей в базу данных производится (как вариант) с помощью утилиты ldapadd. Она воспринимает на входе файл специального формата — так называемый LDIF, LDAP Data Interchange Format (эти файлы так и принято именовать, с расширением ldif). Нетрудно догадаться, что такие или подобные файлы будут управлять всеми операциями с данными.

Вот примерный, из документации, файл, который вы можете создать в любом тестовом редакторе, например в vim (параметры вашего домена, вместо comizdat.com, подставьте по месту; а можете и не подставлять — мы не обидимся).

dn: dc=comizdat,dc=com
objectclass: dcObject
objectclass: organization
o: Comizdat
dc: comizdat

dn: cn=Manager,dc=comizdat,dc=com
objectclass: organizationalRole
cn: Manager

Первая строка каждого блока определяет так называемый узел поиска — DIT, Data Information Tree Node. От этого узла будет производиться поиск. Собственно, в приведенном примере добавляется две записи: одна описывает организацию Comizdat, вторая — тип работника (organizationalRole) Manager.

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

Особый формат имеют также и бинарные данные: они помечаются дополнительным двоеточием и должны быть закодированы по Base64 (ну, я надеюсь, вы можете перекодировать в уме в этот форматJ). Короче, для генерации ldif-файла лучше всего пользоваться программной оболочкой, которая контролирует эти тонкости и не допустит ошибок. Сам формат ldif-файла хорошо описан здесь: www.rfc-editor.org/rfc/rfc2849.txt.

Все записи данных обязательно относятся к одному или нескольким классам, задаваемых параметрами objectClass. Класс задает набор допустимых атрибутов (полей), некоторые из которых обязательные, а некоторые — опциональные. Для полей заданы формат, правила сортировки, тип, кодировка и т.д. Для атрибутов может быть определено несколько наименований, обычно два — полное и сокращенное. К примеру, поля c, o, ou являются сокращениями от countryName, organizationName и organizationUnitName.

Кроме того, что файл ldif имеет общий формат, он еще должен удовлетворять схемам, которые описывают допустимые классы и их атрибуты. Распространенные схемы обычно хранятся в каталоге /usr/local/etc/openldap/schema и имеют расширение *.schema. Другие схемы поставляются с пакетами, их использующими: например, DHCP-демон поставляется со схемой dhcp.schema. Схемы состоят из двух частей: сначала определяются атрибуты с уникальными именами, из которых впоследствии конструируются классы.

Прежде чем использовать в своей базе данных какую-нибудь схему, вы должны включить ее в файл конфигурации slapd.conf с помощью команды include. Например, для стандартных адресных записей в файл конфигурации включена запись include /usr/local/etc/openldap/schema/core.schema.

При создании нового класса от уже существующего, наследуются существующие поля и добавляются новые. Сами атрибуты тоже упорядочены — наподобие того как упорядочены суффиксы в системе имен DNS: сначала записи группируются по более общему признаку, например по стране, потом — по организации и т.д. Существует две распространенные классификации: глобальная (имя — домен) и организационная (имя — отдел — организация — страна). Естественно, что в вашей схеме группировка может быть совсем другой. В конце концов, самым достоверным документом по атрибутам являются сами схемы — и прежде чем описывать собственные классы, я бы посоветовал как следует построчно разобраться с core.schema.

Теперь вы можете приписать этот файл в вашу базу данных и протестировать наличие новой записи, связанной с вашим доменом:

ldapadd -x -D “cn=Manager,dc=comizdat,dc=com” -W -f 1.ldif
lpadsearch -x -b ‘dc=comizdat,dc=com’  ’(objectclass=*)’

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

Пару слов о том, что значат параметры:

• -x значит «простая аутентификация», для локального подключения приемлемо;
• -D — домен, к которому следует "прибить" новые данные;
• -W — запросить пароль;
• -f — получать поток из файла, а не стандартного ввода;
• -b — указывает, что поиск нужно начать от определенной «поисковой базы», то есть узла.

Прочие параметры вы можете посмотреть и с помощью man-страниц.

Еще один момент: аутентификация LDAP никак не связана с правами суперпользователя. Вообще-то, запросы к LDAP и чтение разрешены кому ни попадя. И если вы против такого поведения, читайте в документации как сделать, чтобы такого не было.

На этом мы, пожалуй, и завершим введение в OpenLDAP, поскольку разговор о специфике создания баз данных и конструировании запросов соответствует скорее формату книги, чем статьи. Могу только сказать, что запустить систему в работу просто, поскольку вначале вы можете пользоваться только 5% всех возможностей (и, тем не менее, получать от этого пользу). А такие возможности, как репликация или еще более сложные каскадные обновления, а также использование LDAP для системного администрирования, вы освоите по мере необходимости.

LDAP на других платформах

Возможно, вы относитесь к особой категории пользователей и являетесь поклонником серверных платформ Windows? Ну, в таком случае вам тоже доступен LDAP. Собственно, главным ресурсом по этому вопросу является декларация "Майкрософт" по LDAP, доступная на
www.microsoft.com/technet/prodtechnol/winntas/plan/ldapcmr.mspx.

Вкратце: все в этом мире вторично, за исключением Active Directory. С этой точки зрения Active Directory имеет LDAP-совместимый интерфейс. Особого парадокса тут нет: LDAP — это, скорее, метод доступа, совершенно инвариантный к методам физического хранения и управления данными, а также безразличный к операционной среде. И поскольку данные могут быть запрошены через стандартный порт 389 с помощью стандартных же запросов, то можно говорить о поддержке LDAP в Windows. Хотя вместо простых и понятных хеш-таблиц Berkeley DB здесь используются иерархические защищенные хранилища Active Directory.

У этого вопроса есть и обратная: в Active Directory API существуют функции, которые позволяют выполнять запросы к другим LDAP-серверам и на их основе обновлять данные. Этот компонент называется LDAP-провайдер.

Наконец, если вы совсем уж особенный человек и MacOS X предпочитаете всем остальным операционным системам, то и в этом случае для вас не все потеряно в плане установки LDAP-сервера. С использованием LDAP в качестве клиента эта операционка, естественно, не имеет никаких проблем. Теоретически MacOSX принадлежит к семейству BSD, так что для нее можно скомпилировать любой открытый софт. Хотя на самом деле многие испытывают значительные трудности на этом пути, так что лучше все-таки пользоваться "фирмой".

Полезные ссылки

Несколько слов о тех интернет-ресурсах, которые могут помочь с информацией по теме.

Главная ссылка, с которой можно начать освоение LDAP и откуда почерпнул максимум информации я сам, это сайт http://ldapzone.spb.ru/.

Кроме того, вы можете сразу направиться на http://openldap.org, где лежит последний дистрибутив.

Наконец, если вы хотите использовать LDAP в административных целях, вас наверняка заинтересует документ, описывающий применения LDAP в «потусторонних» контекстах, таких как раздача DHCP, учет трафика и сетевых ресусов: "Централизованная схема управления сетью с использованием OpenLDAP".

Эпилог

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

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

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