Наиболее развитым иснтрументом, способным обеспечить создание
распределенных информационных каталогов в сети, является служба
каталогов LDAP (Light Weight Directory Access Protocol), которая в
свою очередь является упрощенным вариантом DAP X.500, разработанного
еще в 1988 году для нужд телекоммуникаций. X.500 оказался очень
сложным протоколом и реализовать его в сетях TCP/IP не представлялось
возможным, поэтому IETF приступила к выработке несколько измененного и
упрощенного варианта X.500. Разработанная спецификация получила
название LDAP-1 и определяла основные понятия, такие как LDAP-клиент и
шлюз, через который обрабатываются клиентские запросы, адресованные к
директории. Следующий вариант LDAP-2 (RFC1777) появился достаточно
скоро, и содержал в себе возможность создания внутренних директорий,
хранящихся на LDAP сервере (понятие которого появилось также в
LDAP-2), не зависящих от X.500. На сегодняшний день широко
используется LDAP-3, в котором устранено множество недостатков
предыдущих версий протоколов. В рамках стандарта LDAP-3 (RFC2251) LDAP
сервер превращается в мощнейшее средство для создания глобальных
информационных каталогов. Стадартом RFC2256 также определяется общая
схема (common schema), которая устанавливается на всех серверах LDAP.
Админинистратор также может расширить схему, добавив описания новых
элементов каталога (классы) и их свойств (атрибуты).
Модель директории LDAP имеет фундаментальные отличия например от
классических реляционных, постреляционных и объектоно-ориентированных
баз данных, которые основаны на использовании таких понятий, как
"отношение" , с помощью которого содержимое базы данных разделяется на
группы однородных объектов. Имеено с группами объектов и происходят
действия в классических базах данных, где группа является естественной
областью операций.
В основе модели директории LDAP лежит идея размещения объектов в
вершинах древовидной структуры. Группировка же объектов происходит по
принципу размещения их в вершине одного поддерева, причем
группироваться могут совершенно разные объекты. Для поиска некоторого
объекта необходимо указать идентификатор корня соответствующего
поддерева.
МОДЕЛЬ ДИРЕКТОРИИ
Данные размещаются в директории в виде объектов. Каждый объект
директории есть отражение какого либо реально существующего объекта -
человека, принтера, компьютера и т.д. Каждый объект имеет несколько
атрибутов, последний в свою очередь имеет название и значение
фиксированного в LDAP типа. Тип определяет формат значения, вид его
представления, способы сопоставления и упорядочивания.
Объекту присваивается класс (или классы) к которому он принадлежит с
помощью обязательного аттрибута objectClass, значением которого
является имя класса.
Классы объектов объявлены в схеме директории (directory schema), где
задаются имя класса, атрибуты, тип атрибутов а также указывается их
обязательность или опциональность. Также могут быть указаны и
родительские классы, определения которых будут наследоваться.
Естественно, атрибут, который упоминался в родительском классе, как
обязательный, для дочернего класса также будет обязательным.
Аналогично и с опциональными атрибутами.
Особенность представления схемы в LDAP является то, что определение
атрибутов не включается в объявление классов, а дается самостоятельно.
Таким образом в схеме сначала дается определение атрибутов, который
затем используется при построении классов объектов. Эта особенность
вызвана тем, что необходимо предотвратить ситуацию появления в классах
атрибутов с одинаковым именем, но с разными типами значений.
ДЕРЕВО ДИРЕКТОРИИ
Объекты в директории компонуются в виде древовидной структуры.
Логическое местоположение объектов в дереве отражает какую либо
подчиненность (географическую, физическую, организационную). При
создании нового объекта необходимо указать его принадлежность к
классу, атрибуты, указать существующий объект, к которому он будет
подчинен и задать относительное уникальное имя (Relative Distinguished
Name). RDN задается посредством указания одного или нескольких
значений атрибутов, при этом если объект имеет несколько атрибутов, то
задается один из них.
Пример:
Здесь RDN является uid. Объект имеет атрибут с именем uid, и этот
атрибут и его значение указано в качестве RDN.
Уникальные имена (Distinguished Name), позволяющие однозначно
идентифицировать объекты в директории, образуются с посредством
конкатенации RDN вышестоящих по иерархии объектов (по аналогии со
службой DNS), записываемые от объекта к корню. Для разделения RDN
внутри DN используется запятая.
РАСПРЕДЕЛЕННАЯ МОДЕЛЬ ДИРЕКТОРИИ
LDAP директория изначально проектировалась как распределенная
система хранения информации. При использовании распределенной модели
различные фрагменты информационного дерева физически хранятся на
разных серверах. Идентифицируются распределенные серверы LDAP в
глобальных сетях с помощью интернет-адреса вида ldap://URL:port. Где
URL есть DNS имя или IP адрес, а port - номер порта (для обычного 389
и для защищенного 686). К интернет-адресу LDAP сервера также может
быть добавлен DN, идентифицирующий соответствующий объект в
директории. Например, объект, имеющий в директории DN
uid=Postnikov,ou=People,dc=nordcomp,dc=ru адресуется с помощью
интернет-адреса в следующем виде:
В распределенной модели каждый сервер хранит собственную базу
данных, содержащую один или несколько фрагментов директории,
являющиеся поддеревьями информационного дерева директории.
Идентификация каждого объекта осуществляется посредством задания
суффикса - DN-имени объекта, являющегося корнем этого поддерева.
Поддерево, определяемое суффиксом, может воспользоваться
переадресацией на другой LDAP сервер с помощью ссылок (referrals).
Внешние ссылки позволяют исключить некоторую информацию из поддерева и
передать ее на обслуживание другому серверу, позволяя представить как
единое целое распределенную директорию. Ссылки представляются в виде
отдельного специального объекта, принадлежащего к классу (objectClass)
Referral, с помощью атрибута ref. Атрибут ref как раз и содержит
ссылку на объект в виде ldap://URL:port/DN.
Для повышения надежности и эффективности в распределенных моделях
применяется также механизм репликации данных, с помощью которого
отдельные фрагменты директории копируются на другие серверы. Помимо
повышения надежности репликация позволяет увеличить производительность
за счет сбалансированной нагрузки серверов и т.п. Например, при
репликации можно избавиться от переадресации запросов.
Репликационный механизм организуется с помощью мастер-сервера и
вторичных серверов (по аналогии с серверами DNS), причем любой LDAP
сервер одновременно может являться как получателем так и поставшиком
данных. Для повышения эффективности репликации, на мастер-сервере
используется журналирование изменений, и реплицируются именно
изменения, которые имели место с последнего момента репликации, а не
все данные.
ФУНКЦИОНАЛЬНАЯ МОДЕЛЬ ДИРЕКТОРИИ
Функциональная модель LDAP директории основана на клиент-серверной
технологии. Существует достаточно большое количество API для различных
языков программирования (C/C++, Perl, JAVA и др.) для доступа к LDAP
директориям. Базовыми функциями LDAP-клиента являются следующие:
открытие соединения клиента с сервером, аутентификация, выполнение
поиска, модификация данных, закрытие соединения.
Современные операционные системы содержат в себе основные утилиты
для работы с LDAP серверами, например в UNIX это утилиты ldapsearch,
ldapmodify и т.д. Существуют также графические клиентские программы
(так называемый LDAP-Browser) , позволяющие просматривать, производить
поиск и изменять содержимое LDAP директорий. В следующей таблице
приведен список наиболее важных операций в LDAP, утилит, их
реализующих, и соответствующее описание в соответствии со стандартом
RFC1823.
Операция--Утилита------Описание
Search----ldapsearch---Производит поиск в директории и возвращает
результат поиска в виде списка значений найденных объектов
Add-------ldapadd------Осуществляет добавление новых объектов в
директорию. При добавлении объектов указывается их DN, objectClassи
значения атрибутов.
Modify----ldapmodify---Производит удаление объектов из директории.
Удаление же контейнерных (поддеревьев) объектов возможно только с
помощью рекурсивных операций.
Delete----ldapdelete---Осуществляет возможность модифицирования
атрибутов (удаление, замена, добавление) и их значений у существующих
объектов в директории.
Bind-------------------Производит открытие сессии клиента с сервером,
предоставляет данные для аутентификации.
Unbind-----------------Закрывает соединение между клиентом и сервером
Abandon----------------Завершает выполнение асинхронной операции на
сервере
ВВЕДЕНИЕ В OPENLDAP 2.x
Пакет OpenLDAP 2.x имеет в составе две основных программы. Это
slapd(8), являющийся сервером директории LDAP и slurpd(8), являющийся
сервером репликации. Программный продукт распространяется в исходных
кодах на основе лицензии GPL, является кроссплатформенным и обладает
следующими возможностями:
Полное соответствие спецификации LDAP v3 как в сетях IPv4 так и
IPv6.
Slapd поддерживает как простую аутентификацию так и защищенный канал
посредством SASL.
Slapd поддерживает использование защиты канала транспортного уровня
(TLS/SSL) с использованием OpenSSL
Контроль доступа, реализованный в slapd, позволяет гибко настроить
конфигурацию в соответствии с требованиями безопасности. Контроль
доступа к объектам диерктории может осуществляться на основе различных
критериев, таких как аутентификационная информация, IP-адреса,
доменные имена и т.д. Slapd поддерживает как статическую так и
динамическую информацию котроля доступа.
Slapd поддерживает UNICODE и различные языки
Slapd может использовать различные типы физических баз данных. Этот
список включает в себя следующие БД: BDB (Berkley DataBase)
высокопроизводительная, транзакционного типа БД, LDBM (упрощенная
версия DBM) и др.
Сервер репликации slurpd(8) ответственен за реплицирование изменения
данных с одного сервера LDAP на другой. slapd и slurpd используют
простой текстовый файл (журнал) для обеспечения взаимодействия друг с
другом.
СБОРКА И УСТАНОВКА OPENLDAP 2.x
Взять исходники OpenLDAP можно непосредственно с сайта проекта или с
ftp-сервера. Проект выпускает две серии пакетов для общего
пользования. Релиз выпускается как только появляются новые функции и
исправляются ошибки предыдущих версий, естественно, некоторые ошибки в
релизе выявляются только после прошествия определенного времени.
Последний релиз (latest release) это релиз обладающий наибольшей
стабильностью. Тем, кто собирается использовать OpenLDAP следует
самостоятельно сделать выбор между "новейшими функциями" и "верной
стабильностью".
После того, как архивированные исходники были скачаны (например, в
директорию /usr/src/openldap), их следует распаковать:
# cd /usr/src/openldap
# gzip -d openldap-VERSION.tgz
# tar -xvf openldap-VERSION.tar
В любом случае рекомендуется внимательно просмотреть содержимое
файлов INSTALL и README. Файлы ISNTALL и README включают в себя
достаточно полные инструкции по установке.
НЕОБХОДИМОЕ ПРОГРАММНОЕ ОБЕСПЕЧЕНИЕ
ПО OpenLDAP использует ПО сторонних производителей для реализации
следующих функций:
1. Безопасность транспортного уровня (TLS)
Клиентская и серверная часть OpenLDAP требует установленных библиотек
TLS, включенных в состав OpenSSL, для реализации функций TLS. Несмотря
на то, что некоторые операционные системы имеют в своем составе
OpenSSL, вам могут потребоваться так называемые DEVELOPMENT части для
компиляции. Во многих дистрибутивах Linux (RedHat, SuSE, Mandrake,
etc) DEVELOPMENTи runtime собираются в пакеты раздельно, поэтому
потребуется их доустановить. Наилучшим вариантом является
использование самой свежей версии OpenSSL, которую можно взять на
сайте проекта www.openssl.org. Следует также отметить, что без
поддержки TLS OpenLDAP не будет являться полностью LDAPv3-compliant.
2. Сервисы аутентификации Kerberos
Клиентская и серверная часть OpenLDAP требует установленных библиотек
Cyrus SASL для реализации сервисов простой аутентификации и
защищенного уровня. Несмотря на то, что некоторые операционные системы
имеют в своем составе эти библиотеки, вам могут потребоваться
DEVELOPMENT части для компиляции. Во многих дистрибутивах Linux
(RedHat, SuSE, Mandrake, etc) DEVELOPMENTи runtime собираются в пакеты
раздельно, поэтому потребуется их доустановить. Аналогично с OpenSSL,
без поддержки Cyrus SASL OpenLDAP не будет являться полностью
LDAPv3-compliant.
3. ПО Баз Данных
Для хранения записей LDAP директории демону slapd требуется база
данных - LDBM. LDBM совместима с [4]Sleepy Cat Software BerkleyDB
(рекомендуется) и с [5]GNU Data Base Manager. В случае, если эти
компоненты отсутствуют, slapd не сможет выпонять функции первичного
LDAP сервера. Чаще всего, оба пакета включены в состав ОС (в BSD
например). ОС Linux может включать в себя отдельно запакованные
runtime и development пакеты. Потребуется установить оба.
4. Нити (Threads)
OpenLDAP полностью использует приемущества threads. Включена поддержка
как POSIX pthreads так и Mach Cthreads. Скрипт ./configure выдаст
сообщение об ошибке, в случае, если он не сможет обнаружить ни одной
подходящей реализации threads.
5. TCP Wrappers
Демон slapd поддерживает использование wrappers (фильтры контроля
доступа IP уровня). Рекомендуется использовать фильтры для
предотвращения нежелательного доступа (особенно в non-public сетях).
КОМПИЛЯЦИЯ И УСТАНОВКА
Рекомендуется ознакомится со списком опций для configure. Для этого
достаточно запустить его следующим образом:
# configure --help
Задавая особые опции configure можно отключить или включить множество
различных функций. Скрипт configure также использует переменные
окружения, передаваемые компилятору:
CC : Указывает на альтернативный компилятор Си
CFLAGS : Указывает дополнительные флаги компилятору
CPPFLAGS : Указывает дополнительные флаги C++ компилятору
LDFLAGS : Указывает дополнительные флаги линковщику
LIBS : Указывает на дополнительные библиотеки
Использование переменных окружения необходимо, в случае если какие то
части (библиотеки или include файлы) находятся в нестандартных
каталогах. Например:
Следует учесть, что переменные окружения устанавливаются в различных
shell по разному (в bash например используется export а не setenv).
Теперь можно запустить скрипт configure с опциями:
# [[env] settings] ./configure [options]
После того, как скрипт configure завершит свою работу, убедитесь, что
все нужные компоненты были найдены (configrure выведет сообщение
"Please, "make depend" to build dependencies"), в противном случае
внесите необходимые изменения в переменные окружения и не забудьте
удалить файл config.cache, запустите configure повторно. Можно
переходить непосредственно к компиляции.
# make depend
# make
Прим: на BSD системах требуется использовать GNU make, gmake.
Тестируем
После компиляции желательно удостоверится в корректности сборки ПО.
# make test
Устанавливаем
После успешной компиляции и тестирования, можно установить OpenLDAP в
указанные configure директории с правами root. По умолчанию OpenLDAP
устанавилвается в /usr/local. Значение по умолчанию изменяется с
помощью опции configure --prefix=/path/to/dir.
# su root -c 'make isntall'
Команда должна завершиться успешна, в противном случае проанализируйте
вывод на консоль. Конфигурационные файлы по умолчанию будут
установлены в /usr/local/etc/openldap.
КОНФИГУРАЦИОННЫЙ ФАЙЛ SLAPD.CONF
Как только ПО было собрано, можно приступать к конфигурированию
непосредственно slapd. Конфигурационная информация, находящаяся (по
умолчанию) в /usr/local/etc/slapd/slapd.conf практически не требует
изменений. Если вы по каким то причинам не хотите использовать именно
этот файл, можете указать альтернативный, с помощью опций командной
строки при запуске slapd.
Формат конфигурационного файла
slapd.conf состоит из трех типов конфигурационной информации:
глобальной, backend-специфичной, и database-специфичной. Глобальная
информация указывается первой, далее следует информация,
ассоциированная с конкретным типом backend, за которой соответственно
информация ассоциированная с конкретной базой данных. Глобальные
директивы "перекрываются" директивами backend и/или database specific,
backend в своб очередь могут быть "перекрыты" database specific.
Пустые строки и строки, начинающиеся с "#" игнорируются. Общий формат
slapd.conf представляется следующим образом:
# Глобальные конфигурационные директивы
<Глобальные конфигурационные директивы>
# определения backend
backend <typeA>
<backend-specific директивы>
# определение первой БД и конфигурационные директивы
database <typeA>
<database-specific директивы>
# определение второй БД и конфигурационные директивы
database <typeB>
<database-specific директивы>
# Последующие backend & database определения & конфигурационные директивы.
Конфигурационные директивы могут принимать аргументы. В таком случае
аргумент отделяется от директивы пробелом/табуляцией. Если аргумент
содержит пробелы, в таком случае его необходимо заключить в кавычки.
Если аргумент содержит кавычки или символ '', в таком случае эти
символы должны предварятся бекслешем ''. Дистрибутив OpenLDAP
включает в себя в качестве примера файл slapd.conf и различные файлы
схем в /usr/local/etc/openldap/schema.
Директивы конфигурационного файла
Далее будут описаны основные директивы конфигурационного файла. Полный
список и описание можно увидеть, воспользовавшись командой man
slapd.conf.
ГЛОБАЛЬНЫЕ ДИРЕКТИВЫ
Директивы, описанные в этой секции, применяются ко всем backend-ам и
базам данных, если не указано другое в backend- или
database-директивах. Аргументы, которые должны быть заменены каким
либо реальным значением, заключены в скобки "<>".
1. access to <what> [by <who> <accesslevel> <control>]+
Директивой дается доступ (тип указывается <accesslevel>) к набору
записей и/или атрибутов (указывается to <what>) одному или нескольким
клиентам, запросившим данные (указывается by <whom>).
2. attributetype <[6]RFC2252 Attribute Type Description>
Директивой описывается тип атрибута директории LDAP.
Директивой указывается маска доступа "по умолчанию", если объекту не
указан конкретно доступ. Каждый последующий тип доступа включает в
себя предыдущий. Таким образом, например, read включает в себя comapre
и search. Значение по умолчанию defaultacces read.
4. idletimeout <целое число>
Директива указывает на количество секунд, после которых slapd должен
закрыть неактивные соединения. Если значение установлено в 0, функция
отключена.
5. include <имя файла>
Директива указывает на дополнительный файл, из которого slapd должен
прочитать конфигурационную информацию, до того, как начать чтение
следующих строк. Дополнительный файл должен содержать конфигурационную
информацию, аналогичную формату slapd.conf. Директива чаще всего
используется для включения файлов схем в директорию LDAP.
Примечание: необходимо быть осторожным с данной директивой, т.к. не
предумотрено контроля "вложенности".
6. loglevel <целое число>
Директива указывает на уровень debug log и статистики операций. Для
логирования используется syslogd. Для того, чтобы использовать все
возможные значения loglevel, необходимо конфигурировать OpenLDAP с
опцией --enable-debug. Узнать, какой уровень какому числу
соответствует можно с помощью команды slapd -?.
7. objectClass <[7]RFC2252 Object Class Desription>
Директива определяет объектный класс.
8. referral <URI>
Директива указывает на ресурс, к которому следует обратится LDAP
серверу, в случае, если не удастся найти нужную информацию в базах
данных.
Пример:
referral ldap://ldap.openldap.org
9. sizelimit <целое число>
Директива указывает на количество максимально возможных записей,
возвращаемых клиенту при операции search.
Значение по умолчанию - 500.
10. timelimit <целое число>
Директива указывает на максимально число секунд, которое может быть
затрачено slapd для выдачи ответа клиенту при операции search. Если
операция поиска не уложилась в указанное время, клиент получит
результат о том, что время для операции превышено.
Значение по умолчанию - 3600.
ОБЩИЕ BACKEND ДИРЕКТИВЫ
Директивы этой секции применяются ко всем базам данных, тип которых
совпадает, если не указаны конкретные директивы для базы данных
отдельно.
11. backend <тип>
Директива указывает на начало секции описания backend-а типа <тип>.
Возможные значения ldbm, shell, passwd (или другие поддерживаемые).
ОБЩИЕ ДИРЕКТИВЫ БД
Директивы этой секции применяются только к тем базам данных, в которых
они указаны. Директивы поддерживаются каждым типом баз данных.
12. database <тип>
Директива указывает на начало секции, описывающей базу данных
соответствующего типа. Тип может принимать значения ldbm, shell,
passwd.
Пример:
database ldbm
13. readonly {on | off}
Директива указывает на режим доступа к БД в режиме "только для
чтения". Значение по умолчанию - off.
Директива указывает на репликационный хост - куда будет производится
репликация данной базы данных.
Параметр host= указывает на хост, и опционально, адрес порта (если
используется нестандартный). Допускается указание как IP адреса хоста,
так и доменного имени. Если <port> не указан, используется стандартный
порт LDAP 389/tcp.
Параметр binddn= указывает на Distinguished Name, с которым нужно
подключаться к slave LDAP серверу. Этот DN должен иметь права записи и
чтения в базе slave LDAP сервера. На практике чаще всего используется
rootdn slave LDAP сервера. Указанный DN обязательно должен совпадать с
updatedn в конфигурационном файле slave LDAP сервера. Так как обычно
строка DN может содержать пробелы, ее нужно заключить в кавычки
"binddn=<DN>".
Параметр bindmethod= задает тип аутентификации, которая будет
использована при репликации данных. Возможные варианты - simple
("простая", пароль передается открытым текстом), kerberos
(используется Kerberos IV или V) или sasl. Использовать simple
аутентификацию не рекомендуется без защиты на транспортном уровне
(TLS/SSL или IPSec). Simple аутентификация требует указания параметров
binddn и credentials.
Непосредственно Kerberos устарел, как метод аутентификации, в связи с
появлением спецификации SASL. Kerberos требует указания binddn и
srvtab.
Рекомендуемым методом аутентификации является SASL. Использование
этого метода требует указания также механизма SASL - параметр mech. В
зависимости от механизма, аутентификационный identity и/или
credentials могут быть указаны параметрами authcid и credentials.
Параметр authzid может быть использован для указания авторизационного
identity.
15. replogfile <имя файла>
Директивой указывается путь к репликационному файлу, который будет
использоватся для отражения изменений в master LDAP сервере. Таким
образом, на slave серверы реплицируется не вся база полностью, а лишь
та информация, которая изменилась с последнего момента репликации.
Естественно, эта директива требуется лишь в случае, если slurpd должен
производить репилкацию.
16. rootdn <DN>
Директивой указывается DN, на который не распространяются правила
доступа, иными словами, это DN, который имеет полный доступ к
директории LDAP. Создавать этот DN непосредственно в директории не
требуется. DN также может ссылатся на SASL identity.
Пример:
rootdn "cn=ldapdmin,dc=nordcomp,dc=ru"
В случае SASL:
rootdn "uid=[8]ldapadmin@NORDCOMP.RU"
17. rootpw <пароль>
Директивой указывается пароль для rootdn. В случае, если используется
SASL, указывать эту директиву не нужно. Пароль может быть как clear
text, так и хешированным SHA1, MD5, CRYPT и др. (рекомендуется).
(Плохой) Пример:
rootpw password
18. suffix <dn suffix>
Директива указывает суффикс DN, относительно которого будут
производится запросы к данной базе данных. Параметр может включать
несколько строк и по крайне мере должна быть указана хотя бы одна.
Пример:
suffix "dc=nordcomp,dc=ru"
Примечание: Когда к backend-у передается запрос, slapd просматривает
суффиксы в каждой из определений баз данных в порядке следования
записей. Т.е. если , например, если у какой то базы суффикс является
префиксом другой базы данных, первая должна быть после второй.
Vova
