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

НАЗВАНИЕ

ОБЗОР

ОПИСАНИЕ

Рекомендуется обладать базовыми знаниями по функциональности механизма манипуляции данными slapd-ldap(5). Данный механизм манипуляции данными разрабатывался как усовершенствование механизма манипуляции данными ldap. Оба этих механизма имеют много общих функций (в действительности, они разделяют также части исходного кода). Если механизм ldap предназначен для выполнения прокси-операций в отношении одного сервера, то механизм meta в основном предназначен для проксирования нескольких серверов с возможностью подмены пространства имён. Эти функции, безусловно полезные во многих ситуациях, могут привести к чрезмерному расходу ресурсов для некоторых приложений, поэтому использование данного механизма должно быть тщательно продумано. Некоторые типичные сценарии использования будут обсуждаться в разделе примеров.

Экземпляр slapd(8), реализующий прокси-сервер, должен иметь сведения схемы данных для атрибутов и объектных классов, используемых в фильтрах, запрашиваемых DN и другой относящейся к запросам информации. Он должен также иметь сведения схемы данных для данных, возвращаемых удалённым сервером. Ответственность за поддержание схемы данных прокси-сервера в актуальном (относительно удалённых серверов) состоянии лежит на администраторе этого прокси-сервера.

Примечание: При подключении к тому же самому экземпляру slapd(8), каждое соединение требует создания нового потока; как следствие, slapd(8) должен быть скомпилирован с поддержкой потоков и может понадобиться произвести некоторые настройки в параметре threads. В этих случаях, если не требуется функционал обращения к нескольким целям, может быть предпочтительнее воспользоваться механизмом манипуляции данными slapd-relay(5), который выполняет транслируемые операции внутри и потому повторно использует то же самое соединение.

ПРИМЕРЫ

КОНФИГУРАЦИЯ

Примечание: В ранних версиях back-ldap и back-meta было рекомендовано всегда устанавливать

lastmod  off

для баз данных ldap и meta. Это было необходимо, потому что проксирование не должно выполняться для операционных атрибутов, относящихся к созданию и модификации записи, поскольку они могут быть ошибочно записаны на целевой сервер (серверы) и привести к ошибке. Текущая реализация автоматически устанавливает lastmod в off, поэтому использование этой директивы избыточно и указывать её не следует.

ДИРЕКТИВЫ КОНФИГУРАЦИИ, СПЕЦИАЛЬНЫЕ ДЛЯ МЕХАНИЗМА META

conn-ttl <time>

Задаёт время жизни (ttl), после которого закэшированное соединение будет прервано и создано заново независимо от того, простаивает это соединение или нет.

default-target none

Указывает механизму манипуляции данными отклонять все операции, которые должны быть обслужены одним сервером-целью, в случае, если цели не выбраны, либо выбрано несколько целей. К таким операциям относятся add, delete, modify, modrdn. Операции compare и bind не входят в этот список, поскольку они не изменяют записей, и, в случае нахождения нескольких совпадений, будет предпринята попытка выполнить операцию в любой цели-кандидате, но успешно может быть завершено не более одной такой операции. Также эта директива может быть использована при обработке целей, чтобы пометить конкретную цель как используемую по умолчанию.

dncache-ttl {DISABLED|forever|<ttl>}

Задаёт время жизни кэша DN. В этот кэш помещается цель, в которой содержится заданный DN, для ускорения выбора цели в случае возвращения нескольких целей в результате некэшированного поискового запроса. Вариант forever означает, что кэш не устаревает никогда; вариант disabled означает, что кэш DN не ведётся; в третьем варианте требуется указать правильный (больший нуля) ttl в формате, данном в описании директивы idle-timeout.

onerr {CONTINUE|report|stop}

Позволяет выбрать поведение в случае возвращения одной из целей ошибки во время поиска. Вариант по умолчанию, continue, состоит в продолжении выполнения операции и попытке вернуть как можно больше данных. Если в качестве значения директивы указано stop, поиск прекращается сразу же, как только одна из целей вернула ошибку, и эта ошибка немедленно передаётся клиенту. Если в качестве значения директивы указано report, поиск продолжается до конца, но, в случае, если хотя бы одна цель вернула ошибочный код, возвращается первый неуспешный код ошибки.

norefs <NO|yes>

Если этот параметр установлен в yes, в ответ на поисковые запросы не будут возвращаться поисковые ссылки-продолжения. По умолчанию ответы с такими ссылками возвращаются (если только версия протокола запроса не была LDAPv2). При указании перед спецификациями целей, действие директивы распространяется на все цели, если оно не переопределяется этой же директивой в настройках конкретной цели.

noundeffilter <NO|yes>

Если этот параметр установлен в yes, то в случаях, когда поисковый фильтр неопределён или содержит неопределённые элементы, вместо выполнения поиска будет сразу возвращён успешный результат. По умолчанию поисковый запрос, после замены неопределённых элементов фильтра на (!(objectClass=*)), передаётся удалённому серверу; поиковый фильтр с такими элементами соответствует пустому результирующему набору. При указании перед спецификациями целей, действие директивы распространяется на все цели, если оно не переопределяется этой же директивой в настройках конкретной цели.

protocol-version {0,2,3}

Эта директива указывает, какая версия протокола должна использоваться при работе с удалённым сервером. Если задано значение 0 (по умолчанию), прокси использует ту же версию протокола, что и клиент, иначе используется указанная явно версия протокола. Прокси возвращает ошибку unwillingToPerform при попытке выполнения операции, несовместимой с запрашиваемой версией протокола. При указании перед спецификациями целей, действие директивы распространяется на все цели, если оно не переопределяется этой же директивой в настройках конкретной цели.

pseudoroot-bind-defer {YES|no}

Если эта директива установлена в yes, то аутентификация на удалённом сервере от имени идентификационной сущности псевдо-администратора (pseudo-root, идентификационная сущность, определяемая в директиве idassert-bind) будет отложена до тех пор, пока фактически не понадобится для выполнения последующих операций. В противном случае все подсоединения от имени rootdn будут сразу передаваться на цели.

quarantine <interval>,<num>[;<interval>,<num>[...]]

Включает режим карантина для тех URI, при обращении к которым был возвращён код LDAP_UNAVAILABLE, так что попытки повторного соединения будут выполняться только через заданные временные интервалы, а не каждый раз, когда клиент запрашивает выполнение операции. Шаблон для определения алгоритма выполнения повторных попыток следующий: выполнять повторную попытку после того, как пройдёт как минимум interval секунд после прошлой попытки, ровно num раз; затем использовать следующий шаблон. Если в последнем шаблоне в качестве num указано "+", повторные попытки будут выполняться неограниченное количество раз; в противном случае, после отработки последнего шаблона попыток подключения больше выполняться не будет. Эта директива должна указываться перед спецификациями целей; один и тот же шаблон распространяется на все цели.

rebind-as-user {NO|yes}

Если этот параметр задан, учётные данные подсоединения клиента запоминаются для последующих подключений при попытке повторной установки разорванного соединения, либо при разрешении отсылок, если параметр chase-referrals установлен в yes.

session-tracking-request {NO|yes}

Этот параметр указывает, следует ли добавлять во все запросы элемент управления отслеживания сессии (session tracking). Ассоциированные с каждым запросом IP-адрес и имя хоста клиента, а также его идентификационная сущность (если они известны), передаются удалённому серверу в информационных целях. Этот параметр нельзя использовать, если параметр protocol-version установлен в 2. При указании перед спецификациями целей, действие директивы распространяется на все цели, если оно не переопределяется этой же директивой в настройках конкретной цели.

single-conn {NO|yes}

Указывает, следует ли сбрасывать текущее закэшированное соединение при выполнении клиентом повторного подсоединения.

use-temporary-conn {NO|yes}

Если этот параметр установлен в yes, то, когда при попытке обращения к удалённому серверу общее соединение занято другими процессами, создаётся временное соединение; в противном случае, процесс ждёт, когда общее соединение станет доступным.

СПЕЦИФИКАЦИЯ ЦЕЛИ

uri <protocol>://[<host>]/<naming context> [...]

В качестве части <protocol> может указываться всё, что принимает вызов ldap_initialize(3) ({ldap|ldaps|ldapi} и разновидности); часть <host> может быть опущена, значение по умолчанию берётся из настроек ldap.conf(5). Часть <naming context> является обязательной для первого URI, но должна быть опущена в последующих URI, если они присутствуют. Часть <naming context> URI должна "входить" в контекст именования базы данных механизма meta, например:

suffix "dc=foo,dc=com"
uri    "ldap://x.foo.com/dc=x,dc=foo,dc=com"

Не требуется, чтобы часть <naming context> была уникальна среди всех целей; она может также совпадать с одним из значений директивы "suffix". В одной директиве uri могут быть определены несколько URI. Дополнительные URI должны представлять собой отдельные аргументы и не должны иметь части <naming context>. При указании нескольких URI библиотека будет взаимодействовать с первым доступным сервером из списка. Например, если l1.foo.com и l2.foo.com - это реплики одного и того же сервера, то при настройках

suffix "dc=foo,dc=com"
uri    "ldap://l1.foo.com/dc=foo,dc=com" "ldap://l2.foo.com/"

обращение к серверу l2.foo.com будет происходить, если сервер l1.foo.com не отвечает. В таких случаях список URI внутренне переупорядочивается так, что недоступные URI перемещаются в конец, и при последующих соединениях предпочтение будет отдаваться последнему успешно ответившему URI.

acl-authcDN <административное DN, используемое для проверки контроля доступа>

Задаёт DN, используемое при подсоединении к целевому серверу с целью проверки ACL, как в механизме LDAP. Предполагается, что идентификационная сущность, определяемая записью, указанной в этой директиве, будет иметь на целевом сервере доступ на чтение к атрибутам, используемым на прокси-сервере для проверки ACL. Задавая подобные настройки, вы ничем не рискуете; они используются только для проверки прав доступа. Идентификационная сущность acl-authcDN ни при каких обстоятельствах не используется прокси неявно при выполнении клиентом анонимного подключения.

acl-passwd <password>

Задаёт пароль для записи, указанной в директиве acl-authcDN.

bind-timeout <microseconds>

Определяет таймаут (в микросекундах), используемый при ожидании ответа на запрос асинхронного подсоединения bind. Первоначальный вызов ldap_result(3) выполняется с компромиссным таймаутом в 100000 миллисекунд; если этот таймаут будет превышен, последующие вызовы используют значение, указанное в директиве bind-timeout. Если директива bind-timeout не определялась, последующие вызовы также используют значение по умолчанию. При указании перед спецификациями целей, действие директивы распространяется на все цели, если оно не переопределяется этой же директивой в настройках конкретной цели.

chase-referrals {YES|no}

Включает/отключает автоматический переход по отсылкам, осуществление которого делегируется библиотеке libldap. При этом, если используется директива rebind-as-user, выполняется повторное подсоединение. По умолчанию переход по отсылкам осуществляется. При указании перед спецификациями целей, действие директивы распространяется на все цели, если оно не переопределяется этой же директивой в настройках конкретной цели.

client-pr {accept-unsolicited|DISABLE|<size>}

Эта директива позволяет использовать элемент управления Paged Results (RFC 2696) при выполнении операций поиска в конкретной цели, вне зависимости от запроса клиента. При указании числового значения, в элементе управления Paged Results в качестве размера страницы всегда используется size. При указании accept-unsolicited ответы с установленным элементом управления Paged Results будут приниматься и обрабатываться даже когда этот элемент управления не запрашивался (в целях совместимости с плохо реализованными удалёнными DSA). Клиент не ставится в известность о том, что между slapd-meta(5) и удалёнными серверами выполняются запросы с обработкой постраничных результатов. По умолчанию (disable), элемент управления Paged Results не используется, и ответы, в которых он установлен, не принимаются. При указании перед спецификациями целей, действие директивы распространяется на все цели, если оно не переопределяется этой же директивой в настройках конкретной цели.

default-target [<target>]

Директива default-target также может использоваться при настройке цели. Если аргументы не указаны, то текущая цель помечается как цель по умолчанию. При указании опционального числового аргумента, цель <target> помечается как цель по умолчанию. Нумерация целей начинается с 1. Цель, указанная в аргументе <target>, должна быть определена.

filter <pattern>

Данная директива позволяет задать шаблон регулярного выражения regex(5) для указания того, какие конкретно поисковые фильтры будут обслуживаться сервером-целью.

Если фильтр в поисковом запросе соответствует шаблону pattern, данная цель принимается во внимание при выполнении этого запроса; в противном случае, данная цель игнорируется. Для каждой цели может быть указано несколько директив filter.

idassert-authzFrom <authz-regexp>

Эта директива, если указана, определяет, каким локальным идентификационным сущностям разрешено использовать возможность утверждения идентификационной сущности. Строка <authz-regexp> подчиняется правилам, определённым для атрибута authzFrom. Подробное описание синтаксиса этого поля можно найти в разделе man-страницы slapd.conf(5), посвящённом директиве authz-policy.

idassert-bind bindmethod=none|simple|sasl [binddn=<simple DN>] [credentials=<simple password>] [saslmech=<SASL mech>] [secprops=<properties>] [realm=<realm>] [authcId=<authentication ID>] [authzId=<authorization ID>] [authz={native|proxyauthz}] [mode=<mode>] [flags=<flags>] [starttls=no|yes|critical] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_protocol_min=<major>[.<minor>]] [tls_crlcheck=none|peer|all]

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

auth (на выполнение аутентификации) к атрибутам, используемым на прокси-сервере для аутентификации и авторизации. Кроме того, предполагается, что этой идентификационной сущности разрешено производить авторизацию пользователей. Для этого требуется иметь привилегии proxyAuthz к широкому диапазону DN, например, authzTo=dn.subtree:, а также чтобы на удалённом сервере директива authz-policy была установлена в to или both. Подробное описание этих настроек, а также замечания по их использованию и недостаткам можно найти в man-странице slapd.conf(5). Поддерживаемые методы bindmethod:

none|simple|sasl

По умолчанию используется значение none, то есть никакого утверждения идентификационной сущности не выполняется.

Параметр authz используется для указания того, что при подсоединении SASL должна применяться простая (native) авторизация SASL, если таковая доступна; поскольку соединения кэшируются, эту возможность следует использовать, только когда авторизация выполняется с фиксированной идентификационной сущностью (например, посредством параметров authzDN или authzID). В противном случае используется значение по умолчанию - proxyauthz, то есть ко всем операциям добавляется элемент управления proxyAuthz (Proxied Authorization, RFC 4370).

Поддерживаемые режимы (аргумент mode):

<mode> := {legacy|anonymous|none|self}

Если значение <mode> не указано, но задан параметр authzId, прокси всегда будет выполнять авторизацию от имени этой идентификационной сущности. Значение <authorization ID> может быть задано в форматах

u:<user>

[dn:]<DN>

Предполагается, что значение идентификационной сущности в первом формате будет расширено удалённым сервером в соответствии с правилами authz; подробнее смотрите в man-странице slapd.conf(5). Если применяется второй формат, независимо от того, присутствует префикс dn: или нет, указываемая строка должна удовлетворять требованиям валидации и нормализации DN.

Режим по умолчанию - legacy, при котором подразумевается, что прокси-сервер будет либо выполнять простое подсоединение от имени authcDN, либо SASL-подсоединение от имени authcID, а затем производить утверждение идентификационной сущности клиента, если тот не пытается подсоединиться анонимно. Прямые подсоединения всегда проксируются. При других режимах подразумевается, что прокси-сервер всегда будет либо выполнять простое подсоединение от имени authcDN, либо SASL-подсоединение от имени authcID, если это не ограничивается правилами idassert-authzFrom (смотрите выше), в таком случае операция будет завершена неудачей; после подсоединения прокси будет выполнять утверждение некоторой другой идентификационной сущности в зависимости от режима <mode>. В режиме anonymous будет выполняться утверждение пустой идентификационной сущности. В режиме self будет выполняться утверждение идентификационной сущности клиента. В режиме none элемент управления proxyAuthz использоваться не будет, таким образом будет выполняться утверждение идентификационной сущности authcDN или authcID. Для всех режимов, требующих использования элемента управления proxyAuthz, идентификационная сущность прокси-сервера должна иметь на удалённом сервере соответствующие права authzTo, либо у утверждаемых идентификационных сущностей должны быть соответствующие права authzFrom. Следует, однако, отметить, что функция утверждения идентификационных сущностей полезна, главным образом, когда утверждаемые идентификационные сущности не существуют на удалённом сервере.

В качестве флагов (аргумент flags) могут быть заданы

override,[non-]prescriptive,proxy-authz-[non-]critical

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

При использовании флага prescriptive (по умолчанию), операции будут завершаться неудачей с кодом inappropriateAuthentication для тех идентификационных сущностей, утверждение которых не разрешено шаблонами из директивы idassert-authzFrom. При использовании флага non-prescriptive, для тех идентификационных сущностей, утверждение которых не разрешено шаблонами из директивы idassert-authzFrom, операции выполняются анонимно.

При использовании флага proxy-authz-non-critical (по умолчанию), элемент управления proxyAuthz не помечается как критичный (в нарушение требований RFC 4370). Рекомендуется использование флага proxy-authz-critical.

Значения по умолчанию настроек TLS соответствуют значениям основных настроек TLS slapd, за исключением параметра tls_reqcert, значением по умолчанию которого является "demand".

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

idle-timeout <time>

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

[<d>d][<h>h][<m>m][<s>[s]]

где <d>, <h>, <m> и <s> интерпретируются, соответственно, как дни, часы, минуты и секунды. При указании перед спецификациями целей, действие директивы распространяется на все цели, если оно не переопределяется этой же директивой в настройках конкретной цели.

keepalive <idle>:<probes>:<interval>

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

map {attribute|objectclass} [<local name>|*] {<foreign name>|*}

Отображает объектные классы и атрибуты как в механизме манипуляции данными LDAP. Смотрите slapd-ldap(5).

network-timeout <time>

Устанавливает значение таймаута, после которого, в случае отсутствия сетевой активности, будет возвращаться poll(2)/select(2), а затем connect(2). Значение указывается в секундах, и его можно задать таким же, как и для директивы idle-timeout. При указании перед спецификациями целей, действие директивы распространяется на все цели, если оно не переопределяется этой же директивой в настройках конкретной цели.

nretries {forever|never|<nretries>}

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

rewrite* ...

Параметры перезаписи описываются в разделе "ПЕРЕЗАПИСЬ".

subtree-{exclude|include} <rule>

Эта директива позволяет указать, какие конкретно поддеревья будут обслуживаться сервером-целью. Синтаксис поддерживаемых правил:

<rule>: [dn[.<style>]:]<pattern>

<style>: subtree|children|regex

Если в качестве <style> указано subtree или children, шаблон <pattern> представляет собой DN, который должен быть в пределах контекста именования, обслуживаемого целью. Если в качестве <style> указано regex, <pattern> представляет собой шаблон регулярного выражения regex(5). Если префикс dn.<style>: опущен, для соблюдения обратной совместимости неявно подразумевается dn.subtree:.

В форме subtree-exclude, если запрашиваемое DN соответствует хотя бы одному правилу, данная цель не принимается во внимание при выполнении этого запроса; в противном случае, данная цель рассматривается, основываясь на значении запрашиваемого DN. Когда выполняемый запрос является поисковым, также принимается во внимание диапазон поиска scope.

В форме subtree-include, если запрашиваемое DN соответствует хотя бы одному правилу, данная цель принимается во внимание при выполнении этого запроса; в противном случае, данная цель игнорируется.

    | совпадение |  форма    |
    | с шаблоном |  exclude  |
    +------------+-----------+----------------------+
    |     Да     |    Да     | не кандидат          |
    |     Нет    |    Да     | продолжение проверки |
    +------------+-----------+----------------------+
    |     Да     |    Нет    | кандидат             |
    |     Нет    |    Нет    | не кандидат          |
    +------------+-----------+----------------------+

Для каждой цели может быть указано несколько директив subtree-exclude или subtree-include, но по отношению друг к другу они являются взаимоисключающими.

suffixmassage <virtual naming context> <real naming context>

Все директивы, начинающиеся с "rewrite", относятся к механизму перезаписи slapd. Директива suffixmassage была представлена в механизме LDAP. С её помощью выполнялось преобразование суффикса во время проксирования. С введением инструментов перезаписи директива считается устаревшей. Однако, она была сохранена как в целях сохранения обратной совместимости, так и для упрощения конфигурирования в случаях, когда требуется выполнение простого преобразования суффикса. Эту директиву можно рассматривать как сокращённую запись базовых инструкций перезаписи, выполняющих преобразование суффикса. Список правил перезаписи, подразумеваемых в этой директиве, можно найти в разделе "ПЕРЕЗАПИСЬ".

t-f-support {NO|yes|discover}

включает применение абсолютных фильтров (смотрите RFC 4526), если их поддерживает удалённый сервер. Если задано значение discover, поддержка абсолютных фильтров удалённым сервером будет определяться путём опроса root DSE этого сервера. При указании перед спецификациями целей, действие директивы распространяется на все цели, если оно не переопределяется этой же директивой в настройках конкретной цели.

timeout [<op>=]<val> [...]

Этот параметр позволяет задавать таймауты для каждого типа операций. Операциями могут быть

<op> ::= bind, add, delete, modrdn, modify, compare, search

Общая продолжительность операции search контролируется либо параметром timelimit поискового запроса, либо ограничениями по времени, заданными на стороне сервера (смотрите директивы timelimit и limits в man-странице slapd.conf(5)). Данный параметр timeout контролирует, насколько долго целевой сервер может не отвечать на запрос, прежде чем операция будет прервана. Для операций, не указанных в списке (unbind и abandon), назначать таймауты бессмысленно, поскольку они не подразумевают возвращения какого-либо ответа. Также поддержка таймаутов не реализована для определённых на данный момент расширенных (extended) операций. Если никакой операции op не указано, значение таймаута val применяется ко всем поддерживаемым операциям. При указании перед спецификациями целей, действие директивы распространяется на все цели, если оно не переопределяется этой же директивой в настройках конкретной цели.

Примечание: если превышено ограничение timelimit, выполняется отмена операции (в соответствии с директивой cancel); протокол не предоставляет какого-либо способа отката операций, так что клиент не будет оповещён о результате выполнения операции, была ли она в итоге удачной или нет. В случае превышения таймаута во время выполнения операции bind, соединение разрывается в соответствии с RFC4511.

tls {[try-]start|[try-]propagate}

Указывает, что при инициализации соединения необходимо выполнить расширенную операцию StartTLS; работает, только если в директиве URI не указана схема протокола ldaps://. При значении propagate операция StartTLS будет вызываться, только если она вызывается в оригинальном соединении. Префикс try- позволяет прокси продолжать выполнение операций, если операция StartTLS завершилась неудачей; его использование крайне не рекомендуется. При указании перед спецификациями целей, действие директивы распространяется на все цели, если оно не переопределяется этой же директивой в настройках конкретной цели.

СЦЕНАРИИ РАЗВЁРТЫВАНИЯ

Для начала рассмотрим пару сценариев.

1) Два сервера каталогов содержат два непересекающихся уровня одного контекста именования, скажем "dc=a,dc=foo,dc=com" и "dc=b,dc=foo,dc=com". Тогда не имеющая внутренних противоречий база данных META может быть настроена так:

database meta
suffix   "dc=foo,dc=com"
uri      "ldap://a.foo.com/dc=a,dc=foo,dc=com"
uri      "ldap://b.foo.com/dc=b,dc=foo,dc=com"

Из-за отсутствия неоднозначности легко определить, к какой цели будет направлена та или иная операция. Единственная операция, которая приведёт к обращению к нескольким целям, это операция поиска search с базой "dc=foo,dc=com" и диапазоном, как минимум, "one", в результате которой будет порождено два поисковых запроса, по одному для каждой из целей.

2a) Два сервера каталогов не содержат какой-либо части определённого контекста именования, но их следует представить как единое DIT [Предостережение: подразумевается уникальность (преобразованных) записей в каталогах этих двух серверов; проверка целостности могла бы повлечь за собой чрезмерное расходование ресурсов и не была реализована]. Предположим, у нас есть два каталога "dc=bar,dc=org" и "o=Foo,c=US", и мы бы хотели, чтобы они выступали как ветки дерева "dc=foo,dc=com", скажем, "dc=a,dc=foo,dc=com" и "dc=b,dc=foo,dc=com". Тогда нам нужно настроить базу данных META так:

database      meta
suffix        "dc=foo,dc=com"

uri           "ldap://a.bar.com/dc=a,dc=foo,dc=com"
suffixmassage "dc=a,dc=foo,dc=com" "dc=bar,dc=org"

uri           "ldap://b.foo.com/dc=b,dc=foo,dc=com"
suffixmassage "dc=b,dc=foo,dc=com" "o=Foo,c=US"

И вновь, направление операций к одной или другой цели можно определить без неоднозначности, хотя требуется произвести некоторые преобразования. Обратите внимание, что виртуальные контексты именования каждой цели являются ветками контекста именования базы данных; они перезаписываются туда и обратно при выполнении операций в отношении целевых серверов. Что означает "туда и обратно" будет разъяснено позже.

Если выполняется поиск с базой "dc=foo,dc=com", то в случае указания диапазона "base" такой поиск завершится неудачей с ошибкой "no such object"; фактически, общего корня двух целей (до преобразования) не существует. Если указан диапазон "one", опрошены будут обе цели, при этом база поиска будет заменена на базовую запись соответствующей цели, а диапазон понижен до "base". В общем случае, поиск с диапазоном "one" будет выполнен и диапазон снижен, только если входная база поиска как минимум на один уровень ниже контекста именования цели (до преобразования).

Наконец, если указан диапазон "sub", входная база будет заменена на непреобразованные контексты именования каждой из целей, а диапазон оставлен без изменения.

2b) Теперь рассмотрим предыдущий сценарий, но при условии, что два сервера разделяют один и тот же контекст именования:

database      meta
suffix        "dc=foo,dc=com"

uri           "ldap://a.bar.com/dc=foo,dc=com"
suffixmassage "dc=foo,dc=com" "dc=bar,dc=org"

uri           "ldap://b.foo.com/dc=foo,dc=com"
suffixmassage "dc=foo,dc=com" "o=Foo,c=US"

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

ACL

а) разрешения диктуются удалённым сервером; прокси просто передает клиенту то, что он получает от удаленного сервера.

б) удалённый сервер возвращает "всё подряд"; за защиту данных от несанкционированного доступа отвечает прокси.

Конечно, последний вариант выглядит менее разумно, но это не всегда так. Можно представить себе сценарий, когда удалённый хост не ограничивает доступ к данным, которые считаются "открытыми" во внутренней сети, а прокси-сервер, через который предоставляется доступ к этому хосту из внешней сети, может накладывать дополнительные ограничения. Для этих целей прокси необходимо иметь возможность настройки всех поддерживаемых сервером критериев поиска совпадений ACL. В настоящий момент механизмы прокси реализуют все возможные критерии, поддерживаемые slapd, за исключением одного приведённого ниже специфического случая (пожалуйста, оставьте запрос в ITS <http://www.openldap.org/its/>, если вы найдёте другие исключения): по правилу

access to dn="<dn>" attrs=<attr>
       by dnattr=<dnattr> read
       by * none

невозможно найти совпадение, если запрашиваемый атрибут <attr> не является <dnattr>, а атрибут определения членства <dnattr> не был запрошен (например, в поисковом запросе).

В действительности, slapd разрешает данный ACL, используя часть полученной с удалённого сервера записи, без какого-либо последующего привлечения механизма манипуляции данными. Таким образом, если атрибут <dnattr> не был получен, совпадение оценить невозможно, и не потому, что нет значений атрибута, совпадающих с условием, а потому, что необходимый атрибут не присутствует.

Примечание по ACL и отображению атрибутов: ACL применяются к отображённым атрибутам. Например, если атрибут, известный на прокси как "foo", отображается на удалённом сервере в "bar", то локальные ACL применяются к атрибуту "foo", и им ничего неизвестно об удалённом имени этого атрибута. Удалённый сервер будет проверять разрешения для "bar", а локальный сервер, возможно, будет накладывать дополнительные ограничения на "foo".  

ПЕРЕЗАПИСЬ

Лежащая в основе идея заключалась в создании для сервера slapd легковесного модуля перезаписи (изначально предназначавшегося для механизма манипуляции данными LDAP).  

Процесс работы

Флаги управления поиском совпадений с шаблоном

`C'

соблюдать регистр символов при сравнении строки с шаблоном (по умолчанию регистр символов игнорируется).

`R'

использовать ''основные'' регулярные выражения POSIX (по умолчанию используются ''расширенные'').

`M{n}'

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

Флаги действий

`:'

применить правило только один раз (по умолчанию применяется рекурсивно).

`@'

прекратить применять правила в случае совпадения; текущее правило всё ещё будет применяться рекурсивно; для того чтобы применить текущее правило только один раз, а затем прекратить, используйте этот флаг в комбинации с флагом `:'.

`#'

прекратить текущую операцию, если было найдено совпадение с правилом, и выдать ошибку `unwilling to perform'.

`G{n}'

перейти на n правил назад и продолжить (опасайтесь зацикливания!). Имейте ввиду, что `G{1}' подразумевается в каждом правиле.

`I'

игнорировать ошибки в правиле; это означает, что в случае возникновения ошибки, например, возникшей в ходе применения карты, эта ошибка интерпретируется как отсутствие совпадения. Ошибка `unwilling to perform' не переопределяется.

`U{n}'

использовать n в качестве кода возврата, если было найдено совпадение с правилом; этот флаг не отменяет рекурсивного выполнения правила, поэтому, если требуется, чтобы правило выполнялось только один раз, этот флаг должен использоваться в комбинации с флагом `:', например, `:U{16}' возвратит значение `16' после ровно одного выполнения правила, если было найдено совпадение с шаблоном. Следовательно, поведение этого флага эквивалентно флагу `@', но при этом возвращается код n; другими словами, `@' эквивалентен `U{0}'. По соглашению, включены свободно доступные коды возврата, большие 16-ти; остальные коды возврата зарезервированы.

Порядок указания флагов может иметь значение. Например, `IG{2}' означает игнорировать ошибки и переходить на две строки вперёд как в случае нахождения совпадения, так и в случае ошибки, тогда как `G{2}I' означает игнорировать ошибки, но осуществлять переход на две строки вперёд только в случае нахождения совпадения.

При необходимости будут добавлены дополнительные флаги (главным образом, флаги действий).  

Шаблоны поиска совпадений

Синтаксис шаблонов подстановки

единственное очевидное исключение - это `%%', которое оставляется как есть;

основная конструкция подстановки - `%d', где `d' это цифра; 0 означает строку целиком, а 1-9 - это подсовпадения;

если за `%' следует `{', это означает выполнение расширенной подстановки. Шаблон такой подстановки:

`%' `{' [ <op> ] <name> `(' <substitution> `)' `}'

где <name> должно быть именем карты в правильном формате, то есть

<name> ::= [a-z][a-z0-9]* (регистр символов не имеет значения)
<op> ::= `>' `|' `&' `&&' `*' `**' `$'

а <substitution> должно быть шаблоном подстановки в правильном формате, без ограничений на уровень вложенности.

Операторы:

>

вызов подконтекста; <name> должно быть правильным, заранее определённым именем контекста перезаписи

|

вызов внешней команды; <name> должно указывать на правильное, заранее определённое имя команды (ЕЩЁ НЕ РЕАЛИЗОВАНО)

&

присвоение значения переменной; <name> определяет переменную в структуре выполняемой операции, которая может быть разыменована позже; оператор & присваивает значение переменной в рамках текущего контекста перезаписи; оператор && присваивает значение переменной в рамках всей сессии, то есть её значение может быть использовано позднее другими контекстами перезаписи

*

разыменование переменной; <name> должно указывать на переменную, которая определена и ей присвоено значение для выполняемой операции; оператор * разыменовывает переменную в рамках текущего контекста перезаписи; оператор ** разыменовывает переменную в рамках всей сессии, то есть значение этой переменной доступно всем контекстам перезаписи

$

разыменование параметра; <name> должно указывать на существующий параметр; идея заключается в том, чтобы сделать доступными механизму перезаписи некоторые задаваемые системой параметры времени исполнения, такие как имя хоста клиента, DN подсоединения (если оно есть), параметры-константы, инициализируемые во время конфигурации, и так далее; в настоящий момент механизмами back-ldap и back-meta не задаются никакие параметры, но в конфигурационном файле с помощью директивы rewriteParam можно определить параметры-константы.

Экранирование в строковых шаблонах подстановки осуществляется с помощью символа `%', который используется вместо символа `\', поскольку `\' уже экранируется низкоуровневыми процедурами разбора slapd; как следствие, при экранировании регулярных выражений требуется использовать два символа `\', например, выражение `.*\.foo\.bar' должно записываться как `.*\\.foo\\.bar'.  

Контексты перезаписи

Все основные операции сервера ассоциированы с контекстами перезаписи; они подразделяются на две основные группы: перезапись строк в сообщениях клиент -> сервер и в сообщениях сервер -> клиент.

клиент -> сервер:

(default)            если определено правило и не указано
                     никакого конкретного контекста
bindDN               bind
searchBase           search
searchFilter         search
searchFilterAttrDN   search
compareDN            compare
compareAttrDN        compare AVA
addDN                add
addAttrDN            add AVA
modifyDN             modify
modifyAttrDN         modify AVA
modrDN               modrdn
newSuperiorDN        modrdn
deleteDN             delete
exopPasswdDN         DN расширенной операции password modify (если проксируется)

сервер -> клиент:

searchResult         search (только если определён; нет значения по
                     умолчанию; выполняется над DN и атрибутами синтаксиса DN
                     результатов поиска)
searchAttrDN         search AVA
matchedDN            все операции (только если применение возможно)

Основные директивы конфигурации

rewriteEngine { on | off }

Если эта директива задана в `on', настроенные процедуры перезаписи будут выполняться; если директива задана в `off', перезапись выполняться не будет (простой способ остановить перезапись без необходимости внесения слишком больших изменений в конфигурационный файл).

rewriteContext <context name> [ alias <aliased context name> ]

<context name> - это имя, идентифицирующее контекст, то есть имя, которое будет использоваться приложением для того, чтобы обратиться к набору правил, содержащемуся в этом контексте. Кроме того, это имя используется при перезаписи строк для ссылки на подконтексты. Один контекст может быть псевдонимом другого. В этом случае контекст-псевдоним не содержит правил, и в результате любого обращения к нему происходит доступ к тому контексту, псевдонимом которого он является.

rewriteRule <regex match pattern> <substitution pattern> [ <flags> ]

Определяет, как будет перезаписана строка, если было найдено совпадение с шаблоном. Примеры приведены ниже.

Дополнительные директивы конфигурации

rewriteMap <map type> <map name> [ <map attrs> ]

Позволяет определить карту, которая трансформирует перезапись подстроки во что-то иное. Ссылка на карту происходит внутри шаблона подстановки правила.

rewriteParam <param name> <param value>

Задаёт значение с глобальной областью видимости, на которое можно сослаться командой `%{$paramName}'.

rewriteMaxPasses <number of passes> [<number of passes per rule>]

Задаётся максимальное общее количество проходов перезаписи, которое может быть выполнено в рамках одной операции перезаписи (во избежание зацикливания). Безопасное значение по умолчанию - 100; имейте ввиду, что достижение этого предела всё ещё интерпретируется как успешное выполнение операции; рекурсивный вызов правил просто прерывается. Это ограничение применяется к операции перезаписи в целом, а не только к одному правилу. Дополнительно может быть установлено ограничение на выполнение одного правила. Данное общее ограничение переопределяется путём задания специфичных ограничений для конкретных правил с помощью флага `M{n}.

Примеры конфигурации

# Для отключения перезаписи задайте значение `off'
rewriteEngine on

# Правила, реализуемые директивой "suffixmassage"
rewriteEngine on
# весь поток данных от клиента к серверу, в части, касающейся DN
rewriteContext default
rewriteRule "(.*)<virtualnamingcontext>$" "%1<realnamingcontext>" ":"
# пустое правило для фильтров
rewriteContext searchFilter
# весь поток данных от сервера к клиенту
rewriteContext searchResult
rewriteRule "(.*)<realnamingcontext>$" "%1<virtualnamingcontext>" ":"
rewriteContext searchAttrDN alias searchResult
rewriteContext matchedDN alias searchResult

# Всё, определённое здесь, относится к контексту `default'.
# Данное правило меняет контекст именования всего, что отправляется для
# `dc=home,dc=net' на `dc=OpenLDAP, dc=org'

rewriteRule "(.*)dc=home,[ ]?dc=net"
            "%1dc=OpenLDAP, dc=org"  ":"

# поскольку общепринятые/нормализованные DN не включают пробелов
# после разделителей rdn, например, `,', достаточно такого правила:

rewriteRule "(.*)dc=home,dc=net"
            "%1dc=OpenLDAP,dc=org"  ":"

# Начинается новый контекст (заканчивается ввод предыдущего).
# Это правило добавляет пробелы между частями DN, если их нет.
rewriteContext  addBlanks
rewriteRule     "(.*),([^ ].*)" "%1, %2"

# А это убирает пробелы
rewriteContext  eatBlanks
rewriteRule     "(.*),[ ](.*)" "%1,%2"

# Здесь управление переходит обратно к контексту перезаписи по
# умолчанию; правила добавляются в конец списка уже существующих.
# Всё, что попадает сюда, перенаправляется в правило `addBlanks'
rewriteContext  default
rewriteRule     ".*" "%{>addBlanks(%0)}" ":"

# Перезапись базы поискового запроса в соответствии с правилами
# `default'.
rewriteContext  searchBase alias default

# Результаты поиска с DN OpenLDAP перезаписываются обратно в
# контекст именования `dc=home,dc=net' с поглощением пробелов.
rewriteContext  searchResult
rewriteRule     "(.*[^ ]?)[ ]?dc=OpenLDAP,[ ]?dc=org"
                "%{>eatBlanks(%1)}dc=home,dc=net"    ":"

# Подсоединение с предоставлением адреса электронной почты
# вместо полного DN: для начала нам необходима ldap-карта,
# переводящая атрибуты в DN (аргумент, используемый при вызове
# карты добавляется к URI и выступает в качестве фильтра)
rewriteMap ldap attr2dn "ldap://host/dc=my,dc=org?dn?sub"

# Затем нам нужно выявить DN, представляющий собой только адрес
# электронной почты, например, `mail=someone@example.com';
# обратите внимание, что согласно этому правилу в случае нахождения
# совпадения перезапись останавливается; в случае возникновения
# ошибки, она будет проигнорирована. Если мы, кроме того,
# отображаем виртуальный контекст именования в реальный, нам также
# необходимо настроить перезапись обычных DN, поскольку правила
# контекста перезаписи bindDN переопределяют правила, настроенные
# по умолчанию.
rewriteContext bindDN
rewriteRule "^mail=[^,]+@[^,]+$" "%{attr2dn(%0)}" ":@I"

# Следующий пример довольно сложный. В нём поисковый фильтр преобразуется
# в случае, когда тот, кто выполняет поиск, имеет административные
# привилегии. Во-первых, мы должны отслеживать DN подсоединения
# входящих запросов и сохранять их в переменной `binddn', которая
# будет доступна в рамках всей сессии, а также оставлять их на месте
# для того, чтобы можно было осуществлять обычные подключения:
rewriteContext  bindDN
rewriteRule     ".+" "%{&&binddn(%0)}%0" ":"

# Поисковый фильтр, содержащий `uid=', перезаписывается, только
# если подсоединение осуществлялось от имени соответствующего DN.
# Чтобы сделать это, в первом правиле происходит подстановка DN
# подключения, а фильтр разбивается на префикс (переменная prefix),
# значение AVA `uid=<arg>' (переменная arg) и суффикс (переменная
# suffix). Тег `<>' добавляется в конец DN. Если DN указывает на
# запись в поддереве `ou=admin', фильтр перезаписывается: условие
# `uid=<arg>' соединяется с условием `cn=<arg>' через логическое ИЛИ;
# в противном случае всё остаётся как есть. Это может понадобиться,
# например, чтобы позволить модулю apache auth_ldap-1.4 аутентифицировать
# пользователей, логины которых могут быть либо в атрибуте `uid',
# либо в атрибуте `cn', но только если запрос поступает, например,
# от пользователя `cn=Web auth,ou=admin,dc=home,dc=net'.
rewriteContext searchFilter
rewriteRule "(.*\\()uid=([a-z0-9_]+)(\\).*)"
  "%{**binddn}<>%{&prefix(%1)}%{&arg(%2)}%{&suffix(%3)}"
  ":I"
rewriteRule "[^,]+,ou=admin,dc=home,dc=net"
  "%{*prefix}|(uid=%{*arg})(cn=%{*arg})%{*suffix}" ":@I"
rewriteRule ".*<>" "%{*prefix}uid=%{*arg}%{*suffix}" ":"

# В этом примере показано, как исключить нежелательные значения атрибутов,
# значениями которых являются DN, из результатов поиска. В первом правиле
# ищутся DN, оканчивающиеся на "ou=People,dc=example,dc=com"; в случае
# нахождения совпадения, перезапись успешно завершается. Второе правило
# совпадает со всем остальным, и приводит к тому, что значение будет отвергнуто.
rewriteContext searchResult
rewriteRule ".*,ou=People,dc=example,dc=com" "%0" ":@"
rewriteRule ".*" "" "#"

Определение LDAP-прокси (возможное развитие slapd-ldap(5))

  rewriteRule '^cn=root,.*' '%0'                     'G{3}'
  rewriteRule '^cn=[a-l].*' 'ldap://ldap1.my.org/%0' ':@'
  rewriteRule '^cn=[m-z].*' 'ldap://ldap2.my.org/%0' ':@'
  rewriteRule '.*'          'ldap://ldap3.my.org/%0' ':@'

(Первое правило приведено здесь просто для иллюстрации действия `G{n}'; оно может быть перефразировано так:

  rewriteRule '^cn=root,.*' 'ldap://ldap3.my.org/%0' ':@'

тем самым экономится один проход перезаписи...).

КОНТРОЛЬ ДОСТУПА

НАЛОЖЕНИЕ КЭШИРУЮЩЕГО ПРОКСИ-СЕРВЕРА

УСТАРЕВШИЕ ДИРЕКТИВЫ

pseudorootdn <DN-заместитель в случае подсоединения от имени rootdn>

Вместо этой директивы используйте idassert-bind.

pseudorootpw <пароль-заместитель в случае подсоединения от имени rootdn>

Вместо этой директивы используйте idassert-bind.

ФАЙЛЫ

/usr/local/etc/openldap/slapd.conf

конфигурационный файл slapd по умолчанию.

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

АВТОР

Index

НАЗВАНИЕ

ОБЗОР

ОПИСАНИЕ

ПРИМЕРЫ

КОНФИГУРАЦИЯ

ДИРЕКТИВЫ КОНФИГУРАЦИИ, СПЕЦИАЛЬНЫЕ ДЛЯ МЕХАНИЗМА META

СПЕЦИФИКАЦИЯ ЦЕЛИ

СЦЕНАРИИ РАЗВЁРТЫВАНИЯ

ACL

ПЕРЕЗАПИСЬ

Процесс работы

Флаги управления поиском совпадений с шаблоном

Флаги действий

Шаблоны поиска совпадений

Синтаксис шаблонов подстановки

Контексты перезаписи

Основные директивы конфигурации

Дополнительные директивы конфигурации

Примеры конфигурации

Определение LDAP-прокси (возможное развитие slapd-ldap(5))

КОНТРОЛЬ ДОСТУПА

НАЛОЖЕНИЕ КЭШИРУЮЩЕГО ПРОКСИ-СЕРВЕРА

УСТАРЕВШИЕ ДИРЕКТИВЫ

ФАЙЛЫ

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

АВТОР

Партнёры:

Хостинг: