LDAP Linux HOWTO

В этом документе представлена информация об установке, настройке, запуске и обслуживании LDAP (Lightweight Directory Access Protocol) сервера на Linux, а также приводятся детали создания LDAP баз данных, способов обновления и удаления информации из базы данных, путей реализации роуминга и способов использования Netscape Address Book.

[Luiz Ernesto Pinheiro Malere (malere@yahoo.com).]

Введение

Главная цель этого документа - установка и использование сервера каталогов LDAP на вашей Linux машине. Вы научитесь устанавливать, настраивать, запускать и обслуживать LDAP сервер. Далее вы научитесь способам помещения, извлечения и обновления информации в вашем каталоге с помощью клиентов LDAP и утилит. Демон для LDAP сервера каталогов называется slapd, и он запускается на многих различных UNIX платформах.

Также есть другой демон, который заботится о репликации между LDAP серверами. Он называется slurpd и, в данный момент, вам не следует о нем беспокоится. В этом документе вы запускаете slapd, который предоставляет службу каталогов только для вашего домена, без репликации, следовательно, без slurpd.

Такие простые настройки сервера хороши для начала, и, если вы захотите, позже их легко можно обновить до другой конфигурации. Представленная в этом документе информация представляет собой хорошее введение в использование протокола LDAP. Возможно, после прочтения этого документа вы почувствуете себя увереннее для расширения возможностей вашего сервера, и даже написания собственных клиентов, используя доступные C, C++ и Java Development Kits.

Что такое служба каталогов?

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

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

Существует много различных путей реализовать службу каталогов. Различные методы позволяют помещать в каталоге информацию различного типа, помещать различные требования на то, как на эту информацию можно ссылаться, запрашивать и обновлять, как она защищается от несанкционированного доступа и т.п. Некоторые службы каталогов локальны, и предоставляют службы в ограниченном контексте (например, служба finger на одной машине). Другие службы глобальны, и предоставляют обслуживание в более обширном контексте.

Механизмы баз данных LDAP, объекты и атрибуты

Slapd поставляется с тремя различными механизмами баз данных, которые вы можете выбрать. Это: LDBM - высокоскоростная дисковая база данных; SHELL - интерфейс базы данных к обычным UNIX командам и shell скриптам; и PASSWD - простая база данных на основе файла паролей.

В этом документе я предполагаю, что вы выбрали базу данных LDBM.

База данных LDBM работает, назначая компактный уникальный четырехбайтовый идентификатор каждому элементу базы данных. Она использует этот идентификатор для ссылок на записи из индексов. База данных состоит из одного главного файла индексов под названием id2entry, который устанавливает соответствие уникального индекса элемента (EID) текстовому представлению самого элемента. Также поддерживаются другие индексные файлы.

Для импортирования или экспортирования информации каталога между серверами каталогов основанных на LDAP или для описания набора вносимых в каталог изменений, обычно используется формат LDIF, т.е. LDAP Data Interchange Format. Файл LDIF хранит информацию об объектно-ориентированной иерархии элементов. Пакет LDAP, который вы собираетесь использовать, поставляется с утилитой конвертирования LDIF файлов в LDBM формат.

Типичный LDIF файл выглядит так:

dn: o=TUDelft, c=NL
o: TUDelft
objectclass: organization
dn: cn=Luiz Malere, o=TUDelft, c=NL
cn: Luiz Malere
sn: Malere
mail: malere@yahoo.com
objectclass: person

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

В LDAP, класс объектов определяет набор атрибутов, которые используются для определения элемента. Стандарт LDAP определяет такие основные виды классов объектов:

  • Группа каталогов, включая неупорядоченный список индивидуальных объектов или групп объектов.

  • Местоположение, такое как имя страны и описание.

  • Организации в каталоге.

  • Люди в каталоге.

Элемент может принадлежать более чем одному классу. Например, элемент человека определен классом объектов person, но также могут быть определены атрибуты в классах объектов inetOrgPerson, groupOfNames и organization. Структура классов объектов сервера (его схема) определяет общий список требуемых и разрешенных атрибутов отдельного элемента.

Данные каталога представлены в виде пар атрибут-значение. Любая определенная часть информации ассоциируется с этим описательным атрибутом.

Например, атрибут commonName, или cn, используется для размещения имени человека. Человек по имени Jonas Salk может быть представлен в каталоге как

cn: Jonas Salk

Каждый человек, введенный в каталог, определяется набором атрибутов в классе объектов person. Прочие атрибуты этого элемента могут включать:

givenname: Jonas
surname: Salk
mail: jonass@airius.com

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

Разрешенные атрибуты включают атрибуты, которые могут быть представлены в элементах класса объектов. Например, в классе объектов person, обязательны атрибуты cn и sn. Атрибуты description, telephoneNumber, seeAlso, и userpassword разрешены, но не обязательны.

Каждый атрибут имеет соответствующее синтаксическое определение. Синтаксическое определение описывает тип предоставляемой атрибутом информации:

  • bin "binary" двоичный

  • ces "case exact string" строка с соответствием регистра (регистр символов должен совпадать при сравнении)

  • cis "case ignore string" строка с игнорированием регистра (регистр символов игнорируется при сравнении)

  • tel строка с номером телефона (подобен cis но пробелы и тире `- ' игнорируются при сравнении)

  • dn "distinguished name" отличительное имя

Чтобы узнать, где в вашей системе лежат классы объектов и атрибуты, перейдите к первому параграфу "Настройка LDAP сервера"

Установка LDAP сервера

Для установки LDAP сервера необходимо пять шагов: Установить требуемые пакеты (если они еще не установлены), скачать сервер, распаковать программу, настроить Makefile-ы и создать сервер.

Требуемые пакеты

Для полной совместимости с LDAPv3, клиентам и серверу OpenLDAP требуется установка некоторых дополнительных пакетов. В моем случае, я устанавливал OpenLdap v2.0.11 на дистрибутив RedHat 2.2.15. Моей целью было обнаружить, на отсутствие каких пакетов будут жаловаться установочные скрипты. Они не жаловались! Однако это не правило, возможно, для успешного построения OpenLDAP v2.xx вам потребуется получить и установить такие дополнительные пакеты:

библиотеки OpenSSL TLS

Библиотеки OpenSSL TLS обычно входят в состав системы или являются опциональными программным компонентом. Официальный OpenSSL url http://www.openssl.org

Службы аутентификации Kerberos

Клиенты и сервера OpenLDAP поддерживают службы аутентификации на основе Kerberos. В частности, OpenLDAP поддерживает механизм аутентификации SASL/GSSAPI, используя либо пакет Heimdal, либо пакет MIT Kerberos V. Если вы захотите использовать основанную на Kerberos SASL/GSSAPI аутентификацию, вы должны установить либо Heimdal, либо MIT Kerberos V. Heimdal Kerberos доступен по http://www.pdc.kth.se/heimdal. MIT Kerberos доступен по http://web.mit.edu/kerberos/www.

Для использования обеспечиваемых Kerberos служб аутентификации крайне рекомендуется:

Cyrus's Simple Authentication and Security Layer Libraries

Библиотеки Cyrus's SASL обычно входят в состав системы или являются опциональными программными компонентами. Cyrus SASL доступен по http://asg.web.cmu.edu/sasl/sasl-library.html. Cyrus SASL будет использовать библиотеки OpenSSL и Kerberos/GSSAPI, если они предустановленны.

Программы баз данных

Главный механизм работы баз данных в slapd в OpenLDAP - LDBM, для хранения элементов он требует наличия пакета с совместимой базой данных. LDBM совместим с Sleepycat Software BerkeleyDB (рекомендуется) или с Free Software Foundation's GNU Database Manager (GDBM). Если на время конфигурирования ни один из этих пакетов не доступен, вы не сможете построить slapd с поддержкой главного механизма работы с базой данных.

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

BerkeleyDB доступен со страницы Sleepycat Software http://www.sleepycat.com/download.html. Тут доступно несколько версий. На момент написания, рекомендуется последний выпуск версии 3.1.

GDBM доступен со страницы FSF сайта ftp://ftp.gnu.org/pub/gnu/gdbm. На момент написания последняя версия 1.8.

Нити

OpenLDAP предназначен для использования преимущества нитей. OpenLDAP поддерживает POSIX pthreads, Mach CThreads, и множество других разновидностей. Если configure скрипт не найдет подходящей системы нитей, то он будет жаловаться. Если это происходит, проконсультируйтесь с секцией Software - Installation - Platform Hints в OpenLDAP FAQ http://www.openldap.org/faq.

TCP Wrappers

slapd поддерживает TCP wrappers (IP фильтры контроля доступа), если они предустановленны. Для серверов содержащих приватную информацию рекомендуется использование TCP wrappers или других фильтров доступа IP-уровня (таких как предоставляемые IP-firewall).

Загрузка пакета

Есть два свободно распространяемых LDAP сервера: University of Michigan LDAP сервер и OpenLDAP сервер. Также есть Netscape Directory Server, который бесплатен только при определенных условиях (например, образовательные институты получают его бесплатно). Сервер OpenLDAP основан на последней версии сервера University of Michigan и для него доступны списки рассылки и дополнительная информация. Этот документ предполагает, что вы используете сервер OpenLDAP.

Последнюю версию tar.gz можно получить по следующему адресу:

http://www.openldap.org

Если вы хотите получить последнюю версию сервера University of Michigan, сходите по адресу:

ftp://terminator.rs.itd.umich.edu/ldap

Для написания этого документа я использовал версию 2.0.4 пакета OpenLDAP. Моя операционная система- Slackware Linux с ядром 2.2.13.

На сайте OpenLDAP вы всегда можете найти последнюю разрабатываемую и последнюю стабильную версии OpenLDAP сервера. На момент обновления этого документа последняя стабильная версия была openldap-stable-20000704.tgz. Последняя разрабатываемая версия была openldap-2.0.4.tgz.

Настройка программы

Есть несколько опций, которые вы захотите подстроить для получения наилучшей программы для вашего сайта.

Для настройки программы нужно сделать два шага:

  • Отредактировать ldapconfig.h.edit, размещенный в подкаталоге include относительно каталога, где вы распаковали программу.

  • Запустить скрипт configure (если вы крутой парень, то вместо запуска скрипта configure можете отредактировать файл Make-common :^)

В файле include/ldapconfig.h.edit вы можете установить опции расположения демонов slapd и slurpd. Сам файл хорошо комментирован, а его настройки по умолчанию отражают наиболее общие администраторские предпочтения, если вы спешите - можете проскочить этот шаг:

vi include/ldapconfig.h.edit 

Исходный код OpenLDAP сервера поставляется с настроечным скриптом для выбора опций, таких как каталоги установки, флаги компиляции и линковки. В каталоге, где вы распаковали программу, наберите:

./configure --help 
Она напечатает все опции, которые можно подстроить с помощью скрипта configure перед созданием программы. Вот некоторые полезные опции для задания каталогов установки --prefix=pref, --exec-prefix=eprefix и --bindir=dir. Обычно, если вы запускаете configure без опций, он автоматически определяет подходящие настройки и подготавливает построение программы в обычном месте расположения. Так что наберите:
./configure 
И смотрите на выводимую информацию и проверьте, что все прошло хорошо

Построение сервера

После настройки программы вы можете начинать построение. Сначала создайте зависимости командой:

make depend 
После - постройте сервер командой:
make 
Если все прошло гладко - сервер будет создан и настроен. Если нет - вернитесь к предыдущему шагу и пересмотрите конфигурационные настройки. Вы должны проверить специфичные для платформы подсказки, они расположены в doc/install/hints относительно каталога, в котором вы распаковали сервер.

Теперь установите исполняемые файлы и man страницы. Для этого вам нужно быть суперпользователем (в зависимости от того, куда вы устанавливаете файлы):

su 
make install 
Вот и все, теперь у вас есть исполняемый файл сервера и исполняемые файлы некоторых других утилит. Для указаний о настройке и работе LDAP сервера обратитесь к секции
Разд. Настройка LDAP сервера >.

Исполняемый файл OpenLdap 2.0 сервера называется slapd. OpenLdap 2.0 официально был выпущен 30 Августа и охватывал протокол Ldap v3, как определено RFC 2251.

Главные особенности OpenLDAP 2.0 таковы:

  • Поддержка LDAPv2 и LDAPv3 (RFC2251-2256,2829-2831)

  • Поддержка взаимодействия с существующими клиентами

  • поддержка IPv4 и IPv6

  • Strong Autentication (SASL) (RFC2829)

  • Start TLS (RFC2830)

  • Language Tags (RFC2596)

  • Служба расположения основана на DNS (RFC2247+"locate" I-D)

  • Усовершенствованный автономный сервер

  • Named References/ManageDsaIT ("nameref" I-D)

  • Усовершенствованная подсистема контроля доступа

  • Пул нитей

  • Поддержка приоритетов нитей

  • Поддержка множества слушателей

  • LDIFv1 (RFC2849)

  • Усовершенствованное определение платформы/подсистемы

Заметка: На Linux Documentation Project (LDP) существует документ называемый LDAP Implementation HOWTO. Этот документ - великолепный ресурс для тех, что хочет исследовать новые свойства OpenLDAP 2.0. Дата его выпуска где-то Декабрь 2000.

В последней версии OpenLDAP пакета, также возможно проверить созданные исполняемые файлы. Пакет поставляется со скриптом, который можно запустить командой:

make test

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

Настройка LDAP сервера

Как только программа была создана и установлена, вы готовы к ее настройке для использования на вашем сайте. Вся настройка slapd выполняется посредством файла slapd.conf, установленном в каталоге, который вы указали в prefix в конфигурационном скрипте или по умолчанию в /usr/local/etc/openldap.

Эта секция описывает наиболее часто используемые директивы файла slapd.conf. Полный их список смотрите в man станице lapd.conf(5). Директивы конфигурационного файла разделены по категориям: глобальные, специфичные для механизмов баз данных и специфичные для баз данных. Тут вы найдете описание этих директив, и их значения по умолчанию (если они есть), а также примеры их использования.

Формат конфигурационного файла

Файл slapd.conf состоит их трех типов конфигурационной информации: глобальной, специфичной для механизма базы данных, и специфичного для базы данных. Глобальная информация указывается первой, за ней следует информация, связанная с отдельным типом механизма базы данных, за которой следует информация, связанная с отдельным экземпляром базы данных.

Глобальные директивы могут переопределяться в описании механизмов баз данных и/или директивах базы данных. Директивы механизма базы данных могут переопределяться директивами базы данных.

Пустые строки и строки с комментариями, начинающиеся с символа '#' игнорируются. Если строка начинается с пробельного символа, она рассматривается как продолжение предыдущей строки. Общий формат файла slapd.conf таков:

# глобальные конфигурационные директивы
<глобальные конфигурационные директивы>

# определение механизма базы данных
backend <typeA>
<специфичные для механизма базы данных директивы>

# определение базы данных и конфигурационные директивы
database <typeA>
<директивы специфичные для базы данных>

# определение второй базы данных и конфигурационные директивы
database <typeB>
<директивы специфичные для базы данных>

# определение третьей базы данных и конфигурационные директивы
database <typeA>
<директивы специфичные для базы данных>

# последующие механизмы баз данных, определения баз данных и конфигурационные директивы
...

Конфигурационные директивы могут иметь аргументы, в этом случае они разделяются пробельным пространством. Если аргумент содержит пробельные символы, он должен заключаться в кавычки "например так". Если аргумент содержит дойную кавычку или символ обратного слеша `\', символ должен предваряться символом обратного слеша `\'.

Дистрибутив содержит пример конфигурационного файла, который будет установлен в каталог /usr/local/etc/openldap. Примеры файлов содержащих определение схемы (типы атрибутов и классы объектов) находятся в каталоге /usr/local/etc/openldap/schema.

Глобальные директивы

Директивы, описанные в этой секции, применяются ко всем механизмам баз данных и базам данных, если не переопределяются в определениях механизмов баз данных или баз данных. Аргументы, которые необходимо заменить соответствующим текстом, приведены в скобках <>.

access to <что> [ by <кому> <уровень доступа> <control> ]+

Директива предоставляет доступ (указанный в <уровень доступа>) к набору записей и/или 
атрибутов (указанных в <что>) одному или более запрашивающих  (указанных в <кому>). 
Более детальное описание смотрите в примерах контроля доступа.

attributetype <RFC2252 описание типа атрибута>

Эта директива определяет тип атрибута.

defaultaccess { none | compare | search | read | write }

Эта директива указывает доступ по умолчанию для всех запрашивающих, если не указана директива 
access. Любой назначенный уровень доступа включает в себя все нижележащие уровни доступа (например, 
read доступ предполагает также search и compare, но не write).

По-умолчанию:
defaultaccess read

idletimeout <целое число>

Указывает период ожидания в секундах пред принудительным закрытием находящегося в состоянии
ожидания соединения с клиентом. По умолчанию idletimeout равен 0, и это значение отключает 
эту функцию.

include <имя файла>

Эта директива указывает slapd перед чтением следующей строчки конфигурационного файла 
читать дополнительную конфигурационную информацию. Включаемый файл должен быть обычным 
файлом в формате конфигурационного файла slapd. Файл часто используется для включения 
файлов содержащих спецификации схем.

Заметка: вы должны быть осторожны с этой директивой - нет предела числу вложенных директив include, также нет никакого способа обнаружения циклов.

loglevel <целое число>

Эта директива указывает уровень, на котором должны регистрироваться в syslog  отладочные 
сообщения и статистика работы (на данный момент регистрация ведется с помощью  syslogd(8) 
LOCAL4). Чтобы эта функция работала (за исключением двух уровней статистики, которые всегда
включены), вам следует сконфигурировать OpenLDAP с опцией --enable-debug (по умолчанию).
Уровни доступа аддидивны. Для отображения номеров соответствующих определенному типу 
отладочной информации вызовите slapd с ключом -? или сверьтесь со следующей таблицей.
Для <целое число> возможны значения:

-1 включает всю отладочную информацию
0 без отладочной информации
1 трассировать вызовы функций
2 отладка обработки пакетов
4 тщательная отладочная трассировка
8 управление соединением
16 печать принятых и отправленных пакетов
32 обработка фильтра поиска
64 обработка конфигурационного файла
128 обработка списка контроля доступа
256 регистрировать статистику соединения/обработки/результатов
512 регистрировать статистику отправленных элементов 
1024 печать коммуникаций с shell механизмом баз данных 
2048 печать отладки анализа элемента  

Пример: 
loglevel 255 или loglevel -1
Это приведет к занесению в syslog большого количества отладочной информации. 
По умолчанию:
loglevel 256 

objectclass <RFC2252 описание класса объектов>

Эта директива определяет класс объектов.

referral <URI>

Эта директива определяет возвращаемую ссылку в случае, если slapd не может
найти в локальной базе данных информацию для обработки запроса.

Пример:
referral ldap://root.openldap.org

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

sizelimit <целое число>

эта директива указывает максимальное количество элементов возвращаемых одной операцией поиска.

По умолчанию:
sizelimit 500

timelimit <целое число>

Эта директива указывает максимальное число секунд (в реальном времени), которые slapd
затрачивает, отвечая на запрос. Если запрос не завершился за это время, будет возвращен
результат, указывающий на истечение времени.

По умолчанию:
timelimit 3600

Общие директивы базы данных

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

database <тип>

Эта директива отмечает начало нового экземпляра базы данных. 
<тип> должен быть одним из ldbm, shell, passwd, или другим поддерживаемым типом базы данных.

Пример:
database ldbm

Эта запись отмечает определение нового экземпляра базы данных на основе LDBM.

readonly { on | off }

Эта директива переводит базу данных в режим "только-чтение",
Любые попытки модифицировать базу данных вернут ошибку "unwilling to perform".

Пример:
readonly off

replica

replica host=<имя хоста>[:<порт>] [bindmethod={ simple | kerberos | sasl }] ["binddn=<отличительное имя>"] [mech=<механизм>] [authcid=<identity>] [authzid=<identity>] [credentials=<пароль>] [srvtab=<имя файла>]

Эта директива указывает место для репликации базы данных. Параметр
host= указывает хост и опционально порт места нахождения подчиненного экземпляра slapd.
В качестве <имя хоста> может использоваться либо имя домена, либо IP адрес. 
Если <порт> не указан, то используется стандартный для LDAP номер порта (389).

Параметр binddn= указывает отличительное имя для привязки обновлений в подчиненном slapd.
Это должно быть отличительное имя с доступом чтение/запись в подчиненной базе данных slapd
обычно дается как rootdn в конфигурационном файле подчиненного сервера. Оно также должно
соответствовать директиве updatedn в конфигурационном файле подчиненного slapd. 
Так как отличительные имена вероятнее всего содержат пробелы, то вся строка
"binddn=<отличительное имя>" должна заключаться в кавычки.

Атрибут bindmethod - simple, kerberos или sasl, в зависимости от типа используемой для
подключения к подчиненному slapd аутентификации: простая парольная аутентификация,
Kerberos аутентификация или SASL аутентификация.

Не следует использовать парольную идентификацию, если не используется адекватное
обеспечение целостности и конфиденциальности (например, TLS или IPSEC). 
Простая аутентификация требует указания параметров binddn и credentials.

Kerberos аутентификация устарела по сравнению с механизмами SASL 
аутентификации, в частности механизмы KERBEROS_V4 и GSSAPI. Kerberos 
аутентификация требует указания параметров binddn и srvtab.

Рекомендуется использовать SASL аутентификацию. Аутентификация SASL требует 
указания используемого механизма в параметре mech. В зависимости от механизма,
может указываться особенность аутентификации и/или удостоверение, параметрами 
authcid и credentials соответственно. Параметр authcid может использоваться 
для указания особенности аутентификации.

replogfile <имя файла>

Эта директива указывает имя регистрационного файла репликации, в котором slapd 
регистрирует изменения. Регистрационный файл репликации обычно записывается 
slapd и читается slurpd. Обычно эта директива используется только slurpd при
репликации базы данных. Однако вы также можете его использовать для генерации
регистрационной информации транзакции, если slurpd не запущен. В этом случае,
вам будет нужно периодически обрезать этот файл, иначе он чрезвычайно разрастется.

rootdn <отличительное имя>

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

Пример с элементом:
rootdn "cn=Manager, dc=example, dc=com"

Пример с SASL:
rootdn "uid=root@EXAMPLE.COM"

rootpw <пароль>

Эта директива указывает пароль приведенного выше отличительного имени, который будет всегда работать,
не зависимо от того, существует ли элемент с данным отличительным именем и есть ли у него пароль.
Эта директива устарела ввиду SASL аутентификации.

Пример:
rootpw secret

suffix <суффикс отличительного имени>

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

Пример:
suffix "dc=example, dc=com"

Этому отличительному имени будут передаваться запросы, заканчивающиеся на "dc=example, dc=com".

Заметьте: Когда механизму базы данных передается запрос, slapd смотрит на строку суффикса(ов) 
в каждом определении базы данных в порядке их появления в файле. Таким образом, если один 
суффикс базы данных является префиксом для другого, он должен указываться позже в
конфигурационном файле.

updatedn <отличительное имя>

Эта директива применима только к подчиненному slapd. Она указывает отличительное имя,
которому разрешено внесение изменений в реплику. Это может быть отличительное имя, к
которому привязывается slurpd(8) при внесении изменений в реплику или отличительное
имя, ассоциированное с SASL особенностью.

Пример с элементом:
updatedn "cn=Update Daemon, dc=example, dc=com"

Пример с SASL:
updatedn "uid=slurpd@EXAMPLE.COM"

updateref <URL>

Эта директива применима только к подчиненному slapd. Она указывает URL, 
возвращаемый клиентам, которые получают запросы обновления на реплику.
Если она указана несколько раз, то предоставляется каждый URL.

Пример:
update  ldap://master.example.net

Директивы специфичные для LDBM механизма базы данных

Директивы этой категории применимы только к механизму базы данных LDBM. То есть, они должны следовать за строкой "database ldbm" и перед любой другой "database" строкой.

cachesize <целое число>

Эта директива указывает размер поддерживаемого экземпляром механизма базы 
данных LDBM кеша элементов в памяти.

По умолчанию:
cachesize 1000

dbcachesize <целое число>

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

По умолчанию:
dbcachesize 100000

dbnolocking

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

dbnosync

Эта опция приводит к отложенной синхронизации изменений в памяти с содержимым
базы данных на диске. Включение этой опции может увеличить производительность
ценой безопасности данных.

directory <каталог>

Эта директива указывает каталог, в котором находятся файлы, содержащие базу данных LDBM
и связанные с ними индексные файлы.

По-умолчанию:
directory /usr/local/var/openldap-ldbm

index {<список атрибутов> | default} [pres,eq,approx,sub,none]

Эта директива указывает индексы для хранения данных атрибутов. Если указан
только <список атрибутов>, то поддерживаются только индексы по умолчанию.

Пример:
index default pres,eq
index objectClass,uid
index cn,sn eq,sub,approx

Первая строка устанавливает начальный набор поддерживаемых индексов на present 
и equality. Вторая строка приводит к тому, что набор индексов по умолчанию (pres,eq)
поддерживается для objectClass и uid типов атрибутов. Третья строка обозначает 
поддержку индексов equality, substring, и approximate для cn и sn типов атрибутов.

mode <целое число>

Эта директива указывает режим защиты вновь создаваемых индексных файлов базы данных.

По умолчанию:
mode 0600

Примеры контроля доступа

Функции контроля доступа представленные в Разд. Глобальные директивы > очень мощные. В этой секции приводятся примеры их использования. Для начала несколько простых примеров:

access to * by * read 

эта директива дает всем доступ для чтения. Если указана только она, то результат такой же, как и при указании строки defaultaccess.

defaultaccess read 

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

access to dn=".*, o=U of M, c=US" 
by * search 
access to dn=".*, c=US" 
by * read 

Доступ на чтение (read) назначается элементам в поддереве c=US, за исключением элементов в поддереве "o=University of Michigan, c=US", к которым дается доступ на поиск (search). Если сохранен порядок следования этих директив, U-M-специфичная директива никогда не совпадет, так как все U-M элементы являются также c=US элементами.

Следующий пример снова показывает важность порядка следования, как директив доступа, так и выражений "by". Он также показывает использование селектора атрибута для предоставления доступа к указанным атрибутам и различным селекторам <кому>.

access to dn=".*, o=U of M, c=US" attr=homePhone 
by self write 
by dn=".*, o=U of M, c=US" search 
by domain=.*\.umich\.edu read 
by * compare 
access to dn=".*, o=U of M, c=US" 
by self write 
by dn=".*, o=U of M, c=US" search 
by * none 

Этот пример применяется к элементам поддерева "o=U of M, c=US". Сам элемент имеет доступ на запись ко всем атрибутам, кроме homePhone, другие U-M элементы могут выполнять поиск по ним, все остальные не имеют доступа. Атрибут homePhone доступен на запись самому элементу, для поиска прочим U-M элементам, для чтения клиентам, подключающимся из домена umich.edu, и для сравнения всем остальным.

Иногда полезно разрешить отдельному отличительному имени добавлять или удалять самого себя из атрибута. Например, Если вы хотите создать группу и разрешить людям добавлять или удалять только их собственное отличительное имя в атрибуте member, вы могли бы добиться этого с помощью такой access директивы:

access to attr=member,entry 
by dnattr=member selfwrite 

Селектор dnattr <кому> говорит, что доступ применяется к элементам, перечисленным в атрибуте member. Селектор доступа selfwrite говорит, что эти члены могут удалять только их собственное отличительное имя из атрибута, но не другие значения. Добавление элемента атрибута необходимо, так как для доступа к любым атрибутам элемента необходим доступ к элементу.

Обратите внимание, что конструкция attr=member в выражении <что>, является сокращением выражения "dn=* attr=member" (т.е., оно соответствует атрибуту member во всех элементах).

Заметка: Более детальную информацию о контроле доступа в LDAP смотрите в OpenLDAP Administrator's Guide на http://www.openldap.org.

Пример конфигурационного файла

Далее следует пример конфигурационного файла с поясняющими вставками. Он определяет две базы данных для обработки различных частей X.500 дерева; обе являются экземплярами LDBM баз данных. Номера строк приведены только для ссылок и не должны включаться в файл. Во-первых, глобальная конфигурационная секция:

  1.    # пример конфигурационного файла - секция глобальных настроек
  2.    include /usr/local/etc/schema/core.schema
  3.    referral ldap://root.openldap.org
  4.    access to * by * read

Строка 1 - комментарий. Строка 2 включает другой конфигурационный файл, содержащий ядро определения схемы. Директива referral в строке 3 обозначает, что запросы, не относящиеся к определенным ниже локальным базам данных, будут перенаправляться на LDAP сервер на стандартном порту (389) на хосте root.openldap.org.

Строка 4 - глобальный уровень доступа. Она используется только при отсутствии соответствующего уровня доступа к базе данных или если целевой объект не контролируется ни одной базой данных (такой как Root DSE).

Следующая секция конфигурационного файла определяет LDBM механизм базы данных, который будет обрабатывать запросы к "dc=example,dc=com" части дерева. База данных реплицируется на два подчиненных slapd, один на truelies, другой на judgmentday. Для некоторых атрибутов поддерживаются индексы, и атрибут userPassword защищается от несанкционированного доступа.

  5.    # ldbm определение для example.com
  6.    database ldbm
  7.    suffix "dc=example, dc=com"
  8.    directory /usr/local/var/openldap
  9.    rootdn "cn=Manager, dc=example, dc=com"
 10.    rootpw secret
 11.    # директивы репликации
 12.    replogfile /usr/local/var/openldap/slapd.replog
 13.    replica host=slave1.example.com:389
 14.            binddn="cn=Replicator, dc=example, dc=com"
 15.            bindmethod=simple credentials=secret
 16.    replica host=slave2.example.com
 17.            binddn="cn=Replicator, dc=example, dc=com"
 18.            bindmethod=simple credentials=secret
 19.    # определения индексируемых атрибутов
 20.    index uid pres,eq
 21.    index cn,sn,uid pres,eq,approx,sub
 22.    index objectClass eq
 23.    # ldbm определения контроля доступа
 24.    access to attr=userPassword
 25.            by self write
 26.            by anonymous auth
 27.            by dn="cn=Admin,dc=example,dc=com" write
 28.            by * none
 29.    access to *
 30.            by dn="cn=Admin,dc=example,dc=com" write
 31.            by * read

Строка 5 - комментарий. Начало определения базы данных отмечено ключевым словом database в строке 6. Строка 7 указывает суффикс отличительных имен для передаваемых этой базе данных запросов. Строка 8 определяет каталог расположения файлов базы данных.

Строки 9 и 10 идентифицируют элемент "суперпользователя" базы данных и связанный с ним пароль. Этот элемент не подлежит контролю доступа или ограничениям по размеру или времени.

Строки с 11 по 18 для репликации. Строка 12 определяет регистрационный файл репликации (где регистрируются изменения в базе данных - в этот файл пишет slapd, а читает из него slurpd). Строки с 13 по 15 определяют имя и порт реплицируемого хоста, отличительное имя для привязки при выполнении обновлений, метод привязки (simple) и удостоверение подлинности (пароль) для binddn. Строки с 16 по 18 определяют второй сайт репликации.

Строки с 20 по 22 указывают поддерживаемые для различных атрибутов индексы.

Строки с 24 по 31 определяют контроль доступа к элементам базы данных. Во всех элементах атрибут userPassword доступен на запись самому элементу и элементу "admin". Он может использоваться в целях аутентификации/авторизации, но во всех остальных случаях он не доступен для чтения. Все остальные атрибуты доступны для записи элементу "admin" и могут быть считаны аутентифицированными пользователями.

Следующая секция примера конфигурационного файла определяет другую LDBM базу данных. Она обрабатывает запросы, относящиеся к поддереву dc=example,dc=net. Обратите внимание, что в строке 37, из-за глобального правила доступа в строке 4, должен быть разрешен доступ на чтение.

 32.    # ldbm определение example.net
 33.    database ldbm
 34.    suffix "dc=example, dc=net"
 35.    directory /usr/local/var/ldbm-example-net
 36.    rootdn "cn=Manager, dc=example, dc=com"
 37.    access to * by users read

Запуск LDAP сервера

slapd разработан для запуска в качестве одиночного сервера. Это позволяет серверу получать преимущество от кэширования, управлять вопросами параллельной работы с нижележащими базами данных, и сберегать системные ресурсы. Запуск из inetd(8) НЕ ВОЗМОЖЕН.

Ключи командной строки

slapd поддерживает несколько описанных в руководстве ключей командной строки. Эта секция описывает несколько часто используемых ключей:

-f <имя файла>

Этот ключ указывает альтернативный файл конфигурации slapd. По умолчанию он
/usr/local/etc/openldap/slapd.conf.

-h <URL>

Этот ключ определяет конфигурацию слушателя. По умолчанию ldap:/// что подразумевает LDAP поверх TCP
на всех интерфейсах на порту по умолчанию для LDAP 389. Вы можете указать пару хост-порт или другие
схемы протокола (например,  ldaps:// или ldapi://). Например, -h "ldaps:// ldap://127.0.0.1:667"
приведет к созданию двух слушателей: один - LDAP поверх SSL на всех интерфейсах на порту по 
умолчанию LDAP/SSL 636, и другой - LDAP поверх TCP на локальном узле (петлевом интерфейсе) на порту
667. Хост можно указывать в форме IPv4 чисел разделенных точками или в форме имени хоста.
Значение номера порта должно быть числом.

-n <имя службы>

Этот ключ определяет имя службы используемой для регистрации и других целей.
Служба по умолчанию - slapd.

-l <локальный пользователь syslog>

Этот ключ определяет локального пользователя для функции syslog(8). Допустимы значения
LOCAL0, LOCAL1, LOCAL2, ..., и LOCAL7. По умолчанию LOCAL4.
Эта опция может не поддерживаться всеми системами.

-u пользователь -g группа

Этот ключ определяет пользователя и группу, соответственно,
от чьего имени происходит запуск программы. 
Пользователь может быть либо именем, либо uid. Группа может быть
либо именем группы, либо gid.

-r каталог

Этот ключ определяет каталог запуска. После открытия слушателей, но до чтения
каких-либо конфигурационных файлов или инициализации механизмов баз данных,
slapd выполнит для этого каталога chroot(2).

-d <уровень> | ?

Этот ключ устанавливает slapd уровень отладки на значение <уровень>.
Если уровень - символ `?', выводятся различные уровни отладки, и slapd завершается,
вне зависимости от любых других приложенных ключей.
Текущие уровни отладки:

-1  включает всю отладочную информацию  
0  без отладки  
1  трассировать вызовы функций  
2  отладка обработки пакетов  
4  тщательная отладочная трассировка
8  управление соединением  
16  печать принятых и отправленных пакетов
32  обработка фильтров поиска 
64  обработка конфигурационного файла
128  обработка списка контроля доступа
256  регистрировать статистику соединения/обработки/результатов
512  регистрировать статистику отправленных элементов
1024  печать коммуникаций с shell механизмом базы данных  
2048  печать отладки анализа элемента  

Вы можете активировать несколько уровней, указав по одному отладочному уровню в каждом ключе. 
Или, так как уровни отладки аддидивны, вы можете вычислить число самостоятельно. То есть, если вы
хотите трассировать вызовы функций и видеть обработку конфигурационного файла, вы можете установить
уровень в сумму их значений (в данном, случае, -d 65). Либо вы можете заставить slapd выполнить 
сложение (например -d 1 -d 64). Более подробную информацию ищите в <ldap.h>.

Заметка: для вывода какой-либо отладочной информации, кроме двух уровней статистики доступных 
по умолчанию, slapd должен быть откомпилирован с  -DLDAP_DEBUG. 

Создание и поддержание базы данных

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

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

Создание базы данных в реальном времени

Программный пакет OpenLDAP поставляется с утилитой ldapadd, которая используется для добавления записей при запущенном LDAP сервере. Если вы выбрали создание базы данных в реальном времени, вы можете использовать ldapadd для добавления элементов. После первичного добавления элементов, вы все еще можете использовать ldapadd для добавления элементов. Перед запуском sldap Вы должны проверить, что в вашем файле sldap.conf установлены следующие конфигурационные опции:

suffix <отличительное имя>

Как описано в Разд. Настройка LDAP сервера >, эта опция указывает, какие элементы помещены в этой базе данных. Вы должны ее установить в значение отличительного имени корня поддерева, которое вы собираетесь создать. Например:

suffix "o=TUDelft, c=NL"

Вы должны проверить, что указали каталог, где должны быть созданы индексные файлы:

directory <каталог>

Например:

directory /usr/local/tudelft

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

rootdn <отличительное имя>

rootpw <passwd> /* Не забудьте тут используется crypto или SHA пароль!!! */

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

Если вы используете SASL механизм аутентификации LDAP, строку rootpw можно отбросить. Более подробную информацию ищите в секциях Настойка LDAP и Аутентификация.

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

index {<attrlist> | default} [pres,eq,approx,sub,none]

Например, для индексации атрибутов cn, sn, uid и objectclass можно использовать следующие строки конфигурации индексов.

index cn,sn,uid

index objectclass pres,eq

index default none

Как только вы все настроили по вашему вкусу, запустите slapd, подключитесь с помощью вашего любимого LDAP клиента, и начните добавлять элементы. Например, для добавления с помощью утилиты ldapadd элемента TUDelft и следующего за ним элемента Postmaster, вы можете создать файл /tmp/newentry с таким содержимым:

o=TUDelft, c=NL 
objectClass=organization 
description=Technical University of Delft Netherlands 

cn=Postmaster, o=TUDelft, c=NL 
objectClass=organizationalRole 
cn=Postmaster 
description= TUDelft postmaster - postmaster@tudelft.nl 

и затем использовать подобную команду для создания элемента:

ldapadd -f /tmp/newentry -D "cn=Manager, o=TUDelft, c=NL" -w secret 

Вышеприведенная команда предполагает, что у вас rootdn установлен в "cn=Manager, o=TUDelft, c=NL" а rootpw в "secret". Если вы хотите набирать пароль в командной строке, используйте опцию -W в команде ldapadd вместо -w "password". Вам будет выдано приглашение к вводу пароля:

ldapadd -f /tmp/newentry -D "cn=Manager, o=TUDelft, c=NL" -W 
Enter LDAP Password: 

Автономное создание базы данных

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

suffix <отличительное имя>

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

suffix "o=TUDelft, c=NL"

Вы должны проверить, что вы указали каталог, где должны быть созданы индексные файлы:

directory <каталог>

Например:

directory /usr/local/tudelft

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

dbcachesize <целое число>

Например:

dbcachesize 50000000

Будет создан 50 Мб кеш, он достаточно велик (на University of Michigan, база данных содержит около 125Кб элементов, и наибольший индексный файл около 45 Мб). Немного поэкспериментируйте с этим значением, и параллельно (объясняется ниже) посмотрите, как работает ваша система. Помните о необходимости вернуть это значение обратно после создания индексных файлов и до запуска slapd.

В конце, в нужно указать какие индексы вы хотите создать. Это делается одной или более опциями.

index {<attrlist> | default} [pres,eq,approx,sub,none]

Например:

index cn,sn,uid pres,eq,approx

index default none

Буду созданы индексы presence, equality и approximate для атрибутов cn, sn, и uid, а для других атрибутов не будет создано никаких индексов. Более подробную информацию смотрите в конфигурационном файле Разд. Настройка LDAP сервера >.

Как только вы настроили все, как хотели, вы создаете первичную базу данных и ассоциированные индексы программой slapadd(8):

slapadd -l <входной файл> -f <конфигурационный файл slapd> [-d <уровень отладки>] [-n <целое число>|-b <суффикс>]

Аргументы имеют следующее значение:

-l <входной файл>

Определяет входной LDIF файл, содержащий добавляемые элементы в текстовой форме (Взгляните на следующую секцию).

-f <конфигурационный файл slapd>

Указывает конфигурационный файл slapd, в котором определено: где создавать индексы, какие индексы создавать и т.п.

-d <уровень отладки>

Включает отладку, в соответствии с <уровень отладки>. Уровни отладки такие же, как и для slapd. Смотрите секцию Разд. Ключи командной строки > в части запуск slapd.

-n <номер базы данных>

Необязательный аргумент указывает, какую базу данных модифицировать. Первая по списку база данных в конфигурационном файле считается 1, вторая - 2, и т.д. По умолчанию, используется первая ldbm база данных в конфигурационном файле. Не должен использоваться вместе с ключом -b.

-b <суффикс>

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

Иногда возникает необходимость перегенерировать индексы (например, после модификации slapd.conf(5)). Это можно сделать используя, программу slapindex(8). slapindex вызывается так:

slapindex -f <конфигурационный файл slapd> [-d <уровень отладки>] [-n <номер базы данных>|-b <суффикс>]

Где ключи -f, -d, -n и -b такие же, как и для программы slapadd(1). slapindex перестраивает все индексы, основываясь на текущем содержимом базы данных.

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

slapcat -l <filename> -f <slapdconfigfile> [-d <debuglevel>] [-n <databasenumber>|-b <suffix>]

где -n или -b выбирают базу данных в файле slapd.conf(5) указанном в ключе -f. Соответствующий LDIF вывод пишется в стандартный вывод или файл указанный ключом -l.

Подробнее о LDIF формате

LDAP Data Interchange Format (LDIF) используется для представления элементов LDAP в простом текстовом формате. Базовый формат элемента таков:

#комментарий 
dn: <отличительное имя> 
<attrdesc>: <значение атрибута> 
<attrdesc>: <значение атрибута> 
... 

Строки, начинающиеся с символа '#', являются комментариями. Описание атрибута (attrdesc) может быть простым типом атрибута как, например, cn или objectClass или 1.2.3 (OID ассоциированный с типом атрибута) или может включать опции, такие как cn;lang_en_US или userCertificate;binary.

Строка может продолжаться на следующей строке с отступом в один пробел или символ табуляции. Например:

dn: cn=Barbara J Jensen, dc=example, dc=
 com
cn: Barbara J
    Jensen

эквивалентно:

dn: cn=Barbara J Jensen, dc=example, dc=com
cn: Barbara J Jensen

Несколько значений атрибутов разделяются на строки, например:

cn: Barbara J Jensen
cn: Babs Jensen

Если <значение атрибута> содержит непечатные символы или начинается с пробела, двоеточия (':'), или знака меньше ('<'), то <attrdesc> завершенное двумя двоеточиями, за которым следует значение, закодированное в base64. Например, значение " begins with a space" будет закодировано так:

cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=

Также вы можете указать URL содержащий значение атрибута. Например, следующая запись определяет, что значение jpegPhoto должно быть получено из файла /path/to/file.jpeg.

cn:< file://path/to/file.jpeg
Несколько элементов в одном LDIF файле разделяются пустыми строками. Вот пример LDIF файла содержащего три элемента.
# Элемент Barbara
dn: cn=Barbara J Jensen, dc=example, dc=com
cn: Barbara J Jensen
cn: Babs Jensen
objectClass: person
sn: Jensen

# элемент Bjorn
dn: cn=Bjorn J Jensen, dc=example, dc=com
cn: Bjorn J Jensen
cn: Bjorn Jensen
objectClass: person
sn: Jensen
# закодированная в Base64 фотография в JPEG
jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD
A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ
ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG

# элемент Jennifer
dn: cn=Jennifer J Jensen, dc=example, dc=com
cn: Jennifer J Jensen
cn: Jennifer Jensen
objectClass: person
sn: Jensen
# JPEG фотография в файле
jpegPhoto:< file://path/to/file.jpeg

Заметьте, что jpegPhoto в элементе Bjorn закодировано в base 64, а jpegPhoto в элементе Jennifer берется по месту указания URL.

Завершающие пробелы не обрезаются от значений в LDIF файле. А также не сжимаются повторяющиеся множественные пробелы. Если вы не хотите, чтобы они были в ваших данных, не ставьте их.

Утилиты ldapsearch, ldapdelete и ldapmodify

ldapsearch это - интерфейс shell к библиотечному вызову ldap_search(3). Используйте эту утилиту для поиска элементов в вашем LDAP механизме базы данных.

Далее следует синтаксис вызова ldapsearch (чтобы узнать, что обозначает каждый ключ, загляните в man страницу ldapsearch):

ldapsearch  [-n]  [-u]  [-v]  [-k]  
[-K]  [-t]  [-A] [-B] [-L] 
[-R] [-d уровень отладки] [-F sep] [-f файл] 
[-D binddn]  [-W]  [-w bindpasswd]  
[-h ldaphost]  [-p ldapport]   [-b основание поиска]   
[-s base|one|sub] 
[-a never|always|search|find] [-l timelimit] 
[-z sizelimit] filter [attrs...] 

ldapsearch открывает соединение с сервером LDAP, присоединяется, и выполняет поиск с фильтром filter. Фильтр должен соответствовать строковому представлению фильтров LDAP, как определено в RFC 1558. Если ldapsearch находит один или более элементов, то извлекаются атрибуты, указанные в attrs, элементы и их значения печатаются в стандартный вывод. Если attrs не указан, возвращаются все атрибуты.

Вот несколько примеров использования ldapsearch:

ldapsearch -b 'o=TUDelft,c=NL' 'objectclass=*' 

ldapsearch -b 'o=TUDelft,c=NL' 'cn=Rene van Leuken' 

ldasearch -u -b 'o=TUDelft,c=NL' 'cn=Luiz Malere' sn mail 

Ключ -b определяет основание поиска (начальную точку поиска), а ключ -u указывает выводить информацию в понятном для пользователя виде.

ldapdelete это - shell интерфейс к библиотечному вызову ldap_delete(3). Эта утилита используется для удаления элементов из вашего LDAP механизма базы данных.

Синтаксис вызова ldapdelete таков (что означает каждый ключ можно найти в man странице ldapdelete):

ldapdelete   [-n]   [-v]  [-k]  [-K]  
[-c]  [-d уровень отладки]  [-f файл]  [-D binddn]  
[-W]  [-w пароль] [-h ldaphost] [-p ldapport] 
[dn]... 

ldapdelete открывает соединение к LDAP серверу, подключается и удаляет один или более элементов. Если приложен один или более dn аргумент, элементы с этим отличительными именами будут удалены. Каждое отличительное имя должно быть строковым представлением отличительного имени в соответствии с RFC 1779. Если вызов был сделан без аргументов, список отличительных имен читается со стандартного ввода (или из файла указанного ключом -f).

Вот несколько примеров использования ldapdelete:

ldapdelete 'cn=Luiz Malere,o=TUDelft,c=NL' 

ldapdelete -v 'cn=Rene van Leuken,o=TUDelft,c=NL' -D 'cn=Luiz Malere,o=TUDelft,
c=NL' -W 

Ключ -v обозначает многословный режим, ключ -D обозначает Binddn (отличительное имя для аутентификации), а ключ -W обозначает запрашивать пароль.

ldapmodify это - shell интерфейс к библиотечным вызовам ldap_modify(3) и ldap_add(3). Эта утилита используется для изменения содержимого элементов вашего LDAP механизма баз данных.

Синтаксис вызова ldapmodify таков (что обозначает каждый ключ можно посмотреть в man странице ldapmodify):

ldapmodify   [-a]  [-b]  [-c]  [-r]  
[-n]  [-v]  [-k]  [-d уровень отладки]  
[-D binddn]  [-W]  [-w пароль] 
[-h ldaphost] [-p ldapport] [-f файл] 

ldapadd [-b] [-c] [-r] [-n] 
[-v]  [-k]  [-K]  [-d уровень отладки]  
[-D binddn]  [-w пароль]  [-h ldaphost] 
[-p ldapport] [-f файл] 

ldapadd - это просто жесткая ссылка на утилиту ldapmodify. При вызове ldapadd автоматически включается ключ -a (добавить элемент) утилиты ldapmodify.

ldapmodify открывает соединение к LDAP серверу, подключается, изменяет или добавляет элементы. Информация об элементах читается из стандартного ввода или из файла указываемого ключом -f.

Вот несколько примеров использования ldapmodify:

Предполагается, что файл /tmp/entrymods существует и содержит следующее:

dn: cn=Modify Me, o=University of Michigan, c=US 
changetype: modify 
replace: mail 
mail: modme@terminator.rs.itd.umich.edu 
- 
add: title 
title: Grand Poobah 
- 
add: jpegPhoto 
jpegPhoto: /tmp/modme.jpeg 
- 
delete: description 
- 

Команда:

ldapmodify -b -r -f /tmp/entrymods 

заменит содержимое атрибута mail элемента "Modify Me" на значение "modme@terminator.rs.itd.umich.edu", добавит заголовок "Grand Poobah", и содержимое файла /tmp/modme.jpeg в jpegPhoto, а также полностью удалит атрибут description.

Аналогичные вышеприведенным изменения можно выполнить, используя старый формат ввода ldapmodify:

cn=Modify Me, o=University of Michigan, c=US 
mail=modme@terminator.rs.itd.umich.edu 
+title=Grand Poobah 
+jpegPhoto=/tmp/modme.jpeg 
-description 

И еще одна команда:

ldapmodify -b -r -f /tmp/entrymods 

Предполагается, что файл /tmp/newentry существует и содержит следующее:

dn: cn=Barbara Jensen, o=University of Michigan, c=US 
objectClass: person 
cn: Barbara Jensen 
cn: Babs Jensen 
sn: Jensen 
title: the world's most famous manager 
mail: bjensen@terminator.rs.itd.umich.edu 
uid: bjensen 

Команда:

ldapadd -f /tmp/entrymods 

добавит элемент с отличительным именем: cn=Barbara Jensen, o=University of Michigan, c=US, если он еще не существует. Если элемент с таким отличительным именем уже существует, команда укажет на ошибку и не заменит содержимое элемента.

Предполагается, что файл /tmp/newentry существует и содержит:

dn: cn=Barbara Jensen, o=University of Michigan, c=US 
changetype: delete 

Команда:

ldapmodify -f /tmp/entrymods 

удалит элемент Babs Jensen.

Ключ -f определяет файл (читать информацию о изменениях из файла, а не из стандартного ввода), ключ -b обозначает двоичный режим (любые значения начинающиеся с '/' во входном файле интерпретируются как двоичные), ключ -r обозначает заменять (по умолчанию заменять существующие значения)

Дополнительная информация и свойства

В этой секции вы найдете информацию о Netscape Address Book - LDAP клиенте, который можно использовать для доступа к вашему каталогу. Также представлены детали реализации роуминга используя Netscape Navigator, версии 4.5 или выше и ваш LDAP сервер. Цель описания этих свойств - дать людям понятие о возможностях LDAP протокола. В конце вы увидите некоторую информацию о аутентификации с использованием LDAP, утилитах миграции на LDAP, графических утилитах для LDAP, системе регистрации slapd и безопасном завершении процесса slapd.

Роуминг

Цель роуминга в том, что где бы вы ни находились в сети, вы сможете получить ваши записные книжки, предпочтения, почтовые фильтры, и т.д. используя Netscape Navigator и LDAP сервер. Это очень хорошая функция. Представьте, что вы получили доступ к Web, у вас могут быть свои собственные настройки броузера. Если путешествуете и вам нужен доступ к сайту с котировками в вашей локальной записной книжке, не беспокойтесь. Загрузите записную книжку и прочие конфигурационный файлы на LDAP сервер, позже вы их сможете получить, не зависимо от места вашего нахождения.

Для реализации роуминга вам следует сделать следующие шаги:

  • Включить новый файл схемы в ваш конфигурационный файл slapd.conf

  • Установить поле модификации в секции database вашего конфигурационного файла slapd.conf

  • Изменить ваш Ldif файл, добавив элементы профилей пользователей, которые хотят использовать роуминг

  • Настроить Netscape Navigator для использования LDAP сервера в качестве Roaming Access Server

  • Перезапустите LDAP сервер с новыми установками.

- Включение нового файла схемы: Скопируйте ниже приведенную секцию и вставьте ее в файл с расширением .schema Обычно лучше всего сохранить его в каталоге /usr/local/etc/openldap/schema. Если хотите, файл можно загрузить с: http://home.kabelfoon.nl/~hvdkooij/mull.schema. Помните, что ваш slapd.conf файл должен включать определение core.schema файла, используйте строку:

include /usr/local/etc/schema/core.schema

#       Эта схема требует загрузки core schema

# Используется для размещения информации Netscape Roaming Profile в OpenLDAP v2.
# Помещает фактическое имя профиля в базу данных.
attributeType ( 1.3.6.1.4.1.7081.1.1.1
         NAME 'nsLIProfileName'
         DESC 'Store Netscape Roaming Profile name'
         EQUALITY caseIgnoreMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# Используется для размещения Netscape Roaming Profile информации в OpenLDAP v2.
attributeType ( 1.3.6.1.4.1.7081.1.1.2
         NAME 'nsLIPrefs'
         DESC 'Store Netscape Roaming Profile preferences'
         EQUALITY caseExactIA5Match
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

# Используется для размещения Netscape Roaming Profile информации в OpenLDAP v2.
attributeType ( 1.3.6.1.4.1.7081.1.1.3
         NAME 'nsLIElementType'
         DESC ''
         EQUALITY caseIgnoreMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# Используется для помещения Netscape Roaming Profile информации в OpenLDAP v2.
attributeType ( 1.3.6.1.4.1.7081.1.1.4
         NAME 'nsLIData'
         DESC 'Store the actual data blocks'
         EQUALITY bitStringMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )

# Используется для размещения Netscape Roaming Profile информации в OpenLDAP v2.
attributeType ( 1.3.6.1.4.1.7081.1.1.5
         NAME 'nsLIVersion'
         DESC 'Store Netscape Roaming Profile version'
         EQUALITY integerMatch
         SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )

# Используется для размещения Netscape Roaming Profile информации в OpenLDAP v2.
# Это базовый holder of the Roaming Profile и он должен быть создан перед
# тем, как вы попытаетесь занести информацию в LDAP базу данных
objectClass ( 1.3.6.1.4.1.7081.1.2.1
         NAME 'nsLIProfile'
         DESC 'Base holder of the NetScape Roaming Profile'
         SUP top
         MUST ( objectClass $ nsLIProfileName )
         MAY ( nsLIPrefs $ uid $ owner )
         )

# Используется для размещения Netscape Roaming Profile информации в OpenLDAP v2.
# Этот класс объектов будет хранить данные.
objectClass ( 1.3.6.1.4.1.7081.1.2.2
         NAME 'nsLIProfileElement'
         DESC 'Contains the actual Roaming Profile data'
         SUP top
         MUST ( objectClass $ nsLIElementType )
         MAY ( owner $ nsLIData $ nsLIVersion )
         )

# Конец файла 

- Установка поля модификации: Чтобы убедиться, что Netscape может сравнивать вашу локальную копию с копией данных профиля на сервере LDAP, вам нужно установить время модификации в базе данных. Будет достаточно добавить простую строку в database секции вашего файла slapd.conf. Просто добавьте:

lastmod on

- Изменение вашего Ldif файла: Каждому пользователю, который желает использовать роуминг в Netscape, нужен элемент профиля в файле Ldif. Взгляните на пример простого LDIF файла с элементами профилей:

dn: o=myOrg,c=NL 
o: myOrg 
objectclass: organization 

dn: cn=seallers,ou=People,o=myOrg,c=NL 
cn: seallers 
userpassword: myPassword 
objectclass: top 
objectclass: person 

dn: nsLIProfileName=seallers,ou=Roaming,o=myOrg,c=NL 
nsLIProfileName: seallers
owner: cn=seallers,ou=People,o=myOrg,c=NL 
objectclass: top 
objectclass: nsLIProfile 

Эти элементы можно добавить, используя программу Разд. Утилиты ldapsearch, ldapdelete и ldapmodify >. Возможно в вашем случае вам потребуется только добавить элемент соответствующий перемещаемому профилю (dn: nsLIProfileName=...).

- Настройка Netscape Navigator: Следующий шаг - настроить Netscape на ваш LDAP сервер для активации роуминга. Просто выполните последовательность:

Войдите в меню Edit => Preferences => Roaming User

Теперь вам следует активировать Roaming Access для этого профиля, щелкнув на кнопку соответствующую этой опции.

Заполните поле имени пользователя соответствующим значением, оно должно быть идентично полю nsLIProfileName= из элемента профиля пользователя из LDIF профиля. Пример: seallers

Для просмотра опций роуминга переместитесь стрелкой вниз на опцию Roaming User в левой стороне окна Preferences Window.

Щелкните на Server Information, активируйте LDAP Server и заполните поля следующей информацией:

Address: ldap://myHost/nsLIProfileName=$USERID,ou=Roaming,o=myOrg,c=NL 

User DN: cn=$USERID,ou=People,o=myOrg,c=NL

ВНИМАНИЕ: Перед запуском броузера Netscape автоматически заменяет переменную $USERID на имя выбранного профиля. Так если вы выбрали профиль seallers, он изменит $USERID на seallers, если вы выбрали профиль gonzales, он изменит $USERID на gonzales. Если вы не знакомы с профилями, запустите приложение Profile Manager, которое поставляется в наборе Netscape Comunicator. Это приложение разработано для обслуживания нескольких пользователей броузера на одной машине, и каждый из них имеет собственные настройки броузера.

И финальный шаг - перезапуск сервера. Посмотрите секцию Разд. Завершение LDAP сервера > для понимания того, как его безопасно остановить и Разд. Запуск LDAP сервера > как его снова запустить.

Адресная книга Netscape

Как только вы запустили LDAP сервер, вы можете получить к нему доступ из различных клиентов (например, утилиты командной строки ldapsearch). Очень интересный клиент - Netscape Address Book. Он доступен в 4.x версии Netscape, но для стабильной работы с LDAP сервером вам следует использовать версию 4.5 или выше.

Просто выполните последовательность:

Откройте Netscape Navigator -> Выберите Communicator Menu -> Address Book

Будет запущена Netscape Address Book с некоторыми LDAP каталогами по умолчанию. Вам следует добавить ваш собственный LDAP каталог тоже!

Выберите File Menu -> New Directory

Заполните поля с информацией о сервере. Например:

- Description: TUDelft

- LDAP Server: dutedin.et.tudelft.nl

- Server Root: o=TUDelft, c=NL

По умолчанию LDAP порт - 389. Не изменяйте его, если вы не меняли эту опцию при создании сервера.

Теперь, сделайте несколько простых запросов к вашему серверу, используя поле Show Names Containing, или расширенных запросов используя кнопку Search.

Утилиты миграции LDAP

Утилиты миграции LDAP - коллекция Perl скриптов от PADL Software Ltd. Они используются для преобразования конфигурационных файлов в LDIF. Перед их использованием я рекомендую прочесть лицензионное соглашение. Если вы планируете использовать ваш сервер для аутентификации пользователей, то эти утилиты могут быть очень полезны. Используя утилиты миграции для преобразования ваших NIS или файлов паролей в LDIF формат, создаются файлы совместимые с вашим LDAP сервером. Эти Perl скрипты применимы для миграции с ваших users, groups, aliases, hosts, netgroups, networks, protocols, RPC и существующих служб имен (NIS, файлы и NetInfo) в LDIF формат.

Для загрузки утилит миграции LDAP и получения более подробной информации, посетите следующий адрес:

http://www.padl.com/tools.html

Пакет поставляется с файлом README, а имена файлов скриптов интуитивны. Сначала взгляните на файл README, а затем начните применять скрипты.

Аутентификация с помощью LDAP

Для доступа к службе LDAP, LDAP клиент должен себя аутентифицировать в службе. То есть, он должен сообщить LDAP серверу кто пытается получить доступ к данным, и сервер может решить, что клиенту разрешено видеть и делать. Если клиент успешно проходит аутентификацию на LDAP сервере, то далее при получении запроса от клиента, он проверит, разрешено ли клиенту выполнять запрос. Этот процесс называется контролем доступа.

В LDAP, аутентификация производится в операции "привязки". Ldapv3 поддерживает три типа аутентификации: анонимную, простую и SASL аутентификацию. Клиент, который посылает LDAP запросы без выполнения "привязки", рассматривается как анонимный клиент. Простая аутентификация состоит в отправке LDAP сервер полного отличительного имени клиента (пользователя) и клиентского пароля прямым текстом. Этот механизм имеет проблему безопасности, так как пароль может быть прочитан по сети. Для избежания раскрытия пароля таким способом, вы можете использовать механизм аутентификации по шифрованному каналу (например, SSL), который поддерживается LDAP сервером.

Наконец, SASL - Simple Authentication and Security Layer (RFC 2222). Он определяет протокол вызов-ответ, в котором клиент и сервер обмениваются данными с целью аутентификации и установления уровня безопасности, на котором происходит дальнейшая коммуникация. Используя SASL, LDAP может поддерживать любой тип аутентификации согласованный между LDAP клиентом и сервером. Использование SASL будет представлено в следующей версии этого Howto, так как установка библиотеки Cyrus SASL пока не тривиальна.

И еще о аутентификации пользователей для доступа к информации вашего дерева каталога, ваш LDAP сервер может аутентифицировать пользователей также и из других служб (Sendmail, Login, Ftp, и т.п.). Это достигается перемещением определенной информации о пользователе на ваш LDAP сервер и использованием механизма под названием PAM (Pluggable Authentication Module).

Изначально в UNIX, аутентификация пользователя выполнялась посредством ввода пользователем пароля, система проверяла соответствие пароля зашифрованному официальному, паролю, хранимому в /etc/passwd. Это было сначала. С тех пор, приобрели популярность большое количество методов аутентификации, включая более усложненные замены файла /etc/passwd и аппаратные устройства называемые Smart картами. Проблема в том, что при разработке каждой новой схемы аутентификации, требуется внесения изменений во все необходимые программы (login, ftpd и т.п.). PAM обеспечивает способ разработки программ, которые не зависят от схемы аутентификации. Эти программы для работы требуют подключения к ним "модулей аутентификации" во время работы.

Модуль аутентификации для LDAP доступен в виде tar файла исходного кода по следующему адресу:

http://www.padl.com/pam_ldap.html

Далее я полагаю, что ваш дистрибутив Linux уже подготовлен к работе с PAM. Если нет - взгляните на этот URL: http://www.kernel.org/pub/linux/libs/pam. Различные поставщики Linux используют различные стандарты настроек имеющих отношение к PAM. Обычно, конфигурационные файлы PAM размещены в каталоге /etc/pam.d/. Тут вы можете найти файл для каждой вашей запущенной службы. Например, если вы хотите использовать LDAP сервер для регистрации пользователей после загрузки Linux, вы должны сделать ваш Linux PAM совместимым (как описано в начале этого параграфа), установить LDAP PAM модуль и отредактировать файл с именем login в конфигурационном каталоге PAM (/etc/pam.d/) следующим содержимым :

#%PAM-1.0
auth       required     /lib/security/pam_securetty.so
auth       required     /lib/security/pam_nologin.so
auth       sufficient   /lib/security/pam_ldap.so
auth       required     /lib/security/pam_unix_auth.so try_first_pass
account    sufficient   /lib/security/pam_ldap.so
account    required     /lib/security/pam_unix_acct.so
password   required     /lib/security/pam_cracklib.so
password   required     /lib/security/pam_ldap.so
password   required     /lib/security/pam_pwdb.so use_first_pass
session    required     /lib/security/pam_unix_session.so

Службы регистрации

Для генерирования регистрационной информации slapd использует syslog(8). Пользователь по умолчанию в syslog(8) называется LOCAL4, но также допустимы значения от LOCAL0, LOCAL1, до LOCAL7.

Для активации системы регистрации вам следует отредактировать ваш syslog.conf файл, обычно размещенный в каталоге /etc.

Создайте такую строку:

local4.*=====/usr/adm/ldalog

Она приведет к использованию пользователя по умолчанию LOCAL4 в syslog. Если вы не знакомы с синтаксисом этой строки, загляните в man страницу syslog, syslog.conf и syslogd. Если вы хотите изменить пользователя по умолчанию или указать уровень генерируемой регистрационной информации, вам потребуются следующие ключи запуска slapd:

-s уровень-syslog Этот ключ указывает slapd на каком уровне отладки должны регистрироваться выражения в syslog(8). Уровень описывает серьезность сообщения и должен быть одним из следующих ключевых слов из списка (от высшего к низшему): emerg, alert, crit, err, warning, notice, info, and debug. Пример: slapd -f myslapd.conf -s debug

-l локальный-пользователь-syslog Выбирает локального пользователя syslog(8). Возможны значения LOCAL0, LOCAL1, и так далее до LOCAL7. По умолчанию - LOCAL4. Однако, эта опция допускается только на системах, которые поддерживают пользователей в syslog(8).

Теперь просмотрите сгенерированную регистрационную информацию. Она окажет вам огромную помощь при разрешении проблем с запросами, обновлениями, привязкой, и т.п.

Ссылки

В этой главе вы найдете дополнительную документацию по LDAP: полезные URL, хорошие книги и RFC определения.

[Источник: linux-ve.net]

[ опубликовано 12/06/2003 ]

Luiz Ernesto Pinheiro Malere (malere@yahoo.com). - LDAP Linux HOWTO   Версия для печати