Глава 5. Примеры OpenLDAP

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

В этом разделе мы возьмём за основу реализацию отдельно стоящего каталога LDAP и будем последовательно, шаг за шагом, её совершенствовать.

Перед тем, как начать — если Вы ещё не обзавелись LDAP-браузером, сделайте это сейчас. Open Source предоставляет таковых с избытком. LDAP-браузер — это специализированный LDAP-клиент, позволяющий, в общем случае, получать доступ и исследовать LDAP-каталог. Это бесценный инструмент. Без него Вы слепы. Как минимум, LDAP-браузер должен быть способен производить подключения — либо анонимно, либо используя указанный DN, экспортировать LDIF-файлы и выполнять поиск. Если же он может ещё и добавлять записи и атрибуты, а также импортировать данные из LDIF-файлов — это вообще прекрасно. Если Вы мазохист, можете, конечно, использовать утилиты командной строки, такие как ldapadd и ldapsearch. Но ведь можно найти и более действенные способы удовлетворения своей страсти — побиться головой о стену, например. В любом случае, выбор полностью за Вами.

Содержание

5.1 Простой каталог

5.1.1 Проектирование DIT
5.1.2 Выбор структурного объектного класса
5.1.3 Файл slapd.conf
5.1.4 Файл LDIF
5.1.5 Загрузка LDIF-файла
5.1.6 Добавление записей с помощью LDIF
5.1.7 Изменение записей с помощью LDIF
5.1.8 Напоследок просто подурачимся

5.2 Защита каталога

5.2.1 Политика безопасности
5.2.2 Добавление групп
5.2.3 ACL — директивы access файла slapd.conf
5.2.4 Тестирование ACL

5.3 Расширение иерархии

5.3.1 Расширение требований
5.3.2 Реализация расширения
5.3.3 LDIF для реализации расширения
5.3.4 ACL — директивы access файла slapd.conf
5.3.5 Тестирование ACL

5.4 Создание и добавление объектов

5.4.1 Требования
5.4.2 Реализация
5.4.3 Определения атрибутов
5.4.4 Определение объектного класса и набора схемы
5.4.5 ACL — директивы access файла slapd.conf
5.4.6 LDIF
5.4.7 Тестирование изменений

5.5 Технология единого входа (Single Sign On)
5.6 Отсылки и репликация

В данных примерах описано последовательное усовершенствование каталога от простейшей отправной точки в следующем порядке:

1. Шаг 1: обыкновенный (заурядный) каталог имён и адресов без системы безопасности (анонимный доступ на чтение и ограниченный доступ на запись).

2. Шаг 2: добавление политики безопасности — анонимный доступ на чтение определённых полей, защищённый доступ к другим полям и ограниченный защищённый доступ на запись.

3. Шаг 3: добавление двух дополнительных веток к иерархии — общедоступной, но защищённой ветки customer и ветки equipment.

4. Шаг 4: добавление новых объектных классов и некоторых атрибутов.

5. Шаг 5: усовершенствование до технологии единого входа (single sign on, SSO) для поддержки Samba, FTP, Apache и email (в данном случае courier).

6. Шаг 6: распределение контроля (отсылки), внедрение одного скрытого главного сервера (репликация).

Примечание: OpenLDAP находится в процессе перехода от текстового конфигурационного файла (slapd.conf) к конфигурации времени исполнения (on-line configuration, OLC или cn=config). Поскольку OpenLDAP серии версий 2.4 всё ещё поддерживает slapd.conf, большинство дистрибутивов продолжают плыть по воле волн, используя эти файлы. Другие решили перейти к использованию OLC (cn=config), некоторые даже утверждают, что они это сделали и предоставляют специальные инструметы и скрипты чтобы "облегчить Вашу жизнь". Если Ваша инсталляция относится к этой последней категории, Вам нужно сделать три вещи: прочитать документацию, поставляемую с реализацией OpenLDAP Вашего дистрибутива; хорошенько познакомиться с OLC (cn=config); немного погоревать — изначальная кривая Вашего обучения задралась несколько круче, чем предполагалось. Тем не менее, Вы всегда можете вернуться к классической конфигурации slapd.conf, и мигрировать на OLC лишь когда Вы сами посчитаете это нужным (для понимания процесса перехода внимательно прочитайте этот раздел). Разделы примеров содержат замечания и пояснения, охватывающие конфигурацию slapd.conf и, возможно, OLC (cn=config).

Начнём с простого каталога имён и адресов без системы безопасности. Когда Вы начинаете работу с таким сложным приложением, как LDAP, есть около 6-ти миллионов вещей, которые могут пойти не так. Мы пропускаем систему безопасности, чтобы уменьшить количество ошибок примерно до 3-х миллионов. Не помещайте в этот каталог какую-либо конфиденциальную информацию. Безопасность, — даже тривиальная система безопасности, — неотъемлемая часть любого каталога. Безопасность, однако, поддаётся наращиванию; она не влияет на хранящиеся в каталоге данные, и может быть модернизирована в любое время.

5.1.1 Проектирование DIT

На самом деле, это очень важный этап, и Вы можете провести всю оставшуюся жизнь, проектируя своё DIT. Люди даже пишут книги по этой теме. Существует несколько документированных нами общепринятых практик, но в Вашем конкретном случае они могут не заработать. Примите их за то, чем они, по сути, и являются — отправной точкой для Ваших размышлений по этому предмету.

Мы решили следовать классическому, описанному в RFC 2377 формату, и использовали формат dc для корневой записи DIT.

Также мы организовали иерархию адресной книги в разделе people и использовали для этого раздела атрибут ou. Итак, мы остановились на вот такой структуре DIT:

5.1.2 Выбор структурного объектного класса

Вселенский плач и скрежет зубов — обычный аккомпанемент для выбора первичного объектного класса. И всё же это необходимый ритуал LDAP, так давайте займёмся этим прямо сейчас!

В общем случае, на наш взгляд, наиболее полезный для обыкновенных (заурядных) каталогов объектный класс — это inetorgperson, поскольку он является частью БОЛЬШОЙ иерархии с большим количеством атрибутов (убедитесь сами, следуя по ссылкам SUP — вышестоящей иерархии). Если нам не хватит какого-нибудь атрибута — можно добавить его позже, в шаге 4 как раз это и делается. Решение принято; дело закрыто.

5.1.3 Файл slapd.conf

Вот пример slapd.conf, который позволит нам начать работу. В нём используется механизм манипуляции данными Oracle Berkeley DataBase (BDB) (в настоящее время предпочитаемая и рекомендуемая OpenLDAP база данных):

#
###### ПРИМЕР 1 — ПРОСТОЙ КАТАЛОГ ############
#
# Примечание: inetorgperson использует атрибуты и
#     объектные классы из всех трёх наборов схемы
#
# NB: В RH Linux наборы схемы располагаются в /etc/openldap
#
include		/usr/local/etc/openldap/schema/core.schema
include		/usr/local/etc/openldap/schema/cosine.schema
include		/usr/local/etc/openldap/schema/inetorgperson.schema


# НЕТ СИСТЕМЫ БЕЗОПАСНОСТИ — условия безопасности пропущены
# по умолчанию анонимный доступ на чтение
# только rootdn может осуществлять запись

# НЕТ ОТСЫЛОК

# НЕ заботимся о файле ARGS, пока не обретём уверенности в своих силах
# stop-скрипту slapd следующая строка необходима для работы:
pidfile /var/run/slapd.pid

# Включаем большое количество вывода в журнал — нам это может понадобиться
# но при этом генерируются журналы огромных размеров
loglevel 	-1 

# Определения ЗАГРУЗКИ МОДУЛЕЙ
# до версии 2.3 не требуется (закомментируйте)
moduleload back_bdb.la

# НЕТ соединений TLS

# Определение backend не требуется

#######################################################################
# Определение базы данных bdb
# 
# Замените ниже example и com на подходящее имя домена
# 
# Если у Вас нет домена, то, поскольку example.com зарезервирован для
# экспериментов, можете оставить его, либо поменять на my.inc
#
#######################################################################

database bdb
suffix "dc=example, dc=com"

# root или администратор
rootdn "cn=jimbob, dc=example, dc=com"
rootpw dirtysecret
# Директория базы данных ДОЛЖНА существовать до того, как Вы запустите slapd 
# Не забудьте поменять путь на подходящий Вам
directory	/var/db/openldap/example-com

# Устанавливаемые для каталога индексы
# Только полное соответствие для unique id
index	uid	eq
# Стандартный поиск для commonname, givenname и email
index	cn,gn,mail eq,sub
# Несколько вариантов для поиска surname
index sn eq,sub
# В индексах выше sub включает в себя subintial,subany,subfinal
# Оптимизируем поиск по подразделениям
index ou eq
# Если при поиске будет встречаться objectClass, раскомментируйте следующую строку
# index objectClass eq
# Продемонстрировано использование параметра индексирования default
index default eq,sub
# Настройка индексирования пропущена, по умолчанию используется eq,sub
index telephonenumber

# Другие параметры базы данных
# Дополнительная информация в разделе справочника по slapd.conf
cachesize 10000
checkpoint 128 15

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

Примечания:

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

2. Настройки безопасности определяются с помощью директив access. В данном случае их отсутствие позволяет осуществлять анонимный доступ на чтение (аутентификация не требуется), доступ на запись не даётся. Поскольку в примере есть директивы rootdn и rootpw, можно осуществлять запись в каталог от имени этого dn, а также экспериментировать с подключениями при создании записей.

3. В примере отсутствует директива backend, строгой необходимости в которой нет, даже несмотря на то, что в некоторых руководствах утверждается обратное. Если Вам нравится печатать, добавьте её.

4. Выбранные нами индексы призваны оптимизировать некоторые формы доступа. При поиске можно использовать и те атрибуты, которые не были проиндексированы — просто это будет дольше.

5.1.4 Файл LDIF

Представленный ниже LDIF создаёт структуру DIT и добавляет единственную запись в раздел people, позднее с помощью LDIF мы добавим другие две записи. Для добавления других записей, поиска и всех остальных забавных вещей можно также воспользоваться LDAP-браузером.

Данный LDIF будет добавлен с помощью утилиты ldapadd при запущенном OpenLDAP (slapd). Если у Вас много данных, которые Вы готовы поместить в каталог, Вам придётся вновь и вновь создавать LDIF и помещать в каталог столько данных, сколько Вам надо. Если у Вас действительно много данных (больше 1 000 записей), возможно Вы захотите воспользоваться методом загрузки записей slapadd из соображений экономии ресурсов.

Перед тем, как создавать LDIF-файл, мы должны выяснить, какие данные ДОЛЖНЫ присутствовать — в нашем случае это также позволит минимизировать записи, чтобы примеры оставались короткими. Беглый просмотр иерархии объектных классов inetorgperson позволяет найти все те атрибуты, которые должны присутствовать. Наша инспекция показала, что всего два атрибута, cn и sn, являются обязательными. Следующий LDIF устанавливает нашу первоначальную иерархию, а также добавляет одну запись в раздел people:

## Определение DIT ROOT/BASE/SUFFIX ####
## используется формат RFC 2377
## замените встречающиеся ниже example и com на требуемые
## или, для экспериментов, оставьте как есть

## dcObject — это ВСПОМОГАТЕЛЬНЫЙ объектный класс и, кроме него, запись
## ДОЛЖНА иметь СТРУКТУРНЫЙ объектный класс (в данном случае, organization)
# это последовательность ЗАПИСИ и ей предшествует ПУСТАЯ СТРОКА

dn: dc=example,dc=com
dc: example
description: Моя замечательная компания. В эту строку можно поместить столько текста, сколько хотите
 в этой строке продолжение информации из предыдущей строки вплоть до 32Kb 
 строка оканчивается либо на <CR>, либо на <CR><LF>, то есть отрабатывается ENTER
 с систем как Windows, так и *nix — новая строка ДОЛЖНА начинаться с ОДНОГО ПРОБЕЛА
objectClass: dcObject
objectClass: organization
o: Example, Inc.

## ПЕРВЫЙ уровень иерархии — люди (people) 
## для объектных классов используется смешанная форма записи в верхнем и нижнем регистре
# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой

dn: ou=people, dc=example,dc=com
ou: people
description: All people in organisation
objectclass: organizationalunit

## ВТОРОЙ уровень иерархии
## ДОБАВЛЯЕМ одну запись в ПЕРВЫЙ уровень (people)
# это последовательность ЗАПИСИ, она должна предваряться ПУСТОЙ строкой
# ou: Human Resources — это название подразделения

dn: cn=Robert Smith,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Robert Smith
cn: Robert J Smith
cn: bob  smith
sn: smith
uid: rjsmith
userpassword: rJsmitH
carlicense: HISCAR 123
homephone: 555-111-2222
mail: r.smith@example.com
mail: rsmith@example.com
mail: bob.smith@example.com
description: swell guy
ou: Human Resources

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

Примечания:

1. <предупреждение> В версиях данного руководства до 0.1.2 в приведённом выше примере мы некорректно определяли dn: dc=example,dc=com как dn: dc=example.com. Это успешно загружалось в OpenLDAP 2.0 и 2.1, но стало отклоняться в OpenLDAP 2.2 (ошибка 64). </предупреждение>

2. Записи при добавлении начинаются со строки, первыми символами которой являются 'dn:'. В общем случае, для этих целей может использоваться любой атрибут при условии соблюдения уникальности 'dn:', и, во избежание излишней нагрузки при поиске, обычно им становится наиболее часто используемый при доступе к записи DN. Поэтому в последней записи в приведённом выше LDIF используется значение cn=Robert Smith,ou=people,dc=example,dc=com, подразумевая, что cn= будет наиболее часто используемым DN при доступе к записям. Однако, если запись будет использоваться для аутентификации, то данный DN ДОЛЖЕН быть таким, чтобы его можно было использовать во время операций подсоединения. В этом случае более подходящими могут быть DN типа uid=rjsmith,ou=people,dc=example,dc=com. Поскольку для данного начального DN (или DN 'создания') нет специального термина в стандартах LDAP, то, при использовании в целях идентификации, он иногда называется DN принципала (Principal DN). Дополнительная информация по этой теме.

3. Для упрощения описания некоторых концепций LDIF мы используем некоторые введённые нами термины.

4. Как упоминалось в комментариях, директива version: не является строго обязательной. Если она присутствует, то (в настоящий момент) она должна быть установлена в 1 для указания версии 1 формата LDIF. Данная директива была включена просто потому, что делать это полезно (Good Thing™). Будущие версии могут быть несовместимы, либо могут налагать более строгие требования к корректности — лучше заиметь хорошие привычки сейчас. Во время нашего тестирования мы заметили, что некоторые особо безумные версии OpenLDAP могут приводиться в ступор директивами version, выдавая сообщения об ошибках с предположениями об отсутствии DN. Если это произошло, удалите строку version и все соответствующие комментарии (как мы это сделали в примере выше).

5. Комментарии обозначаются # только в первом символе строки. В следующей строке # интерпретируется как содержимое:

   cn: my name #this is my name
   

   В результате атрибут cn будет содержать 'my name #this is my name'.

6. Между записями должна быть КАК МИНИМУМ одна ПУСТАЯ строка (перед строками, начинающимися с dn:). Это ОЧЕНЬ важно — в противном случае могут возникать странные ошибки.

7. Предполагается, что строка является строкой ПРОДОЛЖЕНИЯ, если предыдущая строка оканчивается разделителем строк (<CR> или последовательностью <Cr><LF>), а текущая начинается РОВНО С ОДНОГО ПРОБЕЛА.

8. В именах атрибутов в приведённом выше файле непоследовательно используются символы в верхнем и нижнем регистрах — в частности, эта ужасная псевдовенгерская нотация (она же CamelCase или "ГорбатыйРегистр") objectClass или все буквы в нижнем регистре objectclass. Работает и то, и другое. Следуйте любому стилю на Ваш выбор.

9. Строка cn: bob smith содержит несколько кажущихся ошибок. Здесь есть два пробела между 'bob' и 'smith' и оба они в нижнем регистре. Ни одна из этих кажущихся ошибок на имеет никакого эффекта в работе каталога, поскольку атрибут cn (дочерний от атрибута name) использует нечувствительное к регистру правило соответствия и LDAP при поиске выполняет некоторые интересные вещи.

10. В большом количестве руководств Вы встретите objectclass: top и определение всех объектных классов в иерархии. Начиная с OpenLDAP 2.0, это не является обязательным. Принимайте решение, будете ли Вы это делать, исходя из требований Вашей системы, или из того, любите или нет Вы печатать.

11. Пробел, следующий за : (двоеточием) в каждой строке, ЖИЗНЕННО НЕОБХОДИМ.

12. Во многих руководствах Вы найдёте определённую для rootdn (администратора) запись в файле LDIF (в данном примере slapd.conf это rootdn "cn=jimbob,dc=example,dc=com"). Так как rootpw определён в файле slapd.conf, наличие данной записи в каталоге не является обязательным и может быть потенциально опасным, поскольку таким образом данная запись предоставляется для внешнего доступа. Мы категорически не советуем Вам так поступать и приводим подробное обсуждение этой темы здесь.

13. Мы использовали несколько значений cn, чтобы увеличить шансы найти человека по имени. Мы использовали параметры eq,sub (в файле slapd.conf) при индексировании атрибута cn. Поступите Вы так или нет — ворос политики и предпочтений. Можно предположить, что sn будет основным параметром при поиске человека, в этом случае, возможно, Вы захотите использовать параметр индексирования approx для поиска по созвучным значениям. Выбор значения Robert Smith для помещения в строку dn: (dn: cn=Robert Smith,dc=example,dc=com) абсолютно произволен, его можно заменить на любое другое из значений cn.

14. В каждой из этих записей неявно используется директива changetype: add, которая должна следовать сразу за строкой dn: и которая является значением по умолчанию. Мы рассмотрим использование LDIF-директивы changetype позже.

15. Некоторые из добавленных нами атрибутов могут показаться немного странными, просто они будут использоваться в дальнейших примерах для иллюстрации некоторых моментов. Вы можете добавить в LDIF любые другие атрибуты из выбранной Вами иерархии объектных классов.

Большинство систем каталогов может быть построено с помощью приведённого выше подмножества полного набора директив LDIF-файлов.

5.1.5 Загрузка LDIF-файла

Чтобы загрузить LDIF-файл, нам понадобится работающий сервер OpenLDAP (slapd), поэтому, если он еще не запущен, мы должны запустить его сейчас, с помощью команды, подобной следующей:

[redhat] /etc/rc.d/init.d/ldap start
[bsd] /usr/local/etc/openldap/slapd.sh start

# убеждаемся, что slapd запущен
ps ax | grep slapd
# (если slapd успешно запустился, Вы увидите запись его процесса)

Примечание: аргументы командной строки демона slapd можно найти здесь.

Предположим, что мы сохранили приведённый выше LDIF как createdit.ldif в директорию /tmp. Тогда мы будем загружать LDIF-файл с помощью примерно такого вызова ldapadd (приведённая ниже команда разбита на две строки только из соображений форматирования HTML и должна записываться в одну строку):

ldapadd -H ldap://ldaphost.example.com -x -D "cn=jimbob,dc=example,dc=com" 
 -f /tmp/createdit.ldif -w dirtysecret

Замените ldaphost.example.com на имя того хоста, на котором располагается Ваш каталог LDAP. Если мы вызываем команду на том же хосте, на котором работает LDAP-сервер, параметр -H может быть опущен. Параметр -x указывает, что мы не будем использовать SASL-аутентификацию, он требуется только начиная с OpenLDAP версий 2.x. В параметре -D указан DN, от имени которого мы производим подключение, он необходим, поскольку мы определили rootdn и не определили других установок access; — администратору приходится выполнять всю работу. Указывать пароль вслед за параметром -w, как мы это сделали в примере, мягко скажем, небезопасно, впрочем, как небезопасен на текущий момент и весь наш каталог!

5.1.6 Добавление записей с помощью LDIF

Следующий LDIF демонстрирует, как добавить дополнительные записи с помощью LDIF.

version: 1

## Добавление одной записи в раздел people

dn: cn=John Smith,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: John Smith
cn: John J Smith
sn: Smith
uid: jsmith
userpassword: jSmitH
carlicense: HISCAR 124
homephone: 555-111-2223
mail: j.smith@example.com
mail: jsmith@example.com
mail: john.smith@example.com
ou: Sales

## Добавление другой записи в раздел people

dn: cn=Sheri Smith,ou=people,dc=example,dc=com
objectclass: inetOrgPerson
cn: Sheri Smith
sn: smith
uid: ssmith
userpassword: sSmitH
carlicense: HERCAR 125
homephone: 555-111-2225
mail: s.smith@example.com
mail: ssmith@example.com
mail: sheri.smith@example.com
ou: IT

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

Предположим, что мы сохранили приведённый выше LDIF как addentry.ldif в директории /tmp. Тогда мы будем загружать LDIF-файл с помощью примерно такого вызова ldapadd (приведённая ниже команда разбита на две строки только из соображений форматирования HTML и должна записываться в одну строку):

ldapadd -H ldap://ldaphost.example.com -x -D "cn=jimbob,dc=example,dc=com" 
 -f /tmp/addentry.ldif -w dirtysecret

5.1.7 Изменение записей

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

version: 1

## МОДИФИЦИРУЕМ запись Robert Smith

dn: cn=Robert Smith,ou=people,dc=example,dc=com
changetype: modify
add: telephonenumber
telephonenumber: 555-555-1212
telephonenumber: 212
-
replace: uid
uid: rjosmith
-
replace: mail
mail: robert.smith@example.com
mail: bob.smith@example.com
-
# добавление атрибута с использованием формата URL
add: jpegphoto
jpegphoto: < file://path/to/jpeg/file.jpg
-
delete: description

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

Примечания:

1. Директива changetype: modify сообщает OpenLDAP, что мы собираемся вносить изменения в данную запись. Для удаления записи целиком можно использовать директиву changetype: delete.

2. Директива add: атрибут сообщает OpenLDAP, что мы собираемся добавить атрибут, определение которого должно следовать сразу за этой директивой. В данном случае мы добавляем к записи атрибуты telephonenumber (являющиеся атрибутами объектного класса organizationalPerson).

3. Директива replace: атрибут сообщает OpenLDAP, что мы собираемся заменить атрибут, определение которого должно следовать сразу за этой директивой. В данном случае мы заменяем атрибуты uid и mail. Для атрибута mail мы первоначально добавили три значения, при выполнении replace все они будут удалены и добавлены новые из данного LDIF. После завершения операции у записи Robert Smith будет только два атрибута mail — те, которые были взяты из данного LDIF.

4. Строка jpegphoto: < file://path/to/jpeg/file.jpg сообщает OpenLDAP, что требуется прочитать содержимое файла, указанного в полном описании пути. В этом случае знак < предваряется пробелом и непосредственно за ним также ДОЛЖЕН следовать пробел (Примечание: хотя это и противоречит формату, приведённому в примерах 5 и 6 RFC 2849, зато работает). Если у Вас нет под рукой подходящего JPEG-файла (он может быть любым), закомментируйте эти две строки.

   Примечание переводчика: рабочий формат указания файла — без пробела после двоеточия:
   jpegPhoto:< file:///tmp/robert.jpg

5. Строка delete: description сообщает OpenLDAP, что требуется удалить атрибут description — мы решили, что Mr. Robert Smith не такой уж замечательный парень (swell guy).

Предположим, что мы сохранили приведённый выше LDIF как modentry.ldif в директории /tmp. Тогда мы будем загружать LDIF-файл с помощью примерно такого вызова ldapadd (приведённая ниже команда разбита на две строки только из соображений форматирования HTML и должна записываться в одну строку):

ldapadd -H ldap://ldaphost.example.com -x -D "cn=jimbob,dc=example,dc=com" 
 -f /tmp/modentry.ldif -w dirtysecret

Замените ldaphost.example.com на имя того хоста, на котором располагается Ваш каталог LDAP. Файл не обязательно должен иметь расширение .ldif, это просто соглашение, которое мы решили использовать; его с таким же успехом можно было бы назвать modentry.file или вообще как угодно.

5.1.8 Напоследок просто подурачимся

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

1. С помощью LDAP-браузера или LDIF-файлов добавьте дополнительные записи или атрибуты к существующим записям. Для записи в каталог Вы должны подключаться от имени cn=jimbob,dc=example,dc=com (rootdn или администратор) и использовать ассоциированный с ним rootpw.

2. Используйте ldapsearch или Ваш LDAP-браузер для поиска по различным критериям.

3. Наконец, либо в семействе браузеров Mozilla (например, FireFox или K-meleon), либо MS Explorer (5+) попробуйте напечатать в адресной строке и перейти по такому LDAP URL:

   ldap://ldaphost.example.com/ou=people,dc=example,dc=com??one?(objectclass=*)
   

   Замените ldaphost.example.com на имя того хоста, на котором располагается Ваш каталог LDAP. Также замените все ссылки на example и com, чтобы они соответствовали Вашей реализации.