Как только программа была создана и установлена, вы готовы к ее настройке для использования на вашем сайте. Вся настройка 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 |
Директивы в этой секции применимы только к механизму базы данных, в котором они определены. Они поддерживаются каждым типом механизма базы данных. Эти директивы применимы ко всем экземплярам баз данных одного типа и, в зависимости от директивы, могут переопределяться директивами баз данных.
backend <тип>
Эта директива отмечает начало определения механизма базы данных. <тип> должен быть одним из ldbm, shell, passwd, или других поддерживаемых типов механизмов базы данных. |
Директивы этой секции применимы только к базе данных, в которой они определены. Они поддерживаются всеми типами баз данных.
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. То есть, они должны следовать за строкой "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 |
slapd поддерживает и другие типы механизмов баз данных кроме LDBM:
ldbm: Berkeley или GNU DBM совместимый механизм
passwd: обеспечивает доступ к /etc/passwd в режиме только для чтения
shell: Shell механизм (к внешней программе)
sql: механизм базы данных на основе SQL
Детали смотрите в man странице slapd.conf(5).
Функции контроля доступа представленные в Разд. Глобальные директивы> очень мощные. В этой секции приводятся примеры их использования. Для начала несколько простых примеров:
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 |