Глава 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, описанные в рабочих примерах.

to <what>
Сущность, к которой применяется директива контроля доступа. В одной директиве может быть несколько записей what, разделённых пробельными символами. Условия what могут принимать одну из следующих форм:
* Шаблон, означающий совпадение с любой записью.

dn[.type]=pattern

Данная форма определяет запись на основании её DN (строка, заключённая в кавычки), например, dn="ou=people,dc=example,dc=com". type — это необязательный квалификатор, который может принимать одно из следующих значений:

regex (значение по умолчанию для OpenLDAP вплоть до версии 2.2; начиная с 2.2 значением по умолчанию является base или exact) Регулярное выражение. Если часть его заключена в круглые скобки (), то та подстрока, которая в результате совпала с выражением в скобках (подсовпадение), может затем быть использована в последующих условиях <who> с помощью формы $digit, где digit — цифра от 1 до 9, и $1 заменяется на первое подсовпадение, $2 — на второе, и так далее. Пример:
# Если тестовый 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"
Учебник по регулярным выражениям.
base base используется по умолчанию, если type пропущено (начиная с OpenLDAP версии 2.2). Определяет, что в сравнении участвует та запись, на которую указывает pattern.
exact exact — псевдоним для base.
one указывает на все записи непосредственно (на один уровень) ниже pattern
subtree указывает на все подзаписи (на всех уровнях) ниже pattern, включая и саму запись, определяемую pattern.
children указывает на все подзаписи (на всех уровнях) ниже pattern, но не включая саму запись, определяемую pattern.

Примечание: Значение по умолчанию, подразумеваемое в формате DN, изменилось с выходом OpenLDAP версии 2.2 с regex на base. Несмотря на то, что параметр type является необязательным, его следует всегда указывать, как для исключения двусмысленности, так и для обеспечения обратной и прямой совместимости (в случае, если значение по умолчанию вновь изменится).

attrs=attrlist

Единичный атрибут или разделённый запятыми список атрибутов, к которым применяется директива контроля доступа. (Примечание: Ранее OpenLDAP принимал как attr, так и attrs. Текущие версии (2.4) теперь выдают предупреждения, что attr является устаревшим, поэтому в нашей документации и во всех файлах примеров мы заменили данный параметр на attrs).

Есть три дополнительных псевдоатрибута, которые можно использовать:

entry область действия ограничивается данной записью
children разрешается доступ к дочерним объектам идентифицированной записи
@objectclass В OpenLDAP 2.2+ конструкция @ включает в себя все атрибуты указанного объектного класса; например, attrs=@inetOrgPerson будет включать все атрибуты данного объектного класса и всех его родительских объектных классов (organizationalPerson, person). Если используется форма !, то включаются только атрибуты, которых НЕТ в определениях данного объектного класса (и его родительских объектных классов), то есть attrs=!inetOrgPerson исключает все атрибуты в списках MUST и MAY для данного объектного класса (и его родительских объектных классов).

filter=ldapfilters

Строковое представление поискового фильтра.

Примеры:

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

# доступ к определённым атрибутам
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 <who>
В выражении контроля доступа может быть несколько условий <who>. Они могут принимать следующие формы:
* Шаблон, означающий совпадение с кем угодно.

anonymous

Доступ, предоставленный пользователям, не прошедшим проверку подлинности. Может быть использован в сочетании с auth, например:

... by anonymous auth

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

users

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

self

Доступ к записи разрешается только при условии, что пользователь прошёл аутентификацию от имени данной записи с паролем, используемым в этой записи.

dn[.type[,modifier]]=pattern
 

Доступ предоставляется совпавшему DN. Необязательный параметр type принимает те же значения, что и в форме dn условия what. При использовании же с данным условием (<who>) в type также разрешено значение level{n}, где n начинается от 0 и определяет единственный уровень в DIT, отсчитываемый от pattern. Так, level{0} — функциональный эквивалент base (или exact), level{1} — функциональный эквивалент one, а level{3} указывает, что будут совпадать только записи на 3-м уровне ниже pattern. pattern представляет собой строку в кавычках. Ключевое слово expand может быть использовано совместно с type в качестве модификатора, указывающего, что значения в форме $<digit> должны быть заменены на подсовпадения из условия <what>. Примечание: в версии 2.4 использование модификатора expand совместно с regex отклоняется, даже если присутствует выражение подсовпадения. Пример:

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

Замечание (от которого может произойти помрачение рассудка): подсовпадения в форме $n, как правило, работают только когда предшествующее условие <what> типа regex. Однако, при использовании в условии <what> значений type типа base, subtree, one или children специальное значение подсовпадения $0 заменяется на совпавшую в условии <what> строку DN целиком. Хуже того, если в условии <what> type будет subtree, one или children, то специальное значение подсовпадения $1 заменяется на самое правое значение в условии <what>. Примеры:

# Две следующие директивы 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
dnattr=attrname
 

Доступ предоставляется тем пользователям, чьи DN перечислены в атрибуте attrname той записи, к которой они собираются получить доступ.

group[/objectclass[/attrname]][.type]=pattern
 

Доступ предоставляется членам группы, DN записи которой указан в pattern. Необязательные параметры objectclass и attrname могут использоваться для указания атрибута, на основании которого определяется членство в группе (значение по молчанию для objectclass — groupOfNames, для attrname — member). Необязательный параметр type может быть либо expand (что позволяет подстановку из регулярного выражения в предыдущих условиях), либо exact (по умолчанию). pattern представляет собой строку в кавычках.

peername[.type]=pattern
peername[.ip|ipv6|path]=value
 

Существует две формы директивы peername. При использовании вместе с type, pattern должен указывать тип поиска соответствия в форме IP=ip[:port] (для IPv4 и IPv6) или

PATH=/full/path (для имени файла именованного канала). type может быть либо regex (подразумевается, что будут осуществляться подстановки из регулярных выражений в предыдущих условиях), либо exact (псевдоним — base). Примечание: при типе exact (по умолчанию) индикаторы типа поиска соответствия IP= или PATH= включаются в совпадение.

Во второй форме явный тип канала определяется квалификатором в левой части выражения, а value задаётся в форматах:

peername.ip=ipv4[%netmask][{port}]
peername.ipv6=ipv6[%netmask][{port}]
peername.path=/path/to/named/pipe/file/name

Примечание: Необязательный номер порта заключается в фигурные скобки.

Примеры:

# Простой формат 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)

Хотя поддержка формата IP-префикса (или слеш-нотации) и обсуждается в некоторых документациях, в ходе наших экспериментов (на 2.4.8) выяснилось, что указание netmask для IP-адресов в формате IP-префикса не поддерживается. Поскольку форматы адресации IPv6 поддерживают только формат IP-префикса для указания маски подсети, создаётся впечатление, что в настоящее время маски подсетей для IPv6 не поддерживаются.

sockname[.type]=pattern
sockurl[.type]=pattern
 

Для определения возможности доступа имя файла именованного канала (для формы sockname) или URL источника (для формы sockurl) сравнивается с pattern. Необязательный параметр type может быть либо regex (подразумевается, что будут осуществляться подстановки из регулярных выражений в предыдущих условиях), либо exact (по умолчанию).

domain[.type[,modifier]]=pattern
 

Доменное имя хоста, с которого производится подключение, сравнивается с pattern для определения возможности доступа. Необязательный параметр type может быть expand (подразумевается, что будут осуществляться подстановки из регулярных выражений в предыдущих условиях), exact (по умолчанию), либо subtree. subtree считается совпавшим, когда полностью определённое доменное имя точно соответствует шаблону домена, или одна из конечных частей (с правой стороны) при разделении по точкам полностью определённого доменного имени точно соответствует шаблону домена. Так, конструкции domain.subtree=example.com будут соответствовать example.com, ftp.example.com или ldap.example.com, но не www.anexample.com. Доменное имя хоста, с которого производится подключение, определяется путём выполнения обратного разрешения DNS-имени по IP-адресу хоста. В IPv4 нет строгого требования, чтобы для IP адресов устанавливалось обратное разрешение (такое требование есть в IPv6), поэтому подобный контроль доступа на основе доменного имени должен применяться с большой осторожностью. По умолчанию, обратное разрешение DNS-имени (требуемое данной функцией) отключено (смотрите reverse-lookup). Значение modifier может быть только expand, таким образом domain.expand= функционально эквивалентно domain.exact,expand=.

set[.style]=pattern
 

описание этой конструкции ещё не готово

ssf=n
transport_ssf=n
tls_ssf=n
sasl_ssf=n
Такая версия позволяет использовать фактор силы криптографической защиты, ассоциируемой с сессией пользователя, для определения возможности получения доступа. Это применимо только при использовании сессий, защищаемых с помощью SASL или TLS/SSL. Значение n определяет минимальный требуемый уровень защиты информации, выражаемый как минимальное число бит в ключе какого-либо криптографического алгоритма — как правило, в диапазоне от 40 до 256, в зависимости от применяемого алгоритма (стандартные значения — 40, 56, 64, 128, 164 и 256). Так, значение 1 указывает, что может быть применён любой уровень криптографической защиты; значение 128 указывает, что будет пропущена сессия с применением криптографического алгоритма, длина ключа которого не менее 128 бит, а при ключе, скажем, длиной 56 бит сессия будет отклонена. Примеры:
# Указывает, что пользователь, запрашивающий доступ, 
# ДОЛЖЕН использовать сессию 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

aci=attrname

Контроль доступа определяется по значению атрибута attrname той записи, к которой осуществляется доступ. ACI являются экспериментальными; для того, чтобы эта функция работала, её нужно включить во время компиляции.

<accesslevel>

accesslevel определяет уровень доступа или конкретные привилегии доступа, которые будут предоставлены тому, у кого было найдено совпадение с полем who. Может быть в такой форме:

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

Описание параметров:

self

Модификатор self позволяет выполнение специальных операций, таких как получение определённого уровня доступа или привилегий, только в случае, когда в операции участвует запись пользователя, от имени которого происходит запрос. Это означает, что пользователь, делающий запрос, произвёл подключение с проверкой подлинности. Примером может послужить право на запись самого себя в атрибут member записи группы, позволяющее кому-либо добавлять/удалять свой собственный DN из списка членов группы, не имея при этом возможности сделать это с другими членами группы.

level

level определяет привилегии доступа и может принимать одно из приведённых значений. Каждый уровень доступа включает в себя все нижестоящие уровни; так, уровень search позволяет получать доступ search, compare, auth и disclose.

Может принимать одно из следующих значений:

manage Можно управлять объектами, определёнными в условии <what>. Это самый высокий уровень полномочий, аналогичный root в системе *nix или rootDN в OpenLDAP.
write Можно осуществлять запись в объекты, определённые в условии <what>.
read Можно читать содержимое атрибутов, определённых в условии <what>.
search Можно осуществлять поиск по атрибутам, определённым в условии <what>.
compare Можно осуществлять сравнение объектов, определённых в условии <what>.
auth Означает, что OpenLDAP позволяет осуществить внутренний доступ к атрибутам, определённым в условии <what>, исключительно в целях аутентификации/авторизации, например, в ходе операции подсоединения.
disclose Содержимое атрибутов, определённых в условии <what>, может быть раскрыто в сообщениях об ошибках.
none Доступ не разрешается.

priv

Модель доступа priv опирается на явные настройки привилегий доступа для каждого условия. Знак = сбрасывает все предыдущие дополнительные настройки доступа, и, как следствие, окончательные привилегии доступа будут равны тем, которые определены в самом условии. Знаки + и - добавляют/удаляют привилегии доступа к существующим. Привилегии могут быть m = manage, w = write, r = read, s = search, d = disclose, c = compare и x = authentication. В одном выражении может быть добавлено более одной привилегии.

Формат:

{=|+|-}{w|r|s|c|x}+
<control>
control не является обязательным, и, если присутствует, принимает одно из следующих значений:

stop

Значение по умолчанию; подразумевается, когда control отсутствует. В случае совпадения контроль доступа прекращается.

continue

continue позволяет перейти к рассмотрению других условий <who> в том же самом условии <access>; таким образом можно попытаться осуществить последовательное изменение привилегий. Если больше не найдено ни одного совпадения с условиями <who>, будет применено последнее из совпавших условий <who>.

break

break позволяет перейти к обработке других условий <access>, совпадающих с тем же целевым объектом.

Вот и всё, что касается директивы 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, не могут производить запись в какой бы то ни было атрибут, а пользователи, не прошедшие аутентификацию, не могут читать, производить поиск или выполнять любую другую операцию над какой-либо записью или атрибутом.

Наверх

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

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

LDAP — Структура с общей и персональными адресными книгами

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

  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 [...]

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

bind_anon_cred Разрешает простые соединения с предоставлением учётных данных (пароля), но без предоставления значения DN. Если данная характеристика не указана, все подобные подсоединения будут отклоняться (LDAP_INVALID_CREDENTIALS = 49, x'31).
bind_anon_dn Разрешает простые соединения с предоставлением DN, но без предоставления учётных данных — технически это неавторизованное соединение. Если данная характеристика не указана, все подобные подсоединения будут отклоняться (LDAP_UNWILLING_TO_PERFORM = 53, x'35).
bind_v2 Разрешает серверу принимать соединения LDAP версии 2, в противном случае они будут отклоняться.
prozy_authz_anon Описание будет позже.
update_anon Позволяет под контролем ACL вносить изменения в DIT при анонимных подключениях. По умолчанию при анонимных подключениях, независимо от каких-либо настроек ACL, нельзя производить запись в DIT, если данная характеристика не включена.

Примеры:

# фрагмент 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 [...]

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

bind_anonПредотвращает анонимные подключения, то есть подключения без предоставления DN и учётных данных (пароля). В любом случае, даже без указания этой директивы, подключения с предоставлением DN, но без предоставления учётных данных (пароля) будут завершаться неудачей (но могут быть разрешены с помощью директивы allow bind_anon_dn). Точно также подключения без предоставления DN, но с предоставлением учётных данных (пароля) будут завершаться неудачей (но могут быть разрешены с помощью директивы allow bind_anon_cred).
bind_simpleОтключает возможность любых простых подключений — как анонимных, так и с проверкой подлинности. Использование данного ключевого слова означает, что сервер будет принимать только методы аутентификации SASL.
noneЗначение по умолчанию.
tls_2_anonОписание будет позже.
tls_authcОписание будет позже.

Примеры:

# форма 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)

Лучше определять директивы index файла slapd.conf перед первоначальной загрузкой каталога (с помощью ldapadd), тогда при первоначальной загрузке соответствующие индексы будут созданы автоматически. При внесении изменений в настройки индексов после первоначальной загрузки требуется переиндексирование (повторное создание индексов) каталога с помощью slapindex (предупреждение: перед этим slapd должен быть остановлен).

В OLC (cn=config) используется атрибут olcDbIndex, который может присутствовать только в записях olcDatabase={Z}xxx,cn=config. Кроме того, переиндексирование выполняется в режиме реального времени, то есть любое изменение какого-либо из атрибутов olcDbIndex применяется немедленно и сразу происходит переиндексирование (выполнение slapindex не требуется). Непонятно, однако, как при использовании OLC (cn=config) определить, когда переиндексирование выполнилось — нет каких-либо видимых индикаторов его завершения.

Формат:

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

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

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

Атрибуты olcDbIndex (директивы index) определяют, какие индексы будут обслуживаться OpenLDAP. Может быть включено любое количество параметров индексирования. Даже если атрибут не был указан в директивах index, его всё равно можно использовать в поисковых фильтрах — если это будет происходить часто, то, конечно, производительность будет страдать, а если раз в жизни — ничего страшного.

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

Необязательный параметр default содержит те индексы, которые должны поддерживаться по умолчанию. Они применяются к атрибутам в последующих директивах index, в которых пропущен список индексов. Атрибут olcDbIndex (директива index) со значением default должен быть определен до появления атрибутов olcDbIndex (директив index) без списка индексов. Если определено несколько атрибутов olcDbIndex (директив index) со значением default, каждый из них будет влиять на атрибуты olcDbIndex (директивы index), следующие непосредственно за ним, до появления очередного атрибута olcDbIndex (директивы index) со значением default.

Индекс pres следует использовать, если предполагается, что будут выполняться поисковые запросы в форме 'objectclass=person' или 'attribute=mail'.

Индекс approx НЕОБХОДИМО использовать, если предполагается, что будут выполняться поисковые запросы в форме 'sn~=person' (поиск 'созвучных' значений).

Индекс eq следует использовать, если предполагается, что будут выполняться поисковые запросы в форме 'sn=smith', то есть без применения поисковых шаблонов (используется только правило EQUALITY).

Индекс sub следует использовать, если предполагается, что будут выполняться поисковые запросы в форме 'sn=sm*', то есть с применением поисковых шаблонов (используется правило SUBSTR). Данный индекс можно задать более конкретно, указывая subinitial (оптимизация под 'sn=*s'), subany (оптимизация под 'sn=*n*') или subfinal (оптимизация под 'sn=th*'). Для одного атрибута можно указать несколько индексов типа sub.

Параметр special связан с подтипами (subtype), может быть либо nolang, либо nosubtypes.

Будьте очень внимательны при выборе того, какие индексы будут поддерживаться каталогом. Лучше делать это на основании требований приложений; если их не учитывать, это может серьёзно повлиять на производительность каталога. И наоборот, нет никакого смысла индексировать те атрибуты, поиск по которым никогда не осуществляется. Если в поисковых запросах используются только правила EQUALITY, нет смысла устанавливать индексирование sub. Индексы потребляют память (чем больше индексов, тем больше они занимают оперативную память). Кроме того, операции записи и модификации при большом количестве индексов будут выполняться дольше, поскольку требуется время и ресурсы на обновление индексов.

Примеры:

# Простое использование значения 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:

numberhex-valuelog-nameОписание уровня журналирования
-10xFFFFanyвключить всю отладочную информацию
00x0000-журналирование отключено — в журнал ничего не выводится, в том числе критические ошибки. Не рекомендуется.
10x1traceотслеживание вызовов функций
20x2packetsотладка обработки пакетов
40x4argsусиленная отладка
80x8connsуправление соединениями
160x10BERвывод посылки и приёма пакетов
320x20filterобработка поисковых фильтров
640x40configобработка конфигурационного файла
1280x80ACLобработка списков контроля доступа
2560x100statsстатистика соединений/операций/результатов (значение по умолчанию)
5120x200stats2статистика посылки записей журнала
10240x400shellвывод взаимодействия с механизмами манипуляции данными shell
20480x800parseвывод отладочной информации разбора записей
40960x1000cacheкеширование (не используется)
81920x2000indexиндексирование (не используется)
163840x4000syncвывод журнала syncrepl (репликации)
327680x8000nonenone — неверное наименование, на данном уровне выводятся сообщения, не попавшие в другие категории, включая, в том числе, высокоприоритетные сообщения

Директива 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, применяются аддитивно, то есть все их требования должны быть соблюдены. В директиве может быть указано одно или несколько из перечисленных ниже значений (разделённых пробельными символами, например, пробелом или табуляцией):

authcТребуется, чтобы при любом обращении к DIT, перед тем как выполнить какую-либо операцию с каталогом, была пройдена LDAP-аутентификация. Использование этого значения также подразумевает неявное использование ключевого слова bind.
bindТребуется, чтобы при любом обращении к DIT, перед тем как выполнить какую-либо операцию с каталогом, было выполнено подсоединение (bind). Данное ключевое слово просто требует подсоединения, которое может быть и анонимным подсоединением, и не подразумевает требования прохождения LDAP-аутентификации.
LDAPv3Требуется, чтобы при любом обращении к DIT использовались процедуры 3-ей версии протокола LDAP.
noneЗначение по умолчанию. Указывает, что никаких требований не предъявляется, и может применяться для сброса требований после их использования в разделе database. При отсутствии подобного сброса, последнее значение атрибута olcRequires (директивы require), определённого ранее, распространяется на все последующие разделы database. Если же сброса не произошло и объявляются следующие атрибуты olcRequires (директивы require), то требования каждой последующей директивы складываются с требованиями всех предыдущих директив с момента последнего сброса (то есть директивы являются аддитивными).
SASLТребуется, чтобы перед выполнением операций с DIT была выполнена SASL-аутентификация. Использование данного значения не подразумевает прохождения LDAP-аутентификации или подсоединения; таким образом, неявного использования ключевых слов authc и bind не подразумевается.
strongТребуется, чтобы перед выполнением операций с DIT были выполнены либо SASL, либо TLS процедуры. Использование данного значения не подразумевает прохождения LDAP-аутентификации или подсоединения; таким образом, неявного использования ключевых слов authc и bind не подразумевается.

Примеры:

# сбрасывает значение предыдущих требований 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 из следующего списка:

sasl=nЕсли устанавливается сессия SASL, то минимальная длина ключа должна быть не менее n.
simple_bind=nСервер будет отказываться принимать любые операции подсоединения, не защищённые сессиями TLS или SASL c SSF не менее n (ошибка LDAP_CONFIDENTIALITY_REQUIRED, 13, x'0D).
ssf=nПри установке соединений SASL или TLS требуется, чтобы минимальная длина ключа была не менее n.
tls=nЕсли устанавливается сессия TLS, то минимальная длина ключа должна быть не менее n.
update_sasl=nСервер будет отказываться принимать любые операции обновления каталога (изменения, модификации, и т.д.), не защищённые сессией SASL с SSF не менее n.
update_ssf=nСервер будет отказываться принимать любые операции обновления каталога (изменения, модификации, и т.д.), не защищённые сессиями SASL или TLS с SSF не менее n.
update_tls=nСервер будет отказываться принимать любые операции обновления каталога (изменения, модификации, и т.д.), не защищённые сессией TLS с SSF не менее n.

Значение 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:

ТипОписание
bdbБаза данных Berkeley от Oracle — в прошлом предпочитаемый механизм OpenLDAP (сейчас — mdb). Директивы, специфичные для bdb. Имена динамически загружаемых модулей — back_bdb.la или back_bdb.so. Будьте осторожны: судя по всему, есть тенденция добавлять номер версии к имени загружаемого модуля, например, back_bdb-2.4.so
configСпециальная запись, позволяющая производить конфигурирование OpenLDAP во время исполнения с помощью LDAP-браузера или файлов LDIF. Использует DIT с жёстко установленным именем cn=config. О настройках и использовании cn=config читайте здесь.
dnssrvЭто не база данных, а механизм, позволяющий slapd генерировать отсылки путём опроса записей DNS на основании указанного суффикса. Директивы, специфичные для dnssrv.
hdbБаза данных Berkeley от Oracle — в прошлом предпочитаемый механизм OpenLDAP (сейчас — mdb). Абсолютно то же самое, что и bdb, только используется иерархическое представление данных. Если Вам часто приходится выполнять переименование целых поддеревьев — это механизм манипуляции данными для Вас! Если Вы не поняли, о чём говорится в последнем предложении — используйте bdb. Директивы, специфичные для hdb (те же самые, что и для bdb). Имена динамически загружаемых модулей — back_hdb.la или back_hdb.so. Будьте осторожны: судя по всему, есть тенденция добавлять номер версии к имени загружаемого модуля, например, back_hdb-2.4.so
mdb Предпочитаемая для OpenLDAP база данных. Использует встроенную, специально разработанную систему баз данных, устраняет зависимость от продуктов Oracle. Директивы, специфичные для mdb. Имена динамически загружаемых модулей — back_mdb.la или back_mdb.so. Будьте осторожны: судя по всему, есть тенденция добавлять номер версии к имени загружаемого модуля, например, back_mdb-2.4.so
ldapПозволяет LDAP следовать по отсылкам (разрешать отсылки), вместо того, чтобы просто возвращать отсылки клиенту. Директивы, специфичные для ldap. Имена динамически загружаемых модулей — back_ldap.la или back_ldap.so. Будьте осторожны: судя по всему, есть тенденция добавлять номер версии к имени загружаемого модуля, например, back_ldap-2.4.so
ldbmLDAP DBM — может использоваться любая из баз данных BDB, GNU DBM, MDBM или NDBM. Директивы, специфичные для ldbm. Механизм считается устаревшим, начиная с OpenLDAP 2.4.
metaПозволяет LDAP следовать по отсылкам (разрешать отсылки), вместо того, чтобы просто возвращать отсылки клиенту. Расширенная версия механизма ldap, позволяющая использовать несколько серверов, а также маскировку контекстов именования (DIT). Директивы, специфичные для meta. Имена динамически загружаемых модулей — back_meta.la или back_meta.so. Будьте осторожны: судя по всему, есть тенденция добавлять номер версии к имени загружаемого модуля, например, back_meta-2.4.so
monitorМеханизм LDAP, позволяющий получать статусную информацию slapd по протоколу LDAP. Директивы, специфичные для monitor. Имена динамически загружаемых модулей — back_monitor.la или back_monitor.so. Будьте осторожны: судя по всему есть тенденция добавлять номер версии к имени загружаемого модуля, например, back_monitor-2.4.so
nullНичего. Эквивалент /dev/null для LDAP.
passwdОчень специфическая конфигурация, позволяющая делать поисковые запросы к системному файлу passwd.
perlПозволяет LDAP проецировать запросы напрямую на объекты PERL.
shellПозволяет LDAP проецировать запросы в команды оболочки (shell) и запускать внешние программы — API для бедных.
sqlПозволяет LDAP использовать ODBC для проецирования LDAP-запросов в реляционные СУБД — оболочка для реляционных СУБД. Директивы, специфичные для sql.

Примеры:

# форма 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+):

accesslogВедение журнала доступа. Сохраняет сведения об изменениях DIT в виде серии записей в отдельном DIT, к которому потом можно обратиться. Данное наложение требуется при репликации типа delta-syncrepl. Параметры и настройки данного наложения здесь. Дополнительную информацию можно получить в man-странице slapo-accesslog. Имена динамически загружаемых модулей — accesslog.la или accesslog.so.
chainСцепление (chaining). Позволяет разрешать (или сцеплять) объекты referral в DIT, таким образом клиенту может возвращаться результат запроса, а не просто отсылка (подробнее об этом здесь). Параметры и настройки данного наложения здесь. Дополнительную информацию можно получить в man-странице slapo-chain. Имена динамически загружаемых модулей — chain.la или chain.so
dynlistДинамические группы. Нестандартная (нет соответствующего RFC) функция, получившая, однако, широкое распространение. С её помощью можно динамически создавать группы на основе LDAP-запросов (в отличие от статических групп, использующих объектный класс groupOfNames). Параметры и настройки данного наложения здесь. Примеры конфигурации и использования здесь. Дополнительную информацию можно получить в man-странице slapo-dynlist. Имена динамически загружаемых модулей — dynlist.la или dynlist.so.
pcacheКэширующий прокси. Позволяет серверу LDAP принимать запросы от клиентов и перенаправлять их на несколько других серверов LDAP. Параметры и настройки данного наложения здесь. Дополнительную информацию можно получить в man-странице slapo-pcache. Имена динамически загружаемых модулей — pcache.la или pcache.so.
ppolicyПолитики паролей. Предоставляет механизмы контроля за использованием паролей: контроль устаревания пароля, обязательное переназначение пароля и т.п. Параметры и настройки данного наложения здесь. Дополнительную информацию можно получить в man-странице slapo-ppolicy. Имена динамически загружаемых модулей — ppolicy.la или ppolicy.so.
rwmПерезапись DN. Предоставляет возможность перезаписи DN перед использованием. Параметры и настройки данного наложения здесь. Дополнительную информацию можно получить в man-странице slapo-rwm.
syncprovКонтроль за обеспечением управления синхронизацией на стороне сервера-поставщика syncrepl. Данное наложение требуется на главном сервере (поставщике) репликации в стиле syncrepl, потребители которого настраиваются атрибутом olcSynrepl (директивой syncrepl). Параметры и настройки данного наложения здесь. Дополнительную информацию можно получить в man-странице slapo-syncprov. Имена динамически загружаемых модулей — syncprov.la или syncprov.so.

Наверх

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; все остальные не являются обязательными.

bindmethod Может быть либо simple, либо sasl. Если bindmethod установлен в simple, то должны быть определены параметры binddn (строка в кавычках) и credentials. При использовании simple все данные, в том числе, возможно, и пароли посылаются в открытом виде и, следовательно, могут быть перехвачены при передаче по сети. Если bindmethod установлен в sasl, то должен быть определён параметр saslmech. В зависимости от этого механизма, аутентификационная идентификационная сущность и/или учётные данные могут быть указаны в параметрах authcid и credentials. Для указания авторизационной идентификационной сущности может быть использован параметр authzid. Специфичные для соединения SASL свойства безопасности (такие как ключевое слово sasl-secprops) могут быть заданы параметром secprops. Отличный от заданного по умолчанию SASL realm может быть задан параметром realm.
binddn Необязательный параметр binddn определяет DN (и любые требуемые для аутентификации сведения в зависимости от выбранного метода bindmethod), которые позволят получить доступ к searchbase. Хотя есть соблазн использовать rootdn целевого DIT, этого следует избегать там, где это только возможно. Указываемому в binddn пользователю требуются только права на чтение (осуществление поиска) в том DIT или в том фрагменте DIT, который будет реплицироваться. В общем случае, нужно использовать DN с минимально возможным уровнем полномочий, либо создать отдельный ACL, предоставляющий минимальный уровень доступа (только чтение). Если параметр не указан, осуществляется анонимное подсоединение — как-то страшновато.
credentials Параметр credentials требуется всегда при bindmethod=simple а также, в зависимости от метода SASL, может потребоваться и при bindmethod=sasl. Он указывает пароль, который будет использоваться при аутентификации во время подсоединения от имени binddn. По умолчанию пароль задаётся в открытом виде (CLEARTEXT), в этом случае он посылается по сети также в открытом виде и, соответственно, может быть перехвачен по сети. Примеры:
# Отправка пароля аутентификации в открытом виде
# форма 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
 ...
interval Этот параметр имеет смысл только при типе репликации RefreshOnly. Он определяет промежуток времени между процессами синхронизации. Время задаётся либо в формате dd:hh:mm:ss, либо количеством секунд. Так, параметр interval=00:01:00:00 (или в секундах interval=3600) говорит о том, что попытки синхронизации будут предприниматься с интервалом в 1 час. Значение по умолчанию — 1 день или 86400 секунд.
logbase Требуется только в случае, когда установлен параметр syncdata=accesslog и включена delta-синхронизация (о том, что это такое, а также примеры конфигурации смотрите здесь). Параметр определяет суффикс DIT, в котором хранится accesslog (он должен соответствовать значению logdb, указанному для наложения overlay accesslog на сервере-поставщике, DIT которого будет реплицироваться.
logfilter Требуется только в случае, когда установлен параметр syncdata=accesslog и включена delta-синхронизация (о том, что это такое, а также примеры конфигурации смотрите здесь). Параметр определяет поисковый фильтр, используемый при чтении accesslog. Типичное значение logfilter при операциях delta-синхронизации:
# форма OLC (cn=config)
olcSynrepl:
 ...
 syncdata=accesslog
 logfilter=(&(objectclass=auditWriteObject)(reqResult=0))

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

Объектный класс auditWriteObject используется при сохранении записей журнала в accesslog. Атрибут reqResult=0 указывает на сохранённый код возврата операции; соответственно, значение 0 говорит о том, что в ответ на поисковый запрос будут возвращаться только успешные операции.

provider Указывает сайт поставщика репликации, содержащий главную копию реплицируемого контента, в виде LDAP URI. Если в URI не задан порт (port), используется стандартные порты LDAP (389) или LDAPS (636).
retry Если во время репликации (как в режиме refreshOnly, так и в режиме refreshAndPersist) возникнет ошибка, потребитель будет пытаться произвести пересоединение согласно значению параметра retry. Это значение представляет собой список пар интервал между повторами (retry-interval) и количество повторов (num-retries). Например, retry="60 10 300 3" указывает потребителю повторять попытки подключения через каждые 60 секунд первые 10 раз, а затем через каждые 300 секунд ещё 3 раза, после этого остановить попытки подключения. num-retries может быть установлено в '+', тогда потребитель будет пытаться подключиться неограниченное количество раз, то есть retry="300 +" указывает повторять попытки подключения через каждые 300 секунд бесконечное количество раз.
rid Идентифицирует текущую директиву syncrepl в составе сервера-потребителя репликации. Это произвольное, уникальное, положительное целое число длиной не более трёх цифр. Так, если на сервере один атрибут olcSyncrepl (директива syncrepl), то для этой цели можно использовать rid=000 (или rid=001, или любое число от 1 до 3 цифр), если на сервере более одного атрибута olcSyncrepl (директивы syncrepl), первый из них может иметь rid=000, второй — rid=001, и так далее. Таким образом, параметр rid должен быть уникальным в составе сервера. Связи между значениями rid и olcServerID/ServerID (SID), который требуется в конфигурации репликации с несколькими главными серверами (multi-master), нет.
schemachecking schemachecking предписывает выполнять стандартные проверки соблюдения схемы данных. Значение по умолчанию — off.
searchbase Содержимое реплики syncrepl определяется с помощью спецификации поиска LDAP — таким образом для потребителя существует возможность реплицировать любое DIT как целиком, так и частично. Сервер-потребитель отправляет поисковый запрос серверу-поставщику согласно спецификации поиска, которая определяется параметрами searchbase (строка в кавычках), scope (значение по умолчанию — sub), filter (значение по умолчанию — (objectclass=*)), attrs (значение по умолчанию —  "*,+", то есть все пользовательские и операционные атрибуты), attrsonly (значение по умолчанию — false), sizelimit (значение по умолчанию — unlimited), и timelimit (значение по умолчанию — unlimited) Эти параметры имеют тот же смысл, что и в обычной спецификации поискового запроса.
starttls Параметр starttls определяет использование расширенной операции StartTLS для установки сессии TLS перед тем, как производить подсоединение к поставщику. Если запрос StartTLS завершился неудачей и значение параметра starttls было critical, сессия будет прервана; если же значение параметра starttls было yes, сессия репликации будет продолжена без TLS. Этот параметр требуется указывать только в случае, когда в URL в параметре provider использовалась схема ldap, например, provider=ldap://ldap1.example.com. Если же использовалась схема ldaps, например, provider=ldaps://ldap1.example.com, то определять параметр starttls не требуется, поскольку в этих условиях операция StartTLS выполняется автоматически.
syncdata

Необязательный параметр syncdata используется для включения delta-синхронизации (о том, что это такое, а также примеры конфигурации смотрите здесь). В нём указывается источник изменений, которые будут применяться к реплицируемому DIT. Значения, которые можно использовать: default (delta-синхронизация не используется), changelog (устаревший формат) или accesslog (включается delta-синхронизация). При этом, для указания соответствующего журнала изменений, необходимо задать параметры logbase и logfilter.

type Протокол LDAP Content Synchronization protocol поддерживает два типа операций. Требуемый тип операции указывается в параметре type. При типе refreshOnly операции синхронизации (поиска) повторяются по расписанию, задаваемому в параметру interval. При завершении сессии синхронизации поставщик возвращает syncCookie и соединение закрывается. По прошествии периода времени, заданного в interval, потребитель инициирует следующую сессию, при этом syncCookie прошлой сессии передаётся для определения диапазона изменений — тогда (если это возможно) потребителю предоставляются только изменения, произошедшие с момента окончания предыдущей сессии. При типе refreshAndPersist начальные этапы сессии такие же, что и при типе refreshOnly, но, после завершения первоначальной синхронизации, соединение не разрывается и изменения (в рамках поискового диапазона синхронизации searchbase) посылаются от поставщика потребителю по мере их возникновения, обеспечивая тем самым практически мгновенное распространение обновлений. При первоначальной репликации syncCookie отсутствует, поэтому диапазон синхронизации будет совпадать с searchbase целиком (обычно это DIT полностью), таким образом можно начать новую репликацию с пустым DIT на сервере-потребителе. Если при этом целевое DIT большого размера, синхронизация может занять значительный промежуток времени.

Механизм репликации 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). Дополнительная информация о репликации и примеры конфигурации здесь.

Директива определяет DN, которому разрешено вносить изменения в реплику.
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

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

Наверх



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

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

Copyright © 1994-2017 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 18 ноября 2016 г.
Переведено участниками проекта Pro-LDAP.ru в 2012-2017 г.