The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Интерактивная система просмотра системных руководств (man-ов)

 ТемаНаборКатегория 
 
 [Cписок руководств | Печать]

slapd-config (5)
  • >> slapd-config (5) ( Русские man: Форматы файлов )
  •  

    НАЗВАНИЕ

    slapd-config - динамическая конфигурация slapd.  

    ОБЗОР

    /usr/local/etc/openldap/slapd.d  

    ОПИСАНИЕ

    Механизм манипуляции данными config управляет всеми сведениями о конфигурации демона slapd(8). Эти сведения о конфигурации также используются инструментами SLAPD: slapacl(8), slapadd(8), slapauth(8), slapcat(8), slapdn(8), slapindex(8) и slaptest(8).

    Механизм манипуляции данными config обратно совместим с прежним вариантом настройки через конфигурационный файл slapd.conf(5), но обеспечивает возможность изменять конфигурацию динамически во время работы сервера. При запуске slapd с настройками из конфигурационного файла slapd.conf динамические изменения также разрешены, но при перезагрузке сервера они не сохранятся. Динамические изменения сохраняются, только если slapd запущен с настройками из конфигурационной директории slapd.d.

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

    cn=Module
    настройки динамически подгружаемых модулей;
    cn=Schema
    определения схемы данных;
    olcBackend=xxx
    настройки, специфичные для механизмов манипуляции данными;
    olcDatabase=xxx
    настройки, специфичные для баз данных.

    Записи cn=Module могут присутствовать в конфигурации, только если slapd был собран с поддержкой динамически подгружаемых модулей. Может быть добавлено несколько записей, по одной для указания каждого конфигурируемого пути к файлам модулей. В каждой записи будут отдельные значения для каждого модуля, который загружается из указанного местоположения. У этих записей не может быть дочерних.

    Запись cn=Schema содержит все встроенные элементы схемы данных. Дочерние по отношению к ней записи содержат все определяемые пользователем элементы схемы данных. Для наборов схемы данных, загруженных из подключаемого файла, имя дочерней записи будет формироваться из имени того подключаемого файла, откуда был загружен набор схемы. Обычно первой записью в этом поддереве будет cn=core,cn=schema,cn=config.

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

    Записи olcDatabase содержат настройки, специфичные для одного конкретного экземпляра базы данных. У этих записей могут быть дочерние записи olcOverlay, соответствующие каким-либо наложениям, настраиваемым с этой базой данных. Записи olcDatabase и olcOverlay, при необходимости, также могут иметь различные дочерние записи для других настроек. Две специальные записи баз данных являются предопределёнными: одна запись для самой конфигурационной базы данных, вторая - для базы данных "frontend". Настройки в базе данных frontend наследуются остальными базами данных, если только они явно не переопределены в записи конкретной базы данных.

    Доступные параметры конфигурации обсуждаются ниже в разделах "Параметры глобальной конфигурации", "Общие параметры механизмов манипуляции данными" и "Общие параметры баз данных". Параметры задаются путём определения LDAP-атрибутов со специфичными для них значениями. В общем случае имена атрибутов LDAP совпадают с соответствующими ключевыми словами slapd.conf, с добавлением к ним префикса "olc".

    Разборщики для многих из этих атрибутов совпадают с теми, что используются для разбора ключевых слов из slapd.conf. Поэтому для тех ключевых слов slapd.conf, в которых разрешено указывать несколько значений, разделённых пробельными символами, в соответствующих атрибутах также разрешено указывать несколько значений параметра в одном значении атрибута. Однако, при чтении атрибутов через протокол LDAP отдельные значения параметра будут возвращены как отдельные значения атрибута.

    Параметры, специфичные для механизмов манипуляции данными, обсуждаются в man-страницах slapd-<backend>(5). Более подробную информацию о конфигурации slapd можно найти в "Руководстве администратора OpenLDAP".  

    ПАРАМЕТРЫ ГЛОБАЛЬНОЙ КОНФИГУРАЦИИ

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

    Данные параметры могут быть определены только в записи cn=config. У этой записи должен быть объектный класс olcGlobal.

    olcAllows: <features>
    Указывает набор возможностей, которые будут разрешены (по умолчанию никакие из перечисленных возможностей не разрешены). bind_v2 разрешает принимать запросы подсоединения bind LDAPv2. Имейте ввиду, что в slapd(8) по-настоящему не реализована поддержка протокола LDAPv2 (RFC 1777), который теперь является историческим (RFC 3494). bind_anon_cred разрешает анонимное подсоединение, когда удостоверяющие данные не пусты (например, если DN является пустым). bind_anon_dn разрешает подсоединение без проверки подлинности (анонимное), когда DN не является пустым. update_anon разрешает обработку операций обновления без проверки подлинности (анонимных) (по результатам контроля доступа и применения других административных ограничений). proxy_authz_anon разрешает обработку прокси-авторизационного контроля без проверки подлинности (анонимного) (по результатам контроля доступа, проверки полномочий и применения других административных ограничений).
    olcArgsFile: <filename>
    Имя файла (с указанием абсолютного пути к нему), который будет содержать параметры командной строки сервера slapd (имя программы и параметры).
    olcAttributeOptions: <option-name>...
    Определяет опции пометки атрибута или префиксы опций пометки/диапазона. Определения опций не должны оканчиваться на `-', а определения префиксов должны оканчиваться на `-'. Префикс `lang-' является предопределённым. Если вы используете директиву olcAttributeOptions, то префикс `lang-' больше не будет предопределённым, и если вы хотите, чтобы он был определён, его нужно указывать явно.

    Описание атрибута с опцией пометки является подтипом описания этого атрибута без опций. За исключением этого, определяемые данным способом опции не имеют специальных семантик. Префиксы, определяемые данным способом, работают также, как опции `lang-': они определяют префиксы для опций пометки, начинающихся с этого префикса. То есть, если вы определили префикс `x-foo-', вы можете использовать опцию `x-foo-bar'. Кроме того, в операциях поиска и сравнения, префикс или имя диапазона (оканчивающееся на `-') совпадает со всеми опциями, начинающимися с этого имени, а также с опцией, имя которой совпадает с именем диапазона без `-' в конце. То есть, `x-foo-bar-' совпадает с `x-foo-bar' и с `x-foo-bar-baz'.

    Согласно RFC 4520 опции, начинающиеся с `x-', зарезервированы для частных экспериментов. Другие опции должны быть зарегистрированы в IANA (смотрите раздел 3.5 RFC 4520). В OpenLDAP также есть встроенная опция `binary', но это опция передачи, а не пометки.

    olcAuthIDRewrite: <rewrite-rule>
    Используется системой аутентификации для преобразования простых имён пользователей в LDAP DN, используемые в целях авторизации. Задачи этого параметра аналогичны задачам параметра olcAuthzRegexp (смотрите ниже). rewrite-rule представляет собой набор правил для перезаписи данных, аналогичных тем, что описаны в man-странице slapo-rwm(5) (без префикса rwm-). Не следует смешивать параметры olcAuthIDRewrite и olcAuthzRegexp.
    olcAuthzPolicy: <policy>
    Используется для указания того, какие правила следует применять для прокси-авторизации. Прокси-авторизация позволяет клиентам аутентифицироваться на сервере с одними удостоверяющими данными пользователя, и при этом определить другую идентификационную сущность, которая будет использоваться в целях авторизации и контроля доступа. По существу, это позволяет пользователю A войти в систему как пользователь B с использованием пароля пользователя A. Флаг none отключает прокси-авторизацию. Это установка по умолчанию. При установленном флаге from будут использоваться правила из атрибута authzFrom авторизационного DN. При установленном флаге to будут использоваться правила из атрибута authzTo аутентификационного DN. При установленном флаге any (псевдоним устаревшего значения both) будет разрешено использовать правила из любого из перечисленных выше атрибутов до первого успешного применения (проверяются в порядке to, from). При установленном флаге all требуется, чтобы правила авторизации из обоих перечисленных выше атрибутов были успешно применены.

    Правила представляют собой механизмы для указания того, каким идентификационным сущностям разрешено выполнять прокси-авторизацию. Атрибут authzFrom в какой-либо записи определяет, каким иным пользователям разрешено выполнять прокси-логин в эту запись. Атрибут authzTo в какой-либо записи определяет, в качестве каких иных пользователей может авторизовываться данный пользователь. Пользователи могут без труда злоупотреблять использованием правил authzTo, если им разрешено записывать произвольные данные в этот атрибут. В общем случае атрибут authzTo должен быть защищён ACL так, чтобы его могли модифицировать только привилегированные пользователи. Значения атрибутов authzFrom и authzTo описывают идентификационную сущность или набор идентификационных сущностей; эти значения могут быть в пяти формах:
    ldap:///<base>??[<scope>]?<filter>
    dn[.<dnstyle>]:<pattern>
    u[.<mech>[/<realm>]]:<pattern>
    group[/objectClass[/attributeType]]:<pattern>
    <pattern>

    <dnstyle>:={exact|onelevel|children|subtree|regex}

    Первая форма - это корректно сформированный LDAP URI, в котором должны отсутствовать части <host>:<port>, <attrs> и <extensions>, таким образом, как в authzFrom, так и в authzTo поиск происходит локально. Вторая форма - это DN, с опциональным модификатором стиля. Модификатор может иметь значения exact, onelevel, children и subtree для диапазонов совпадений exact, onelevel, children и subtree (в этих случаях <pattern> должен быть нормализован в соответствии с правилами нормализации DN), или значение специального стиля regex, в этом случае <pattern> должен интерпретироваться как шаблон POSIX (''расширенного'') регулярного выражения, как описано в regex(7) и/или re_format(7). Шаблон * означает любое неанонимное DN. Третья форма - это идентификатор SASL с опциональными полями <mech> и <realm>, позволяющими указать механизм SASL, а также SASL-realm для тех механизмов, которые его поддерживают. До сих пор обсуждается, нужно ли позволять указывать SASL-механизм, и потому пользователям настоятельно не рекомендуется полагаться на эту возможность. Четвёртая форма - это спецификация группы, состоящая из ключевого слова group, за которым, опционально, следуют спецификации объектного класса objectClass группы и типа атрибута attributeType членства в группе. Поиск группы с DN, указанным в аргументе <pattern>, осуществляется с диапазоном base, и, в случае нахождения совпадения, DN пользователя ищется среди значений атрибута членства в группе attributeType. Для обеспечения обратной совместимости, если тип идентификационной сущности не был предоставлен, то есть присутствует только <pattern>, подразумевается непосредственно этот DN; как следствие, <pattern> подвергается нормализации DN. Поскольку интерпретация значений authzFrom и authzTo может влиять на безопасность, пользователям настоятельно рекомендуется явно устанавливать тип спецификации идентификационной сущности, который будет использоваться. Подмножество этих правил может быть использовано в качестве третьего аргумента в операторе olcAuthzRegexp (смотрите ниже); в частности, формы URI и dn.exact:<dn>.
    olcAuthzRegexp: <match> <replace>
    Используется системой аутентификации для преобразования простых имен пользователей, предоставляемых, например, подсистемой SASL, в LDAP DN, используемые в целях авторизации. Имейте ввиду, что для того чтобы считаться корректным, DN не обязательно должно указывать на существующую запись. При получении запроса авторизации от подсистемы SASL, берутся (если они доступны) SASL-значения USERNAME, REALM и MECHANISM и объединяются в имя в форме:
    UID=<username>[[,CN=<realm>],CN=<mechanism>],CN=auth

    Это имя сравнивается на соответствие POSIX (''расширенному'') регулярному выражению match, и, если совпадение успешно найдено, имя заменяется на строку replace. Если в регулярном выражении match имеется подстрока шаблона, заключённая в круглые скобки, например:
    UID=([^,]*),CN=.*

    то часть имени, соответствующая данному шаблону, будет помещена в нумерованную переменную подстановки $1. Если имеются другие подстроки шаблона в круглых скобках, соответствующие им подсовпадения будут помещены в переменные $2, $3 и т.д., до $9. Эти переменные подстановки могут быть в дальнейшем использованы в строке replace, например:
    UID=$1,OU=Accounts,DC=example,DC=com

    Получаемое в результате подстановки имя может быть либо DN, то есть строка с префиксом "dn:", либо LDAP URI. В последнем случае сервер будет использовать данный URI для выполнения поиска в своей базе (базах) данных, и, если в результате этого поиска будет найдена ровно одна запись, в качестве имени будет использоваться DN этой записи. В LDAP URI не должно быть компонентов hostport, attrs или extensions, но компонент filter является обязательным, например:
    ldap:///OU=Accounts,DC=example,DC=com??one?(UID=$1)

    Часть protocol этого URI обязательно должна быть ldap. Обратите внимание, что на данный поиск накладываются ограничения контроля доступа. В частности, у аутентификационной сущности должно быть право на доступ "auth".

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

    olcConcurrency: <integer>
    Указывает желаемый уровень параллелизма. Передаётся в базовую систему потоков в качестве подсказки. По умолчанию какая-либо подсказка не предоставляется. Этот параметр имеет смысл только на некоторых платформах, где нет однозначного соответствия между пользовательскими потоками и потоками ядра.
    olcConnMaxPending: <integer>
    Указывает максимальное число запросов в режиме ожидания (стоящих в очереди) для анонимной сессии. Если заявки поступают быстрее, чем сервер может их обработать, они будут помещаться в очередь, размер которой ограничен значением этого параметра. Если данный лимит превышен, сессия будет закрыта. Значение по умолчанию - 100.
    olcConnMaxPendingAuth: <integer>
    Указывает максимальное число запросов в режиме ожидания (стоящих в очереди) для сессии, при установке которой пользователь прошёл аутентификацию. Значение по умолчанию - 1000.
    olcDisallows: <features>
    Указывает набор возможностей, которые будут запрещены (разделяются пробельными символами). По умолчанию никакие из перечисленных возможностей не запрещены. bind_anon запрещает принимать анонимные запросы на подсоединение. Имейте ввиду, что данная установка не препятствует анонимному доступу к каталогу (смотрите "require authc"). bind_simple запрещает проводить аутентификацию методом простого подсоединения. tls_2_anon запрещает принудительный перевод сессии в анонимный статус при получении запроса операции StartTLS (смотрите также tls_authc). tls_authc запрещает выполнение операции StartTLS в сессии с проверкой подлинности (смотрите также tls_2_anon).
    olcGentleHUP: { TRUE | FALSE }
    При получении сигнала SIGHUP вместо немедленного отключения будет предпринята попытка 'корректного' отключения: slapd прекратит принимать новые соединения, но установленные текущими клиентами соединения закрывать не будет. Все дальнейшие операции записи, тем не менее, будут возвращать unwilling-to-perform. slapd завершит работу, когда все клиенты закроют свои соединения (если они вообще когда-либо это сделают), или, как и раньше, при получении сигнала SIGTERM. Такое поведение может оказаться полезным, если вы хотите остановить сервер и запустить новый экземпляр сервера slapd с другой базой данных, при этом корректно обслужив текущих активных клиентов. Значение по умолчанию - FALSE. Возможно, вы захотите использовать данный параметр совместно с параметром olcIdleTmeout.
    olcIdleTimeout: <integer>
    Указывает количество секунд ожидания перед принудительным закрытием простаивающего клиентского соединения. Значение 0 (по умолчанию) отключает эту функцию. Возможно, вы захотите также использовать параметр olcWriteTimeout.
    olcIndexIntLen: <integer>
    Указывает длину ключа для упорядоченных целочисленных индексов. В качестве ключей индекса будут использованы наиболее значимые байты двоичного представления целого числа. Длина ключа по умолчанию - 4, что обеспечивает точную индексацию для значений длиной в 31 бит. Для индексирования очень больших значений используется представление числа с плавающей точкой.
    olcIndexSubstrIfMaxlen: <integer>
    Указывает максимальную длину для индексов subinitial и subfinal. Функции индексирования будут обрабатывать только указанное количество символов из значения атрибута; все символы сверх этого количества будут проигнорированы. Значение по умолчанию - 4.
    olcIndexSubstrIfMinlen: <integer>
    Указывает минимальную длину для индексов subinitial и subfinal. Чтобы значение атрибута было обработано функциями индексирования, оно должно состоять как минимум из такого количества символов. Значение по умолчанию - 2.
    olcIndexSubstrAnyLen: <integer>
    Указывает длину, используемую для индексов subany. Чтобы значение атрибута было обработано функциями индексирования, оно должно состоять как минимум из такого количества символов. Значения атрибутов длиннее этой величины будут обработаны в виде сегментов, длина которых равна этой величине. Значение по умолчанию - 4. Индекс subany также будет использоваться при просмотре индексов subinitial и subfinal, когда строка в поисковом фильтре длиннее чем значение атрибута olcIndexSubstrIfMinlen.
    olcIndexSubstrAnyStep: <integer>
    Указывает величину шага, используемую при построении проверяемых значений для просмотров индексов subany. Данная величина задаёт смещение для сегментов строки поискового фильтра при выполнении просмотра индексов subany. Значение по умолчанию - 2. Например (в случае использования значений по умолчанию), операция поиска с фильтром "cn=*abcdefgh*" приведёт к генерации просмотров индексов для значений "abcd", "cdef" и "efgh".

    Примечание: Поддержка индексирования зависит от конкретного используемого механизма манипуляции данными. Также имейте ввиду, что при изменении этих установок обычно требуется удалить любые индексы, зависящие от этих параметров, и пересоздать их с помощью slapindex(8).

    olcListenerThreads: <integer>
    Указывает количество потоков, которые будут использоваться для менеджера соединений. Значение по умолчанию - 1, и этого обычно достаточно для процессоров вплоть до 16 ядер. В качестве значения должна быть установлена степень числа 2.
    olcLocalSSF: <SSF>
    Указывает фактор силы безопасности (Security Strength Factor, SSF), который будет задан для локальных сессий LDAP, например таких, которые устанавливаются на интерфейс ldapi://. Разъяснение значений SSF смотрите в описании опции minssf параметра olcSaslSecProps. Значение по умолчанию - 71.
    olcLogFile: <filename>
    Указывает файл, куда будут записываться сообщения журнала отладки. По умолчанию эти сообщения выдаются только в поток stderr и больше никуда не записываются. При указании параметра logfile сообщения посылаются и на stderr, и в заданный файл.
    olcLogLevel: <integer> [...]
    Указывает уровень, согласно которому отладочные сообщения и статистика операций будут журналироваться системой syslog (в настоящий момент сообщения направляются в канал LOG_LOCAL4 syslogd(8)). Эти уровни должны рассматриваться как определения подсистем, а не как последовательное увеличение подробности журналируемой информации. Некоторые высокоприоритетные сообщения журналируются независимо от того, какой уровень журналирования настроен (если настроен хотя бы какой-нибудь). Уровни журналирования являются аддитивными. Доступны следующие уровни:
    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) вывод отладочной информации репликации LDAPSync
    32768
    (0x8000 none) только сообщения, выводимые независимо от заданного уровня журналирования
    Требуемый уровень журналирования может быть задан одним целым числом (десятичным или шестнадцатеричным), которое является комбинацией нужных уровней журналирования (соединяемых через логическое ИЛИ). Также он может быть задан списком целых чисел (опять же соединяемых через логическое ИЛИ), либо списком ключевых слов, указанных в скобках в списке выше. Таким образом, директивы

        olcLogLevel: 129
        olcLogLevel: 0x81
        olcLogLevel: 128 1
        olcLogLevel: 0x80 0x1
        olcLogLevel: acl trace
    

    эквивалентны. Ключевое слово any может быть использовано в качестве сокращения для включения журналирования на всех уровнях (эквивалент для -1). Ключевое слово none, или эквивалентное ему целочисленное представление, приводит к тому, что в журнал будут попадать только сообщения, выводимые независимо от заданного уровня журналирования. Фактически, если параметра OlcLoglevel нет (или задан уровень 0), журналирования не происходит, поэтому для вывода высокоприоритетных сообщений требуется, как минимум, уровень none.

    olcPasswordCryptSaltFormat: <format>
    Указывает формат "соли", передаваемой вызову crypt(3) для генерации паролей {CRYPT} (смотрите параметр olcPasswordHash) при выполнении расширенной операции изменения пароля LDAP (RFC 3062).

    Передаваемая в качестве аргумента строка должна быть в формате sprintf(3) и может включать один (и только один) шаблон подстановки %s. Этот шаблон будет заменяться строкой случайных символов из диапазона [A-Za-z0-9./]. Например, аргумент "%.2s" обеспечивает "соль" из двух символов, а аргумент "$1$%.8s" указывает некоторым версиям crypt(3) использовать алгоритм MD5 и обеспечивает "соль" из восьми случайных символов. Значение по умолчанию - "%s", при котором обеспечивается "соль" из 31-го символа.

    olcPidFile: <filename>
    Имя файла (с указанием абсолютного пути), в котором будет содержаться идентификатор процесса сервера slapd (смотрите вызов getpid(2)).
    olcPluginLogFile: <filename>
    Имя файла (с указанием абсолютного пути), в котором будут содержаться сообщения журнала от плагинов SLAPI. Подробнее смотрите в slapd.plugin(5).
    olcReferral: <url>
    Указывает отсылку, возвращаемую в случаях, когда slapd(8) не может найти среди своих локальных баз данных подходящую для обработки запроса базу. Если у атрибута определено несколько значений, клиенту предоставляется каждое из указанных url.
    olcReverseLookup: TRUE | FALSE
    Включение/отключение обратных поисковых запросов имени клиента без подтверждения (по умолчанию - FALSE). Доступно, только если при компиляции указывалась опция --enable-rlookups.
    olcRootDSE: <file>
    Указывает имя файла LDIF(5), содержащего определённые пользователем атрибуты для корневой DSE. Эти атрибуты возвращаются вместе с обычно выдаваемыми slapd атрибутами.

    Корневая DSE - это запись с информацией о сервере и его возможностях, содержащейся в операционных атрибутах. У этой записи пустое DN, и получить её содержимое можно, например, таким запросом:
         ldapsearch -x -b "" -s base "+"
    Более подробную информацию можно найти в разделе 5.1 RFC 4512.

    olcSaslAuxprops: <plugin> [...]
    Указывает какие плагины инфраструктуры auxprop использовать для выполнения запросов аутентификации. По умолчанию список плагинов пуст, в этом случае используется только встроенная в slapd поддержка SASL. Обычно никаких других плагинов auxprop не требуется.
    olcSaslHost: <fqdn>
    Используется для указания полного доменного имени, используемого при обработке SASL.
    olcSaslRealm: <realm>
    Указывает SASL-realm. По умолчанию realm пуст.
    olcSaslSecProps: <properties>
    Используется для указания параметров безопасности Cyrus SASL. Флаг none (без указания каких-либо других параметров) приводит к сбросу параметров по умолчанию ("noanonymous,noplain"). Флаг noplain отключает механизмы, потенциально неустойчивые к простым пассивным атакам. Флаг noactive отключает механизмы, потенциально неустойчивые к активным атакам. Флаг nodict отключает механизмы, потенциально неустойчивые к простым атакам по словарю. Флаг noanonymous отключает механизмы, поддерживающие анонимные соединения. Флаг forwardsec требует обеспечения так называемой прямой секретности (forward secrecy) между сессиями. Флаг passcred требует использования механизмов, выполняющих передачу удостоверяющих данных клиента (и, для осуществления этого, разрешает механизмы, способные передавать удостоверяющие данные). Параметр minssf=<factor> указывает минимально приемлемый фактор силы безопасности (security strength factor) в виде целого числа, приблизительно отражающего эффективную длину ключа, используемого для шифрования. 0 (ноль) подразумевает отсутствие защиты, 1 подразумевает только защиту целостности данных, 56 разрешает использование DES или других слабых шифров, 112 разрешает использование Triple DES и других сильных шифров, 128 разрешает использование RC4, Blowfish и других современных сильных шифров. Значение по умолчанию - 0. Параметр maxssf=<factor> указывает максимально возможный фактор силы безопасности (security strength factor) в виде целого числа (смотрите описание опции minssf). Значение по умолчанию - INT_MAX. Параметр maxbufsize=<size> определяет максимально разрешённый размер буфера полученных уровней обеспечениябезопасности.
    Значение 0 отключает уровни обеспечения безопасности. Значение по умолчанию - 65536.
    olcServerID: <integer> [<URL>]
    Указывает целочисленный идентификатор от 0 до 4095 для данного сервера (ограничен тремя шестнадцатеричными цифрами). Идентификатор может быть указан как десятичным, так и шестнадцатеричным числом, в последнем случае перед значением ставится префикс "0x". Отличные от нуля идентификаторы требуются при репликации с несколькими главными серверами, причём каждый главный сервер должен иметь уникальный отличный от нуля идентификатор. Имейте ввиду, что это ограничение применяется также к отдельным главным серверам, базы данных которых входят в набор склеиваемых баз данных. При указании URL данная директива может быть задана несколько раз для предоставления полного списка серверов-участников и их идентификаторов. В предоставляемых URL должны использоваться полные доменные имена каждого сервера. Определённые в этом параметре идентификаторы используются в поле "replica id" всех CSN, генерируемых указанным сервером. Значение по умолчанию - ноль, что является верным лишь для репликации с одним главным сервером. Примеры:

            olcServerID: 1 ldap://ldap1.example.com
            olcServerID: 2 ldap://ldap2.example.com
    
    olcSockbufMaxIncoming: <integer>
    Указывает максимальный размер входящего LDAP PDU для анонимных сессий. Значение по умолчанию - 262143.
    olcSockbufMaxIncomingAuth: <integer>
    Указывает максимальный размер входящего LDAP PDU для сессий с проверкой подлинности. Значение по умолчанию - 4194303.
    olcTCPBuffer [listener=<URL>] [{read|write}=]<size>
    Определяет размер буфера TCP. Если в параметре указан только аргумент size, то он определяет глобальные значения TCP-буферов чтения и записи, которые связываются с любым открытым соединением, ожидающим приёма запросов. При указании аргумента listener, размер буфера назначается конкретному соединению. Квалификаторы read и write позволяют указать отдельно размеры буферов чтения и записи. Подробнее смотрите в man-странице tcp(7). Имейте ввиду, что некоторые операционные системы реализуют автоматическую подстройку TCP-буфера.
    olcThreads: <integer>
    Указывает максимальный размер основного пула потоков. Значение по умолчанию - 16, минимальное значение - 2.
    olcToolThreads: <integer>
    Указывает максимальное число потоков, используемых, когда slapd работает в режиме инструмента. Это число не должно превышать количества процессоров в системе. Значение по умолчанию - 1.
    olcWriteTimeout: <integer>
    Указывает количество секунд ожидания перед принудительным закрытием соединения, в котором выполняется незавершившаяся корректно операция записи. Это позволяет выходить из различных ситуаций, связанных с зависанием сетевого соединения. Значение 0 (по умолчанию) отключает эту функцию.
     

    ПАРАМЕТРЫ TLS

    Если slapd собран с поддержкой Transport Layer Security, можно задать некоторые дополнительные параметры.
    olcTLSCipherSuite: <cipher-suite-spec>
    Позволяет настроить то, какие шифры будут приниматься, а также порядок их предпочтения. Аргумент <cipher-suite-spec> должен представлять собой спецификацию шифров для используемой библиотеки TLS (OpenSSL, GnuTLS или Mozilla NSS). Примеры:
    OpenSSL:
    TLSCipherSuite HIGH:MEDIUM:+SSLv2
    GnuTLS:
    TLSCiphersuite SECURE256:!AES-128-CBC

    Для проверки того, какие шифры доступны в данной спецификации OpenSSL, используйте команду:

            openssl ciphers -v <cipher-suite-spec>
    

    В GnuTLS доступные спецификации можно найти в man-странице gnutls-cli(1) (смотрите описание опции --priority).

    В старых версиях библиотеки GnuTLS, где утилита gnutls-cli не поддерживала опции --priority, можно получить --- ограниченный --- список шифров командой:

            gnutls-cli -l
    

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

            static const SSLCipherSuiteInfo suiteInfo[]
    
    olcTLSCACertificateFile: <filename>
    Указывает файл, содержащий сертификаты всех удостоверяющих центров (Certificate Authorities), которым доверяет slapd.
    olcTLSCACertificatePath: <path>
    Указывает путь к директории, содержащей сертификаты всех удостоверяющих центров в отдельных файлах. Обычно задаётся только один из двух параметров: либо этот, либо TLSCACertificateFile. Если заданы оба параметра, будут рассмотрены сертификаты из обоих местоположений. При использовании библиотеки GnuTLS данный параметр не поддерживается.

    При использовании библиотеки Mozilla NSS аргумент <path> может содержать путь к базе данных сертификатов/ключей Mozilla NSS. Если аргумент <path> содержит пути и к базе данных сертификатов/ключей Mozilla NSS, и к файлам сертификатов удостоверяющих центров, OpenLDAP будет использовать базу данных сертификатов/ключей, а файлы сертификатов удостоверяющих центров проигнорирует.

    olcTLSCertificateFile: <filename>
    Указывает файл, содержащий сертификат сервера slapd.

    При использовании библиотеки Mozilla NSS и базы данных сертификатов/ключей (указанной в параметре olcTLSCACertificatePath), olcTLSCertificateFile определяет имя сертификата, который нужно использовать:

            olcTLSCertificateFile: Server-Cert
    
    Если используется токен, отличный от встроенного внутреннего, сначала указывается имя этого токена, за которым следует двоеточие:
            olcTLSCertificateFile: my hardware device:Server-Cert
    
    Для получения списка имён сертификатов используйте certutil -L:
            certutil -d /path/to/certdbdir -L
    
    olcTLSCertificateKeyFile: <filename>
    Указывает файл, содержащий закрытый ключ сервера slapd, соответствующий сертификату, хранящемуся в файле, указанном в параметре olcTLSCertificateFile. Если данный закрытый ключ защищён паролем, то этот пароль должен вручную вводиться при запуске slapd. Обычно закрытый ключ не защищается паролем, чтобы slapd мог запускаться без вмешательства оператора. В этом случае критически важное значение имеет защита самого файла с ключом.

    При использовании библиотеки Mozilla NSS, olcTLSCertificateKeyFile указывает имя файла, содержащего пароль для ключа, соответствующего сертификату, указанному в параметре olcTLSCertificateFile. Для отключения парольной защиты базы данных сертификатов/ключей можно использовать команду modutil. Например, если в параметре olcTLSCACertificatePath в качестве расположения базы данных сертификатов/ключей указано /etc/openldap/certdb, то для смены пароля на пустую строку используйте:

            modutil -dbdir /etc/openldap/certdb -changepw 'NSS Certificate DB'
    
    Вы должны знать предыдущий пароль, если он был установлен. Предупреждение о запуске браузера следует проигнорировать. На запрос нового пароля нажмите 'Enter'.

    olcTLSDHParamFile: <filename>
    В данной директиве указывается файл, содержащий параметры для обмена ключами по алгоритму Диффи-Хеллмана. Эти параметры требуются при использовании на сервере сертификата DSA, либо сертификата RSA в котором нет варианта использования ключа "шифрование ключа" ("key encipherment"). Имейте ввиду, что при задании этой директивы в некоторых не используемых по умолчанию наборах шифров может быть активирован анонимный обмен ключами по алгоритму Диффи-Хеллмана. Как правило, следует избегать анонимных обменов ключами, поскольку они не обеспечивают настоящую аутентификацию клиента или сервера, а также защиту от атак типа "man-in-the-middle". Вам следует добавить "!ADH" к списку наборов шифров чтобы гарантировать, что эти шифры не используются. При использовании Mozilla NSS параметры обмена ключами по алгоритму Диффи-Хеллмана всегда генерируются случайным образом, поэтому данная директива игнорируется.
    olcTLSProtocolMin: <major>[.<minor>]
    Указывает минимальную версию протокола SSL/TLS, которая будет использоваться для установки защищённого соединения. Если сервер не поддерживает как минимум данную версию протокола, переговоры SSL будут завершаться неудачей. Чтобы указать необходимость использования TLS 1.x или выше, задайте в качестве аргумента этого параметра 3.(x+1), то есть при

            olcTLSProtocolMin: 3.2
    

    требуется использовать TLS 1.1. Если в качестве минимально допустимой указана та версия протокола, которая не поддерживается данной реализацией OpenLDAP, то в итоге будет требоваться та наибольшая версия протокола, которую OpenLDAP поддерживает. Библиотека GnuTLS игнорирует этот параметр.

    olcTLSRandFile: <filename>
    Указывает файл, из которого будут получены случайные данные, если недоступен /dev/[u]random. Обычно задаёт имя сокета EGD/PRNGD. Для указания имени файла источника случайных данных также может быть использована переменная окружения RANDFILE. Библиотеки GnuTLS и Mozilla NSS игнорируют этот параметр.
    olcTLSVerifyClient: <level>
    Определяет, какие проверки требуется (и требуется ли вообще) выполнить с сертификатом клиента во входящей сессии TLS. В качестве аргумента <level> может быть использовано одно из следующих ключевых слов:
    never
    Это установка по умолчанию. slapd не будет запрашивать сертификат у клиента.
    allow
    Сертификат клиента будет запрошен. Если сертификат не был предоставлен, сессия будет продолжена нормальным образом. Если же был предоставлен плохой сертификат, он будет проигнорирован и сессия будет продолжена нормальным образом.
    try
    Сертификат клиента будет запрошен. Если сертификат не был предоставлен, сессия будет продолжена нормальным образом. Если же был предоставлен плохой сертификат, сессия будет немедленно завершена.
    demand | hard | true
    Эти ключевые слова эквивалентны, определены для поддержания совместимости. Сертификат клиента будет запрошен. Если сертификат не был предоставлен, либо был предоставлен плохой сертификат, сессия будет немедленно завершена.

    Обратите внимание, что при использовании с сессией TLS механизма аутентификации SASL EXTERNAL требуется, чтобы у клиента был действующий сертификат. Поэтому для работы аутентификации SASL EXTERNAL установка olcTLSVerifyClient должна отличаться от настройки по умолчанию.

    olcTLSCRLCheck: <level>
    Определяет, следует ли использовать предоставляемые удостоверяющими центрами списки отзыва сертификатов (Certificate Revocation List, CRL) для проверки того, не был ли отозван сертификат клиента. Для использования данного параметра требуется указание параметра olcTLSCACertificatePath. Библиотеки GnuTLS и Mozilla NSS игнорируют этот параметр. В качестве аргумента <level> может быть использовано одно из следующих ключевых слов:
    none
    Проверка CRL не выполняется.
    peer
    Выполняется проверка только CRL удостоверяющего центра, выдавшего сертификат клиента.
    all
    Выполняется проверка CRL всей цепочки сертификатов.
    olcTLSCRLFile: <filename>
    Указывает файл, содержащий список отозванных сертификатов, который нужно использовать для проверки того, не были ли отозваны сертификаты. Эта опция поддерживается только библиотеками GnuTLS и Mozilla NSS.
     

    ПАРАМЕТРЫ ДИНАМИЧЕСКИ ПОДГРУЖАЕМЫХ МОДУЛЕЙ

    Если slapd скомпилирован с опцией --enable-modules, то будут доступны связанные с модулями записи. Эти записи именуются как cn=module{x},cn=config и должны строиться на объектном классе olcModuleList. Для каждого пути olcModulePath должна быть создана одна запись. Механизм config автоматически генерирует индекс "{x}" в RDN, поэтому при первоначальной загрузке таких записей его можно опустить.
    olcModuleLoad: <filename>
    Указывает имя динамически подгружаемого модуля, который требуется загрузить. Аргумент filename может быть именем файла как с указанием, так и без указания абсолютного пути к нему. Поиск файлов без указания абсолютного пути будет производиться в директориях, указанных в атрибуте olcModulePath.
    olcModulePath: <pathspec>
    Определяет список директорий, в которых будет производиться поиск подгружаемых модулей. Обычно пути в списке разделяются двоеточиями, но это зависит от операционной системы. Значение по умолчанию - /usr/local/libexec/openldap, куда при стандартной установке OpenLDAP помещаются модули.
     

    ПАРАМЕТРЫ СХЕМЫ ДАННЫХ

    Определения схемы данных создаются в записях поддерева cn=schema,cn=config. Эти записи должны строиться на объектном классе olcSchemaConfig. Как отмечалось выше, сама запись cn=schema,cn=config является предопределённой, и любые значения, определяемые для неё, будут проигнорированы.

    olcAttributetypes: ( <oid>
     [NAME <name>] [DESC <description>] [OBSOLETE] [SUP <oid>] [EQUALITY <oid>] [ORDERING <oid>] [SUBSTR <oid>] [SYNTAX <oidlen>] [SINGLE-VALUE] [COLLECTIVE] [NO-USER-MODIFICATION] [USAGE <attributeUsage>] )
    Задаёт тип атрибута с использованием определённого в RFC 4512 синтаксиса LDAPv3. Разборщик slapd расширяет спецификацию RFC 4512, позволяя использовать строковые формы наряду с цифровыми OID для OID атрибута и OID синтаксиса атрибута (смотрите описание атрибута olcObjectIdentifier).

    olcDitContentRules: ( <oid>
     [NAME <name>] [DESC <description>] [OBSOLETE] [AUX <oids>] [MUST <oids>] [MAY <oids>] [NOT <oids>] )
    Задаёт правило содержимого DIT с использованием определённого в RFC 4512 синтаксиса LDAPv3. Разборщик slapd расширяет спецификацию RFC 4512, позволяя использовать строковые формы наряду с цифровыми OID для OID атрибута и OID синтаксиса атрибута (смотрите описание атрибута olcObjectIdentifier).

    olcObjectClasses: ( <oid>
     [NAME <name>] [DESC <description>] [OBSOLETE] [SUP <oids>] [{ ABSTRACT | STRUCTURAL | AUXILIARY }] [MUST <oids>] [MAY <oids>] )
    Задаёт объектный класс с использованием определённого в RFC 4512 синтаксиса LDAPv3. Разборщик slapd расширяет спецификацию RFC 4512, позволяя использовать строковые формы наряду с цифровыми OID для OID объектного класса (смотрите описание атрибута olcObjectIdentifier). По умолчанию объектные классы являются структурными ("STRUCTURAL").
    olcObjectIdentifier: <name> { <oid> | <name>[:<suffix>] }
    Определяет строковое имя, которое будет соответствовать заданному OID. Это строковое имя может использоваться вместо цифрового OID в определениях объектного класса и атрибута. Кроме того, определяемое имя может использоваться с суффиксом в форме ":xx", в этом случае будет применяться значение "oid.xx".

     

    ОБЩИЕ ПАРАМЕТРЫ МЕХАНИЗМОВ МАНИПУЛЯЦИИ ДАННЫМИ

    Параметры в записях механизмов манипуляции данными применяются только к базам данных определённого механизма манипуляции данными. Эти параметры поддерживаются всеми типами механизмов манипуляции данными. Запись должна именоваться olcBackend=<databasetype>,cn=config и строиться на объектном классе olcBackendConfig. В качестве <databasetype> должен быть одни из типов bdb, config, dnssrv, hdb, ldap, ldif, mdb, meta, monitor, ndb, null, passwd, perl, relay, shell или sql. В настоящий момент ни в одном механизме манипуляции данными параметры такого типа не реализованы, поэтому данную запись использовать не следует.  

    ПАРАМЕТРЫ БАЗЫ ДАННЫХ

    Параметры базы данных задаются в записи с именем olcDatabase={x}<databasetype>,cn=config, которая должна строиться на объектном классе olcDatabaseConfig. Механизм config автоматически генерирует индекс "{x}" в RDN, поэтому при первоначальной загрузке таких записей его можно опустить.

    Специальная база данных frontend всегда имеет номер "{-1}", а база данных config - "{0}".

     

    ГЛОБАЛЬНЫЕ ПАРАМЕТРЫ БАЗ ДАННЫХ

    Параметры этого раздела могут быть заданы в специальной базе данных "frontend", в этом случае они наследуются всеми остальными базами данных. Эти параметры могут быть переопределены в последующих установках каждой конкретной базы данных. Запись базы данных frontend должна именоваться olcDatabase=frontend,cn=config и строиться на объектном классе olcFrontendConfig.
    olcAccess: to <what> [ by <who> <access> <control> ]+
    Предоставляется доступ (указанный в аргументе <access>) к набору записей и/или атрибутов (указанных в аргументе <what>) одному или более выполняющим запрос (указанным в аргументе <who>). Если никаких списков контроля доступа не определено, политика по умолчанию позволяет кому угодно (всем) читать что угодно, но право вносить изменения в каталог предоставляется только rootdn (то есть, "olcAccess: to * by * read"). Более подробное описание можно найти в slapd.access(5) и в "Руководстве администратора OpenLDAP".

    Настройки контроля доступа в базе данных frontend добавляются в конец списка установок контроля доступа конкретных баз данных. rootdn базы данных всегда может читать и записывать ВСЁ в этой базе данных!

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

    olcDefaultSearchBase: <dn>
    Определяет базу поиска по умолчанию, которая будет использоваться, когда клиент предоставил поисковый запрос с отличным от base диапазоном и пустым базовым DN. На запросы с диапазоном base и пустым базовым DN этот параметр не влияет. Эту настройку можно выполнять только в записи frontend.
    olcExtraAttrs: <attr>
    В этом параметре перечисляются атрибуты, которые требуется добавлять к спискам атрибутов в поисковых запросах. Механизмы манипуляции данными, работающие с локальными хранилищами, возвращают механизму frontend запись целиком. Механизм frontend заботится о том, чтобы возвращать только запрошенные атрибуты, разрешённые в ACL. Однако, для некоторых функций, вроде контроля доступа и ему подобных, могут потребоваться специфичные атрибуты, которые не возвращаются автоматически механизмами манипуляции данными, работающими с удалёнными хранилищами (прокси-механизмы и им подобные). <attr> - это список атрибутов, которые требуются для внутренних целей и потому всегда должны быть получены, даже если они не запрашивались явно клиентами. Этот атрибут может иметь несколько значений.
    olcPasswordHash: <hash> [<hash>...]
    В этом параметре задаются один или несколько алгоритмов хэширования, которые будут использоваться для генерации паролей пользователей, хранящихся в атрибуте userPassword, при выполнении расширенной операции изменения пароля LDAP (RFC 3062). Аргумент <hash> должен быть одним из вариантов {SSHA}, {SHA}, {SMD5}, {MD5}, {CRYPT} или {CLEARTEXT}. Значение по умолчанию - {SSHA}.

    Варианты {SHA} и {SSHA} используют алгоритм SHA-1 (FIPS 160-1), последний из них - с "солью".

    Варианты {MD5}

    and {SMD5} используют алгоритм MD5 (RFC 1321), последний из них - с "солью".

    Вариант {CRYPT} использует вызов crypt(3).

    Вариант {CLEARTEXT} указывает на то, что новый пароль будет добавлен в атрибут userPassword в виде открытого текста.

    Имейте ввиду, что данный параметр не влияет на обработку значений атрибута userPassword при выполнении пользовательскими приложениями других операций LDAP, таких как Add, Modify или иных. Эту настройку можно выполнять только в записи frontend.

    olcReadOnly: TRUE | FALSE
    Этот параметр переводит базу данных в режим "только чтение" ("read-only"). На любые попытки внести изменение в базу данных будет возвращена ошибка "Unwilling to perform". Значение по умолчанию - FALSE. Имейте ввиду, что когда данный параметр установлен в TRUE в базе данных frontend, его нельзя сбросить без перезапуска сервера, поскольку дальнейшие записи в базу данных config будут отклонены.
    olcRequires: <conditions>
    Указывает набор условий, которые будет необходимо соблюдать (по умолчанию - none). Данная директива может быть определена глобально и/или на уровне базы данных; базы данных наследуют глобальные условия, таким образом условия, определённые на уровне базы данных, добавляются к глобальным. Условие bind требует выполнения операции подсоединения bind перед началом работы с каталогом (выполнением каких-либо операций). Условие LDAPv3 требует, чтобы в сессии использовался LDAP версии 3. Условие authc требует прохождения аутентификации перед началом работы с каталогом. Условие SASL требует прохождения SASL-аутентификации перед началом работы с каталогом. Условие strong требует прохождения строгой аутентификации перед началом работы с каталогом. Ключевое слово strong разрешает выполнение как аутентификации "simple" в защищённом режиме, так и SASL-аутентификации. Условие none может быть использовано для обозначения того, что никаких условий соблюдать не требуется (полезно для сброса глобального набора условий в конкретной базе данных); должно быть первым в списке условий.
    olcRestrict: <oplist>
    Указывает список операций, которые будут запрещены. Ограничения, заданные в определении конкретной базы данных, переопределяют любые ограничения, заданные в базе данных frontend. В качестве операций могут быть указаны add, bind, compare, delete, extended[=<OID>], modify, rename, search, либо специальные псевдо-операции read и write, которые объединяют все операции чтения и записи соответственно. Использование olcRestrict write эквивалентно olcReadOnly: TRUE (смотрите выше). Ключевое слово extended позволяет указать OID конкретной операции, которая будет запрещена.
    olcSchemaDN: <dn>
    Указывает уникальное имя для подзаписи подсхемы, управляющей записями на данном сервере. Значение по умолчанию - "cn=Subschema".
    olcSecurity: <factors>
    Определяет набор факторов силы безопасности (разделённых пробельными символами), которые будет необходимо соблюдать (описание факторов силы безопасности смотрите в опции minssf атрибута olcSaslSecprops). Данная директива может быть определена глобально и/или на уровне базы данных. ssf=<n> указывает общий фактор силы безопасности. transport=<n> указывает транспортный фактор силы безопасности. tls=<n> указывает фактор силы безопасности TLS. sasl=<n> указывает фактор силы безопасности SASL. update_ssf=<n> указывает общий фактор силы безопасности, необходимый для внесения изменений в каталог. update_transport=<n> указывает транспортный фактор силы безопасности, необходимый для внесения изменений в каталог. update_tls=<n> указывает фактор силы безопасности TLS, необходимый для внесения изменений в каталог. update_sasl=<n> указывает фактор силы безопасности SASL, необходимый для внесения изменений в каталог. simple_bind=<n> указывает фактор силы безопасности, необходимый для выполнения simple-аутентификации по имени пользователя и паролю. Имейте ввиду, что фактор transport является показателем безопасности, обеспечиваемой лежащим в основе транспортным уровнем, например, ldapi:// (и, наконец, IPSEC). Обычно он не используется.
    olcSizeLimit: {<integer>|unlimited}
    olcSizeLimit: size[.{soft|hard|unchecked}]=<integer> [...]
    Указывает максимальное число записей, которые будут возвращены в ответе на поисковый запрос. Ограничение по размеру по умолчанию - 500. Для того, чтобы задать отсутствие ограничений, используйте ключевое слово unlimited. Второй формат позволяет указать ограничения по размеру более точно. Дополнительные аргументы можно добавлять в одном значении атрибута, либо как разные значения атрибута. Назначение различных флагов смотрите в определении параметра olcLimits.
    olcSortVals: <attr> [...]
    Указывает список многозначных атрибутов, значения которых всегда будут поддерживаться в упорядоченном виде. Применение этого параметра позволяет повысить эффективность выполнения операций Modify, Compare, а также оценки поисковых фильтров с этими атрибутами. Результирующий порядок сортировки зависит от синтаксиса и правил соответствия атрибутов и может не соответствовать лексическому или какому-либо другому известному порядку сортировки. Эту настройку можно выполнять только в записи frontend.
    olcTimeLimit: {<integer>|unlimited}
    olcTimeLimit: time[.{soft|hard}]=<integer> [...]
    Указывает максимальное число секунд (реальных), которые будет тратить slapd, отвечая на поисковый запрос. Ограничение по времени по умолчанию - 3600. Для того, чтобы задать отсутствие ограничений, используйте ключевое слово unlimited. Второй формат позволяет указать ограничения по времени более точно. Дополнительные аргументы можно добавлять в одном значении атрибута, либо как разные значения атрибута. Назначение различных флагов смотрите в определении параметра olcLimits.

     

    ОБЩИЕ ПАРАМЕТРЫ БАЗ ДАННЫХ

    Параметры этого раздела применяются только к конкретной базе данных, для которой они определены. Они поддерживаются всеми типами механизмов манипуляции данными. Все глобальные параметры баз данных также могут быть использованы здесь.
    olcAddContentAcl: TRUE | FALSE
    Управляет тем, будет ли при операции Add выполняться проверка ACL над содержимым добавляемой записи. По умолчанию такая проверка отключена (FALSE). Подробнее о требованиях ACL для операций Add смотрите в man-странице slapd.access(5).
    olcHidden: TRUE | FALSE
    Параметр управляет тем, будет ли база данных использоваться для ответа на запросы. Скрытая база данных никогда не будет выбрана для ответа на какие-либо запросы. Кроме того, любой суффикс, настроенный для этой базы данных, будет игнорироваться при проведении проверок на конфликты с другими базами данных. Значение по умолчанию - FALSE.
    olcLastMod: TRUE | FALSE
    Параметр управляет тем, будет ли slapd автоматически поддерживать в записях атрибуты modifiersName, modifyTimestamp, creatorsName и createTimestamp. Он также управляет атрибутами entryCSN и entryUUID, которые требуются для поставщика репликации syncrepl. Значение по умолчанию - TRUE.
    olcLimits: <selector> <limit> [<limit> [...]]
    Указывает ограничения по времени и по размеру на основании того, кто является инициатором операции, или на основании базового DN. Аргумент <selector> может быть одним из
    anonymous | users | [<dnspec>=]<pattern> | group[/oc[/at]]=<pattern>

    где
    <dnspec> ::= dn[.<type>][.<style>]
    <type> ::= self | this
    <style> ::= exact | base | onelevel | subtree | children | regex | anonymous

    Тип DN self является типом по умолчанию и означает пользователя, от имени которого выполнено подсоединение, а this означает базовый DN операции. Выражение anonymous соответствует всем клиентам, не прошедшим аутентификацию. Выражение.B anonymous соответствует всем клиентам, не прошедшим аутентификацию. Выражение users соответствует всем аутентифицированным клиентам. Если указано только DN записи без каких-либо ключевых слов, подразумевается совпадение DN записи, от которой клиент произвёл аутентификацию, с этим DN (как при указании ключевого слова dn.exact). Если перед шаблоном DN указано опциональное ключевое слово dn, то оценка шаблона зависит от квалификатора стиля dn. При указании квалификаторов exact или base (которые являются синонимами), требуется полное совпадение DN клиента с DN шаблона; при указании квалификатора onelevel требуется, чтобы DN клиента совпадало с DN записи строго на один уровень ниже записи, указанной в шаблоне; при указании квалификатора subtree разрешается совпадение DN клиента с DN записи на любой глубине от указанной в шаблоне записи, в том числе и совпадение с DN самой этой записи; при указании квалификатора children разрешается совпадение DN клиента с DN записи на любой глубине от указанной в шаблоне записи, но не совпадение с DN самой этой записи; при указании квалификатора regex (значение по умолчанию) требуется совпадение с шаблоном, основанным на POSIX (''расширенном'') регулярном выражении. Наконец, квалификатор anonymous совпадает с операциями, выполняемыми без подсоединения; в этом случае поле pattern игнорируется; аналогично использованию формы anonymous условия <selector>. Выражение group с опциональными полями oc (объектный класс) и at (тип атрибута), за которым следует шаблон pattern, задаёт ограничения для любых DN, перечисленных в значениях атрибута at (по умолчанию - member) записи с групповым объектным классом oc (по умолчанию - groupOfNames), DN которой полностью совпадает с шаблоном pattern.

    В настоящее время поддерживаются ограничения size (по размеру) и time (по времени).

    Синтаксис для ограничений по времени - time[.{soft|hard}]=<integer>, где integer - это число секунд, которое будет затрачивать slapd при формировании ответа на поисковый запрос. Если клиент не запросил явно ограничение по времени, будет использовано ограничение soft; если запрошенное клиентом ограничение по времени превысило ограничение hard, вместо запрошенного будет использовано это ограничение. Если в качестве ограничения hard задано ключевое слово soft, ограничение soft будет использовано в любом случае; если в качестве ограничения hard задано ключевое слово unlimited, это означает, что ограничение hard не накладывается. Явно указанное при запросе ограничение по времени, меньшее или равное ограничению hard, будет удовлетворено. Если при задании ограничения не указывались квалификаторы, указанное значение присваивается ограничению soft, а в качестве ограничения hard устанавливается ключевое слово soft, таким образом сохраняется оригинальное поведение.

    Синтаксис для ограничений по размеру - size[.{soft|hard|unchecked}]=<integer>, где integer - это максимальное число записей, которые slapd будет возвращать в ответ на поисковый запрос. Если клиент не запросил явно ограничения по размеру, будет использовано ограничение soft; если запрошенное клиентом ограничение по размеру превысило ограничение hard, вместо запрошенного будет использовано это ограничение. Если в качестве ограничения hard задано ключевое слово soft, ограничение soft будет использовано в любом случае; если в качестве ограничения hard задано ключевое слово unlimited, это означает, что ограничение hard не накладывается. Явно указанное при запросе ограничение по размеру, меньшее или равное ограничению hard, будет удовлетворено. Квалификатор unchecked устанавливает ограничение на число записей-кандидатов, которые будет разрешено проверить при подготовке ответа на поисковый запрос. Смысл данного ограничения в том, что обработка поисковых фильтров, затрагивающих атрибуты, которые не были корректно проиндексированы, может привести к тому, что slapd(8) должен будет проверить большое количество записей-кандидатов на предмет их соответствия этим поисковым фильтрам. Ограничение unchecked предоставляет возможность прекращать такие операции ещё до того, как они начали выполняться. Если количество отобранных записей-кандидатов превысит ограничение unchecked, поиск будет прерван и выдано сообщение Unwilling to perform. Если в качестве ограничения unchecked задано ключевое слово unlimited, данное ограничение не применяется (поведение по умолчанию). Если в качестве ограничения unchecked задано ключевое слово disabled, поиск вообще не выполняется; это может быть использовано для того, чтобы запретить определённому набору пользователей выполнять поисковые запросы. Если при задании ограничения не указывались квалификаторы, указанное значение присваивается ограничению soft, а в качестве ограничения hard устанавливается ключевое слово soft, таким образом, сохраняется оригинальное поведение.

    В случае, если совпадение с условиями данной директивы не найдено, применяются глобальные ограничения. Значения по умолчанию соответствуют значениям директив olcSizeLimit и olcTimeLimit; для unchecked ограничения не назначаются.

    Если в запросе был указан элемент управления pagedResults, по умолчанию используется ограничение по размеру hard, поскольку при запросе конкретного размера страницы подразумевается явное указание количества записей, которые требуется вернуть. Однако, ограничение по размеру применяется к общему количеству записей, возвращаемых на поисковый запрос, а не к одной странице. Можно определить дополнительные ограничения по размеру с использованием синтаксиса size.pr={<integer>|noEstimate|unlimited}, где integer - это максимальный размер страницы, если не было задано явного ограничения. Ключевое слово noEstimate запрещает серверу выдавать расчётное общее число записей, которые могут быть возвращены (примечание: текущая реализация не выдаёт каких-либо расчётных данных). Ключевое слово unlimited показывает, что на размер страницы элемента управления pagedResults ограничений не налагается. Синтаксис size.prtotal={<integer>|unlimited|disabled} позволяет задать ограничение на общее число записей, которые вернёт запрос с элементом управления pagedResults. По умолчанию значение этого ограничения равно значению ограничения hard. Если оно задаётся явно, то integer - это максимальное число записей, которое может вернуть операция поиска с элементом управления pagedResults в целом. Использование ключевого слова unlimited позволяет снять ограничение на количество возвращаемых записей, то есть позволяет использовать элемент управления pagedResults как способ обойти ограничения по размеру, накладываемые на обычный поиск. Ключевое слово disabled отключает возможность использования данного элемента управления, то есть невозможно будет вернуть постраничные результаты. Имейте ввиду, что общее число записей, возвращаемых при использовании в запросе элемента управления pagedResults, не может превышать количества, установленного ограничением по размеру hard, накладываемым на обычный поиск, если только это количество не будет расширено в ограничении prtotal.

    olcMaxDerefDepth: <depth>
    Указывает максимальное число псевдонимов, которые будут разыменованы в ходе поиска записи. Используется для предотвращения бесконечного зацикливания при разыменовании ссылающихся друг на друга псевдонимов. Значение по умолчанию - 15.
    olcMirrorMode: TRUE | FALSE
    Данный параметр переводит базу данных-реплику в зеркальный ("mirror") режим. Операции обновления каталога будут приниматься от любого пользователя, а не только от пользователя, указанного в параметре updatedn. До установки данного параметра база данных уже должна быть настроена как потребитель репликации syncrepl. Данный режим также требует, чтобы был настроен параметр olcServerID (смотрите выше). Значение по умолчанию - FALSE.
    olcPlugin: <plugin_type> <lib_path> <init_function> [<arguments>]
    Настройка плагина SLAPI. Подробнее в man-странице slapd.plugin(5).
    olcRootDN: <dn>
    Указывает уникальное имя (DN), которое не попадает под действие контроля доступа или административных ограничений на операции с этой базой данных. Это DN может быть, а может и не быть ассоциировано с записью каталога. Пустое значение rootdn (по умолчанию) указывает на то, что административный доступ не предоставляется. Рекомендуется, чтобы rootdn указывалось, только когда это необходимо (например, при первоначальном наполнении базы данных). Если rootdn находится в пределах контекста именования (суффикса) базы данных, в параметре olcRootPW также может быть предоставлен пароль для простого подсоединения. Имейте ввиду, что при использовании репликации syncrepl всегда требуется, чтобы для базы данных было определено rootdn. olcRootDN базы данных cn=config по умолчанию соответствует самой записи cn=config.
    olcRootPW: <password>
    Указывает пароль (или хэш пароля) для rootdn. Этот пароль может быть установлен, только если rootdn находится в пределах контекста именования (суффикса) текущей базы данных. Данный параметр принимает пароли во всех указанных в RFC 2307 форматах значения атрибута userPassword, которые известны серверу (смотрите описание параметра olcPasswordHash), а также пароль в открытом виде. Для генерации хэша пароля может быть использована утилита slappasswd(8). Пароли в открытом виде и в формате {CRYPT} не рекомендуются. При пустом значении этого параметра (по умолчанию), подразумевается, что аутентификация rootdn производится иными средствами (например, SASL). Использование SASL рекомендуется.
    olcSubordinate: [TRUE | FALSE | advertise]
    Указывает, что текущая база данных является нижестоящей по отношению к другой базе данных другого механизма манипуляции данными. У нижестоящей базы данных может быть только один суффикс. Этот параметр может использоваться для склеивания нескольких баз данных в единый контекст именования (namingContext). Если суффикс текущей базы данных входит в контекст именования вышестоящей базы данных, поисковые запросы к вышестоящей базе данных будут также распространяться и на нижестоящую. У всех баз данных, объединённых в единый контекст именования, должны быть идентичные значения rootdn. Эта настройка не влияет на поведение других операций LDAP. В частности, нельзя использовать операцию moddn для перемещения записи из одной нижестоящей базы данных в другую нижестоящую в пределах одного контекста именования.

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

    Если утилиты slapcat(8), slapadd(8) или slapindex(8) используются с вышестоящей базой данных, также будут задействованы и все связанные нижестоящие базы данных, поддерживающие эти утилиты.

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

    Имейте ввиду, что функциональность subordinate внутренне реализована через наложение glue, и это наложение будет взаимодействовать с другими используемыми наложениями. По умолчанию наложение glue автоматически конфигурируется как последнее наложение соответствующей базы данных. Его позиция в настройках базы данных может быть сконфигурирована явно путём указания наложения glue в нужной позиции. Явное указание требуется, например, при использовании наложения syncprov, которое должно следовать за glue, чтобы работать со всеми склеиваемыми базами данных:

            dn: olcDatabase={1}mdb,cn=config
            olcSuffix: dc=example,dc=com
            ...
    
            dn: olcOverlay={0}glue,olcDatabase={1}mbdb,cn=config
            ...
    
            dn: olcOverlay={1}syncprov,olcDatabase={1}mdb,cn=config
            ...
    
    Подробнее о наложениях смотрите ниже в разделе "Наложения".
    olcSuffix: <dn suffix>
    Указывает DN суффикса запросов, которые будут передаваться этой базе данных. Можно задавать несколько суффиксов, но хотя бы один должен быть задан для каждого определения базы данных.

    Если суффикс одной базы данных находится "внутри" суффикса другой, определение базы данных с внутренним суффиксом должно быть раньше в конфигурационном файле. Для склеивания таких баз данных вместе можно использовать параметр olcSubordinate.

    olcSyncUseSubentry: TRUE | FALSE
    Указывает, что значение syncrepl contextCSN будет храниться не в корневой записи базы данных, а в дочерней к ней подзаписи. RDN подзаписи будет "cn=ldapsync". Значение по умолчанию, - FALSE, - говорит о том, что contextCSN хранится в корневой записи базы данных.
    olcSyncrepl: rid=<replica ID> provider=ldap[s]://<hostname>[:port] searchbase=<base DN> [type=refreshOnly|refreshAndPersist] [interval=dd:hh:mm:ss] [retry=[<retry interval> <# of retries>]+] [filter=<filter str>] [scope=sub|one|base|subord] [attrs=<attr list>] [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. Содержимое реплики синхронизируется с содержимым главной базы данных с использованием протокола синхронизации содержимого LDAP (LDAP Content Synchronization protocol). Детальную информацию о способах настройки slapd в качестве реплицируемой службы каталогов с использованием механизма репликации syncrepl можно найти в "Руководстве администратора OpenLDAP".

    Значение аргумента rid идентифицирует текущую директиву syncrepl в настройках сервера-потребителя репликации. Это неотрицательное целое число не более трёх десятичных цифр.

    В значении аргумента provider указывается сервер-поставщик репликации, на котором находится главная база данных, в виде LDAP URI. Если значение <port> не задано, используются стандартные номера портов LDAP (389 или 636).

    Содержимое реплики syncrepl представляет собой данные, полученные в результате операции поиска Search, и потому определяется с использованием спецификации этой операции. slapd-потребитель будет посылать поисковые запросы slapd-поставщику в соответствии с данной спецификацией поиска, включающей в себя, как и во всех нормальных спецификациях поиска, параметры searchbase, scope, filter, attrs, attrsonly, sizelimit и timelimit. Значение по умолчанию для scope - sub, для filter - (objectclass=*), а для searchbase нет значения по умолчанию. Значение по умолчанию для списка атрибутов attrs - "*,+", чтобы были возвращены все пользовательские и операционные атрибуты, attrsonly по умолчанию не установлен. Параметры sizelimit и timelimit в качестве значений принимают только ключевое слово "unlimited" и положительное целое число, значение по умолчанию для обоих - "unlimited". Имейте ввиду, что на стороне поставщика, как и при любой другой операции поиска, будут применяться все установленные поставщиком ограничения, касающиеся идентификационной сущности репликации, независимо от того, какие ограничения запрошены операцией синхронизации содержимого LDAP.

    У протокола синхронизации содержимого LDAP два типа операций. При типе операции refreshOnly следующая поисковая операция синхронизации периодически переносится на временной интервал (задаваемый аргументом interval, по умолчанию 1 день) после окончания каждой операции синхронизации. При типе операции refreshAndPersist поисковая операция синхронизации остаётся действующей (не завершается) на slapd поставщика. Дальнейшие обновления в главной базе данных будут генерировать сообщения searchResultEntry для slapd потребителя как ответы на выполняющийся запрос поисковой операции синхронизации. Если первоначальный поиск завершился неудачно из-за ошибки, следующая поисковая операция синхронизации будет запланирована через некоторый промежуток времени (задаваемый аргументом interval; по умолчанию - 1 день).

    Если во время репликации произошла ошибка, потребитель будет пытаться выполнить повторное соединение в соответствии со значением аргумента retry, который представляет собой список из пар <retry interval> и <# of retries>. Например,

    retry="60 10 300 3" позволяет потребителю выполнять повторные попытки подключения через каждые 60 секунд первые 10 раз, а затем через каждые 300 секунд ещё три раза, прежде чем прекратить попытки. Если в значении <# of retries> вместо числа стоит знак `+', это означает неопределённое количество попыток, пока повторное подключение не будет успешно установлено.

    На потребителе репликации LDAP Sync можно осуществлять проверку схемы данных, для этого аргументу schemachecking нужно задать значение on. Значение по умолчанию - off.

    Аргумент network-timeout определяет, как долго потребитель будет ожидать установки сетевого соединения с поставщиком. Аргумент timeout определяет, как долго потребитель будет ожидать выполнения первоначального запроса Bind после установки сетевого соединения. Значения по умолчанию для этих аргументов берутся из ldap.conf(5).

    Для bindmethod simple требуется задать аргументы binddn и credentials; использовать его следует только при наличии адекватных сервисов обеспечения безопасности (например, TLS или IPSEC). ПОМНИТЕ: удостоверяющие данные для простого подсоединения (аргумент credentials) должны указываться в открытом виде! Для bindmethod sasl требуется задать аргумент saslmech. В зависимости от используемого механизма можно указать аутентификационную идентификационную сущность и/или удостоверяющие данные в аргументах authcid и credentials. В аргументе authzid можно указать авторизационную идентификационную сущность. В аргументе secprops можно задать специфические параметры безопасности для подсоединения SASL (как в рассматриваемом выше атрибуте olcSaslSecProps). Отличный от значения по умолчанию SASL-realm можно задать в аргументе realm. На поставщике репликации, помимо того, чтобы разрешить идентификационной сущности syncrepl проходить аутентификацию, также следует предоставить этой идентификационной сущности соответствующие привилегии доступа к данным, которые будут реплицироваться (директива olcAccess), а также установить подходящие ограничения по времени и по размеру (директива olcLimits).

    В аргументе keepalive задаются значения idle, probes и interval, используемые для проверки работоспособности сокета; значение idle - это количество секунд, которое будет простаивать соединение, прежде чем TCP начнёт посылать пробы проверки работоспособности; значение probes - это максимальное число проб, посылаемых TCP перед тем, как закрыть соединение; значение interval - это интервал в секундах между посылками отдельных проб проверки работоспособности. Эти значения разрешено задавать лишь в некоторых системах; в остальных системах аргумент keepalive будет проигнорирован, и будут использованы общесистемные установки.

    Аргумент starttls указывает, что нужно использовать расширенную операцию StartTLS для установления сессии TLS до выполнения подсоединения (Bind) к поставщику. Если этот аргумент имеет значение critical, в случае неудачного завершения запроса StartTLS сессия будет прервана. Если этот аргумент имеет значение yes, в случае неудачного завершения запроса StartTLS сессия syncrepl будет продолжена без TLS. Аргумент tls_reqcert по умолчанию установлен в "demand", значения по умолчанию остальных параметров TLS sycnrepl аналогичны основным настройкам TLS slapd.

    Аргумент suffixmassage позволяет потребителю получать записи из удалённого каталога, контекст именования которого отличается от контекста именования локального каталога. Составная часть DN записей из удалённого каталога, совпадающая с DN в аргументе searchbase, будет заменена значением DN из аргумента suffixmassage.

    Чтобы не реплицировать записи целиком, потребитель может запросить сведения из журнала модификации данных. Такой режим работы называется delta syncrepl. Для его активации, кроме перечисленных выше аргументов, нужно указать параметры журнала, который будет использоваться, в аргументах logbase и logfilter. В аргументе syncdata нужно задать либо "accesslog", если журнал соответствует формату slapo-accesslog(5), либо "changelog", если он соответствует устаревшему формату changelog. Если аргумент syncdata не был указан, либо был указан со значением "default", то параметры работы с журналом игнорируются.

    olcUpdateDN: <dn>
    Данный параметр может применяться только к подчинённой базе данных. В нём указывается DN записи, которой разрешено вносить изменения (по результатам прохождения контроля доступа) в реплику. Требуется только в некоторых сценариях репликации, работающих в режиме посылок изменений. В общем случае, это DN не должно совпадать с rootdn главной базы данных.
    olcUpdateRef: <url>
    Указывает отсылку, которая будет возвращаться клиенту, когда slapd(8) получает запрос на модификацию локальной базы данных, которая является репликой. Если параметр указан несколько раз, клиенту будут предоставлены все url.

     

    ПАРАМЕТРЫ, СПЕЦИФИЧНЫЕ ДЛЯ КОНКРЕТНОГО ТИПА БАЗ ДАННЫХ

    В базах данных различных механизмов манипуляции данными могут быть настроены специфические параметры конфигурации; они описаны отдельно в man-страницах механизмов манипуляции данными. Обзор доступных механизмов манипуляции данными смотрите в man-странице slapd.backends(5).  

    НАЛОЖЕНИЯ

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

    Наложения должны быть настроены как записи, дочерние по отношению к записи конкретной базы данных. RDN записи наложения должно иметь форму olcOverlay={x}<overlaytype>. Запись должна строиться на объектном классе olcOverlayConfig. Механизм config автоматически генерирует индекс "{x}" в RDN, поэтому при первоначальной загрузке таких записей его можно опустить.

    Обзор доступных наложений смотрите в man-странице slapd.overlays(5).  

    ПРИМЕРЫ

    Короткий пример конфигурации в формате LDIF, которую можно применить с помощью утилиты slapadd(8):

    dn: cn=config
    objectClass: olcGlobal
    cn: config
    olcPidFile: /usr/local/var/run/slapd.pid
    olcAttributeOptions: x-hidden lang-
    
    dn: cn=schema,cn=config
    objectClass: olcSchemaConfig
    cn: schema
    
    include: file:///usr/local/etc/openldap/schema/core.ldif
    
    dn: olcDatabase=frontend,cn=config
    objectClass: olcDatabaseConfig
    objectClass: olcFrontendConfig
    olcDatabase: frontend
    # Подтипы от типа атрибута "name" (например, "cn" и "ou")
    # с опцией ";x-hidden" могут быть использованы в поиске/сравнении,
    # но не должны быть показаны при запросе. Смотрите slapd.access(5).
    olcAccess: to attrs=name;x-hidden by * =cs
    # Защита паролей. Смотрите slapd.access(5).
    olcAccess: to attrs=userPassword  by * auth
    # Доступ на чтение к остальным атрибутам и записям.
    olcAccess: to * by * read
    
    # Установка rootpw для базы данных config, теперь мы сможем подключиться.
    # Всем остальным доступ запрещён.
    dn: olcDatabase=config,cn=config
    objectClass: olcDatabaseConfig
    olcDatabase: config
    olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
    olcAccess: to * by * none
    
    dn: olcDatabase=bdb,cn=config
    objectClass: olcDatabaseConfig
    objectClass: olcBdbConfig
    olcDatabase: bdb
    olcSuffix: "dc=our-domain,dc=com"
    # Директория для файлов базы данных ДОЛЖНА существовать до запуска slapd.
    # Доступ к ней должны иметь только slapd и его инструменты.
    # Рекомендуемый режим доступа - 0700.
    olcDbDirectory: /usr/local/var/openldap-data
    # Обслуживаемые индексы
    olcDbIndex:     objectClass  eq
    olcDbIndex:     cn,sn,mail   pres,eq,approx,sub
    
    # Мы принимаем запросы от клиентов, не поддерживающих полную функциональность
    # и не обрабатывающих отсылки, поэтому выполняем удалённый поиск в их интересах
    dn: olcDatabase=ldap,cn=config
    objectClass: olcDatabaseConfig
    objectClass: olcLdapConfig
    olcDatabase: ldap
    olcSuffix: ""
    olcDbUri: ldap://ldap.some-server.com/
    

    Предположим, этот фрагмент LDIF сохранён в файле "config.ldif" и была создана директория /usr/local/etc/openldap/slapd.d. Тогда можно проинициализировать конфигурацию такой командой:

    slapadd -F /usr/local/etc/openldap/slapd.d -n 0 -l config.ldif
    

    Более полный пример конфигурации slapd с аннотациями приведён в "Руководстве администратора OpenLDAP".

    В качестве альтернативы, существующий файл slapd.conf может быть переконвертирован в новый формат с помощью slapd или любого slap-инструмента:

    slaptest -f /usr/local/etc/openldap/slapd.conf -F /usr/local/etc/openldap/slapd.d
    

     

    ФАЙЛЫ

    /usr/local/etc/openldap/slapd.conf
    конфигурационный файл slapd по умолчанию
    /usr/local/etc/openldap/slapd.d
    конфигурационная директория slapd по умолчанию
     

    СМОТРИТЕ ТАКЖЕ

    ldap(3), ldif(5), gnutls-cli(1), slapd.access(5), slapd.backends(5), slapd.conf(5), slapd.overlays(5), slapd.plugin(5), slapd(8), slapacl(8), slapadd(8), slapauth(8), slapcat(8), slapdn(8), slapindex(8), slappasswd(8), slaptest(8).

    "Руководство администратора OpenLDAP" (http://www.OpenLDAP.org/doc/admin/, http://pro-ldap.ru/tr/admin24/).  

    ПРИЗНАНИЕ ЗАСЛУГ

    Программное обеспечение OpenLDAP разработано и поддерживается проектом OpenLDAP <http://www.openldap.org/>. Программное обеспечение OpenLDAP является производным от релиза 3.3 LDAP Мичиганского Университета.


     

    Index

    НАЗВАНИЕ
    ОБЗОР
    ОПИСАНИЕ
    ПАРАМЕТРЫ ГЛОБАЛЬНОЙ КОНФИГУРАЦИИ
    ПАРАМЕТРЫ TLS
    ПАРАМЕТРЫ ДИНАМИЧЕСКИ ПОДГРУЖАЕМЫХ МОДУЛЕЙ
    ПАРАМЕТРЫ СХЕМЫ ДАННЫХ
    ОБЩИЕ ПАРАМЕТРЫ МЕХАНИЗМОВ МАНИПУЛЯЦИИ ДАННЫМИ
    ПАРАМЕТРЫ БАЗЫ ДАННЫХ
    ГЛОБАЛЬНЫЕ ПАРАМЕТРЫ БАЗ ДАННЫХ
    ОБЩИЕ ПАРАМЕТРЫ БАЗ ДАННЫХ
    ПАРАМЕТРЫ, СПЕЦИФИЧНЫЕ ДЛЯ КОНКРЕТНОГО ТИПА БАЗ ДАННЫХ
    НАЛОЖЕНИЯ
    ПРИМЕРЫ
    ФАЙЛЫ
    СМОТРИТЕ ТАКЖЕ
    ПРИЗНАНИЕ ЗАСЛУГ


    Поиск по тексту MAN-ов: 




    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру