| |
В этой главе умопомрачительно подробно описываются все параметры и атрибуты/директивы, с помощью которых управляются системы 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.
Примечание: Параметры командной строки демона slapd приведены здесь.
Параметры конфигурации по своей специфике подразделяются на глобальные (global) и относящиеся к конкретной базе данных или DIT (database). Следующие замечания могут оказаться полезными:
В 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 даны здесь.
Атрибуты записи глобальных настроек (директивы глобального раздела файла slapd.conf) применяются к LDAP-серверу в целом. Обычно они включают в себя параметры окружения, такие как местонахождение файлов. В OLC они определяются с использованием объектного класса olcGlobal в записи cn=config.
Атрибуты (директивы) формируют строгую иерархию: директивы глобального раздела могут быть переопределены директивами из разделов backend или database, в свою очередь директивы из раздела backend могут быть переопределены директивами из разделов database. Если атрибут (директива) были указаны в глобальном разделе и в дальнейшем не подвергались переопределению, сфера их действия (влияния) распространяется на все нижестоящие разделы (backend и database).
В файле slapd.conf все строки, начинающиеся с #, считаются комментариями и игнорируются.
В файле slapd.conf пустые строки игнорируются. Если же строка начинается с пробельного символа, она считается продолжением предыдущей строки. Это может стать причиной неприятностей. Будьте очень осторожны. В целом, slapd.conf очень привередлив по отношению к пробелам и пустотам.
Каждое DIT со своими свойствами определяется в записи базы данных (с использованием базового объектного класса olcDatabaseConfig) или в разделе database файла slapd.conf.
Для каждого DIT должна присутствовать отдельная запись базы данных (раздел database файла slapd.conf); например, если требуется обслуживать два корневых DN, — dc=example,dc=com и dc=example,dc=net, — то должно быть две записи баз данных (раздела database файла slapd.conf). Может присутствовать любое количество таких записей (разделов). Каждая база данных имеет свой номер. О том, как нумеруются записи баз данных в OLC (cn=config), смотрите здесь. В slapd.conf первому разделу database присваивается номер базы данных 1, второму — 2, и так далее.
Обычно данные конфигурации находятся в:
# 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
Если не указано иное, все приведённые ниже атрибуты/директивы могут присутствовать как в записи/разделе глобальных настроек, так и в записях/разделах 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 — что такое сервер TLS
TLSCACertificateFile (olcTLSCACertificateFile)
TLSCertificateFile (olcTLSCertificateFile)
TLSCertificateKeyFile (olcTLSCertificateKeyFile)
TLSCipherSuite (olcTLSCipherSuite)
TLSRandFile (olcTLSRandFile)
TLSEphemeralDHParamFile (olcTLSDHParamFile)
TLSVerifyClient (olcTLSVerifyClient)
Обзор сервера TLS — что такое клиент TLS
TLS_CACERT
Во всех случаях соответствия директив первой показана форма конфигурации OLC (cn=config), а затем (в скобках) форма slapd.conf. Мы сделали это намеренно, чтобы отразить переход к конфигурации в форме OLC (cn=config). В OLC (cn=config) глобальные атрибуты определяются в записи cn=config, основанной на объектном классе olcGlobal. Смотрите также макет OLC и формат записей.
Формат:
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 — это необязательный квалификатор, который может принимать одно из следующих значений:
Примечание: Значение по умолчанию, подразумеваемое в формате DN, изменилось с выходом OpenLDAP версии 2.2 с regex на base. Несмотря на то, что параметр type является необязательным, его следует всегда указывать, как для исключения двусмысленности, так и для обеспечения обратной и прямой совместимости (в случае, если значение по умолчанию вновь изменится). |
||||||||||||
attrs=attrlist |
Единичный атрибут или разделённый запятыми список атрибутов, к которым применяется директива контроля доступа. (Примечание: Ранее OpenLDAP принимал как attr, так и attrs. Текущие версии (2.4) теперь выдают предупреждения, что attr является устаревшим, поэтому в нашей документации и во всех файлах примеров мы заменили данный параметр на attrs). Есть три дополнительных псевдоатрибута, которые можно использовать:
|
||||||||||||
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}] Примечание: Необязательный номер порта заключается в фигурные скобки. Примеры: # Простой формат 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. Может принимать одно из следующих значений:
|
||||||||||||||||
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):
При подключении от имени olcRootDN (rootdn) (администратора) того DIT, к которому происходит подключение, подразумевается наличие волшебных прав и все правила ACL игнорируются. olcRootDN/rootdn может делать что угодно с чем угодно. Запрещённых приёмов нет.
Если не установлено атрибутов olcAccess (директив access to), по умолчанию OpenLDAP неявно устанавливает:
access to * by anonymous read by * none
Пояснение:
Во всех форматах параметров, содержащих выражения в стиле dn, и где стиль dn определён как regex (регулярное выражение), предоставляемый шаблон pattern используется для поиска совпадений с регулярным выражением; таким образом, при использовании в качестве шаблона dn="dc=example,dc=com" будет найдено совпадение со всеми записями поддерева, например, "ou=people,dc=example,dc=com", но при этом будет использовано гораздо больше ресурсов CPU, чем при получении тех же результатов с помощью выражения dn.subtree="dc=example,dc=com". Разумнее избегать использования regex, если можно применить другой формат, — даже если для этого потребуется более одной директивы.
Директивы access обрабатываются при каждом доступе к каталогу, начиная с той, которая определена первой — порядок очень важен. Эти директивы являются аддитивными: вторая добавляется к функциональности первой, третья — ко второй и так далее. Проверка ACL останавливается, как только найдено совпадение с правилом by <who> и доступ был либо предоставлен, либо запрещён.
Стиль составления директив access. Формат допускает свободную форму и, для облегчения понимания, директива может быть записана как:
access to <parameters> by <parameters> by <parameters> ...
Примечание 1: Каждая новая строка в составе директивы должна начинаться с отступа хотя бы в один пробельный символ.
Примечание 2: Хотя формат записи атрибута olcAccess (директивы access to) очень гибок, не разрешается помещать комментарии (строки, начинающиеся с #) в каком-либо месте атрибута olcAccess (директивы access to).
Для каталога может быть установлен один или несколько атрибутов 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
Пояснения:
Каждый атрибут 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
Пояснения:
ACL1
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
Пояснения:
ACL1
ACL2
Построение политики контроля доступа (Access Control Policy, ACP, известную также как ACL) на основании корпоративной политики безопасности (круто!), которая гласит:
Владелец записи каталога имеет право просматривать ВСЕ атрибуты своей записи, включая пароли.
Сотрудники отдела Human Resources должны иметь право обновлять ЛЮБУЮ запись, но не должны иметь прав на чтение или запись паролей пользователей.
В записях каталога атрибуты carlicence, homepostaddress и homephone не должны быть доступны для чтения кому бы то ни было, за исключением сотрудников отдела Human Resources, а также владельца записи каталога.
Все пользователи должны проходить аутентификацию (анонимный доступ не разрешается).
Сотрудники отдела 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
Пояснения:
ACL1
ACL2
ACL3
В данном примере создаются общая и персональные адресные книги, как показано на рисунке:
Будет введена следующая политика:
Для доступа к каталогу все пользователи должны пройти аутентификацию.
Все пользователи, прошедшие аутентификацию, могут просматривать общую адресную книгу (в ветке customers).
Только сотрудники отдела продаж (члены группы salespeople) могут записывать в адресную книгу customers.
Члены группы itpeople могут создавать в каждой записи в ветке people дочернюю запись addressbook.
Владелец персональной адресной книги может читать и записывать в неё — никто больше не может даже просматривать addressbook (за исключением членов группы itpeople, которые могут создать addressbook, но не могут создавать записи внутри неё). Пользователю не разрешено удалять запись addressbook.
Сотрудники отдела IT должны иметь возможность обновлять или изменять пароли во всех записях каталога.
Сотрудники отдела 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
Пояснения:
ACL1
ACL2
ACL3 — children-часть ACL2
ACL4 — children-часть ACL5/ACL6/ACL6A
ACL5 — entry-часть ACL4
ACL6 — добавление любых атрибутов в addressbook
ACL6A — добавление любых атрибутов в addressbook
ACL7
ACL8
ACL9
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
Заставляет OpenLDAP записывать аргументы командной строки, с которыми он был запущен, в указанный файл. Пример:
# форма OLC (cn=config) olcArgsFile: /var/run/ldap.args # форма slapd.conf argsfile /var/run/ldap.args
В качестве альтернативы можно использовать такую команду:
ps ax |grep slapd
В выводе будут указаны аргументы командной строки. Если директива argsfile не указывалась, файл с аргументами создаваться не будет.
В качестве артефакта обработки схемы данных OpenLDAP предоставляет возможность определить один или несколько типов атрибутов с помощью attributetype в файле slapd.conf или olcAttributeTypes в системах OLC (cn=config). Определение типа атрибута подробно описано здесь. Не совсем понятно, что может подвигнуть Вас при использовании slapd.conf добавлять типы атрибутов таким способом — предпочтительнее создать файл пользовательского набора схемы и добавить его с помощью директивы include. Тем не менее, Вы можете сделать и так, если Вас это забавляет. В OLC (cn=config) атрибуты olcAttributeTypes и olcObjectClasses применяются для загрузки всех наборов схемы данных, используемых конфигурацией OLC (cn=config).
Формат:
# форма 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).
Формат:
# форма 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 неотработанных запросов, сессия будет завершена
Формат:
# форма 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 неотработанных запросов, сессия будет завершена
Начиная с 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
Формат:
# форма 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.
# форма 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 # сервер не допускает анонимные подключения
Формат:
# форма OLC (cn=config) olcGentleHUP: TRUE | FALSE # форма slapd.conf gentlehup on | off
Если атрибут olcGentleHUP (директива gentlehup) установлен в TRUE (или on), серверу OpenLDAP разрешено выполнение корректного завершения работы при получении сигнала SIGHUP, например так:
kill -HUP PID
В этом случае OpenLDAP выполнит следующие действия:
Эта команда становится более эффективной, если установлены атрибут 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
Формат:
# форма 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, что, возможно, будет нежелательным побочным эффектом.
Данная директива по своей природе является избыточной в конфигурациях OLC (cn=config) и поддерживается только в целях переконвертации slapd.conf. Наборы схемы данных могут быть добавлены в конфигурацию OLC (cn=config) с помощью описанного здесь процесса.
Директива include позволяет считывать содержимое любого файла и добавлять это содержимое в качестве директив конфигурации. OpenLDAP не выполняет проверки содержимого при добавлении, поэтому могут возникнуть проблемы со вложенными директивами include. Формат директивы:
include /path/to/include/file
Два наиболее распространённых применения данной директивы:
Примеры:
include /usr/local/etc/openldap/schema/core.schema # добавляет содержимое файла core.schema, поставляемого с дистрибутивом include /var/myschemas/myschema.schema # добавляет содержимое файла myschema.schema include /var/passwords/userpass # подключает файл с паролем пользователя, содержащим, к примеру, # директиву rootpw и имеющим права доступа 0600
Лучше определять директивы 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
Обзор других настроек производительности можно найти в соответствующей главе.
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
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:
number | hex-value | log-name | Описание уровня журналирования |
-1 | 0xFFFF | any | включить всю отладочную информацию |
0 | 0x0000 | - | журналирование отключено — в журнал ничего не выводится, в том числе критические ошибки. Не рекомендуется. |
1 | 0x1 | trace | отслеживание вызовов функций |
2 | 0x2 | packets | отладка обработки пакетов |
4 | 0x4 | args | усиленная отладка |
8 | 0x8 | conns | управление соединениями |
16 | 0x10 | BER | вывод посылки и приёма пакетов |
32 | 0x20 | filter | обработка поисковых фильтров |
64 | 0x40 | config | обработка конфигурационного файла |
128 | 0x80 | ACL | обработка списков контроля доступа |
256 | 0x100 | stats | статистика соединений/операций/результатов (значение по умолчанию) |
512 | 0x200 | stats2 | статистика посылки записей журнала |
1024 | 0x400 | shell | вывод взаимодействия с механизмами манипуляции данными shell |
2048 | 0x800 | parse | вывод отладочной информации разбора записей |
4096 | 0x1000 | cache | кеширование (не используется) |
8192 | 0x2000 | index | индексирование (не используется) |
16384 | 0x4000 | sync | вывод журнала syncrepl (репликации) |
32768 | 0x8000 | none | none — неверное наименование, на данном уровне выводятся сообщения, не попавшие в другие категории, включая, в том числе, высокоприоритетные сообщения |
Директива 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 выдаёт просто огромное количество отладочной информации. Понизьте это значение как можно скорее для вывода только тех сведений, которые Вас интересуют, либо покупайте новые диски, много новых дисков.
Сногсшибательный атрибут (директива), представляющий собой косвенный ущерб от плохо реализованных функций — в данном случае, наложений. То, что должно быть задействовано автоматически, исходя из настроек конфигурации, требует ручного определения, да ещё и основанного на ужасающем количестве опций сборки и скрипта 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.
Определяет одну или несколько директорий файловой системы, в которых будут находиться загружаемые модули (наложения). В одной директиве можно задать несколько путей, в этом случае они разделяются двоеточием (*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.
В качестве артефакта обработки схемы данных OpenLDAP предоставляет возможность определить один или несколько объектных классов (objectclass) в файле slapd.conf. Определение объектного класса описано здесь. Не совсем понятно, что может подвигнуть Вас добавлять объектные классы таким способом — предпочтительнее создать файл пользовательского набора схемы и добавить его с помощью директивы include. Тем не менее, Вы можете сделать и так, если Вас это забавляет.
В конфигурации OLC (cn=config) атрибут olcObjectClasses используется для загрузки наборов схемы данных, требуемых системой OLC (cn=config).
Позволяет определить один или несколько методов хэширования, используемых при хранении новых паролей, генерируемых с применением расширенной операции изменения пароля (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.
Заставляет 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 вручную.
Формат:
# форма 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. Дополнительная информация и примеры конфигурации отсылок здесь.
Начиная с версии 2.4 эта директива считается устаревшей и в OLC (cn=config) служит лишь в целях переконвертации slapd.conf. Определяется на главном (master) сервере, используется в репликации в стиле slurpd. Данная директива читается демоном slurpd и устанавливает интервал (в секундах), по истечении которого slurpd будет очередной раз проверять файл replogfile на предмет обновления подчинённых (slave) серверов.
replicationinterval seconds # пример: проверять replogfile каждые 60 секунд replicationinterval 60
Происхождение этой директивы покрыто мраком тайны, но, кажется, она появилась в OpenLDAP версии 2.2. Не совсем понятно, как впрочем, часто бывает в OpenLDAP, каково значение по умолчанию, то есть какой будет интервал репликации, если не указывать данную директиву.
# форма 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
Формат:
# форма 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 # при каждом клиентском доступе
Формат:
# форма OLC (cn=config) olcRootDSE: /path/to/ldif/file # форма slapd.conf rootDSE /path/to/ldif/file
В атрибуте olcRootDSE (директиве rootDSE) указывается LDIF-файл, содержащий определённые пользователем операционные атрибуты, которые будут добавлены к существующей записи rootDSE (доступна для просмотра в subschema subentry). Эти атрибуты являются аддитивными — в дополнение к стандартным (встроенным) атрибутам.
# форма 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 — отклоняться.
Формат:
# форма 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.
Формат:
# форма 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) определяет количество записей, которые будут возвращаться на каждый поисковый запрос. Существует две формы данной директивы, первая из них:
# форма 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 следующим образом:
Если директива 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 записей-кандидатов - запрос отклоняется
Формат:
# форма 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 байт, # при превышении соединение отклоняется
Формат:
# форма 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 байт, # при превышении соединение отклоняется
Формат:
# форма 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) определяет время в секундах, которое 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 следующим образом:
Если директива 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 секундам # если клиент установил какое-либо ограничение времени, оно будет принято
В 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-клиентом. Вот несколько примеров:
Система LDAP, которая занимается только предоставлением доступа внешним клиентам, не имеющая атрибутов olcSyncrepl (директив syncrepl) в какой-либо из записей (разделов) database и не имеющая записей (директив) overlay chain, является TLS-сервером.
Запись (раздел) database, содержащая дочернюю запись (директиву) overlay syncprov и являющаяся поставщиком репликации в конфигурации типа главный-подчинённый (master-slave), всегда является TLS-сервером (потребитель репликации всегда подключается к поставщику).
Запись (раздел) database, содержащая атрибут olcSyncrepl (директиву syncrepl) и являющаяся потребителем репликации в конфигурации типа главный-подчинённый (master-slave), всегда является TLS-клиентом (потребитель репликации всегда подключается к поставщику).
Запись (раздел) database, содержащая атрибут olcSyncrepl (директиву syncrepl) и дочернюю запись (директиву) overlay syncprov в конфигурации репликации с несколькими главными серверами (multi-master), является одновременно и TLS-клиентом (как потребитель репликации, настраиваемый атрибутом (атрибутами) olcSyncrepl (директивой (директивами) syncrepl)), и TLS-сервером (как поставщик репликации syncprov).
Сервер LDAP, содержащий запись/директиву overlay chain, может быть одновременно и TLS-клиентом (для соединения сцепления (chaining)), и TLS-сервером (для обычного пользовательского доступа).
Вы будете приятно удивлены, узнав, что LDAP-клиенты, такие как LDAP-браузер, почтовый клиент и т.п., всегда являются TLS-клиентами!
Несколько рабочих примеров конфигурации TLS/SSL представлены в главе 15. Все серверные директивы TLS указываются в записи cn=config или разделе глобальных настроек slapd.conf. Все клиентские директивы TLS указываются в ldap.conf.
# форма 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.
# форма 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 содержит только открытый ключ), поэтому для него не требуется установки специальных разрешений.
# форма 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/*
# форма 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-шифры.
# форма 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.
# форма 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.
# форма 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.
Формат:
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) объектный класс, по существу, представляет собой пустую заглушку.
Атрибуты (директивы) в разделе database состоят из общих атрибутов (директив), которые касаются почти всех типов данных и специфичных атрибутов (директив), которые относятся к определённому типу, например, bdb.
Формат:
# форма 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 |
ldbm | LDAP 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)
# форма 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
Запись (директива) 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. |
# форма 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
Устарела с выходом 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
Устарела с выходом 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. В этом случае просто генерируется журнал транзакций. Такой файл требует периодического обслуживания, поскольку имеет тенденцию быстро разрастаться.
Определяет 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"
Определяет пароль, который будет применяться к учётной записи 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"
Примечания:
Суффикс (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"
Доступна начиная с версий 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
Дополнительная информация и примеры конфигурации здесь.
Считается устаревшей, начиная с 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) применяется только в конфигурации подчинённого сервера (или сервера-потребителя) и используется как при репликации в стиле 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
Описание скоро будет.
Описание скоро будет.
Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.
Нашли ошибку в переводе? Сообщите переводчикам!
Copyright © 1994-2017 ZyTrax, Inc. Все права защищены. Последнее изменение страницы: 07 сентября 2017 г.
Переведено участниками проекта Pro-LDAP.ru в 2012-2017 г.
Закладки на сайте Проследить за страницей |
Created 1996-2024 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |