6. Конфигурационный файл slapd
В этом разделе описывается настройка slapd(8) с помощью конфигурационного файла slapd.conf(5). slapd.conf(5) является устаревшим и использовать его нужно лишь в том случае, если для работы Вашего каталога требуется один из тех механизмов манипуляции данными, которые ещё не были адаптированы для работы с более новой системой конфигурации slapd-config(5). Настройка slapd(8) с помощью slapd-config(5) описана в предыдущем разделе.
Файл slapd.conf(5) по умолчанию устанавливается в директорию /usr/local/etc/openldap. Альтернативное расположение конфигурационного файла можно указать с помощью параметра командной строки при запуске slapd(8).
6.1. Формат конфигурационного файла
Файл slapd.conf(5) состоит из трёх типов настроечной информации: глобальной, специфичной для механизмов манипуляции данными и специфичной для баз данных. Глобальные настройки указываются первыми, затем следуют настройки для конкретного типа механизма манипуляции данными, за которыми, в свою очередь, следуют настройки конкретного экземпляра базы данных. Глобальные директивы могут переопределяться директивами механизма манипуляции данными и/или базы данных, а директивы механизма манипуляции данными могут переопределяться директивами базы данных.
Пустые строки и строки комментариев, начинающиеся с символа '#' игнорируются. Если строка начинается с пробельного символа, она считается продолжением предыдущей строки (даже если предыдущая строка является комментарием).
Общий формат файла slapd.conf:
# глобальные настройки
<глобальные директивы конфигурации>
# определение механизма манипуляции данными
backend <typeA>
<директивы, специфичные для ММД>
# определение и директивы конфигурации первой базы данных
database <typeA>
<директивы, специфичные для БД>
# определение и директивы конфигурации второй базы данных
database <typeB>
<директивы, специфичные для БД>
# определение и директивы конфигурации третьей базы данных
database <typeC>
<директивы, специфичные для БД>
# последующие определения и директивы конфигурации механизмов манипуляции данными и баз данных
...
У директивы конфигурации могут быть аргументы, которые отделяются друг от друга пробельными символами. Если пробельный символ содержится внутри аргумента, аргумент заключается в двойные кавычки "вот так". Если аргумент содержит двойные кавычки или символ обратного слеша `\', данные символы должны экранироваться символом обратного слеша `\'.
В дистрибутиве есть пример конфигурационного файла, устанавливаемый в директорию /usr/local/etc/openldap. Также есть несколько файлов, содержащих наборы определения схемы (типы атрибутов и объектные классы), устанавливаемых в директорию /usr/local/etc/openldap/schema.
6.2. Директивы конфигурационного файла
В этом подразделе детально описаны часто используемые директивы конфигурации, полный список директив можно найти в man-странице slapd.conf(5). Директивы конфигурационного файла разделены на категории глобальных, специфичных для механизмов манипуляции данными и специфичных для баз данных. Для каждой директивы дается её описание, значение по умолчанию (если есть), и пример использования.
6.2.1. Глобальные директивы
Описанные в данном подразделе директивы применяются ко всем механизмам манипуляции данными и базам данных, если они специально не переопределяются настройками конкретного механизма манипуляции или базы данных. Аргументы, которые требуется заменить актуальными значениями, показаны в угловых скобках <>.
6.2.1.1. access to <what> [ by <who> [<accesslevel>] [<control>] ]+
Эта директива предоставляет доступ (заданный аргументом <accesslevel>) к набору записей и/или атрибутов (заданный аргументом <what>) одному или нескольким пользователям (заданным аргументом <who>). Смотрите раздел Контроль доступа данного руководства для получения подробных сведений о настройке.
Замечание: Если не задано ни одной директивы access, применяется политика контроля доступа по умолчанию access to * by * read, предоставляющая доступ на чтение как авторизованным, так и анонимным пользователям.
6.2.1.2. attributetype <описание типа атрибута согласно RFC4512>
Эта директива определяет тип атрибута. О том, как использовать эту директиву, читайте в разделе Спецификация схемы данных каталога.
6.2.1.3. idletimeout <целое число>
Определяет количество секунд до того, как принудительно закрыть простаивающее клиентское соединение. При установке idletimeout в 0 (значение по умолчанию), эта функция отключается.
6.2.1.4. include <имя файла>
Эта директива определяет, что slapd должен прочитать дополнительную информацию о конфигурации из указанного файла, перед тем как перейти к обработке следующей строки текущего файла. Формат подключаемого файла должен соответствовать нормальному формату конфигурационного файла slapd. В качестве примера обычно подключаемых файлов можно привести файлы, содержащие наборы спецификаций схемы.
Замечание: При использовании данной директивы соблюдайте осторожность: не существует разумных ограничений на количество вложенных директив include, и зацикливание не распознаётся.
6.2.1.5. loglevel <уровень>
Эта директива определяет уровень отладочной информации и статистики работы slapd, которая должна быть журналирована (в настоящее время журналируется в канал LOG_LOCAL4 syslogd(8)). Чтобы это работало (за исключением двух уровней статистики, которые всегда включены), при конфигурации перед сборкой OpenLDAP нужно указать --enable-debug (по умолчанию включено). Уровни журналирования могут быть указаны целым числом или ключевым словом. Можно задать несколько уровней журналирования, либо указать несколько уровней как сумму соответствующих целых чисел. Чтобы узнать соответствие числового значения типу отладочной информации, запустите slapd с ключом -d? или посмотрите таблицу ниже. Возможные значения <уровня>:
| Уровень | Ключевое слово | Описание |
| -1 | any | включить всю отладочную информацию |
| 0 | отключить отладку | |
| 1 | (0x1 trace) | отслеживать вызовы функций |
| 2 | (0x2 packets) | отладка обработки пакетов |
| 4 | (0x4 args) | усиленная отладка |
| 8 | (0x8 conns) | управление соединениями |
| 16 | (0x10 BER) | вывод посылки и приёма пакетов |
| 32 | (0x20 filter) | обработка поисковых фильтров |
| 64 | (0x40 config) | обработка конфигурации |
| 128 | (0x80 ACL) | обработка списков контроля доступа |
| 256 | (0x100 stats) | статистика соединений/операций/результатов |
| 512 | (0x200 stats2) | статистика посылки записей журнала |
| 1024 | (0x400 shell) | вывод взаимодействия с механизмами манипуляции данными shell |
| 2048 | (0x800 parse) | вывод отладочной информации разбора записей |
| 16384 | (0x4000 sync) | обслуживание потребителей syncrepl |
| 32768 | (0x8000 none) | только сообщения, выводимые независимо от заданного уровня журналирования (то есть высокоприоритетные) |
Требуемый уровень журналирования может быть задан одним целым числом (десятичным или шестнадцатеричным), которое является комбинацией нужных уровней журналирования (соединяемых через логическое ИЛИ). Также он может быть задан списком целых чисел (опять же соединяемых через логическое ИЛИ), либо списком ключевых слов, указанных в скобках в соответствующем столбце таблицы выше. Таким образом, директивы
loglevel 129
loglevel 0x81
loglevel 128 1
loglevel 0x80 0x1
loglevel acl trace
эквивалентны.
Примеры:
loglevel -1
Это вызывает журналирование большого количества отладочной информации.
loglevel conns filter
Журналирование только информации о соединениях и обработке поисковых фильтров.
loglevel none
Журналирование только тех сообщений, которые выводятся вне зависимости от настроенного уровня журналирования. Это отличается от установки уровня журналирования в 0, когда журналирование отсутствует. Для журналирования высокоприоритетных сообщений требуется как минимум уровень None.
Значение по умолчанию:
loglevel stats
По умолчанию настраивается журналирование основных статистических сведений. Однако, если не определено никакого loglevel, журналирования не происходит (как в уровне 0).
6.2.1.6. objectclass <описание объектного класса согласно RFC4512>
Эта директива определяет объектный класс. О том, как использовать эту директиву, читайте в разделе Спецификация схемы данных каталога.
6.2.1.7. referral <URI>
Эта директива определяет отсылку, которая возвращается клиенту, когда slapd не может найти подходящую локальную базу данных для обработки запроса.
Пример:
referral ldap://root.openldap.org
С помощью этой директивы в проекте OpenLDAP нелокальные запросы перенаправляются на глобальный LDAP-сервер корневого уровня. Продвинутые клиенты LDAP могут сделать повторный запрос на указанный сервер. Но имейте в виду, что большинство клиентов способны обрабатывать только простые LDAP URL, состоящие из адреса хоста и, возможно, из уникального имени записи.
6.2.1.8. sizelimit <целое число>
Эта директива определяет максимальное количество записей, возвращаемых поисковым запросом.
Значение по умолчанию:
sizelimit 500
Для получения дополнительной информации смотрите раздел Ограничения этого руководства и slapd.conf(5).
6.2.1.9. timelimit <целое число>
Эта директива указывает максимальное количество секунд, которое slapd может потратить, чтобы ответить на поисковый запрос. Если запрос не был обработан за это время, клиенту возвращается уведомление о превышении времени обработки.
Значение по умолчанию:
timelimit 3600
Для получения дополнительной информации смотрите раздел Ограничения этого руководства и slapd.conf(5).
6.2.2. Общие директивы механизмов манипуляции данными
Директивы этого подраздела применяются только к тем механизмам манипуляции данными, для которых они определены. Они поддерживаются всеми типами механизмов манипуляции данными. Директивы механизма манипуляции данными применяются ко всем базам данных того же типа и, в зависимости от директивы, могут быть переопределены директивами конкретной базы данных.
6.2.2.1. backend <тип>
Эта директива обозначает начало определения настроек экземпляра механизма манипуляции данными. <Тип> должен быть одним из поддерживаемых типов механизмов, перечисленных в таблице 6.2.
| Тип | Описание |
| bdb | Механизм Berkeley DB с поддержкой транзакций (устаревший) |
| dnssrv | Механизм DNS SRV |
| hdb | Иерархический вариант механизма bdb (устаревший) |
| ldap | Механизм Lightweight Directory Access Protocol (прокси) |
| mdb | Механизм Memory-Mapped DB (отображаемая в памяти база данных) |
| meta | Механизм мета-каталога |
| monitor | Механизм мониторинга |
| passwd | Предоставление доступа только для чтения к passwd(5) |
| perl | Программируемый механизм Perl |
| shell | Механизм запуска внешних программ Shell |
| sql | Программируемый механизм SQL |
Пример:
backend bdb
Здесь обозначено начало определения настроек нового экземпляра механизма манипуляции данными
6.2.3. Общие директивы баз данных
Директивы этого подраздела применяются только к тем базам данных, для которых они определены. Они поддерживаются всеми типами баз данных.
6.2.3.1. database <тип>
Эта директива обозначает начало определения настроек экземпляра базы данных. <Тип> должен быть одним из поддерживаемых типов механизмов манипуляции данными, перечисленных в таблице 6.2.
Пример:
database bdb
Здесь обозначено начало определения настроек нового экземпляра базы данных
6.2.3.2. limits <критерий отбора> <ограничение> [<ограничение> [...]]
Определяет ограничения по времени и размеру в зависимости от инициатора операции или базового DN.
Для получения дополнительной информации смотрите раздел Ограничения этого руководства и slapd.conf(5).
6.2.3.3. readonly { on | off }
Эта директива переводит базу данных в режим "только для чтения". На все попытки внесения в базу данных изменений возвращается ошибка "unwilling to perform" ("не желают выполнять"). Если эта директива настроена на потребителе репликации, модификации, посылаемые механизмом syncrepl, всё равно будут применяться.
Значение по умолчанию:
readonly off
6.2.3.4. rootdn <DN>
Эта директива определяет DN, на который не будут накладываться контроль доступа и административные ограничения при выполнении операций с этой базой данных. Данный DN не обязательно должен указывать на запись из этой базы данных, и даже на запись из этого каталога. Данный DN может ссылаться на идентификационную сущность SASL.
Пример с записью:
rootdn "cn=Manager,dc=example,dc=com"
Пример с SASL:
rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth"
Информацию об аутентификационных идентификационных сущностях SASL можно посмотреть в разделе Аутентификация SASL.
6.2.3.5. rootpw <пароль>
Эта директива может использоваться для назначения пароля для DN из rootdn (когда в качестве rootdn назначен DN из этой базы данных).
Пример:
rootpw secret
Также можно назначить хэш пароля в форме RFC2307. Для генерации хэша пароля можно использовать slappasswd(8).
Пример:
rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
Данный хэш был сгенерирован командой slappasswd -s secret.
6.2.3.6. suffix <dn суффикса>
Эта директива определяет DN суффикса запросов, которые будут направляться в эту базу данных. Возможно определение нескольких суффиксов. Как минимум один суффикс должен быть определён для каждой базы данных.
Пример:
suffix "dc=example,dc=com"
Запросы с DN, оканчивающимся на "dc=example,dc=com" будут направлены в эту базу данных.
Замечание: Когда выбран механизм манипуляции данными для обработки запроса, slapd ищет строку (строки) определения суффикса в каждом определении базы данных в порядке их указания в файле. Поэтому, если один суффикс базы данных является префиксом к другому, то более общий суффикс должен указываться позже в конфигурационном файле.
6.2.3.7. syncrepl
syncrepl rid=<ID реплики>
provider=ldap[s]://<имя хоста>[:порт]
searchbase=<base DN>
[type=refreshOnly|refreshAndPersist]
[interval=dd:hh:mm:ss]
[retry=[<интервал между повторами> <количество повторов>]+]
[filter=<строка фильтра>]
[scope=sub|one|base]
[attrs=<список атрибутов>]
[exattrs=<attr list>]
[attrsonly]
[sizelimit=<limit>]
[timelimit=<limit>]
[schemachecking=on|off]
[network-timeout=<seconds>]
[timeout=<seconds>]
[bindmethod=simple|sasl]
[binddn=<DN>]
[saslmech=<mech>]
[authcid=<identity>]
[authzid=<identity>]
[credentials=<passwd>]
[realm=<realm>]
[secprops=<properties>]
[keepalive=<idle>:<probes>:<interval>]
[starttls=yes|critical]
[tls_cert=<file>]
[tls_key=<file>]
[tls_cacert=<file>]
[tls_cacertdir=<path>]
[tls_reqcert=never|allow|try|demand]
[tls_cipher_suite=<ciphers>]
[tls_crlcheck=none|peer|all]
[tls_protocol_min=<major>[.<minor>]]
[suffixmassage=<real DN>]
[logbase=<base DN>]
[logfilter=<filter str>]
[syncdata=default|accesslog|changelog]
Эта директива определяет, что текущая база данных будет репликой содержимого каталога основного сервера, и текущий slapd(8) будет работать в роли сервера-потребителя репликации путём запуска механизма syncrepl. Основная база данных располагается на сервере-поставщике репликации, указанном в параметре provider. База данных реплики синхронизируется с содержимым каталога основного сервера с использованием LDAP Content Synchronization protocol (протокол синхронизации содержимого LDAP). Описание протокола можно найти в RFC4533.
Параметр rid используется для идентификации текущей директивы syncrepl в пределах сервера-потребителя репликации. <ID реплики> — уникальный идентификатор спецификации syncrepl, описываемой текущей директивой syncrepl. <ID реплики> должен быть положительным числом длиной не более трёх десятичных цифр.
Параметр provider определяет адрес поставщика репликации как LDAP URI. Параметр provider указывается схемой (ldap или ldaps), именем хоста и, опционально, номером порта, на котором будет слушать slapd поставщика. В качестве <имени хоста> может быть как доменное имя, так и IP-адрес. Например, ldap://provider.example.com:389 или ldaps://192.168.1.1:636. Если <порт> не задан, используются стандартные номера портов LDAP (389 или 636). Обратите внимание, что механизм syncrepl использует протокол, инициируемый со стороны потребителя, поэтому директивы его настройки располагаются на сервере потребителя, в то время как директивы replica располагаются на стороне поставщика. Директивы syncrepl и replica определяют две независимые части механизма репликации. Они не устанавливают никаких взаимных потоков репликации друг к другу.
Содержимое реплики syncrepl формируется как результат поискового запроса. slapd потребителя посылает поисковые запросы к slapd поставщика согласно данной ему спецификации поискового запроса. Спецификация поискового запроса включает в себя параметры searchbase, scope, filter, attrs, exattrs, attrsonly, sizelimit и timelimit, как и в случае обычного поискового запроса. У параметра searchbase нет значения по умолчанию и он должен быть задан обязательно. Значения по умолчанию остальных параметров: scope — sub, filter — (objectclass=*), attrs — "*,+" (то есть репликация и пользовательских, и операционных атрибутов), attrsonly по умолчанию не задан. Параметры sizelimit и timelimit по умолчанию установлены в "unlimited", и могут задаваться либо положительным целым числом, либо "unlimited". Также можно использовать необязательный параметр exattrs для указания атрибутов, которые должны быть исключены из входящих записей.
У протокола
При возникновении ошибок в процессе репликации, потребитель будет пытаться сделать повторное подключение в соответствии с указанным в параметре retry списком пар значений <интервал между повторами> и <количество повторов>. Например, retry="60 10 300 3" позволяет получателю повторять запрос через каждые 60 секунд первые 10 раз, а затем через каждые 300 секунд еще 3 раза перед тем, как прекратить попытки. Если в <количестве повторов> указан +, то повторные попытки будут осуществляться до получения положительного результата (неограниченное количество раз).
С помощью параметра schemachecking можно включить принудительную проверку получаемых данных на соответствие схеме данных на стороне потребителя LDAP Sync. Если он установлен в on, каждая реплицируемая запись будет проверяться, не нарушит ли она целостности схемы данных при помещении её в базу данных реплики. Каждая запись в реплике должна содержать те атрибуты, которые помечены как обязательные в определении схемы. Если этот параметр установлен в off, записи будут сохраняться без проверки на соответствие схеме. Значение по умолчанию — off.
Параметр network-timeout задаёт промежуток времени, в течение которого потребитель репликации будет ожидать установления сетевого соединения с поставщиком. После того, как соединение установлено, параметр timeout определяет, как долго потребитель будет ожидать завершения выполнения первоначального запроса Bind. Значения по умолчанию для этих параметров берутся из настроек в файле ldap.conf(5).
Параметр binddn указывает DN, под которым будет происходить соединение с slapd поставщика для выполнения поисковых запросов syncrepl. Этот DN должен иметь права на чтение к реплицируемому содержимому каталога на главном сервере.
Параметр bindmethod может быть либо simple, либо sasl, в зависимости от метода аутентификации (простая парольная или
Лучше не использовать простую аутентификацию, если не предприняты адекватные меры защиты целостности и конфиденциальности данных (такие как TLS или IPsec). При использовании простой аутентификации требуется задать параметры binddn и credentials.
В общем случае рекомендуется использование аутентификации SASL. Аутентификация SASL требует указания механизма с использованием параметра saslmech. В зависимости от механизма, можно задать аутентификационную идентификационную сущность и/или учётные данные с помощью соответствующих параметров authcid и credentials. Параметр authzid может быть использован для определения авторизационной идентификационной сущности.
Параметр realm указывает realm, с которым некоторые механизмы проводят аутентификацию идентификационной сущности. В параметре secprops указываются настройки безопасности Cyrus SASL.
Параметр keepalive задаёт значения времени простоя, количества проб и интервалов между выполнением проб, используемых для проверки работоспособности сокета; время простоя — это количество секунд, в течение которого соединение должно бездействовать перед тем, как TCP начнет выполнять проверку работоспособности; количество проб представляет собой максимальное число проверок работоспособности, которое следует выполнить TCP перед тем, как разорвать соединение; интервал представляет собой количество секунд между посылками проб работоспособности. Эти значения разрешено задавать лишь в некоторых системах; в остальных системах параметр keepalive будет проигнорирован, и будут использованы общесистемные установки. Например, при указании keepalive="240:10:30" будет выполнено 10 проб работоспособности с интервалом 30 секунд после того, как сокет будет неактивен в течение 240 секунд. Если ответа на эти пробы не будет получено, соединение будет разорвано.
Параметр starttls указывает использование расширенной операции StartTLS для установки сессии TLS до начала аутентификации при подключении к серверу-поставщику. Если установлен аргумент critical, сессия будет прервана в случае неудачного завершения запроса StartTLS. Если этот аргумент не был установлен, сессия syncrepl будет продолжена без TLS. Параметр tls_reqcert по умолчанию установлен в "demand", значения по умолчанию других настроек TLS соответствуют значениям аналогичных основных настроек TLS slapd.
Параметр suffixmassage позволяет потребителю получать записи из удалённого каталога, контекст именования которого отличается от контекста именования локального каталога. Составная часть DN записей из удалённого каталога, совпадающая с DN в параметре searchbase, будет заменена значением DN из параметра suffixmassage.
Вместо того, чтобы реплицировать записи целиком, потребитель может запрашивать журналы изменений данных. Этот режим работы называется дельта-syncrepl. В дополнение к вышеперечисленным параметрам, нужно установить параметры logbase и logfilter в соответствии с типом журнала, который будет использоваться. Параметр syncdata должен быть задан либо в "accesslog" если журнал соответствует формату slapo-accesslog(5), либо в "changelog" если журнал соответствует устаревшему формату changelog. Если параметр syncdata пропущен или установлен в "default", то параметры журналирования игнорируются.
Механизм репликации syncrepl поддерживается механизмами манипуляции данными bdb, hdb и mdb.
Дополнительная информация по использованию этой директивы в разделе Репликация на основе LDAP Sync этого руководства.
6.2.3.8. updateref <URL>
Эта директива применяется только в случае запуска slapd(8) в режиме подчинённого (или теневого) сервера. Она указывает URL, возвращаемый клиентам при попытке выполнить на реплике запрос на обновление. Если директива указывается несколько раз, клиенту возвращаются все
Пример:
updateref ldap://master.example.net
6.2.4. Директивы баз данных BDB и HDB
Директивы этой категории применимы только к базам данных
6.2.4.1. directory <директория>
Эта директива указывает директорию, где будут находиться файлы BDB, содержащие базу данных, и соответствующие им индексы.
Значение по умолчанию:
directory /usr/local/var/openldap-data
6.3. Пример конфигурационного файла
Далее приведён пример конфигурационного файла вперемешку с поясняющим его текстом. В нём определены две базы данных (обе они
1. # пример конфигурационного файла - секция глобальных настроек 2. include /usr/local/etc/schema/core.schema 3. referral ldap://root.openldap.org 4. access to * by * read
Строка 1 — комментарий. В строке 2 подключается другой конфигурационный файл, содержащий определение набора схемы core. Директива referral в строке 3 означает, что на запросы, не относящиеся ни к одной из баз данных, определённых ниже, будет возвращаться отсылка на LDAP сервер, работающий на стандартном порту (389) по адресу root.openldap.org.
В строке 4 определён глобальный уровень контроля доступа. Он применяется ко всем записям (после применения к ним правил контроля доступа, специфичных для базы данных).
В следующей секции конфигурационного файла определена база данных механизма манипуляции данными BDB, которая будет обрабатывать запросы к части дерева "dc=example,dc=com". База данных будет реплицироваться на два подчинённых slapd, один из которых на хосте truelies, а другой — на judgmentday. К некоторым атрибутам будет применяться индексирование, а атрибут userPassword защищается от несанкционированного доступа.
5. # Определение BDB для example.com 6. database bdb 7. suffix "dc=example,dc=com" 8. directory /usr/local/var/openldap-data 9. rootdn "cn=Manager,dc=example,dc=com" 10. rootpw secret 11. # определения индексирования атрибутов 12. index uid pres,eq 13. index cn,sn pres,eq,approx,sub 14. index objectClass eq 15. # определения контроля доступа к базе данных 16. access to attrs=userPassword 17. by self write 18. by anonymous auth 19. by dn.base="cn=Admin,dc=example,dc=com" write 20. by * none 21. access to * 22. by self write 23. by dn.base="cn=Admin,dc=example,dc=com" write 24. by * read
Строка 5 — комментарий. Начало определения базы данных обозначено ключевым словом database в строке 6. В строке 7 определён DN суффикса запросов, обслуживаемых этой базой данных. В строке 8 указана директория, в которой будут размещаться файлы базы данных.
В строках 9 и 10 определены запись администратора базы данных и соответствующий пароль. На эту запись не налагаются ограничения контроля доступа, размера запрашиваемых данных или продолжительности выполнения запроса.
Строки с 12 по 14 устанавливают индексирование для различных атрибутов.
Строки с 16 по 24 определяют контроль доступа к записям в этой базе данных. Во всех записях с атрибутом userPassword изменять этот атрибут может пользователь, ассоциированный с этой же самой записью или с записью "admin". Этот атрибут может использоваться в целях аутентификации/авторизации, в ином случае он недоступен для чтения. Все остальные атрибуты доступны для изменения пользователем, ассоциированным с этой же самой записью или с записью "admin", но доступны для чтения всем пользователям, независимо от того, прошли они аутентификацию или нет.
В следующей секции нашего примера файла конфигурации определяется другая база данных BDB. Она обслуживает запросы к поддереву dc=example,dc=net, но управляется той же самой учётной записью, что и первая база данных. Обратите внимание, что если опустить строку 39, доступ на чтение всё равно будет предоставлен по глобальному правилу доступа в строке 4.
33. # Определение BDB для example.net 34. database bdb 35. suffix "dc=example,dc=net" 36. directory /usr/local/var/openldap-data-net 37. rootdn "cn=Manager,dc=example,dc=com" 38. index objectClass eq 39. access to * by users read
