Глава 6. Конфигурация LDAP

В этой главе умопомрачительно подробно описываются все параметры и атрибуты/директивы, с помощью которых управляются системы LDAP, охватываемые данным руководством (по крайней мере, так обязательно будет). В частности, речь здесь пойдёт об OLC (cn=config) и файле slapd.conf (настройка сервера OpenLDAP), файле ldap.conf (настройка клиента и, частично, сервера OpenLDAP), а также о настройке ApacheDS (server.xml).

Если Вам нужно что-нибудь простенькое применительно к OpenLDAP, воспользуйтесь примерами.

В версиях 2.3 и 2.4 OpenLDAP были представлены существенные изменения, самое значительное из которых состоит в том, что, хотя slapd.conf всё ещё поддерживается (по состоянию на 2.4), OpenLDAP постепенно движется в сторону On-Line конфигурации (OLC), часто упоминаемой в литературе как конфигурация cn=config или slapd.d. Этот метод позволяет производить большинство изменений настроек без необходимости останавливать и снова запускать LDAP-сервер. Конвертация slapd.conf и использование OLC (cn=config) описывается здесь, и постепенно этот способ конфигурации станет основным при описании настроек OpenLDAP в данном руководстве. Обычно запись в cn=config состоит из атрибутов, имена которых эквивалентны названиям директив slapd.conf с добавлением префикса "olc", например, директива access при использовании в системах с cn=config становится атрибутом olcAccess.

Содержание

1. 6.1 Обзор конфигурации
   1. 6.1.1 Переход к использованию и использование OLC (cn=config/slapd.d)
   2. 6.1.1.1 Обзор OLC (cn=config)
   3. 6.1.1.2 Переконвертация slapd.conf в OLC (cn=config)
   4. 6.1.1.3 Макет OLC (cn=config)
   5. 6.1.1.4 Использование OLC (cn=config) (чтение, модификация)
      1. 6.1.1.4.1 Общие замечания по конфигурации OLC (cn=config)
      2. 6.1.1.4.2 Добавление/удаление наборов схемы данных при использовании OLC (cn=schema,cn=config)
      3. 6.1.1.4.3 Добавление/удаление ACP/ACL при использовании OLC (cn=config)
      4. 6.1.1.4.4 Добавление/удаление модулей при использовании OLC (cn=module{0},cn=config)
      5. 6.1.1.4.5 Добавление/удаление баз данных при использовании OLC (olcDatabase={Z}xxx,cn=config)
      6. 6.1.1.4.6 Добавление/удаление наложений при использовании OLC (olcOverlay={Z}xxx,olcDatabase= {Z}xxx,cn=config)
2. 6.2 Список атрибутов (OLC (cn=config)) и директив (slapd.conf)
3. 6.3 Атрибуты (OLC (cn=config)) и директивы (slapd.conf) глобального раздела
4. 6.3.1 Атрибуты (OLC (cn=config)) и директивы (slapd.conf) TLS
5. 6.4 Атрибуты (OLC (cn=config)) и директивы (slapd.conf) раздела backend
6. 6.5 Атрибуты (OLC (cn=config)) и директивы (slapd.conf) раздела database
7. 6.5.1 Атрибуты (OLC (cn=config)) и директивы (slapd.conf) overlay
8. 6.6 Директивы ldap.conf
9. 6.7 Конфигурация ApacheDS

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

6.1 Обзор конфигурации

Параметры конфигурации по своей специфике подразделяются на глобальные (global) и относящиеся к конкретной базе данных или DIT (database). Следующие замечания могут оказаться полезными:

1. В OpenLDAP версии 2.3 представлено существенное, хотя и необязательное (в версии 2.4), изменение метода, по которому директивы конфигурации могут быть применены к slapd. Начиная с версии 2.3 можно продолжать использовать существующий файл slapd.conf, ЛИБО один раз провести конвертацию этого файла и перейти к использованию конфигурации времени исполнения (on-line configuration, OLC), также называемой конфигурацией zero down-time, cn=config или slapd.d (немудрено и запутаться). Чтобы не загромождать текст, в этом руководстве она называется просто OLC. Если коротко, обычно запись в OLC (cn=config) состоит из атрибутов, имена которых эквивалентны (за двумя или тремя исключениями) названиям директив slapd.conf с добавлением префикса "olc", например, директива access при использовании в системах с OLC (cn=config) становится атрибутом olcAccess. В последующих описаниях показаны обе формы: атрибут OLC (cn=config) и директива slapd.conf. Процедура конвертации, дальнейшее использование и эффекты от применения этого метода конфигурации описаны здесь. Макет OLC (cn=config) и описание записей этого DIT даны здесь.

2. Атрибуты записи глобальных настроек (директивы глобального раздела файла slapd.conf) применяются к LDAP-серверу в целом. Обычно они включают в себя параметры окружения, такие как местонахождение файлов. В OLC они определяются с использованием объектного класса olcGlobal в записи cn=config.

3. Атрибуты (директивы) формируют строгую иерархию: директивы глобального раздела могут быть переопределены директивами из разделов backend или database, в свою очередь директивы из раздела backend могут быть переопределены директивами из разделов database. Если атрибут (директива) были указаны в глобальном разделе и в дальнейшем не подвергались переопределению, сфера их действия (влияния) распространяется на все нижестоящие разделы (backend и database).

4. В файле slapd.conf все строки, начинающиеся с #, считаются комментариями и игнорируются.

5. В файле slapd.conf пустые строки игнорируются. Если же строка начинается с пробельного символа, она считается продолжением предыдущей строки. Это может стать причиной неприятностей. Будьте очень осторожны. В целом, slapd.conf очень привередлив по отношению к пробелам и пустотам.

6. Каждое DIT со своими свойствами определяется в записи базы данных (с использованием базового объектного класса olcDatabaseConfig) или в разделе database файла slapd.conf.

7. Для каждого DIT должна присутствовать отдельная запись базы данных (раздел database файла slapd.conf); например, если требуется обслуживать два корневых DN, — dc=example,dc=com и dc=example,dc=net, — то должно быть две записи баз данных (раздела database файла slapd.conf). Может присутствовать любое количество таких записей (разделов). Каждая база данных имеет свой номер. О том, как нумеруются записи баз данных в OLC (cn=config), смотрите здесь. В slapd.conf первому разделу database присваивается номер базы данных 1, второму — 2, и так далее.

8. Обычно данные конфигурации находятся в:

   # OLC (cn=config)
   [fc] /etc/openldap/slapd.d
   [bsd] /usr/local/etc/openldap/slapd.d
   
   # slapd.conf
   [fc] /etc/openldap
   [bsd] /usr/local/etc/openldap
   

6.2 Список атрибутов (OLC (cn=config)) и директив (slapd.conf)

Если не указано иное, все приведённые ниже атрибуты/директивы могут присутствовать как в записи/разделе глобальных настроек, так и в записях/разделах backend или database.

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

Атрибут olcAccess (директива access to)
Атрибут olcAllows (директива allow)
Атрибут olcArgsFile (директива argsfile)
attributetype (olcAttributeTypes)
concurrency (olcConcurrency)
conn_max_pending (olcConnMaxPending)
conn_max_auth (olcConnMaxPendingAuth)
defaultaccess
defaultsearchbase (olcDefaultSearchBase)
disallow (olcDisallows)
gentlehup (olcGentleHUP)
idletimeout (olcIdleTimeout)
include
index (olcDbIndex)
logfile (olcLogFile)
loglevel (olcLogLevel)
olcModuleLoad (moduleload)
modulepath (olcModulePath)
objectclass (olcObjectClasses)
password-hash (olcPasswordHash)
pidfile (olcPidFile)
referral (olcReferral)
replicationinterval
require (olcRequires)
reverse-lookup (olcReverseLookup)
rootDSE (olcRootDSE)
schemadn (olcSchemaDN)
security (olcSecurity)
ServerID (olcServerID)
sizelimit (olcSizeLimit)
sockbuf_max_incoming (olcSockBufMaxIncoming)
sockbuf_max_incoming_auth (olcSockBufMaxIncomingAuth)
threads (olcThreads)
timelimit (olcTimeLimit)

Директивы TLS/SSL (глобальный раздел)

Обзор сервера TLS — что такое сервер TLS

Директивы сервера (поставщика)

TLSCACertificateFile (olcTLSCACertificateFile)
TLSCertificateFile (olcTLSCertificateFile)
TLSCertificateKeyFile (olcTLSCertificateKeyFile)
TLSCipherSuite (olcTLSCipherSuite)
TLSRandFile (olcTLSRandFile)
TLSEphemeralDHParamFile (olcTLSDHParamFile)
TLSVerifyClient (olcTLSVerifyClient)

Директивы клиента (потребителя)

Обзор сервера TLS — что такое клиент TLS
TLS_CACERT

Директивы backend

1. backend (olcBackend)

Директивы database

1. access to (olcAccess)
2. database (olcDatabase)
3. index
4. mirrormode (olcMirrorMode)
5. overlay (olcOverlay)
6. readonly (olcReadOnly)
7. replica (olcReplica)
8. replogfile (olcReplogFile)
9. require (olcRequires)
10. rootdn (olcRootDN)
11. rootpw (olcRootPW)
12. suffix (olcSuffix)
13. syncrepl (olcSyncrepl)
14. updatedn (olcUpdateDN)
15. updateref (olcUpdateref)

6.3 Директивы глобального раздела (OLC (cn=config) и slapd.conf)

Во всех случаях соответствия директив первой показана форма конфигурации OLC (cn=config), а затем (в скобках) форма slapd.conf. Мы сделали это намеренно, чтобы отразить переход к конфигурации в форме OLC (cn=config). В OLC (cn=config) глобальные атрибуты определяются в записи cn=config, основанной на объектном классе olcGlobal. Смотрите также макет OLC и формат записей.

olcAccess (access to)

Формат:

olcAccess: to <what> [ by <who> [<accesslevel>] [<control>] ]+
access to <what> [ by <who> [<accesslevel>] [<control>] ]+

С помощью набора атрибутов olcAccess (директив access to) создаётся то, что принято называть списками контроля доступа (Access Control List, ACL) или политиками контроля доступа (Access Control Policy, ACP).

В атрибуте olcAccess (директиве access to) предоставляется доступ (указываемый в <accesslevel>) к набору записей и/или атрибутов (указываемому в <what>) по одному или нескольким критериям того, кто производит запрос, либо по его характеристикам (определяются в by <who>). Необязательный параметр <control> определяет условие выхода для каждого элемента by <who>, при его отсутствии значение по умолчанию — stop.

Один или несколько атрибутов olcAccess (директив access to) могут быть включены либо в запись cn=config (раздел глобальных настроек), либо в настройки конкретного DIT (путём добавления в запись olcDatabase={Z}xxx,cn=config или в раздел database slapd.conf), либо и туда, и туда. Если атрибут olcAccess (директива access to) определен в записи (разделе) глобальных настроек, то он аддитивно применяется к любым ACL во всех последующих разделах database (DIT). Данная особенность может оказаться как полезным сокращением, так и ночным кошмаром.

Атрибуты olcAccess (директивы access to) обрабатываются по очереди до первого совпадения с условием <what>. Если такое совпадение было обнаружено, процесс продолжается поиском совпадений по всем элементам by <who> того атрибута (директивы), у которого найдено совпадение. Если какое-то из этих условий совпало, выполняется необязательная часть <control> (по умолчанию stop) и результат контроля доступа будет успешным (success). Если же по окончании проверки атрибута olcAccess (директивы access to) не было обнаружено ни одного совпадения с условиями by <who>, то выполняется действие stop, заданное в неявном элементе управления <control>, и результат контроля доступа будет неудачным (fail). Если условие <what> атрибута olcAccess (директивы access to) не совпало, то управление передаётся следующему ACL и процесс повторяется. Если были проверены все ACL и условия <what> ни одного из них не совпали, то выполняется действие stop, заданное в неявном элементе управления <control>, и результат контроля доступа будет неудачным (fail).

Директивы access (ACL) невероятно комплексны. Они позволяют установить очень тонкий контроль над тем, кто, к каким объектам и атрибутам, на каких условиях может получить доступ. Обратная сторона этой комплексности и мощи — то, что очень легко получить ужасающе неверные атрибуты olcAccess (директивы access to). Вы должны тщательно тестировать директивы ACL на доступ со всеми возможными правами. Для этого существует slapacl — автоматизированное средство для тестирования доступа к определенным атрибутам и записям на основе текущих атрибутов olcAccess (директив access to).

В следующих разделах сначала даётся описание параметров, как самих по себе, так и с некоторыми ограниченными примерами, а затем приводится несколько рабочих примеров, иллюстрирующих основные моменты. Возможно, лучший способ понять эту директиву — это, пройдя вскользь по деталям описаний, перейти к примерам, а затем вернуться и перечитать раздел с описаниями для более ясного понимания. Альтернативная стратегия — пройти от начала до конца по разделу примеров (глава 5), в котором поочерёдно наращиваются и используются списки ACL, описанные в рабочих примерах.

# Если тестовый dn - "ou=something,cn=my name,dc=example,dc=com"
# то в результате поиска совпадений $1 = 'my name'
# поскольку первая часть регулярного выражения не заключена в круглые скобки ()
access to dn.regex="ou=[^,]+,cn=([^,]+),dc=example,dc=com"
 by dn.exact,expand="cn=$1,dc=example,dc=com"

Примеры:

# ПРИМЕЧАНИЕ: Это только фрагменты - точки (...) 
#       указывают, что в этом месте может быть больше данных
#       точек не должно быть в итоговой директиве

# доступ к определённым атрибутам
access to attrs=userpassword,homephone ...

# OPENLDAP ДО ВЕРСИИ 2.1
# доступ к определённому DN и всем нижестоящим уровням
# type пропущено, таким образом по умолчанию regex
# распространяется на все DN ниже определённого DN (в том числе и сам этот DN)
access to dn="ou=people,dc=example,dc=com" ...

# OPENLDAP НАЧИНАЯ С ВЕРСИИ 2.2
# функциональный эквивалент предыдущего примера начиная с версии 2.2
# этот же формат (не являющийся значением по умолчанию) будет работать
# и с версиями до 2.2
# доступ к определённому DN и всем нижестоящим уровням
access to dn.subtree="ou=people,dc=example,dc=com" ...

# доступ только к одному уровню ниже определённого DN
access to dn.one="ou=people,dc=example,dc=com" ...

# доступ только к одному уровню ниже определённого DN
# и только к атрибуту userpassword
access to dn.one="ou=people,dc=example,dc=com" attrs=userpassword 
 ...

... by anonymous auth

access to 
 dn.regex="^cn=([^,]+),ou=People,dc=example,dc=com$"
# Предположим, cn=my entry,ou=People,dc=example,dc=com
# У $1 будет значение 'my entry', которое будет подставлено ниже
 by dn.exact,expand="cn=$1,ou=People,dc=example,dc=com" read

# Две следующие директивы access функционально идентичны
# и разрешают доступ на чтение на всё, находящееся
# ниже уровня example.com
 access to dn.children="dc=example,dc=com"
  by dn.base,expand="$0" read
	
access to dn.children="dc=example,dc=com"
  by dn.base,expand="$1" read

# Простой формат IPv4
peername.ip=192.168.2.0

# Формат IPv4 с маской сети
peername.ip=192.168.2.0%255.255.255.0

# IPv4 только от порта 5000
peername.ip=192.168.2.0{5000}

# Простой формат IPv6
peername.ipv6=2001:db8::1

# IPv6 только от порта 5000
peername.ipv6=2001:db8::1{5000)

# Указывает, что пользователь, запрашивающий доступ, 
# ДОЛЖЕН использовать сессию TLS/SSL с минимальной длиной 
# ключа шифрования 40 (разрешены шифры ЭКСПОРТНОГО класса)
 by tls_ssf=40

# Указывает, что пользователь, запрашивающий доступ, 
# ДОЛЖЕН использовать сессию TLS/SSL с минимальной длиной 
# ключа шифрования 128 (исключаются шифры ЭКСПОРТНОГО класса
# и многие другие, например DES)
 by tls_ssf=128
 
# Указывает, что пользователь, запрашивающий доступ, 
# ДОЛЖЕН использовать SASL с любым шифрованием
# (без конкретных требований)
 by sasl_ssf=1
 
# Указывает, что пользователь, запрашивающий доступ, 
# ДОЛЖЕН использовать SASL или TLS/SSL с длиной
# ключа шифрования 64 или более
 by ssf=64

[self]{<level>|<priv>}

{=|+|-}{w|r|s|c|x}+

Вот и всё, что касается директивы access. Довольно просто, не правда ли?!

Рабочие примеры olcAccess (access to)

1. Вводные замечания
2. Доступ по умолчанию
3. Предоставление доступа только пользователям, прошедшим проверку подлинности
4. Использование групп для контроля доступа
5. Общие и персональные адресные книги

Вводные замечания

Для начала несколько общих замечаний об атрибутах olcAccess (директивах access to):

1. При подключении от имени olcRootDN (rootdn) (администратора) того DIT, к которому происходит подключение, подразумевается наличие волшебных прав и все правила ACL игнорируются. olcRootDN/rootdn может делать что угодно с чем угодно. Запрещённых приёмов нет.

2. Если не установлено атрибутов olcAccess (директив access to), по умолчанию OpenLDAP неявно устанавливает:

   access to *
          by anonymous  read
          by *          none
   

   Пояснение:

   1. access to * означает, что политика применяется ко всем атрибутам и записям в DIT.
   2. by anonymous read означает, что кто угодно (не прошедший аутентификацию) может читать любые значения DIT, включая пароли.
   3. by * none указывает, что ни у какого пользователя (*) нет прав на доступ. OpenLDAP также неявно оканчивает каждую директиву access этим правилом (даже если оно уже указано явно) для предотвращения случайных ошибок — всё, что не попадает под действие явно заданных условий, не имеет никаких прав. Если установлена только эта директива access (либо вообще никаких директив access, что по умолчанию означает установку этой директивы), то запись в DIT сможет осуществить только rootdn (администратор) со своим rootpw.

3. Во всех форматах параметров, содержащих выражения в стиле dn, и где стиль dn определён как regex (регулярное выражение), предоставляемый шаблон pattern используется для поиска совпадений с регулярным выражением; таким образом, при использовании в качестве шаблона dn="dc=example,dc=com" будет найдено совпадение со всеми записями поддерева, например, "ou=people,dc=example,dc=com", но при этом будет использовано гораздо больше ресурсов CPU, чем при получении тех же результатов с помощью выражения dn.subtree="dc=example,dc=com". Разумнее избегать использования regex, если можно применить другой формат, — даже если для этого потребуется более одной директивы.

4. Директивы access обрабатываются при каждом доступе к каталогу, начиная с той, которая определена первой — порядок очень важен. Эти директивы являются аддитивными: вторая добавляется к функциональности первой, третья — ко второй и так далее. Проверка ACL останавливается, как только найдено совпадение с правилом by <who> и доступ был либо предоставлен, либо запрещён.

5. Стиль составления директив access. Формат допускает свободную форму и, для облегчения понимания, директива может быть записана как:

   access to <parameters>
          by <parameters>
          by <parameters>
          ...
   

   Примечание 1: Каждая новая строка в составе директивы должна начинаться с отступа хотя бы в один пробельный символ.

   Примечание 2: Хотя формат записи атрибута olcAccess (директивы access to) очень гибок, не разрешается помещать комментарии (строки, начинающиеся с #) в каком-либо месте атрибута olcAccess (директивы access to).

6. Для каталога может быть установлен один или несколько атрибутов olcAccess (директив access), и каждое из правил by <who> может иметь параметр <control>. Пример:

   # Первая директива access
   # форма OLC (cn=config)
   olcAccess: to <what>
          by <who1> break
          by <who2> read
          ...
   # форма slapd.conf
   access to <what>
          by <who1> break
          by <who2> read
          ...
   # Вторая директива access
   access to <what>
          by <who> write
   

   Пояснения:

   1. В первой директиве access при выполнении условия by <who1> break процесс обработки немедленно переходит ко второй директиве access. break означает 'перейти к следующему ACL'.
   2. В первой директиве access при выполнении условия by <who2> read процесс обработки останавливается (stop) с результатом success и вторая директива access не будет выполнена. stop является значением по умолчанию в отсутствие какого-либо явно заданного значения <control>. Эту строку можно было бы записать как by <who2> read stop, если для Вас это более понятно.

7. Каждый атрибут olcAccess (директива access) завершается (обычно) неявным условием by * none stop. Если не обнаружено совпадений со всеми предыдущими условиями by <who>, то это неявное условие прекращает процесс обработки ACL. В большей мере при использовании атрибутов olcAccess (директив access) в разделе глобальных настроек (хотя и в других случаях тоже), это может привести не к тем результатам, которых мы ожидаем, например:

   # Раздел глобальных настроек
   # Первая директива access
   # форма OLC (cn=config)
   olcAccess: to <what>
          by <who1> read
          ...
   # форма slapd.conf
   access to <what>
          by <who1> read
          ...
   # Раздел database
   # Вторая директива access
   access to <what>
          by <who> write
   

   В первой директиве access при выполнении условия by <who1> процесс обработки останавливается (stop) и обращение ко второй директиве не произойдёт никогда.

   Чтобы обращение ко второй директиве access выполнялось для всех обращений, не совпавших с условием by <who1>, нужно использовать следующую форму:

   # Раздел глобальных настроек
   # Первая директива access
   access to <what>
          by <who1> read
          by * break
          ...
   # Раздел database
   # Вторая директива access
   access to <what>
          by <who> write
   

   Параметр break в первой директиве access приведёт к тому, что всем обращениям, не совпавшим с условием by <who1>, не будет предоставлено никаких конкретных прав доступа (разрешающих или запрещающих) и обработка будет передана второй директиве access.

Примеры

Предоставление доступа только пользователям, прошедшим проверку подлинности

Приведённые ниже ACL поэтапно представлены в примерах настройки каталога (глава 5), с их помощью постепенно ограничивается доступ к целевой DIT.

Политика безопасности: Мы требуем, чтобы все пользователи проходили аутентификацию; запрещаем доступ к атрибуту, в котором хранится пароль, для всех, за исключением владельца записи; разрешаем только владельцу записывать (вносить изменения) в свою запись; все остальные пользователи, прошедшие аутентификацию, могут читать все записи (за исключением паролей, как было сказано выше). Данный пример подразумевает использование как минимум объектного класса person (для атрибута userpassword):

# ACL1
# форма OLC (cn=config)
olcAccess: to attrs=userpassword
       by self       write
       by anonymous  auth
       by *          none
# форма slapd.conf
access to attrs=userpassword
       by self       write
       by anonymous  auth
       by *          none
# ACL2
access to *
       by self       write
       by users      read
       by *          none

Пояснения:

1. ACL1

   1. access to attrs=userpassword в ACL1 означает, что данная политика применяется только к атрибуту userpassword.
   2. by self write в ACL1 предоставляет только владельцу записи (прошедшему аутентификацию с использованием userpassword этой записи) права записывать в этот атрибут.
   3. by anonymous auth в ACL1 предоставляет анонимному пользователю доступ к этому атрибуту только в целях аутентификации (используется внутри OpenLDAP для аутентификации).
   4. by * none в ACL1 означает, что всё, что не попало под действие предыдущих условий, не разрешается; таким образом, любой пользователь, не являющийся владельцем записи, не может записывать в userpassword, и даже пользователи, прошедшие аутентификацию, не могут читать данный атрибут (нет прав на чтение).

2. ACL2

   1. access to * в ACL2. Поскольку директивы access являются аддитивными, политика данной директивы применяется ко всем атрибутам всех записей, за исключением атрибута userpassword, для которого в предыдущей директиве определены собственные правила.
   2. by self write в ACL2 предоставляет права производить запись в атрибуты, попадающие под действие данной директивы, только владельцу записи. Поскольку в ACL1 владельцу (self) предоставлен доступ к атрибуту userpassword, он может записывать в любые атрибуты своей записи.
   3. by users read в ACL2 предоставляет любому пользователю, прошедшему аутентификацию, права на чтение всех атрибутов, попадающих под действие данной директивы, (то есть всех, за исключением userpassword, политика доступа к которому определена в ACL1). Если бы мы хотели предоставить права на чтение всех атрибутов (за исключением userpassword) анонимным пользователям, можно было бы использовать условие by anonymous read.
   4. by * none в ACL2. В данном случае это означает, что пользователи, не являющиеся владельцем записи, не могут производить запись в какой бы то ни было атрибут, а пользователи, не прошедшие аутентификацию, не могут читать, производить поиск или выполнять любую другую операцию над какой-либо записью или атрибутом.

Анонимный доступ для пользователей из локальной сети

В данном примере для всех пользователей, подключающихся вне пределов нашей локальной сети, требуется прохождение аутентификации; пользователям, подключающимся из локальной сети, разрешается анонимный доступ на чтение; запрещается доступ к атрибуту, в котором хранится пароль, всем, за исключением владельца записи; только владельцу разрешается записывать (вносить изменения) в свою запись; все остальные пользователи, прошедшие аутентификацию, могут читать все записи (за исключением паролей, как было сказано выше). Данный пример подразумевает использование как минимум объектного класса person (для атрибута userpassword), а также то, что в нашей локальной сети используются адреса из пространства частных локальных сетей класса C: 192.168.1.0-255 (192.168.1.0/24):

# ACL1
# форма OLC (cn=config)
olcAccess: to attrs=userpassword
       by self                 write
       by anonymous            auth
       by *                    none
# форма slapd.conf
access to attrs=userpassword
       by self                 write
       by anonymous            auth
       by *                    none
# ACL2
access to *
       by self                 write
       by users                read
       by peername=192.168.1.* read
       by *                    none

Пояснения:

1. ACL1

   1. access to attrs=userpassword в ACL1 означает, что данная политика применяется только к атрибуту userpassword.
   2. by self write в ACL1 предоставляет только владельцу записи (прошедшему аутентификацию с использованием userpassword этой записи) права записывать в этот атрибут.
   3. by anonymous auth в ACL1 предоставляет анонимному пользователю доступ к этому атрибуту только в целях аутентификации (используется внутри OpenLDAP для аутентификации).
   4. by * none в ACL1. В данном случае это означает, что любой пользователь, не являющийся владельцем записи, не может записывать в userpassword, и даже пользователи, прошедшие аутентификацию, не могут читать данный атрибут (нет прав на чтение).

2. ACL2

   1. access to * в ACL2. Поскольку директивы access являются аддитивными, политика данной директивы применяется ко всем атрибутам всех записей, за исключением атрибута userpassword, для которого в предыдущей директиве определены собственные правила.
   2. by self write в ACL2 предоставляет права производить запись в атрибуты, попадающие под действие данной директивы (то есть все атрибуты), только владельцу записи. Поскольку в ACL1 владельцу (self) предоставлен доступ к атрибуту userpassword, он может записывать в любые атрибуты своей записи.
   3. by users read в ACL2 предоставляет любому пользователю, прошедшему аутентификацию, права на чтение всех атрибутов, попадающих под действие данной директивы, (то есть всех, за исключением userpassword, политика доступа к которому определена в ACL1). Если бы мы хотели предоставить права на чтение всех атрибутов (за исключением userpassword) анонимным пользователям, можно было бы использовать условие by anonymous read.
   4. by peername=192.168.1.* в ACL2 предоставляет любому пользователю, подключающемуся из локальной сети (с ip-адреса из диапазона от 192.168.1.0 до 192.168.1.255), права анонимно читать все атрибуты, попадающие под действие данной директивы, (то есть все, за исключением userpassword). В данной директиве используется проверка на основе регулярного выражения, её можно записать как peername.regex=192.168.1.*.
   5. by * none в ACL2. В данном случае это означает, что пользователи, не являющиеся владельцем записи, не могут записывать в какой бы то ни было атрибут, а пользователи, не прошедшие аутентификацию, не могут читать, производить поиск или выполнять любую другую операцию над какой-либо записью или атрибутом.

Ограничение доступа к частям DIT

Построение политики контроля доступа (Access Control Policy, ACP, известную также как ACL) на основании корпоративной политики безопасности (круто!), которая гласит:

1. Владелец записи каталога имеет право просматривать ВСЕ атрибуты своей записи, включая пароли.

2. Сотрудники отдела Human Resources должны иметь право обновлять ЛЮБУЮ запись, но не должны иметь прав на чтение или запись паролей пользователей.

3. В записях каталога атрибуты carlicence, homepostaddress и homephone не должны быть доступны для чтения кому бы то ни было, за исключением сотрудников отдела Human Resources, а также владельца записи каталога.

4. Все пользователи должны проходить аутентификацию (анонимный доступ не разрешается).

5. Сотрудники отдела IT должны иметь право обновлять или изменять атрибут, в котором хранится пароль, во всех записях каталога.

Данный пример подразумевает использование как минимум объектного класса inetorgperson (для carlicense и других атрибутов), а также то, что существует две группы пользователей, называемые hrpeople и itpeople:

# ACL1
# форма OLC (cn=config)
olcAccess: to attrs=userpassword
       by self       write
       by anonymous  auth
       by group.exact="cn=itpeople,ou=groups,dc=example,dc=com"
                     write
       by *          none
# форма slapd.conf
access to attrs=userpassword
       by self       write
       by anonymous  auth
       by group.exact="cn=itpeople,ou=groups,dc=example,dc=com"
                     write
       by *          none
# ACL2
access to attrs=carlicense,homepostaladdress,homephone
       by self       write
       by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com"
                     write
       by *          none
# ACL3
access to *
       by self       write
       by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com"
                     write
       by users      read
       by *          none

Пояснения:

1. ACL1

   1. access to attrs=userpassword в ACL1 означает, что данная политика применяется только к атрибуту userpassword.
   2. by self write в ACL1 предоставляет владельцу записи (прошедшему аутентификацию с использованием userpassword этой записи) права производить запись в этот атрибут.
   3. by anonymous auth в ACL1 предоставляет анонимному пользователю доступ к этому атрибуту только в целях аутентификации (используется внутри OpenLDAP для аутентификации и остаётся невидимым извне).
   4. by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write в ACL1 предоставляет права на запись в данный атрибут любому члену группы itpeople. Тип exact указывается для повышения производительности: таким образом исключается использование типа regex, который является значением по умолчанию, если никакой конкретный тип не указан.
   5. by * none в ACL1. В данном случае это означает, что любой пользователь, не являющийся владельцем записи и не состоящий в группе itpeople, не может записывать в userpassword, и даже пользователи, прошедшие аутентификацию, не могут читать данный атрибут (нет прав на чтение).

2. ACL2

   1. access to attrs=carlicense,homepostaladdress,homephone в ACL2 означает, что данная политика применяется только к этим атрибутам.
   2. by self write в ACL2 предоставляет владельцу записи (прошедшему аутентификацию с использованием userpassword этой записи) права записывать в эти атрибуты.
   3. by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write в ACL2 предоставляет права на запись в данные атрибуты любому члену группы hrpeople.
   4. by * none в ACL2. В данном случае это означает, что любой пользователь, не являющийся владельцем записи и не состоящий в группе hrpeople, не может записывать в эти атрибуты, и даже пользователи, прошедшие аутентификацию, не могут читать данные атрибуты (нет прав на чтение).

3. ACL3

   1. access to * в ACL3. Поскольку директивы access являются аддитивными, политика данной директивы применяется ко всем атрибутам всех записей, за исключением атрибутов userpassword, carlicense, homepostaladdress и homephone, для которых в предыдущих директивах определены собственные правила.
   2. by self write в ACL3 предоставляет владельцу записи права производить запись в атрибуты, попадающие под действие данной директивы. Поскольку в ACL1 и ACL2 владельцу (self) предоставлен доступ к другим атрибутам, он может производить запись в любые атрибуты своей записи.
   3. by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write в ACL3 предоставляет любому члену группы hrpeople права на запись во все атрибуты, определённые в данном ACL, а также, согласно предыдущему ACL2, в атрибуты carlicense, homepostaladdress и homephone, но не даёт этой группе прав на чтение и запись в атрибут userpassword (это запрещено в ACL1).
   4. by users read в ACL3 предоставляет любому пользователю, прошедшему аутентификацию, права на чтение всех атрибутов, попадающих под действие данной директивы, (то есть всех, за исключением тех, которые определены в ACL1 и ACL2). Если бы мы хотели предоставить права на чтение всех атрибутов (за исключением атрибутов, определённых в ACL1 и ACL2) анонимным пользователям, можно было бы использовать условие by anonymous read.
   5. by * none в ACL3. В данном случае это означает, что пользователи, не являющиеся владельцем записи и не состоящие в группе hrpeople, не могут производить запись в какой бы то ни было атрибут, а пользователи, не прошедшие аутентификацию, не могут читать, производить поиск или выполнять любую другую операцию над какой-либо записью или атрибутом.

Общая и персональные адресные книги

В данном примере создаются общая и персональные адресные книги, как показано на рисунке:

Будет введена следующая политика:

1. Для доступа к каталогу все пользователи должны пройти аутентификацию.

2. Все пользователи, прошедшие аутентификацию, могут просматривать общую адресную книгу (в ветке customers).

3. Только сотрудники отдела продаж (члены группы salespeople) могут записывать в адресную книгу customers.

4. Члены группы itpeople могут создавать в каждой записи в ветке people дочернюю запись addressbook.

5. Владелец персональной адресной книги может читать и записывать в неё — никто больше не может даже просматривать addressbook (за исключением членов группы itpeople, которые могут создать addressbook, но не могут создавать записи внутри неё). Пользователю не разрешено удалять запись addressbook.

6. Сотрудники отдела IT должны иметь возможность обновлять или изменять пароли во всех записях каталога.

7. Сотрудники отдела Human resources (группа hrpeople) должны иметь возможность обновлять или изменять все атрибуты всех пользовательских записей, кроме атрибута userpassword, и не должны иметь возможности читать или изменять персональные адресные книги пользователей (addressbook).

Данный пример подразумевает использование как минимум объектного класса inetorgperson (для carlicense и других атрибутов), а также то, что существует две группы пользователей, называемые hrpeople и itpeople. Записи в адресных книгах обоих типов addressbook и customers используют объектный класс inteorgperson:

# Примечания к ACL
# Эти дополнительные примечания относятся к OpenLDAP версии 2.4:
# 1. В настоящий момент используется ключевое слово attrs вместо attr
#   (это позволяет уменьшить количество предупреждающих сообщений).
# 2. При использовании регулярных выражений нужно удалить модификатор expand, 
#    поскольку OpenLDAP 2.4 отклоняет некоторые (но не все) ACL,
#    содержащие этот модификатор.
# 3. Проверки, производимые OpenLDAP 2.4, гораздо более жесткие,
#    они отклоняют ACL 8, так как в нём содержатся атрибуты,
#    которые будут добавлены позже.
# 4. Если в условии by используется ключевое слово exact и
#    замена с применением регулярного выражения,
#    то должен использоваться модификатор expand.
# ACL1
# форма OLC (cn=config)
olcAccess: to attrs=userpassword
  by self       write
  by anonymous  auth
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by *          none
# форма slapd.conf
access to attrs=userpassword
  by self       write
  by anonymous  auth
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by *          none

# ACL2
# разрешаем читать addressbook владельцу и itpeople; остальные не могут её просматривать
access to dn.regex="^ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
    attrs=entry
  by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" read
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by users none

# ACL3
# разрешаем itgroup создавать addressbook, но не просматривать записи
access to dn.regex="cn=[^,]+,ou=people,dc=example,dc=com$"
   attrs=children
  by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write
  by users none break

# ACL4
# разрешаем создавать записи в своей собственной addressbook;
# остальные не могут получить к ней доступ, требуются права на запись
# в атрибут ENTRY (ACL5 или ACL6A) и дочерние (CHILDREN) записи данной записи (ACL4)
access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
   attrs=children
  by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" write
  by users none

# ACL5 - требуется только до версии 2.2
# разрешаем создание записей в своей addressbook;
# остальные не могут получить к ней доступ, требуются права на запись
# в атрибут ENTRY (ACL5 или ACL6A) и дочерние (CHILDREN) записи данной записи (ACL4)
#access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
#   attrs=entry
#  by dn.regex="cn=$1,ou=people,dc=example,dc=com" write
#  by users none


# ACL6 - требуется только до версии 2.2
# разрешаем создание записей в своей addressbook;
# остальные не могут получить к ней доступ
#access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
#   filter=(objectclass=inetorgperson)
#  by dn.regex="cn=$1,ou=people,dc=example,dc=com" write
#  by users none

# ACL6A - в версиях 2.2+ сразу два ACL, - ACL5 и ACL6, - заменяются данным ACL
access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$"
   attrs=entry,@inetorgperson
  by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" write
  by users none

# ACL7
# разрешаем sales создание записей в customers
# пользователи, прошедшие аутентификацию получают доступ только на чтение
access to dn.one="ou=customers,dc=example,dc=com"
   attrs=children
  by group.exact="cn=salespeople,ou=groups,dc=example,dc=com" write
  by users read

# ACL8
access to attrs=carlicense,homepostaladdress,homephone
  by self       write
  by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write
  by *          none
# ACL9
access to *
  by self       write
  by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write
  by users      read
  by *          none

Пояснения:

1. ACL1

   1. access to attrs=userpassword в ACL1 означает, что данная политика применяется только к атрибуту userpassword.
   2. by self write в ACL1 предоставляет владельцу записи (прошедшему аутентификацию с использованием userpassword этой записи) права производить запись в этот атрибут.
   3. by anonymous auth в ACL1 предоставляет анонимному пользователю доступ к этому атрибуту только в целях аутентификации (используется внутри OpenLDAP для аутентификации).
   4. by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write в ACL1 предоставляет права на запись в данный атрибут любому члену группы itpeople. Тип exact указывается для повышения производительности: таким образом исключается использование типа regex, который является значением по умолчанию, если никакой конкретный тип не указан.
   5. by * none в ACL1 означает, что любой пользователь, не являющийся владельцем записи и не состоящий в группе itpeople, не может записывать в userpassword, и даже пользователи, прошедшие аутентификацию, не могут читать данный атрибут (нет прав на чтение).

2. ACL2

   1. access to dn.regex="^ou=addressbook,cn=([^,]+),ou=people, dc=example,dc=com$" в ACL2 использует регулярное выражение, для того, чтобы данное правило применялось к записям, начинающимся с addressbook (^ — знак привязки к началу строки). В переменной $1 будет сохраняться содержимое cn пользователя (выражение в скобках = ([^,]+)).
   2. attrs=entry в ACL2 — это псевдоатрибут, указывающий на запись (то есть в данном условии речь идёт о самой addressbook, а не о записях внутри addressbook).
   3. by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" read в ACL2 предоставляет владельцу записи (прошедшему аутентификацию с использованием userpassword этой записи) права на чтение addressbook. $1 выполняет подстановку cn пользователя (полученного из приведённого выше regex. Эффект от данного ACL — разрешение только самому владельцу записи просматривать персональную адресную книгу addressbook.
   4. by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write в ACL2 предоставляет права записывать в данную запись любому члену группы itpeople. Это требуется для создания записи addressbook. Для создания записи требуются права на осуществление записи в псевдоатрибут entry и в псевдоатрибут children родительской записи (смотрите права на children в ACL3).
   5. by users none в ACL2. В данном случае это означает, что пользователи, не являющиеся владельцем записи и не состоящие в группе itpeople, не могут читать данную запись (нет прав на чтение).

3. ACL3 — children-часть ACL2

   1. access to dn.regex="cn=[^,]+,ou=people,dc=example,dc=com$" в ACL3 использует регулярное выражение для соответствия ЛЮБЫМ записям в ветке people (у regex НЕТ привязки к началу строки с помощью знака ^). Это используется для предоставления children-доступа (доступа к записям-потомкам) к каждой записи в ветке cn.
   2. attrs=children в ACL3 — это псевдоатрибут, указывающий на все записи-потомки записей, расположенных в ветке people (то есть, в данном случае, addressbook).
   3. by group.exact="cn=itpeople,ou=groups,dc=example,dc=com" write в ACL3 предоставляет членам группы itpeople права записывать в записи-потомки любой записи в ветке people. Чтобы разрешить создание записи, требуются права производить запись для псевдоатрибута entry самой записи (ACL2) и для псевдоатрибута children родительской записи — это как раз и есть children-часть данного разрешения. Этот ACL и ACL2 позволяют только членам группы itpeople (но НЕ самому пользователю-владельцу) создавать и удалять запись addressbook.
   4. by users none break в ACL3 означает, что пользователи, не являющиеся владельцем записи и не состоящие в группе itpeople, не могут читать запись addressbook (нет прав на чтение). break очень важен, поскольку он позволяет OpenLDAP продолжить тестирование. Без break тестирование данного ACL будет оканчиваться неудачей при прохождении OpenLDAP уровня addressbook и до перехода к записям в ветке addressbook, то есть владелец адресной книги (cn), так же, как и все остальные пользователи, получит права доступа none — и, следовательно, записать что-либо в запись в ветке addressbook не удастся.

4. ACL4 — children-часть ACL5/ACL6/ACL6A

   1. access to dn.regex="ou=addressbook,cn=([^,]+),ou=people,dc=example,dc=com$" в ACL4 использует регулярное выражение для соответствия ЛЮБЫМ записям в ветке addressbook (у regex НЕТ привязки к началу строки с помощью знака ^). Данный ACL предоставляет права производить запись в дочерние (children) записи ветки addressbook (записи в адресной книге), эти права требуются как составная часть для обеспечения возможности создания записи. Переменная $1 будет содержать cn пользователя (выражение в скобках = ([^,]+)).
   2. attrs=children в ACL4 — это псевдоатрибут, указывающий на все записи-потомки записей, расположенных в ветке people (то есть, в данном случае, addressbook).
   3. by dn.exact,expand="cn=$1,ou=people,dc=example,dc=com" write в ACL4. $1 заменяется содержимым cn пользователя, полученным из regex в условии to. В этом условии данному cn (владельцу) предоставляются права производить запись в записи-потомки любой записи в ветке cn. Чтобы разрешить создание записи, требуются права производить запись для псевдоатрибута entry самой записи (ACL5/ACL6 или ACL6A) и для псевдоатрибута children родительской записи — это как раз и есть children-часть данного разрешения. Данный ACL и ACL5/ACL6A позволяют только cn (владельцу) создавать и удалять записи в ветке addressbook.
   4. by users none в ACL4 означает, что любой пользователь, не являющийся владельцем записи, не может читать addressbook (нет прав на чтение).

5. ACL5 — entry-часть ACL4

   1. Требуется только в ранних версиях OpenLDAP — до 2.2. Начиная с версии 2.2 используйте ACL6A. ACL5 — это entry-часть, дополняющая ACL4. Она требуется, чтобы разрешить создание новой записи в ветке addressbook. Данный ACL полность совпадает с ACL4, за исключением attrs=entry. Данный ACL вместе с ACL4 позволяет только cn (владельцу) создавать и удалять записи в addressbook. Порядок присутствия children и entry правил не важны.

6. ACL6 — добавление любых атрибутов в addressbook

   1. Требуется только в ранних версиях OpenLDAP — до 2.2. Начиная с версии 2.2 используйте ACL6A. У ACL6 та же область действия и синтаксис, что и у ACL4 и ACL5, он разрешает владельцу добавлять любые поля из объектного класса inetorgperson с помощью конструкции filter=(objectclass=inetorgperson). Это требуется только в версиях OpenLDAP до 2.2. В версиях 2.2+ ACL5 и ACL6 могут быть объединены с использованием синтаксиса attrs=entry,@inetorgperson. Данный синтаксис не поддерживается в версиях OpenLDAP до 2.2.

7. ACL6A — добавление любых атрибутов в addressbook

   1. ACL6A можно использовать только начиная с OpenLDAP версии 2.2, в более ранних версиях необходимо использовать ACL5 и ACL6.
   2. У ACL6A та же область действия и синтаксис, что и у ACL4, он разрешает владельцу добавлять любые поля из объектного класса inetorgperson с помощью конструкции attrs=entry,@inetorgperson. Данный синтаксис не поддерживается в версиях OpenLDAP до 2.2.

8. ACL7

   1. access to dn.one="ou=customers,dc=example,dc=com" в ACL7 означает, что данная политика применяется к объектам, находящимся на один уровень ниже customers (записи в общей адресной книге).
   2. attrs=children в ACL7 указывает только на дочерние для customers записи (записи в общей адресной книге).
   3. by group.exact="cn=salespeople,ou=groups,dc=example,dc=com" write в ACL7 предоставляет любым членам группы salespeople права производить запись в записи в общей адресной книге.
   4. by users read в ACL7 предоставляет любому пользователю, прошедшему аутентификацию, читать записи из общей адресной книги.

9. ACL8

   1. access to attr=carlicense,homepostaladdress,homephone в ACL8 означает, что данная политика применяется только к этим атрибутам.
   2. by self write в ACL8 предоставляет владельцу записи (прошедшему аутентификацию с использованием userpassword этой записи) права производить запись в эти атрибуты.
   3. by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write в ACL8 предоставляет права на запись в данные атрибуты любому члену группы hrpeople.
   4. by * none в ACL8. В данном случае это означает, что любой пользователь, не являющийся владельцем записи и не состоящий в группе hrpeople , не может записывать в эти атрибуты, и даже пользователи, прошедшие аутентификацию, не могут читать данные атрибуты (нет прав на чтение).

10. ACL9

    1. access to * в ACL9. Поскольку директивы access являются аддитивными, политика данной директивы применяется ко всем атрибутам всех записей, за исключением атрибутов userpassword, carlicense, homepostaladdress и homephone, для которых в предыдущей директиве определены собственные правила.
    2. by self write в ACL9 предоставляет владельцу записи права производить запись в атрибуты, попадающие под действие данной директивы (то есть все атрибуты). Поскольку в ACL1 и ACL8 владельцу (self) предоставлен доступ к другим атрибутам, он может производить запись в любые атрибуты своей записи.
    3. by group.exact="cn=hrpeople,ou=groups,dc=example,dc=com" write в ACL9 предоставляет любому члену группы hrpeople права на запись во все атрибуты, определённые в данном ACL, а также, согласно предыдущему ACL8, в атрибуты carlicense, homepostaladdress и homephone, но не даёт этой группе прав на чтение и запись в атрибут userpassword (это запрещено в ACL1).
    4. by users read в ACL9 предоставляет любому пользователю, прошедшему аутентификацию, права на чтение всех атрибутов, попадающих под действие данной директивы, (то есть всех, за исключением тех, которые определены в ACL1 и ACL8). Если бы мы хотели предоставить права на чтение всех атрибутов (за исключением атрибутов, определённых в ACL1 и ACL8) анонимным пользователям, можно было бы использовать условие by anonymous read.
    5. by * none в ACL9. В данном случае это означает, что пользователи, не являющиеся владельцем записи и не состоящие в группе hrpeople, не могут производить запись в какой бы то ни было атрибут, а пользователи, не прошедшие аутентификацию, не могут читать, производить поиск или выполнять любую другую операцию над какой-либо записью или атрибутом.

olcAllows (allow)

allow feature [...]

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

Примеры:

# фрагмент slapd.conf
# глобальные настройки
...
allow bind_v2
...

# форма OLC (cn=config)
olcAllows: bind_v2

olcArgsFile (argsfile)

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

# форма OLC (cn=config)
olcArgsFile: /var/run/ldap.args

# форма slapd.conf
argsfile /var/run/ldap.args

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

ps ax |grep slapd

В выводе будут указаны аргументы командной строки. Если директива argsfile не указывалась, файл с аргументами создаваться не будет.

olcAttributeTypes (attributetype)

В качестве артефакта обработки схемы данных OpenLDAP предоставляет возможность определить один или несколько типов атрибутов с помощью attributetype в файле slapd.conf или olcAttributeTypes в системах OLC (cn=config). Определение типа атрибута подробно описано здесь. Не совсем понятно, что может подвигнуть Вас при использовании slapd.conf добавлять типы атрибутов таким способом — предпочтительнее создать файл пользовательского набора схемы и добавить его с помощью директивы include. Тем не менее, Вы можете сделать и так, если Вас это забавляет. В OLC (cn=config) атрибуты olcAttributeTypes и olcObjectClasses применяются для загрузки всех наборов схемы данных, используемых конфигурацией OLC (cn=config).

olcConcurrency (concurrency)

Формат:

# форма OLC (cn=config)
olcConcurrency: integer

# форма slapd.conf
concurrency integer

Атрибут olcConcurrency (директива concurrency), если таковой определен, представляет собой "подсказку" системе потоков OpenLDAP. По умолчанию эта директива не содержит никакого значения. Примеры:

# форма OLC (cn=config)
olcConcurrency: 25

concurrency 25
# говорит о том, что будет использовано 25 потоков 
# позволяет осуществлять 25 параллельных операций

Не совсем понятно, какова связь между атрибутом olcConcurrency (директивой concurrency) и атрибутом olcThreads (директивой (threads).

olcConnMaxPending (conn_max_pending)

Формат:

# форма OLC (cn=config)
olcConnMaxPending: integer

# форма slapd.conf
conn_max_pending integer

Атрибут olcConnMaxPending (директива conn_max_pending) определяет количество запросов в режиме ожидания (стоящих в очереди) в пределах одной анонимной сессии. Если данный лимит превышен, сессия будет закрыта, однако стоящие в настоящий момент в очереди запросы будут обработаны. Значение по умолчанию — 100. Примеры:

# форма OLC (cn=config)
olcConnMaxPending: 10

# форма slapd.conf
conn_max_pending 10
# если в пределах одной анонимной сессии в очередь поставлены
# 10 неотработанных запросов, сессия будет завершена

olcConnMaxPendingAuth (conn_max_auth)

Формат:

# форма OLC (cn=config)
olcConnMaxPendingAuth: integer

# форма slapd.conf
conn_max_auth integer

Атрибут olcConnMaxPendingAuth (директива conn_max_auth) определяет количество запросов в режиме ожидания (стоящих в очереди) в пределах одной сессии, при установке которой пользователь прошёл аутентификацию. Если данный лимит превышен, сессия будет закрыта, однако стоящие в настоящий момент в очереди запросы будут обработаны. Значение по умолчанию — 1000. Примеры:

# форма OLC (cn=config)
olcConnMaxPendingAuth: 100

# форма slapd.conf
conn_max_auth 100
# если в пределах одной сессии от клиента, прошедшего аутентификацию,
# в очередь поставлены 100 неотработанных запросов, сессия будет завершена

defaultaccess

Начиная с OpenLDAP 2.1 данная директива считается устаревшей — используйте директиву access to. Не поддерживается в OLC (cn=config), кроме как в целях переконвертации файлов slapd.conf.

Директива defaultaccess — глобальное значение по умолчанию для контроля доступа, распространяющаяся на все запросы, если Вы не определили директив access to. Формат:

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

Данный список иерархичен ВПРАВО, то есть уровень доступа read позволяет также search и compare, но не write; write позволяет read, search и compare. Значение по умолчанию, в случае если не указано ни директивы defaultaccess, ни директив access to:

defaultaccess read
# разрешено read, search и compare, но НЕ РАЗРЕШЕНО write

olcDefaultSearchBase (defaultsearchbase)

Формат:

# форма OLC (cn=config)
olcDefaultSearchBase: dn

# форма slapd.conf
defaultsearchbase dn

Атрибут olcDefaultSearchBase (директива defaultsearchbase), если таковой указан, определяет dn, который будет использовать при поисковых запросах с поисковым диапазоном one или sub и пустым DN. Если эта директива не указана, то по умолчанию подобные поисковые запросы отклоняются с сообщением NoSuchObject. Примеры:

# форма OLC (cn=config)
olcDefaultSearchBase: dc=example,dc=com

# форма slapd.conf
defaultsearchbase dc=example,dc=com
# в поисковые запросы с пустым базовым dn
# будет подставлен приведённый выше dn

В конфигурации OLC (cn=config) данный атрибут добавляется в запись olcDatabase={-1}frontend,cn=config, в отличие от всех остальных глобальных атрибутов, которые добавляются в запись cn=config.

olcDisallows (disallow)

# форма OLC (cn=config)
olcDisallows: feature [...]

# форма slapd.conf
disallow feature [...]

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

Примеры:

# форма OLC (cn=config)
olcDisallows: bind_anon

# форма slapd.conf

disallow bind_anon 
# сервер не допускает анонимные подключения

olcGentleHUP (gentlehup)

Формат:

# форма OLC (cn=config)
olcGentleHUP: TRUE | FALSE

# форма slapd.conf
gentlehup on | off

Если атрибут olcGentleHUP (директива gentlehup) установлен в TRUE (или on), серверу OpenLDAP разрешено выполнение корректного завершения работы при получении сигнала SIGHUP, например так:

kill -HUP PID

В этом случае OpenLDAP выполнит следующие действия:

1. прекратит ожидание новых входящих запросов;
2. продолжит обработку стоящих в очереди и текущих запросов;
3. вернёт 'unwilling to perform' (не желаю исполнять) на стоящие в очереди запросы на запись;
4. остановится по завершении всех текущих операций

Эта команда становится более эффективной, если установлены атрибут olcIdleTimeout (директива idletimeout) и атрибут olcTimeLimit (директива timelimit). OpenLDAP будет, как всегда, немедленно реагировать на сигнал SIGTERM. Значение по умолчанию — FALSE (или off).

Примеры:

# форма OLC (cn=config)
olcGentleHUP: TRUE

# форма slapd.conf
gentlehup on
# разрешена возможность корректного завершения при получении SIGHUP

# форма OLC (cn=config)
olcGentleHUP: FALSE

# форма slapd.conf
gentlehup off
# по умолчанию - выполнять SIGHUP аналогично SIGTERM

olcIdleTimeout (idletimeout)

Формат:

# форма OLC (cn=config)
olcIdleTimeout: integer

# форма slapd.conf
idletimeout integer

Атрибут olcIdelTimeout (директива idletimeout) определяет время в секундах, по истечении которого простаивающее клиентское соединение будет принудительно закрыто (выполнится принудительная операция unbind).

Если атрибут olcIdelTimeout (директива idletimeout) не указан или период установлен в 0, данная возможность отключена, то есть простаивающие клиентские соединения будут поддерживаться неограниченное время (сервер не будет выполнять принудительной операции unbind). Примеры:

# форма OLC (cn=config)
olcIdleTimeout: 0

# форма slapd.conf
idletimeout 0
# простаивающие клиенты не отключаются

# форма OLC (cn=config)
olcIdleTimeout: 30

# форма slapd.conf
idletimeout 30
# простаивающие клиенты отключаются через 30 секунд

Предостережение: Это значение распространяется на все подключения, обслуживаемые сервером. Если данный сервер является либо потребителем репликации (использует директиву syncrepl с типом, имеющим значение refreshAndPersist), либо поставщиком репликации (использует директиву overlay syncprov с одним или несколькими потребителями типа refreshAndPersist), то весьма вероятно, что установленные ими соединения будут бездействовать в течение длительного периода времени. В таких условиях необходимо соблюдать крайнюю осторожность при использовании атрибута olcIdelTimeout (директивы idletimeout), поскольку при разрыве соединения тип подключений репликации может смениться на refreshOnly, что, возможно, будет нежелательным побочным эффектом.

include

Данная директива по своей природе является избыточной в конфигурациях OLC (cn=config) и поддерживается только в целях переконвертации slapd.conf. Наборы схемы данных могут быть добавлены в конфигурацию OLC (cn=config) с помощью описанного здесь процесса.

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

include /path/to/include/file

Два наиболее распространённых применения данной директивы:

1. подключения заранее подготовленных (существующих) файлов .schema (обычно находятся в /usr/local/etc/openldap/schema или /etc/openldap/schema).
2. считывание файлов, которые могут содержать конфиденциальную информацию, например пароли; эти файлы могут быть защищены путём ограничения доступа с помощью chmod.

Примеры:

include /usr/local/etc/openldap/schema/core.schema
# добавляет содержимое файла core.schema, поставляемого с дистрибутивом
include /var/myschemas/myschema.schema
# добавляет содержимое файла myschema.schema
include /var/passwords/userpass
# подключает файл с паролем пользователя, содержащим, к примеру, 
# директиву rootpw и имеющим права доступа 0600

olcDbIndex (index)

# форма OLC (cn=config)
olcDbIndex: attrlist | default indices

# форма slapd.conf
index attrlist | default indices

# indices = [pres [,approx] [,eq] [,sub] [,special]]

# Простое использование значения default
# форма OLC (cn=config)
olcDbIndex: default pres,eq
olcDbIndex: cn,sn,uid

# форма slapd.conf
index default pres,eq
index cn,sn,uid

# Определяем индексы наличия и соответствия
# для атрибутов cn, sn и uid
# две приведённые выше директивы index выполняют
# абсолютно то же, что и три, приведённые ниже
index cn pres,eq
index sn pres,eq
index uid pres,eq

index cn eq,sub,subinitial
# Создаём индексы для атрибута cn (commonname)
# для поисков EQUALITY, SUBSTR, а также дальнейшая оптимизация
# для поисков типа sc=a*

index sn eq,approx,sub
# Создаём индексы для атрибута sn (surname)
# для поисков EQUALITY и SUBSTR
# Примечание: Индекс approx index - пустая трата времени,
#     поскольку для sn не определено правило ORDERING,
#     требуемое для поисков approx. Приводится лишь для
#     иллюстрации возможности использования

index mail pres,eq,sub
# Создаём индексы для атрибута mail on
# для поисков на наличие, EQUALITY и SUBSTR

index objectclass eq
# Оптимизируем поиски по форме objectclass=person

olcLogFile (logfile)

OpenLDAP производит журналирование через syslogd (используя LOCAL4) во всех случаях (способ настройки syslogd для перенаправления сообщений LDAP в отдельный файл смотрите в описании атрибута olcLogLevel (директивы loglevel)). В дополнение к этому можно использовать атрибут olcLogFile (директиву logfile) для создания отдельного файла, содержащего только журнал LDAP. Даже при использовании этой директивы OpenLDAP также будет производить журналирование той же информации через syslogd. Пример:

# форма OLC (cn=config)
olcLogFile: /path/to/ldap/log/file

# форма slapd.conf
logfile /path/to/ldap/log/file

# файл дожен существовать до запуска OpenLDAP
touch /path/to/ldap/log/file
chown ldap:ldap /path/to/ldap/log/file

olcLogLevel (loglevel)

OpenLDAP производит журналирование через канал LOCAL4 syslogd. Чтобы направить журнал LDAP в отдельный файл средствами syslog, добавьте в syslog.conf (обычно /etc/syslog.conf) такую строку:

# добавляем в syslog.conf
local4.* /var/log/ldap.log

# создаём пустой log-файл
touch /var/log/ldap.log

# перезапускаем syslogd
killall -HUP syslogd
ИЛИ
/etc/rc.d/syslogd restart

С помощью этих действий журналы всех уровней канала local4 (то есть OpenLDAP) будут выводиться /var/log/ldap.log. Другой способ — воспользоваться атрибутом olcLogFile (директивой logfile).

Примечание: Если в командной строке при запуске slapd указан аргумент -d, то он переопределяет любые значения, задаваемые в параметрах olcLogLevel/loglevel.

Уровни журналирования OpenLDAP задаются следующей директивой:

loglevel number | hex-value | log-name

Возможные значения number, hex-value и log-name:

Директива loglevel принимает единичное значение или список значений, разделённых пробелами. Каждое значение может быть комбинацией number, hex-value или log-name из приведённой выше таблицы. Результаты соединяются друг с другом через логическое ИЛИ. Кроме того, можно задать множественное значение, состоящее из нескольких объединённых в одну записей типа number или hex-value, как показано в следующих примерах:

loglevel 255
# задаёт уровни 1, 2, 4, 8, 16, 32, 64 и 128
# добавляются все эти значения

loglevel 2176
# 2048 + 128
loglevel 296
# 256 + 32 + 8

# использование единичного hex-value (128)
loglevel 0x80

# множественное hex-value (1 + 128)
loglevel 0x81 
# аналогично такой директиве
loglevel 0x1 0x80

# использование log-name (единичное значение)
loglevel acl

# несколько значений log-name
loglevel acl sync

# комбинация различных типов
loglevel 1 0x40 conns

Если атрибут olcLogLevel (директива loglevel) не определен, уровень журналирования по умолчанию — 256 (только stats).

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

olcModuleLoad (moduleload)

Сногсшибательный атрибут (директива), представляющий собой косвенный ущерб от плохо реализованных функций — в данном случае, наложений. То, что должно быть задействовано автоматически, исходя из настроек конфигурации, требует ручного определения, да ещё и основанного на ужасающем количестве опций сборки и скрипта configure, которые, при использовании RPM, обычно оказываются недоступными для пользователя. Но только не для пользователя OpenLDAP.

Атрибут olcModuleLoad (директива moduleload) указывается в разделе глобальных настроек и определяет имя динамически загружаемого модуля, который будет использоваться сервером исходя из настроек конфигурации. Указание этой директивы имеет очень важное значение, если: a) наложение является динамическим (смотрите ниже), и b) наложение используется (например, в директиве database) или указывается в директиве overlay. Название наложения может задаваться как с указанием полного пути к файлу модуля, так и просто именем файла и должно содержать суффикс библиотеки .la (библиотеки, собранные в libtool) или .so (библиотеки разделяемых объектов). Для имен, не содержащих абсолютного пути, поиск файлов производится в директориях, указанных в атрибуте olcModulePath (директиве modulepath) или, если olcModulePath/modulepath не заданы, в директориях, указанных в PATH, LTDL_LIBRARY_PATH и LD_LIBRARY_PATH. Данный атрибут (директива) и атрибут olcModulePath (директива modulepath) могут применяться только если при сборке была указана опция --enable-modules (в большинстве дистрибутивов указана).

Следует отметить, что модули OpenLDAP могут быть статическими или динамическими (только динамические наложения требуют использования атрибутов olcModuleLoad (директив moduleload)). Покажем разницу между статическими и динамическими модулями на примере. Если при запуске скрипта configure OpenLDAP задано, скажем, --enable-accesslog=mod, то наложение accesslog будет собрано отдельным модулем и, следовательно, ДОЛЖНО подключаться с помощью атрибута olcModuleLoad (директивы moduleload). Если скрипту configure передавался параметр в форме --enable-accesslog, то данное наложение при сборке будет встроено в демон slapd, то есть оно будет собрано как статическое наложение. В таком случае указание атрибута olcModuleLoad (директивы moduleload) для accesslog вызовет ошибку, поскольку при --enable-accesslog отдельного модуля для данного наложения не создаётся (для получения полного списка опций скрипта configure выполните ./configure --help из директории сборки OpenLDAP). Чтобы наверняка узнать, является ли нужный модуль динамическим, можно помотреть в директорию, где хранятся собранные модули([bsd] /usr/local/libexec/openldap) [fc] /usr/libexec/openldap или /usr/sbin/openldap). Если этот модуль там есть и он используется при конфигурации OpenLDAP, его необходимо указать в атрибуте olcModuleLoad (директиве moduleload), а если его там нет — можно предположить, что он собран статически. Если есть сборка модуля с обоими суффиксами .la и .so — используйте файл с суффиксом .la, а если он не работает — тогда с суффиксом .so. Если не работают оба файла, мы можем порекомендовать только ритуальное самоубийство. Имена модулей можно посмотреть в описании директив overlay и database.

# форма OLC (cn=config)
olcModuleLoad: module-name

# форма slapd.conf 
moduleload module-name

# пример - загрузка наложения syncprov
# форма OLC (cn=config)
olcModuleLoad: syncprov.la

# форма slapd.conf 
moduleload syncprov.la

# формат с указанием полного пути
# форма OLC (cn=config)
olcModuleLoad: /usr/local/libexec/openldap/syncprov.la

# форма slapd.conf 
moduleload /usr/local/libexec/openldap/syncprov.la

Примечание: Атрибуты olcModuleLoad и olcModulePath определяются в записи cn=modules{0},cn=config, использующей объектный класс olcModuleList.

olcModulePath (modulepath)

Определяет одну или несколько директорий файловой системы, в которых будут находиться загружаемые модули (наложения). В одной директиве можно задать несколько путей, в этом случае они разделяются двоеточием (*nix) или точкой с запятой (windows). Если эта директива не определялась, поиск осуществляется в директориях, заданных в переменных окружения PATH, LTDL_LIBRARY_PATH и LD_LIBRARY_PATH. Смотрите также описание атрибута olcModuleLoad (директивы moduleload).

Примечание: В конфигурации OLC (cn=config) атрибут olcModulePath может иметь только одно значение (SINGLE-VALUE). Атрибуты olcModuleLoad и olcModulePath определяются в записи cn=modules{0},cn=config, использующей объектный класс olcModuleList.

olcObjectClasses (objectclass)

В качестве артефакта обработки схемы данных OpenLDAP предоставляет возможность определить один или несколько объектных классов (objectclass) в файле slapd.conf. Определение объектного класса описано здесь. Не совсем понятно, что может подвигнуть Вас добавлять объектные классы таким способом — предпочтительнее создать файл пользовательского набора схемы и добавить его с помощью директивы include. Тем не менее, Вы можете сделать и так, если Вас это забавляет.

В конфигурации OLC (cn=config) атрибут olcObjectClasses используется для загрузки наборов схемы данных, требуемых системой OLC (cn=config).

olcPasswordHash (password-hash)

Позволяет определить один или несколько методов хэширования, используемых при хранении новых паролей, генерируемых с применением расширенной операции изменения пароля (Extended Modify Password Operation, RFC 3602), в атрибуте userPassword. Формат:

# форма OLC (cn=config)
olcPasswordHash: {hash}[,{hash} [, ...]]

# форма slapd.conf 
password-hash {hash}[,{hash} [, ...]]

Значения hash должны быть из набора поддерживаемых методов: {SSHA}, {SHA}, {SMD5}, {MD5}, {CRYPT} или {CLEARTEXT}. Значение по умолчанию — {SSHA}. Пример:

# форма OLC (cn=config)
olcPasswordHash: {SHA},{SSHA}

# форма slapd.conf 
password-hash {SHA},{SSHA}

Здесь методом хэширования по умолчанию для всей серверной части задаётся {SHA} (FIPS-160 без "соли"). При задании нескольких значений они должны разделяться запятыми, при этом нельзя помещать между разделителями пробелы — slapd просто не загрузится.

В конфигурации OLC (cn=config) данный атрибут указывается/добавляется в запись olcDatabase={-1}frontend,cn=config, а не в запись глобальных настроек cn=config.

olcPidFile (pidfile)

Заставляет OpenLDAP (slapd) записывать PID в указанный файл. Пример:

# форма OLC (cn=config)
olcPidFile:  /var/run/ldap.pid

# форма slapd.conf 
pidfile /var/run/ldap.pid

Данный PID может быть использован в команде kill или для посылки других сигналов в ldap. В качестве альтернативы можно использовать такую команду:

ps ax |grep slapd

В выводе будет указана информация о PID. Если атрибут olcPidFile (директива pidfile) не указывался, файл с PID создаваться не будет. Большинство скриптов запуска/остановки/перезапуска slapd будут работать лишь при наличии PID-файла, причём в том месте, где они его ожидают найти. У Вас есть два варианта: использовать атрибут olcPidFile (директиву pidfile) для того, чтобы определить тот путь к файлу pid, который ожидают стандартные скрипты и пользоваться этими скриптами, либо не использовать olcPidFile/pidfile (или задать в них нестандартные для Вашей системы пути) и запускать/останавливать slapd вручную.

olcReferral (referral)

Формат:

# форма OLC (cn=config)
olcReferral: uri

# форма slapd.conf 
referral uri

Атрибут olcReferral (директива referral) позволяет OpenLDAP возвращать указанный uri в качестве отсылки (referral) в случае, когда запрашиваемое значение DN не входит ни в одну базу данных/DIT (суффикс не совпадает с указанными в атрибутах olcSuffix (директивах suffix) разделов database) этого сервера. Не все клиенты способны обработать возвращённый uri, который должен быть сформирован как полный LDAP URL, содержащий максимально возможное количество информации, и должен правильно указывать на сайт, позволяющий анонимный доступ к требуемому корневому DN. Примеры:

# форма OLC (cn=config)
olcReferral: ldap://ldap.openldap.org/

# форма slapd.conf 
referral ldap://ldap.openldap.org/
# в данном URL предпринимается попытка получить доступ к rootDSE системы OpenLDAP,
# находящейся по данному адресу, которая может завершиться неудачей!

# форма OLC (cn=config)
olcReferral: ldap://ldap.example.com/dc=example,dc=com??one?(objectclass=*)

# форма slapd.conf 
referral ldap://ldap.example.com/dc=example,dc=com??one?(objectclass=*)
# система по адресу ldap.example.com должна уметь обслуживать запросы такого рода
# и возвращать все записи первого уровня, поддерживаемые всеми LDAP-серверами
# в данной системе - своего рода обзор общих сервисов/предметных областей

Примечание: Атрибут olcReferral (директива referral) применяется, когда сервер не может найти запрашиваемый DN внутри структуры своих DIT. Отсылки как делегирование полномочий на обслуживание подмножества DIT стандартным способом настраиваются с помощью специальных записей с объектным классом referral внутри структуры DIT. Дополнительная информация и примеры конфигурации отсылок здесь.

replicationinterval

Начиная с версии 2.4 эта директива считается устаревшей и в OLC (cn=config) служит лишь в целях переконвертации slapd.conf. Определяется на главном (master) сервере, используется в репликации в стиле slurpd. Данная директива читается демоном slurpd и устанавливает интервал (в секундах), по истечении которого slurpd будет очередной раз проверять файл replogfile на предмет обновления подчинённых (slave) серверов.

replicationinterval seconds

# пример: проверять replogfile каждые 60 секунд
replicationinterval 60

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

olcRequires (require)

# форма OLC (cn=config)
olcRequires: policy [...]

# форма slapd.conf 
require policy [...]

Данная директива, которая может указываться как в разделе глобальных настроек, так и в разделе database, определяет требования, которые должны быть соблюдены перед получением любого рода доступа к серверу. При использовании в разделе database установленное значение требований сохраняется, пока не будет сброшено (olcRequires: none/require none). Следующие друг за другом атрибуты olcRequires (директивы require), если это не атрибут/директива сброса olcRequires: none/require none, применяются аддитивно, то есть все их требования должны быть соблюдены. В директиве может быть указано одно или несколько из перечисленных ниже значений (разделённых пробельными символами, например, пробелом или табуляцией):

Примеры:

# сбрасывает значение предыдущих требований olcRequires/require и
# устанавливает требование прохождения LDAP-аутентификации для данного DIT
# форма OLC (cn=config)
olcRequires: none authc

# форма slapd.conf 
require none authc

olcReverseLookup (reverse-lookup)

Формат:

# форма OLC (cn=config)
olcReverseLookup: TRUE | FALSE

# форма slapd.conf 
reverse-lookup on | off

Если атрибут olcReverseLookup (директива reverse-lookup) установлен в TRUE (или on), то OpenLDAP будет использовать обратное разрешение имён DNS при каждом обращении клиента. Значение по умолчанию — FALSE (или off). Этот атрибут (директива) будет работать лишь в том случае, если при сборке использовалась опция --enable-rlookups. Примеры:

# форма OLC (cn=config)
oldReverseLookup: TRUE

# форма slapd.conf 
reverse-lookup on
# заставляет OpenLDAP выполнять обратное разрешение имён DNS
# при каждом клиентском доступе

olcRootDSE (rootDSE)

Формат:

# форма OLC (cn=config)
olcRootDSE: /path/to/ldif/file

# форма slapd.conf 
rootDSE /path/to/ldif/file

В атрибуте olcRootDSE (директиве rootDSE) указывается LDIF-файл, содержащий определённые пользователем операционные атрибуты, которые будут добавлены к существующей записи rootDSE (доступна для просмотра в subschema subentry). Эти атрибуты являются аддитивными — в дополнение к стандартным (встроенным) атрибутам.

olcSecurity (security)

# форма OLC (cn=config)
olcSecurity: ssf-policy

# форма slapd.conf 
security ssf-policy [...]

Данный атрибут (директива) может быть определен в записи (разделе) глобальных настроек, в этом случае областью его действия будут все разделы database, либо он может быть указан в конкретной записи (разделе) database, в этом случае область его действия ограничивается только этим DIT (при этом переопределяются политики любых директив из раздела глобальных настроек, если таковые имеются). При использовании защищенных соединений (TLS или SASL) атрибут olcSecurity (директива security) определяет минимальный фактор силы безопасности (Security Strength Factor, SSF), применяющийся к любому типу безопасности (TLS или SASL) или требующий выполнения транзакции конкретного типа. Может быть определено одно или несколько (разделённых пробельными символами) значений ssf-policy из следующего списка:

Значение n указывает требуемый уровень безопасности, выражаемый как минимальное количество бит в криптографическом ключе, который будет использоваться. Как правило, это значение берётся из диапазона от 40 до 256 (стандартные значения: 40, 56, 64, 128, 164 и 256) в зависимости от алгоритма, который будет задействован. Таким образом, значение 1 показывает, что может применяться любой уровень криптографической защиты, а значение 128 — что сессии с применением криптографических алгоритмов с длиной ключа 128 и более будут пропускаться, а с длиной ключа, скажем, 56 — отклоняться.

olcSchemaDN (schemadn)

Формат:

# форма OLC (cn=config)
olcSchemaDN: cn=name

# форма slapd.conf 
schemadn cn=name

Атрибут olcSchemaDN (директива schemadn) определяет название subschema subentry, используемое OpenLDAP. Значение по умолчанию — 'cn=subschema'. Примеры:

# форма OLC (cn=config)
olcSchemaDN: cn=ldapsubschema

# форма slapd.conf 
schemadn cn=ldapsubschema
# изменяет название subschema subentry с
# subschema (по умолчанию) на ldapsubschema

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

olcServerID (ServerID)

Формат:

# форма OLC (cn=config)
olcServerID: number [URL]

# форма slapd.conf 
serverid number [URL]

Только для OpenLDAP версий 2.4+. Атрибут olcServerID (директива serverid) определяет метод, по которому данный сервер можно уникально идентифицировать с помощью либо числа (number) (известного как SID), либо URL (или нескольких URL). Этот атрибут (директива) используется в репликации с несколькими главными серверами, поддерживаемой начиная с OpenLDAP 2.4. Параметр number — это произвольное число, содержащее от 1 до 3 цифр, которое уникально идентифицирует сервер в группе нескольких главных серверов репликации (multi-master group). Значение по умолчанию — 000. Идентификатор сервера (server ID, SID) используется (как и значение rid обновлённого (в версии 2.4) CSN) для уникальной идентификации хоста в качестве источника обновлений. Если параметр директивы передаётся в опциональной форме URL, то данная директива может присутствовать несколько раз. Во многих примерах конфигурации с несколькими главными серверами показано, что все серверы в группе главных серверов репликации идентифицируются с помощью ассоциированных с ними URL. Эксперименты показывают, что это необязательное требование (информация о поставщике указывается в директиве syncrepl), числовой формат также прекрасно работает. Ключевой характеристикой является то, что указанное значение (не важно, число или URL) в любой момент уникально идентифицирует данный сервер. При выборе того, каким форматом Вы будете пользоваться, имейте в виду два момента. Во первых, даже если число ServerID в данный момент уникально, оно может не всегда оставаться уникальным, например, если Вы впоследствии захотите производить репликацию с сервера, которому уже выделен SID 001. Во вторых, если DIT конфигурации сервера cn=config впоследствии реплицируется на другой сервер с тем же самым SID, результат может быть непредсказуемым. Использование в качестве SID URL сервера может обеспечить гарантированно уникальное значение данного идентификатора. Ну, а если нет — кроме ритуального самоубийства ничего не остаётся. Наконец, нет никакой связи между SID (server ID) и параметром rid директивы syncrepl. Примеры:

# форма OLC (cn=config)
olcServerID: 001

# форма slapd.conf 
serverid 001
# то же, что и предыдущее, но с одним символом
serverid 1

# в форме URI 
# форма OLC (cn=config)
olcServerID: ldap1.example.com

# форма slapd.conf 
serverid ldap1.example.com

olcSizeLimit (sizelimit)

Атрибут olcSizeLimit (директива sizelimit) определяет количество записей, которые будут возвращаться на каждый поисковый запрос. Существует две формы данной директивы, первая из них:

# форма OLC (cn=config)
olcSizeLimit: integer | unlimited

# форма slapd.conf 
sizelimit integer | unlimited

Здесь integer — значение от 1 до 65435. unlimited (или -1) говорит о том, что ограничений на количество возвращаемых результатов не накладывается.

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

# форма OLC (cn=config)
olcSizeLimit: size[.{soft|hard|unchecked}]=integer

# форма slapd.conf 
sizelimit size[.{soft|hard|unchecked}]=integer

Здесь integer — это максимальное число записей, которые slapd будет возвращать в ответ на поисковый запрос. Поведение директивы зависит от необязательного квалификатора soft, hard или unchecked следующим образом:

1. Если при запросе клиент явно не указывал ограничений по размеру, используется мягкое (soft) ограничение.
2. Если указанное клиентом ограничение по размеру превысило жёсткое (hard) ограничение, возвращается ошибка "Administrative limit exceeded" (превышено административное ограничение).
3. Если ограничение hard равно 0 или ключевому слову "soft", ограничение soft используется в любом случае.
4. Если ограничение hard равно -1 или ключевому слову "none", жёстких ограничений не накладывается.
5. Явно указанное при запросе ограничение по размеру меньшее или равное жёсткому ограничению будет удовлетворено.
6. Квалификатор unchecked устанавливает ограничение на количество записей-кандидатов, которые могут быть рассмотрены в ходе обработки поискового запроса. Если количество отобранных записей-кандидатов превысило ограничение unchecked, поиск будет прерван с ошибкой LDAP_UNWILLING_TO_PERFORM (53, x'35) (не желаю исполнять). Если ограничение unchecked равно -1 или ключевому слову "none", ограничений на количество обрабатываемых записей-кандидатов не накладывается (поведение по умолчанию).
7. Если квалификаторы не указаны, значение integer присваивается мягкому ограничению, а жёсткое ограничение устанавливается в ноль, таким образом сохраняется оригинальное поведение, как при первой форме определения директивы sizelimit.

Если директива sizelimit не была определена, значение по умолчанию — 500. Примеры:

# форма OLC (cn=config)
olcSizeLimit: 0

# форма slapd.conf 
sizelimit 0
# не отключать простаивающих клиентов

# форма OLC (cn=config)
olcSizeLimit: 100

# форма slapd.conf 
sizelimit 100
# в ответ возвращается не более 100 записей

# расширенная форма
# форма OLC (cn=config)
olcSizeLimit: size=100

# форма slapd.conf 
sizelimit size=100
# то же самое, что и sizelimit 100

# форма OLC (cn=config)
olcSizeLimit: size.soft=100 size.hard=200

# форма slapd.conf 
sizelimit size.soft=100 size.hard=200
# если клиент не установил ограничений, то ограничения равны 100
# если клиент установил ограничения, превышающие 200 - запрос отклоняется
# нет ограничений на количество записей-кандидатов при поиске

# форма OLC (cn=config)
olcSizeLimit: size.unchecked=1000

# форма slapd.conf 
sizelimit size.unchecked=1000
# если клиент не установил ограничений, то будет возвращено
# максимум 500 записей (значение по умолчанию)
# если же клиент установил ограничение, то
# если клиентское ограничение превысило 500 (значение по умолчанию) - запрос отклоняется
# если при обработке выбрано более 1000 записей-кандидатов - запрос отклоняется

olcSockbufMaxIncoming (sockbuf_max_incoming)

Формат:

# форма OLC (cn=config)
olcSockbufMaxIncoming: bytes

# форма slapd.conf 
sockbuf_max_incoming bytes

Атрибут olcSockbufMaxIncoming (директива sockbuf_max_incoming) определяет максимальный PDU (размер блока) в байтах для входящих анонимных сессий. Значение по умолчанию — 262143. Примеры:

# форма OLC (cn=config)
olcSockbufMaxIncoming: 5000

# форма slapd.conf 
sockbuf_max_incoming 5000
# максимальный размер PDU (блока данных) - 5000 байт,
# при превышении соединение отклоняется

olcSockbufMaxIncomingAuth (sockbuf_max_incoming_auth)

Формат:

# форма OLC (cn=config)
olcSockbufMaxIncomingAuth: integer

# форма slapd.conf 
sockbuf_max_incoming_auth integer

Атрибут olcSockbufMaxIncomingAuth (директива sockbuf_max_incoming_auth) определяет максимальный PDU (размер блока) в байтах для входящих сессий с проверкой подлинности. Значение по умолчанию — 4194303. Примеры:

sockbuf_max_incoming_auth 5000
# максимальный размер PDU - 5000 байт,
# при превышении соединение отклоняется 

olcThreads (threads)

Формат:

# форма OLC (cn=config)
olcThreads: integer

# форма slapd.conf 
threads integer

Атрибут olcThreads (директива threads) определяет количество потоков, которые может использовать OpenLDAP. Чем выше это значение, тем больше одновременных запросов может обработать сервер. Значение по умолчанию — 16. Примеры:

# форма OLC (cn=config)
olcThreads: 25

# форма slapd.conf 
threads 25
# разрешено максимум 25 потоков

Не совсем понятно, какова связь между атрибутом olcThreads (директивой threads) и атрибутом olcConcurrency (директивой concurrency).

olcTimeLimit (timelimit)

Атрибут olcTimeLimit (директива timelimit) определяет время в секундах, которое slapd может потратить на формирование ответа на поисковый запрос. Если за это время обработка запроса не будет завершена, клиенту возвращается ошибка о превышении ограничения времени. Существует две формы данной директивы, первая из них:

# форма OLC (cn=config)
olcTimeLimit: seconds | unlimited

# форма slapd.conf 
timelimit seconds | unlimited

Здесь seconds — число секунд, которое slapd будет тратить на формирование ответа на поисковый запрос, unlimited или -1 говорит о том, что ограничений на время обработки поискового запроса не накладывается.

Вторая (расширенная) форма предоставляет больше контроля над временем обработки запроса и имеет следующий формат:

# форма OLC (cn=config)
olcTimeLimit: time[.{soft|hard}]=seconds [..]

# форма slapd.conf 
timelimit time[.{soft|hard}]=seconds [..]

Здесь seconds — число секунд, которое slapd будет тратить на формирование ответа на поисковый запрос. Поведение директивы определяется необязательным квалификатором soft или hard следующим образом:

1. Если при запросе клиент явно не указывал ограничений времени, используется мягкое (soft) ограничение.
2. Если указанное клиентом ограничение времени превысило жёсткое (hard) ограничение, возвращается ошибка "Administrative limit exceeded" (превышено административное ограничение).
3. Если ограничение hard равно 0 или ключевому слову "soft", ограничение soft используется в любом случае.
4. Если ограничение hard равно -1 или ключевому слову "none", жёстких ограничений не накладывается.
5. Явно указанное при запросе ограничение времени меньшее или равное жёсткому ограничению будет удовлетворено.
6. Если квалификаторы не указаны, значение integer присваивается мягкому ограничению, а жёсткое ограничение устанавливается в ноль, таким образом сохраняется оригинальное поведение, как при первой форме определения директивы timelimit.

Если директива timelimit не была определена, устанавливается ограничение в 3600 секунд (1 час). Примеры:

# форма OLC (cn=config)
olcTimeLimit: 15

# форма slapd.conf 
timelimit 15
# для выполнения поискового запроса отводится 15 секунд
# при превышении возвращается ошибка time limit exceeded

# форма OLC (cn=config)
olcTimeLimit: 0

# форма slapd.conf 
timelimit 0
# отключает ранее установленные ограничения
# (становится равным значению по умолчанию 3600)
timelimit unlimited
# ограничений по времени не накладывается

# расширенный формат
# форма OLC (cn=config)
olcTimeLimit: time=15

# форма slapd.conf 
timelimit time=15
# то же самое, что и timelimit 15

# форма OLC (cn=config)
olcTimeLimit: time.soft=15 time.hard=20

# форма slapd.conf 
timelimit time.soft=15 time.hard=20
# если клиент не установил ограничение времени, то ограничение равно 15 секундам
# если клиент установил ограничение времени, превышающее 20 - запрос отклоняется

# форма OLC (cn=config)
olcTimeLimit: time.soft=15

# форма slapd.conf 
timelimit time.soft=15
# если клиент не установил ограничение времени, то ограничение равно 15 секундам
# если клиент установил какое-либо ограничение времени, оно будет принято

# форма OLC (cn=config)
olcTimeLimit: time.soft=15 time.hard=none

# форма slapd.conf 
timelimit time.soft=15 time.hard=none
# если клиент не установил ограничение времени, то ограничение равно 15 секундам
# если клиент установил какое-либо ограничение времени, оно будет принято

6.3.1 Директивы TLS/SSL (OLC (cn=config) и slapd.conf)

Обзор TLS — что такое TLS сервер/клиент

В OpenLDAP атрибуты/директивы, необходимые для сервера (в частности, TLS-сервера), и для клиента (в частности, TLS-клиента) различаются. Термин LDAP-клиент применяется, скажем, по отношению к LDAP-браузеру или почтовому клиенту, считывающему адресную книгу из LDAP, тогда как системы OpenLDAP являются серверами. Однако TLS несколько размывает границы между этими понятиями. То, что мы называем сервером LDAP, может оказаться как TLS-сервером, так и TLS-клиентом, а может быть сразу и TLS-клиентом, и TLS-сервером, — в последнем случае для него необходимо определять как серверные, так и клиентские атрибуты/директивы TLS. Ключевым различием между сервером и клиентом TLS является то, что TLS-сервер никогда не является инициатором соединения, им всегда является TLS-клиент. Данные различия определяются на уровне записи/раздела database; таким образом, один из разделов database в slapd.conf (или olcDatabase в cn=config) может быть TLS-сервером, а другой — TLS-клиентом. Вот несколько примеров:

1. Система LDAP, которая занимается только предоставлением доступа внешним клиентам, не имеющая атрибутов olcSyncrepl (директив syncrepl) в какой-либо из записей (разделов) database и не имеющая записей (директив) overlay chain, является TLS-сервером.

2. Запись (раздел) database, содержащая дочернюю запись (директиву) overlay syncprov и являющаяся поставщиком репликации в конфигурации типа главный-подчинённый (master-slave), всегда является TLS-сервером (потребитель репликации всегда подключается к поставщику).

3. Запись (раздел) database, содержащая атрибут olcSyncrepl (директиву syncrepl) и являющаяся потребителем репликации в конфигурации типа главный-подчинённый (master-slave), всегда является TLS-клиентом (потребитель репликации всегда подключается к поставщику).

4. Запись (раздел) database, содержащая атрибут olcSyncrepl (директиву syncrepl) и дочернюю запись (директиву) overlay syncprov в конфигурации репликации с несколькими главными серверами (multi-master), является одновременно и TLS-клиентом (как потребитель репликации, настраиваемый атрибутом (атрибутами) olcSyncrepl (директивой (директивами) syncrepl)), и TLS-сервером (как поставщик репликации syncprov).

5. Сервер LDAP, содержащий запись/директиву overlay chain, может быть одновременно и TLS-клиентом (для соединения сцепления (chaining)), и TLS-сервером (для обычного пользовательского доступа).

6. Вы будете приятно удивлены, узнав, что LDAP-клиенты, такие как LDAP-браузер, почтовый клиент и т.п., всегда являются TLS-клиентами!

Несколько рабочих примеров конфигурации TLS/SSL представлены в главе 15. Все серверные директивы TLS указываются в записи cn=config или разделе глобальных настроек slapd.conf. Все клиентские директивы TLS указываются в ldap.conf.

olcTLSCACertificateFile (TLSCACertificateFile)

# форма OLC (cn=config)
olcTLSCACertificateFile: /path/to/CA/cert/file.pem

# форма slapd.conf 
TLSCACertificateFile /path/to/CA/cert/file.pem

Атрибут (директива) сервера TLS. Определяет путь до файла и имя файла сертификата Удостоверяющего центра (Certicate Authority, CA), известного также как корневой сертификат. Этот сертификат используется только при проверке входящих сертификатов. Данная директива требуется лишь в случае, когда сервер ожидает поступления или требует предъявления сертификата клиента (атрибут olcTLSVerifyClient (директива TLSVerifyClient) установлен в одно из значений try, demand или allow). Если используется значение по умолчанию атрибута olcTLSVerifyClient (директивы TLSVerifyClient) never, определять директиву TLSCACertificateFile не нужно. Если данная директива определяется, она указывает на корневой (CA) сертификат, который должен быть получен у поставщика сертификатов X.509 (то есть у Удостоверяющего центра, CA). Как правило, это файл в формате PEM (Privacy enhanced Mail) с расширением .pem или, если он был получен из установки браузера MSIE, с расширением .cer. Если рабочий сертификат X.509 (указанный в атрибуте olcTLSCertificateFile (директиве TLSCertificateFile)) подписан промежуточным удостоверяющим центром, то в файле формата PEM должны присутствовать все сертификаты удостоверяющих центров вплоть до центра корневого уровня. PEM — это текстовый формат, и несколько сертификатов могут помещаться в один и тот же файл в произвольном порядке — смотрите заметки и примеры по формату PEM. В данном файле нет конфиденциальной информации (сертификат X.509 содержит только открытый ключ), поэтому для него не требуется установки специальных разрешений.

Примечание: Если LDAP-сервер выступает в роли TLS-клиента, например, как потребитель репликации с установленным атрибутом olcSyncrepl (директивой syncrepl), то требуемый корневой (CA) сертификат определяется в директиве TLS_CACERT в файле ldap.conf.

olcTLSCertificateFile (TLSCertificateFile)

# форма OLC (cn=config)
olcTLSCertificateFile: /path/to/cert/file.pem

# форма slapd.conf 
TLSCertificateFile /path/to/cert/file.pem

Атрибут (директива) сервера TLS. Определяет путь до файла и имя файла рабочего сертификата X.509 сервера (в атрибуте cn= DN в поле subject данного сертификата указан URL этого LDAP-сервера, например, ldap.example.com). Данный сертификат содержит открытый ключ, используемый при обмене ключами в протоколе TLS. Указываемый в директиве файл, как правило, в формате PEM (Privacy Enhanced Mail) обычно имеет суффикс .pem. PEM — это текстовый формат (смотрите заметки и примеры по формату PEM). Если данный сертификат является самоподписанным, то в зависимости от того, как он был создан, может потребоваться (или не потребоваться) атрибут olcTLSCACertificateFile (директива TLSCACertificateFile). Примеры конфигурации OpenLDAP с самоподписанным сертификатом можно посмотреть здесь. В данном файле нет конфиденциальной информации (сертификат X.509 содержит только открытый ключ), поэтому для него не требуется установки специальных разрешений.

olcTLSCertificateKeyFile (TLSCertificateKeyFile)

# форма OLC (cn=config)
olcTLSCertificateKeyFile: /path/to/private/key/file.pem

# форма slapd.conf 
TLSCertificateKeyFile /path/to/private/key/file.pem

Атрибут (директива) сервера TLS. Определяет расположение секретного ключа, открытый ключ которого содержится в сертификате сервера (определённом в атрибуте olcTLSCertificateFile (директиве TLSCertificateFile)). Этот ключ используется для декодирования посылаемых клиентом TLS во время переговоров об установке соединения TLS сведений о ключе pre-master (на основании которого будет вычисляться общий секретный ключ, используемый впоследствии для шифрования данных). Как правило, файл с ключом имеет суффикс .pem. Данный секретный ключ — очень важная конфиденциальная информация и, в идеале, он должен храниться в отдельной структуре директорий файловой системы с ограниченными правами на чтение или, как минимум, сам файл с ключом должен иметь права только на чтение (0400) для учётной записи, от имени которой запускается OpenLDAP — обычно ldap. Примеры конфигурации OpenLDAP с самоподписанным сертификатом можно посмотреть здесь. Пример:

# форма OLC (cn=config)
olcTLSCertificateKeyFile: /certs/ldapcert.pem

# форма slapd.conf 
TLSCertificateKeyFile /certs/ldapcert.pem

# минимальная защита - установка прав только на файл
# подразумевается учётная запись ldap
chown ldap:ldap /certs/ldapcert.pem
chmod 0400 /certs/ldapcert.pem

# установка защиты на директорию и файл
chown -R ldap:ldap /certs/*
chmod -R 0400 /certs/*

olcTLSCipherSuite (TLSCipherSuite)

# форма OLC (cn=config)
olcTLSCipherSuite: cipher-list

# форма slapd.conf 
TLSCipherSuite cipher-list

Атрибут (директива) сервера TLS. Это необязательная директива и по умолчанию подразумевается значение ALL (смотрите ниже). Определяет один или несколько шифров, которые будут использоваться во время переговоров об установке соединения TLS. В ходе этих переговоров клиент TLS предлагает список шифров и сервер TLS примет первый шифр из своего списка шифров, который совпадёт с одним из предлагаемых клиентом. Используемый в описании данной директивы термин cipher-list определяет список (в формате OpenSSL), который будет переконвертирован библиотеками OpenSSL в список шифров в формате TLS/SSL. Дополнительную информацию о формате chiper-list можно получить в документации по шифрам OpenSSL. Примеры конфигурации OpenLDAP с самоподписанным сертификатом можно посмотреть здесь.

Список доступных шифров (и, следовательно, cipher-list) определяется форматом открытого ключа, содержащегося в сертификате X.509, указанного в атрибуте olcTLSCerificateFile (директиве TLSCertificateFile). Так, если данный сертификат содержит открытый ключ RSA, то только шифры открытого ключа RSA могут быть использованы на этапах обмена ключами/аутентификации при установке соединения TLS.

Если требуется обоюдная проверка сертификатов (и сервер и клиент TLS посылают сертификаты), то либо должен быть известен формат открытого ключа обоих сертификатов сервера и клиента TLS, либо должно использоваться значение ALL (смотрите команды ниже).

Отдельные пункты в cipher-list разделяются двоеточием, запятой или пробельным символом. Далее приводится подмножество имён RSA TLSv1, которые могут фигурировать в cipher-list, и эквивалентных им текстовых значений шифров TLS (при отправке по каналу они переконвертируются в шестнадцатеричные значения). Примечание: Слово EXPORT (или EXP), встречающееся в некоторых именах, указывает, что эти шифры являются экспортируемыми, то есть некоторые шифры разрешено использовать только в определённых странах (смотрите документацию Бюро промышленности и безопасности Министерства торговли США и Вассенарские соглашения), и это необходимо учитывать при настройке системы TLS, которая будет использоваться на международном уровне.

НАЗВАНИЕ ШИФРА TLS                      НАЗВАНИЕ CIPHER-LIST OPENSSL
==============================          ===================
TLS_RSA_WITH_NULL_MD5                   NULL-MD5
TLS_RSA_WITH_NULL_SHA                   NULL-SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5          EXP-RC4-MD5
TLS_RSA_WITH_RC4_128_MD5                RC4-MD5
TLS_RSA_WITH_RC4_128_SHA                RC4-SHA
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5      EXP-RC2-CBC-MD5
TLS_RSA_WITH_IDEA_CBC_SHA               IDEA-CBC-SHA
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA       EXP-DES-CBC-SHA
TLS_RSA_WITH_DES_CBC_SHA                DES-CBC-SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA           DES-CBC3-SHA
TLS_RSA_WITH_AES_128_CBC_SHA            AES128-SHA
TLS_RSA_WITH_AES_256_CBC_SHA            AES256-SHA
TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA     EXP1024-DES-CBC-SHA
TLS_RSA_EXPORT1024_WITH_RC4_56_SHA      EXP1024-RC4-SHA

Чтобы вывести список значений cipher-list, поддерживаемых локальной инсталляцией OpenSSL, используйте:

# Все действительные шифры (ALL) 
openssl ciphers -v ALL

# Все действительные шифры только для TLSv1
openssl ciphers -v -tls1 ALL

# Действительные шифры только для TLSv1, использующие
# алгоритм обмена ключами/аутентификации RSA
openssl ciphers -v -tls1 RSA

# Действительные шифры только для TLSv1, использующие
# алгоритм обмена ключами/аутентификации RSA
# исключая экспортируемые шифры
openssl ciphers -v -tls1 RSA:!EXP
# ПРИМЕЧАНИЕ: в некоторых оболочках знак ! требует экранирования
openssl ciphers -v -tls1 RSA:\!EXP

# То же, что и предыдущая команда, но исключаются NULL-шифры
openssl ciphers -v -tls1 RSA:!EXP:!NULL
# ПРИМЕЧАНИЕ: в некоторых оболочках знак ! требует экранирования
openssl ciphers -v -tls1 RSA:\!EXP:\!NULL

# Действительные шифры только для TLSv1, использующие
# алгоритм обмена ключами/аутентификации RSA
# только экспортируемые шифры
openssl ciphers -v -tls1 RSA:EXP
# ИЛИ
openssl ciphers -v TLSv1+RSA:EXP

В атрибуте olcTLSCipherSuite (директиве TLSCipherSuite) в качестве chipher-list могут указываться либо общие параметры (используемые в команде openssl chiphers), тогда для получения списка конкретных шифров может быть использована команда openssl, как показано выше (в этом случае порядок предпочтения шифров определяется openssl), либо явно заданный список шифров в порядке их предпочтения. Одно или несколько поддерживаемых значений в cipher-list должны поддерживаться клиентом TLS. Алгоритм поиска совпадений шифров (выбора того, какой шифр будет использован) таков: первый (наиболее предпочтительный) шифр из предоставляемых клиентом, который также поддерживается и сервером, становится шифром соединения (сессии). В следующих примерах используется только подмножество TLSv1 (SSLv3):

# Cipher-list содержит только основанные на RSA
# шифры аутентификации и обмена ключами 
# поддерживаемые TLSv1 (и SSLv3)

# форма OLC (cn=config)
olcTLSCipherSuite: TLSv1+RSA

# форма slapd.conf 
TLSCipherSuite TLSv1+RSA

# Cipher-list содержит только основанные на RSA
# шифры аутентификации и обмена ключами 
# поддерживаемые TLSv1 (и SSLv3)
# исключая экспортируемые и NULL-шифры
# форма OLC (cn=config)
olcTLSCipherSuite: TLSv1+RSA:!EXPORT:!NULL

# форма slapd.conf 
TLSCipherSuite TLSv1+RSA:!EXPORT:!NULL

# Упорядоченный список основанных на RSA
# шифров аутентификации и обмена ключами 
# форма OLC (cn=config)
olcTLSCipherSuite: DES-CBC-SHA:DES-CBC3-SHA:RC4-SHA:RC4-MD5

# форма slapd.conf 
TLSCipherSuite DES-CBC-SHA:DES-CBC3-SHA:RC4-SHA:RC4-MD5

# Все шифры за исключением NULL-шифров
# форма OLC (cn=config)
olcTLSCipherSuite: ALL:!NULL

# форма slapd.conf 
TLSCipherSuite ALL:!NULL

# Значение по умолчанию, эквивалентно случаю
# когда директива не задана
# форма OLC (cn=config)
olcTLSCipherSuite: ALL

# форма slapd.conf 
TLSCipherSuite ALL

Примечание: OpenSSL поддерживает ряд шифров, в результате применения которых может произойти NULL-шифрование данных большого объёма и имитовставок MAC (если этот шифр будет единственным, который взаимно поддерживается и сервером, и клиентом). Это означает, что безопасно выполняется только процесс аутентификации, а вся последующая передача данных происходит в открытом виде. Чтобы предотвратить использование таких шифров, используйте значение !NULL в cipher-list или явно задайте список шифров, не включая в них NULL-шифры.

olcTLSRandFile (TLSRandFile)

# форма OLC (cn=config)
olcTLSRandFile: /path/to/random/file/name

# форма slapd.conf 
TLSRandFile /path/to/random/file/name

Атрибут (директива) сервера TLS. Большинство *nix систем, таких как Linux и BSD, поддерживают либо /dev/urandom, либо /dev/random, поэтому данный атрибут (директива) обычно не требуется. Также можно использовать этот атрибут (директиву) для указания альтернативного источника случайных данных в случае, когда к ним выдвигаются специальные требования, либо /dev/urandom (/dev/random) невозможно прочитать, поскольку он занят другими приложениями. Если директива определяется, она указывает файл, содержащий случайные данные. Альтернативные формы, приемлемые для OpenSSL (который используется в реализации TLS-функций OpenLDAP), можно найти в OpenSSL FAQ.

olcTLSHDParamFile (TLSEphemeralDHParamFile)

# форма OLC (cn=config)
olcTLSHDParamFile: /path/to/file

# форма slapd.conf 
TLSEphemeralDHParamFile /path/to/file

Атрибут (директива) сервера TLS. Указывает файл, содержащий параметры для обмена ключами по алгоритму Диффи-Хеллмана (Diffie-Hellman ephemeral key exchange). Данная директива требуется только когда в файле olcTLSCertificateFile/TLSCertificateFile содержится сертификат DSA/DSS (и olcTLSCertificateKeyFile/TLSCertificateKeyFile указывает на ключ DSA/DSS). Параметры можно сгенерировать следующей командой:

openssl dhparam [-dsaparam] -out <filename> <numbits>

Дополнительную информацию о параметрах DH (dhparam) можно получить на сайте openssl.

olcTLSVerifyClient (TLSVerifyClient)

# форма OLC (cn=config)
olcTLSVerifyClient: never | allow | try | demand

# форма slapd.conf 
TLSVerifyClient  never | allow | try | demand  

Атрибут (директива) сервера TLS. TLS позволяет производить как аутентификацию только сервера (только у сервера есть сертификат X.509), так и обоюдную аутентификацию (и у клиента, и у сервера есть сертификаты X.509). Атрибут olcTLSVerifyClient (директива TLSVerifyClient) определяет, каким образом сервер TLS будет осуществлять обоюдную аутентификацию на основе сертификатов X.509. Значение (по умолчанию) never указывает, что сервер никогда не будет запрашивать сертификат клиента. Значение allow указывает, что сервер будет запрашивать сертификат клиента, и если таковой не будет предоставлен, сессия будет продолжена нормальным образом; если же клиентский сертификат предоставлен, но не может быть проверен (не удалось найти соответствующий корневой (CA) сертификат), то данный клиентский сертификат будет проигнорирован и сессия будет продолжена нормальным образом. Значение try указывает, что сервер будет запрашивать сертификат клиента, и если таковой не будет предоставлен, сессия будет продолжена нормальным образом; если же клиентский сертификат предоставлен, но не может быть проверен (не удалось найти соответствующий корневой (CA) сертификат), то сессия будет прервана. Значение demand указывает, что сервер будет запрашивать сертификат клиента, и если таковой не будет предоставлен, сессия будет прервана; если клиентский сертификат не может быть проверен (не удалось найти соответствующий корневой (CA) сертификат), то сессия также будет прервана. Значение по умолчанию — never.

6.4 Директивы раздела backend (OLC (cn=config) и slapd.conf)

backend

Формат:

backend type

Директива backend определяет название механизма манипуляции данными, который будет использоваться. В конфигурации OLC (cn=config) механизм манипуляции данными определяется записью в форме olcBackend={Z}type,cn=config (где Z представляет собой порядковый номер данной записи в упорядоченном множестве таких записей), использующей объектный класс olcBackendConfig. Полный список поддерживаемых типов механизмов манипуляции данными точно такой же, как и для атрибута olcDatabase (директивы database), смотрите описание далее по тексту.

Пример:

backend bdb
# будут использоваться базы данных Berkeley (Oracle)

Примечание: Нет строгой необходимости в присутствии данной записи (директивы) — можно обойтись без неё и конфигурации OLC (cn=config) и slapd.conf останутся вполне жизнеспособными, тем более в том случае, если наша конфигурация OLC (cn=config) (или slapd.conf) вообще не использует механизмов манипуляции данными. Поскольку данная директива должна указываться непосредственно перед определением записей/директив database того же самого типа, наличие двух практически одинаковых директив может вызвать путаницу. Возможно, разработчикам OpenLDAP пришла в голову идея указания 'общих параметров', которые будут применяться ко всем разделам databases одного типа, что избавляет от необходимости печатать одно и то же (хорошая мысль). Однако, поскольку в большинстве систем LDAP используется одно-единственное DIT (и, следовательно, одна запись/раздел database), практической пользы от записи/директивы backend немного. Используемый в OLC (cn=config) объектный класс, по существу, представляет собой пустую заглушку.

6.5 Директивы раздела database (OLC (cn=config) и slapd.conf)

Атрибуты (директивы) в разделе database состоят из общих атрибутов (директив), которые касаются почти всех типов данных и специфичных атрибутов (директив), которые относятся к определённому типу, например, bdb.

1. olcAccess (access to)
2. Запись (директива) database
3. olcDbIndex (index)
4. olcMirrorMode (mirrormode)
5. Запись (директива) overlay
6. olcReadOnly (readonly)
7. replica
8. replogfile
9. olcRootDN (rootdn)
10. olcRootPW (rootpw)
11. olcSuffix (suffix)
12. olcSyncrepl (syncrepl)
13. updatedn
14. olcUpdateRef (updateref)

Запись (директива) database

Формат:

# форма slapd.conf
database type

Запись (директива) database указывает на начало определения DIT, а также то, каким образом данное DIT будет отображаться в файловой системе.

В конфигурации OLC (cn=config) базы данных определяются записями в форме olcDatabase={Z}type,cn=config. Описание макета/организации cn=config DIT смотрите здесь. Описание добавления/удаления записей database смотрите здесь.

Список поддерживаемых OpenLDAP (slapd) значений type:

Примеры:

# форма slapd.conf
database bdb
# будет использоваться база данных Berkeley (sleepy cat)

olcMirrorMode (mirrormode)

# форма OLC (cn=config)
olcMirrorMode: TRUE | FALSE

# форма slapd.conf
mirrormode TRUE | FALSE

Атрибут olcMirrorMode (директива mirrormode) теоретически используется для указания, что база данных запущена в режиме зеркала ("mirrormode") — вариант репликации с несколькими главными серверами (multi-mastering), разработанный до появления в 2.4+ разнонаправленной репликации с несколькими главными серверами (N-way multi-mastering). В конфигурации с несколькими главными серверами должен присутствовать атрибут olcMirrorMode: TRUE (директива mirrormode TRUE). В случае slapd.conf данная директива должна быть определена во всех разделах database главного сервера, выставляемых для репликации, ПОСЛЕ ВСЕХ ДИРЕКТИВ SYNCREPL в каждом из разделов database. Это необходимо, чтобы разрешить запись в эти разделы database. Во всех случаях (slapd.conf и OLC (cn=config)), если не добавить данную директиву, то операции записи в DIT, выставляемое для репликации с несколькими главными серверами (у которого сразу определены атрибут olcSyncRepl (директива syncrepl) и запись (директива) overlay syncprov), будут завершаться неудачей. Примеры:

# пример размещения директивы в slapd.conf
# при репликации с несколькими главными серверами
# директивы глобальных настроек
...

# фрагмент раздела DIT (database)
database bdb
...
# реплика от первого главного сервера (поставщика)
syncrepl
 ...
# реплика от второго главного сервера (поставщика)
syncrepl
 ...
# собственное определение поставщика
overlay syncprov
...
# после ВСЕХ директив syncrepl
mirrormode TRUE

olcOverlay (overlay)

Запись (директива) overlay указывает на использование наложения (или расширения). В случае конфигурации slapd.conf она определяется в разделе database и всегда должна указываться после всех остальных директив раздела database. За каждой директивой overlay следуют одна или несколько директив, специфичных для данного наложения, которые описаны в документации к наложению (смотрите ниже). Для каждого раздела database могут быть определены несколько директив overlay (за каждой из которых следует одна или несколько директив, специфичных для конкретного наложения). В этом случае они будут применяться в обратном (от их фактического указания в slapd.conf) порядке — то есть наложение, определённое последним, будет применено первым.

В конфигурации OLC (cn=config) каждое наложение — это дочерняя запись по отношению к той записи database, к которой данное наложение будет применяться. Эта запись имеет форму olcOverlay={Z}name,olcDatabase={z}type,cn=config. Описание макета/организации cn=config DIT смотрите здесь. Описание добавления/удаления записей overlay смотрите здесь.

Формат директивы overlay в slapd.conf:

# форма slapd.conf
overlay overlay-name

# пример с двумя директивами overlay
# (наложение accesslog применяется первым)

overlay syncprov
syncprov-checkpoint 10 100
...
overlay accesslog
logdb cn=accesslog
...

Далее приведён неполный список имён наложений (полный список можно найти в man-странице slapd.overlays для версий 2.4+):

olcReadOnly (readonly)

# форма OLC (cn=config)
olcReadOnly: TRUE | FALSE

# форма slapd.conf
readonly on | off

Атрибут olcReadOnly (директива readonly) запрещает выполнение запросов на модификацию (в ответ на них будет возвращаться "не желают исполнять" ("unwilling to perform")), переводя DIT в режим "только для чтения". Если DIT работает как подчинённое (смотрите информацию и примеры конфигурации репликации здесь), то такое DIT автоматически переводится в режим "только для чтения" на всех серверах, за исключением тех, которые указаны в атрибуте olcUpdateDN (директиве updatedn) (при репликации в стиле slurp) или тех, на которых не определялось атрибута olcSyncrepl (директивы syncrepl) (при репликации в стиле syncrepl). В этом случае данная директива НЕ ДОЛЖНА присутствовать. Пример:

# запретить операции модификации для этого DIT
# форма OLC (cn=config)
olcReadOnly: TRUE

# форма slapd.conf
readonly on

replica

Устарела с выходом OpenLDAP 2.4, в конфигурациях OLC (cn=config) поддерживается только в целях переконвертации slapd.conf. Директива replica используется (совместно с директивой replogfile) для описания одного или нескольких подчинённых серверов, на которые производится репликация DIT в стиле slurpd. Данная директива может присутствовать только в определении ГЛАВНОЙ копии DIT (раздел database) на главном сервере репликации. В директиве replica указываются расположение и особенности доступа к каждой ПОДЧИНЁННОЙ копии данного DIT. Дополнительная информация и примеры конфигурации репликации здесь. Директиву replica можно определять только при настройке OpenLDAP вплоть до версии 2.3 (при использовании репликации в стиле slurpd). В версии 2.4 директива replica стала устаревшей и была заменена на атрибут olcSyncrepl (директиву syncrepl). Общий формат директивы replica:

replica uri=ldap[s]://hostname[:port]
 [bindmethod={simple|kerberos|sasl}]
 [binddn="DN"]
 [saslmech=mech]
 [authcid=identity]
 [authzid=identity]
 [credentials=password]
 [srvtab=filename]

В параметре uri указывается схема, хост и, опционально, порт сервера, на котором расположен подчинённый экземпляр DIT. В качестве имени хоста (hostname) можно указать как доменное имя, так и IP-адрес. Если порт (port) не задан, используются стандартные номера портов LDAP: 389 для схемы ldap или 636 — для ldaps.

В параметре binddn указывается DN (строка в кавычках), от имени которого происходит подключение к подчинённому серверу при внесении изменений в подчинённую копию DIT. Это должно быть DN с правами на чтение и запись в базу данных подчинённого slapd, а также оно должно совпадать с DN, указанном в директиве updatedn файла slapd.conf на подчинённом сервере. Из соображений безопасности не рекомендуется, чтобы данный DN совпадал с rootdn главной базы данных (тем не менее, это возможно). Если binddn — это не rootdn, в таком случае он должен указывать на действительную запись в DIT с атрибутом userPassword (или authPassword).

Значением параметра bindmethod может быть simple, kerberos или sasl. Этот параметр указывает метод аутентификации, который будет использоваться при обновлении подчинённой копии DIT. Простая (simple) аутентификация не рекомендуется, если не были соблюдены адекватные меры защиты целостности и конфиденциальности данных (например, TLS или IPSEC). Для простой аутентификации требуется определение параметров binddn и credentials.

Аутентификация kerberos считается устаревшей в пользу механизмов аутентификации SASL, таких как KERBEROS_V4 и GSSAPI. Для аутентификации kerberos требуется определение параметров binddn и srvtab. Подробнее эту тему мы раскрывать не будем.

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

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

Примеры:

# простой уровень безопасности, подключение к подчинённому
# серверу ldap-rep1.example.com с паролем в открытом виде
replica uri=ldap://ldap-rep1.example.com bindmethod=simple
  binddn="uid=admin,ou=admin,dc=example,dc=com" credentials=guess

# простой уровень безопасности, подключение к подчинённому
# серверу ldap-rep1.example.com с паролем в открытом виде
replica uri=ldap://ldap-rep1.example.com bindmethod=simple
  binddn="uid=admin,ou=admin,dc=example,dc=com" 
  credentials=dirtysecret

replogfile

Устарела с выходом OpenLDAP 2.4, в конфигурациях OLC (cn=config) поддерживается только в целях переконвертации slapd.conf. Директива replogfile используется (совместно с директивой replica) для описания одного или нескольких подчинённых серверов, на которые производится репликация DIT в стиле slurpd. Данная директива может присутствовать только в определении ГЛАВНОЙ копии DIT (раздел database) на главном сервере репликации. Директива replogfile задаёт расположение файла, используемого для хранения обновлений каталога, которые slurpd будет рассылать на один или несколько подчинённых серверов. Дополнительная информация и примеры конфигурации репликации здесь. Директиву replogfile можно определять только при настройке OpenLDAP вплоть до версии 2.3 (при использовании репликации в стиле slurpd). В версии 2.4 директива replogfile стала устаревшей, для неё нет эквивалентной директивы при репликации в стиле syncrepl. Общий формат директивы replogfile:

replogfile path/to/logfile

Здесь путь path/to/logfile может быть абсолютным или относительным.

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

Примеры:

# относительный формат пути
replogfile ../log/slavedit.log

# абсолютный формат пути
replogfile /var/log/ldap/slavedit.log

Директива replogfile может также использоваться без соответствующей директивы replica и без запуска slurpd. В этом случае просто генерируется журнал транзакций. Такой файл требует периодического обслуживания, поскольку имеет тенденцию быстро разрастаться.

olcRootDN (rootdn)

Определяет DN root (несчастливый и вводящий в заблуждение в данном контексте термин) или администратора для данного DIT. При подключении от имени rootdn автоматически предоставляются права производить запись во все записи, объектные классы и атрибуты данного DIT — глобальные и локальные ACL не применяются (обходятся любые правила, определённые в атрибутах olcAccess (директивах access)). Если директива rootdn отсутствует, права администратора не предоставляются. Как правило, rootdn требуется на этапе первоначального построения каталога, но после его запуска в работу rootdn может быть удалена по соображениям безопасности. Для olcRootDN/rootdn разрешены только подключения к LDAP с проверкой подлинности.

Запись администратора "волшебная": если пароль для неё определен в olcRootPW/rootpw, то существование в каталоге нормальной записи с таким DN не требуется, то есть нет необходимости делать эту запись видимой в структуре DIT. По соображениям безопасности пользователь может решить не определять соответствующий атрибут olcRootPW (директиву rootpw). В таком случае, поскольку пароль всегда требуется для получения привилегий rootdn/администратора, этот пароль должен храниться в записи DIT, на которую указывает olcRootDN/rootdn. Таким образом, в этом случае данная запись должна быть видимой в структуре DIT и иметь корректный атрибут пароля, например, userPassword из объектного класса person.

DN, указываемый в olcRootDN/rootdn, как правило, находится в пространстве имён того DIT, в записи (разделе) database которого он определяется. Так, если суффикс (olcSuffix/suffix) DIT — dc=example,dc=com , то olcRootDN/rootdn может быть любым DN в пространстве имён dc=example,dc=com, к примеру, cn=anything,dc=example,dc=com. Если же DN, указываемый в olcRootDN/rootdn, находится вне пределов пространства имён данного DIT, то, в зависимости от других параметров конфигурации, при попытке подключения от имени этого DN может быть сгенерирована отсылка в соответствующий DIT для получения пароля. Необязательный атрибут olcRootPW (директива rootpw) обеспечивает аутентификацию при подключении от имени olcRootDN/rootdn.

Во многих дистрибутивах есть файл-пример, в котором olcrootDN/rootdn определён как "cn=Manager,dc=example,dc=com" или что-то в этом роде. Выбор имени cn=Manager совершенно произволен — с таким же успехом это может быть cn=gobbledegook.

# форма OLC (cn=config)
olcSuffix: dc=example,dc=com
# olcRootDN в пространстве имён данного DIT
olcRootDN: cn=joeschmo,dc=example,dc=com

# форма slapd.conf
suffix "dc=example,dc=com"
# rootdn DN в пространстве имён данного DIT
rootdn "cn=joeschmo,dc=example,dc=com"

olcRootPW (rootpw)

Определяет пароль, который будет применяться к учётной записи root или администратора того DIT, которое описывается в данной записи (разделе) database. Эта директива имеет эффект лишь в том случае, когда olcRootDN/rootdn находится в пространстве имён данной записи (раздела) database. Пароль может быть определён как в открытом виде, так и, в целях его защиты, в формате хэш-пароля (создаётся утилитой slappasswd). Пароль можно дополнительно заключать в кавычки для удобства или на случай, если в нём есть пробельные символы. Следует отметить, что использование хэша — это всего лишь способ защиты пароля от непреднамеренной утечки. В качестве альтернативного метода (только для slapd.conf) можно установить права доступа к файлу slapd.conf так, чтобы только у группы ldap (обычно пользователь ldap и группа ldap) были права на чтение с маской доступа 0740 или ниже (slapd автоматически обеспечивает корректные разрешения на slapd.conf, изменяя их при загрузке в случае необходимости). Даже если пароль в OLC (cn=config) или slapd.conf защищён с помощью хэша, в случае, когда LDAP-клиент посылает по сети пароль администратора для проверки подлинности, он отправляется в открытом виде, затем к нему применяется соответствующий механизм хэширования, и результат сравнивается со значением, хранящимся в olcRootPW/rootpw. Таким образом, пароль по-прежнему уязвим к перехватам по сети (TLS снимает данную угрозу).

Если атрибут olcRootPW (директива rootpw) опущен, то могут быть использованы другие методы обеспечения безопасности (например, SASL). Примеры:

# форма OLC (cn=config)
olcRootDN: cn=good,dc=example,dc=com
# простая версия с паролем в открытом виде
# не ставьте пробелов после пароля, если они действительно не нужны!
olcRootPW: secret
# версия с ограничителями
olcRootPW: "secret"
# версия с хэшем SSHA
olcRootPW: {SSHA}HZvHCuZL/YcWfpi/WkqVWASiCxQnEzfW
# то же с ограничителями
olcRootPW: "{SSHA}HZvHCuZL/YcWfpi/WkqVWASiCxQnEzfW"

# форма slapd.conf
rootdn "cn=good,dc=example,dc=com"
# простая версия с паролем в открытом виде
# не ставьте пробелов после пароля, если они действительно не нужны!
rootpw secret
# версия с ограничителями
rootpw "secret"
# версия с хэшем SSHA
rootpw {SSHA}HZvHCuZL/YcWfpi/WkqVWASiCxQnEzfW
# то же с ограничителями
rootpw "{SSHA}HZvHCuZL/YcWfpi/WkqVWASiCxQnEzfW"

Примечания:

1. О том, как добавить хэшированный пароль в OLC (cn=config) или файл slapd.conf, смотрите примечания к описанию утилиты slappasswd в соответствующей главе данного руководства.
2. У многих алгоритмов хэширования, поддерживаемых slappasswd, есть версия с "солью". В данном случае "соль" — добавление некоторого количества случайных данных к паролю, что значительно снижает эффективность применения атак, основанных на подборе по словарю. В общем случае, если используется хэширование, нужно выбирать версии алгоритмов хэширования с "солью".
3. Чтобы защитить пароль при передаче по сети, используйте либо методы SASL, либо TLS/SSL.

olcSuffix (suffix)

Суффикс (suffix) — один из многих путанных терминов в LDAP (известный также как root или base). Атрибут olcSuffix (директива suffix) указывает Distinguished Name узла самого верхнего (корневого) уровня в DIT, описываемого в данной записи (разделе) database. У Вас может быть несколько DIT, каждый из которых описывается в отдельной записи (разделе) database. Примечание: Суффиксы для баз данных config и monitor жестко установлены соответственно в cn=config и cn=monitor, и не могут быть изменены с помощью атрибута olcSuffix (директивы suffix). Именование корневого DN может вызвать головную боль.

# форма OLC (cn=config)
# формат RFC 2377
olcSuffix: dc=example,dc=com

# формат X.500
olcSuffix: ou=example,c=us

# форма slapd.conf
# формат RFC 2377
suffix "dc=example,dc=com"

# формат X.500
suffix "ou=example,c=us"

olcSyncrepl (syncrepl)

Доступна начиная с версий 2.2+. Указывает, что текущая база данных (DIT) является репликой, синхронизирующейся с содержимым другого DIT, путём придания данному серверу статуса потребителя репликации и запуска механизма репликации syncrepl. Соответствующий главный сервер (поставщик репликации) настраивается с помощью записи (директивы) overlay syncprov. Содержимое реплики синхронизируется с содержимым главного сервера по протоколу LDAP Content Synchronization protocol (RFC 4533). Начиная с версии 2.4, OpenLDAP поддерживает оба классических варианта репликации: главный-подчинённый сервер (Master-Slave) и несколько главных серверов (Multi-Master). Дополнительная информация и примеры конфигурации здесь.

# форма OLC (cn=config)
olcSynrepl:

# форма slapd.conf
syncrepl 
  [attrs= attr list>]
  [attrsonly]
  [authcid=identity]
  [authzid= identity]
  [binddn=dn]
  [bindmethod=simple|sasl]
  [credentials=passwd]
  [filter=filter str]
  [interval=dd:hh:mm:ss]
  [logbase=base DN]
  [logfilter=filter str]
  provider=ldap[s]://hostname[:port]
  [realm=realm]
  [retry=[retry-interval num-retries | + ]
  rid=replica-ID 
  [saslmech=mech]
  [schemachecking=on|off]
  [scope=sub|one|base] 
  searchbase=base DN
  [secprops=properties]
  [sizelimit=number-of-entries | unlimited]
  [starttls=yes|critical]
  [syncdata=default|accesslog|changelog]
  [timelimit=time-in-secs | unlimited]
  [type=refreshOnly|refreshAndPersist]

Обязательные параметры: rid, provider и searchbase; все остальные не являются обязательными.

# Отправка пароля аутентификации в открытом виде
# форма OLC (cn=config)
olcSynrepl:
 ...
 bindmethod=simple
 binddn="cn=goodguy,dc=example,dc=com"
 credentials=dirtysecret
 ...
# форма slapd.conf
syncrepl
 ...
 bindmethod=simple
 binddn="cn=goodguy,dc=example,dc=com"
 credentials=dirtysecret
 ...

# форма OLC (cn=config)
olcSynrepl:
 ...
 syncdata=accesslog
 logfilter=(&(objectclass=auditWriteObject)(reqResult=0))

# форма slapd.conf
syncrepl
 ...
 syncdata=accesslog
 logfilter=(&(objectclass=auditWriteObject)(reqResult=0))

Механизм репликации syncrepl поддерживается только механизмами манипуляции данными back-bdb и back-hdb (по состоянию на 2.4.31).

Примеры:

Потребитель будет запрашивать обновления с хоста master-ldap.example.com (используя порт по умолчанию 389) с интервалом в 1 час. Если подключиться к поставщику не удалось, потребитель будет повторно пытаться установить соединения через каждые 5 секунд 5 раз, а затем каждые 300 секунд (5 минут) неограниченное количество раз. Реплицируется DIT целиком (подразумевается, что суффикс гланой копии DIT dc=example,dc=com). Передаются все записи (параметр filter не задан) со всеми пользовательскими и операционными атрибутами (attrs="*,+"). Используется простое подключение от имени cn=admin,ou=people,dc=example,dc=com с паролем в открытом виде. Дополнительная информация и примеры конфигурации здесь.

# форма OLC (cn=config)
olcSuffix: rid=000 
  provider=ldap://master-ldap.example.com
  type=refreshOnly
  interval=00:1:00:00
  retry="5 5 300 +" 
  searchbase="dc=example,dc=com"
  attrs="*,+"
  bindmethod=simple
  binddn="cn=admin,ou=people,dc=example,dc=com"
  credentials=guess
	
# форма slapd.conf
syncrepl rid=000 
  provider=ldap://master-ldap.example.com
  type=refreshOnly
  interval=00:1:00:00
  retry="5 5 300 +" 
  searchbase="dc=example,dc=com"
  attrs="*,+"
  bindmethod=simple
  binddn="cn=admin,ou=people,dc=example,dc=com"
  credentials=guess

Дополнительная информация и примеры конфигурации здесь.

updatedn

Считается устаревшей, начиная с OpenLDAP 2.4, в конфигурациях OLC (cn=config) поддерживается только в целях переконвертации slapd.conf. Данная директива применяется только с экземплярами DIT на подчинённом сервере в случае репликации в стиле slurpd для OpenLDAP вплоть до версии 2.3 (в версии 2.4 стала устаревшей и заменена на директиву syncrepl). Дополнительная информация о репликации и примеры конфигурации здесь.

updatedn DN | SASL-identity

Аргументом директивы может быть DN, от имени которого при внесении изменений в реплику подключается slurpd (применяется, когда в директиве replica на главном сервере bindmethod установлен в simlpe), либо DN, ассоциированный с идентификационной сущностью SASL (если в директиве replica bindmethod установлен в sasl).

# Пример с DN:
updatedn "cn=admin,dc=example,dc=com"

# Пример с SASL:
updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"

olcUpdateRef (updateref)

Атрибут olcUpdateRef (директива updateref) применяется только в конфигурации подчинённого сервера (или сервера-потребителя) и используется как при репликации в стиле slurpd, так и в стиле syncrepl. Дополнительную информацию о репликации и примеры конфигурации можно найти здесь. Поскольку подчинённый сервер (или сервер-потребитель) доступен только для чтения, данная директива определяет URL, который будет возвращаться клиентам, пытающимся выполнить запрос модификации (изменения) к подчинённому экземпляру DIT.

# форма OLC (cn=config)
olcUpdateRef: uri 

# форма slapd.conf
updateref uri

Здесь uri указывается в обыкновенном формате scheme://host[:port]. Если директива updateref определена несколько раз, в возвращаемой отсылке будут указаны все URL.

Примеры:

# порт по умолчанию 389
# форма OLC (cn=config)
olcUpdateRef: ldap://ldap.example.com

# форма slapd.conf
updateref ldap://ldap.example.com

# нестандартный порт
# форма OLC (cn=config)
olcUpdateRef: ldap://ldap.example.com:10389

# форма slapd.conf
updateref ldap://ldap.example.com:10389

# ldap-порт по умолчанию для защищённых соединений (636)
# форма OLC (cn=config)
olcUpdateRef: ldaps://ldaps.example.com

# форма slapd.conf
updateref ldaps://ldaps.example.com

6.5.7 Директивы slapd.conf, специфичные для базы данных null

Описание скоро будет.

6.5.8 Директивы slapd.conf, специфичные для базы данных passwd

Описание скоро будет.

Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.

Нашли ошибку в переводе? Сообщите переводчикам!