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

НАЗВАНИЕ

ОБЗОР

ОПИСАНИЕ

Для сессий, явно выполняющих подсоединение Bind к базе данных back-ldap, всегда создаётся своё собственное соединение к удалённому LDAP-серверу. Анонимные сессии совместно используют единственное анонимное подключение к удалённому серверу. Для сессий, выполняющих подсоединение через другие механизмы, все сессии с одинаковым DN будут совместно использовать одно и то же соединение. Эта стратегия объединения подключений может увеличить эффективность прокси путём снижения накладных расходов на повторное открытие/закрытие нескольких соединений.

База данных ldap может также выполнять роль информационной службы, то есть идентификационные сущности клиентов, прошедших аутентификацию локально, предъявляются удалённому серверу, возможно, в несколько изменённой форме. Для этих целей прокси-сервер подсоединяется к удалённому серверу от имени некоторой административной идентификационной сущности и, если необходимо, авторизуется от имени предъявленной идентификационной сущности. Смотрите правила idassert-* ниже. На удалённом сервере административной идентификационной сущности прокси-сервера должно быть разрешено проходить авторизацию посредством соответствующих правил authzTo; более подробную информацию смотрите в man-странице slapd.conf(5).

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

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

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

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

lastmod  off

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

uri <ldapurl>

Указывает, какой LDAP-сервер использовать. В одном аргументе ldapurl можно задавать несколько URI, тогда библиотека вызовов будет вызывать первый доступный сервер из списка. Пример:

uri "ldap://host/ ldap://backup-host/"

URI в списке разделяются пробельным символом или запятой. Всякий раз, когда ответивший сервер не является первым в списке, список переупорядочивается и ответивший сервер перемещается на первое место; таким образом в следующий раз, когда потребуется установить соединение, обращение к этому серверу будет выполняться в первую очередь.

acl-bind bindmethod=simple|sasl [binddn=<simple DN>] [credentials=<simple password>] [saslmech=<SASL mech>] [secprops=<properties>] [realm=<realm>] [authcId=<authentication ID>] [authzId=<authorization ID>] [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]

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

Задавая подобные настройки, вы ничем не рискуете; они используются только для проверки прав доступа. По умолчанию используется simple-подсоединение с пустыми binddn и credentials, то есть соответствующие операции будут выполняться анонимно. Если данная директива не задана, но задана директива idassert-bind, используются настройки из этой директивы. Подробнее смотрите в описании директивы idassert-bind.

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

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

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

cancel {ABANDON|ignore|exop[-discover]}

Определяет, каким образом будут обрабатываться отмены операций. По умолчанию применяется вариант abandon, то есть операции будут немедленно отбрасываться. Если задан вариант ignore, никаких действий предприниматься не будет, а все получаемые в дальнейшем ответы будут игнорироваться. Это может привести к тому, что получаемые ответные сообщения будут ставиться в очередь для этого соединения, поэтому рекомендуется, чтобы соединения с большой продолжительностью работы могли закрываться по таймауту (смотрите директивы idle-timeout и conn-ttl), и эти ресурсы в конце концов высвобождались. Если задан вариант exop, будет запрашиваться выполнение расширенной операции cancel (RFC 3909), в результате которой будет выполняться отмена текущей операции. Операция cancel ожидает ответа от удалённого сервера, поэтому её использование не рекомендуется. Если задан вариант exop-discover, то определение того, поддерживается ли расширенная операция cancel, выполняется путём опроса root DSE удалённого сервера.

chase-referrals {YES|no}

Включает/отключает автоматический переход по отсылкам, осуществление которого делегируется библиотеке

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

conn-ttl <time>

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

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

С введением этой директивы устаревшими стали директивы idassert-authcDN, idassert-passwd, idassert-mode и idassert-method.

idassert-passthru <authz-regexp>

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

idle-timeout <time>

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

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

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

network-timeout <time>

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

norefs <NO|yes>

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

noundeffilter <NO|yes>

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

onerr {CONTINUE|stop}

Эта директива позволяет определить поведение в случае, когда во время поиска удалённый сервер возвращает ошибку. Если задано значение continue (по умолчанию), будет возвращён признак успешного выполнения поиска. Если задано значение stop, ошибка, возникшая на удалённом сервере, будет возвращаться клиенту.

protocol-version {0,2,3}

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

proxy-whoami {NO|yes}

Включает проксирование расширенной операции WhoAmI. Если эта опция включена, механизм back-ldap будет заменять оригинальную процедуру WhoAmI slapd своей собственной. В сессиях slapd, которые были аутентифицированы механизмом back-ldap, запрос WhoAmI будет перенаправлен удалённому LDAP-серверу. Другие сессии будут обрабатываться локальным сервером slapd как и прежде. Эта опция главным образом полезна в сочетании с прокси-авторизацией (Proxy Authorization).

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

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

rebind-as-user {NO|yes}

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

session-tracking-request {NO|yes}

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

single-conn {NO|yes}

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

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.

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

tls {[try-]start|[try-]propagate|ldaps} [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_crlcheck=none|peer|all]

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

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

use-temporary-conn {NO|yes}

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

ОБРАТНАЯ СОВМЕСТИМОСТЬ

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

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

Идентификационная сущность acl-authcDN ни при каких обстоятельствах не используется прокси неявно при выполнении клиентом анонимного подключения. С другой стороны, настройки из директив idassert-* могут быть использованы для реализации такого поведения, что небезопасно и должно применяться с максимальной осторожностью.

Данная директива отменяется аргументом binddn параметра acl-bind (если bindmethod=simple), и в будущем будет исключена.

acl-passwd <password>

Ранее эта директива называлась bindpw. Задаёт пароль для записи, указанной в директиве acl-authcDN. Данная директива отменяется аргументом credentials параметра acl-bind (если bindmethod=simple), и в будущем будет исключена.

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

DN, которое используется для передачи идентификационной сущности клиента целевому серверу посредством элемента управления proxyAuthz, когда клиент не принадлежит фрагменту DIT, который проксируется механизмом back-ldap. Данная директива отменяется аргументом binddn параметра idassert-bind (если bindmethod=simple), и в будущем будет исключена.

idassert-passwd <password>

Задаёт пароль для записи, указанной в директиве idassert-authcDN. Данная директива отменяется аргументом crendentials параметра idassert-bind (если bindmethod=simple), и в будущем будет исключена.

idassert-mode <mode> [<flags>]

Определяет, какой тип утверждения идентификационной сущности используется. Данная директива отменяется аргументом mode параметра idassert-bind, и в будущем будет исключена.

idassert-method <method> [<saslargs>]

Данная директива отменяется аргументом bindmethod параметра idassert-bind, и в будущем будет исключена.

port <port>

Эта директива больше не поддерживается. Используйте описанную выше директиву uri.

server <hostname[:port]>

Эта директива больше не поддерживается. Используйте описанную выше директиву uri.

suffixmassage, map, rewrite*

Эти директивы больше не поддерживаются back-ldap; их функциональность делегирована наложению rwm. Чтобы получить оригинальное поведение, достаточно добавить директиву

overlay rwm

а затем указывать префикс rwm- перед всеми объявлениями rewrite/map. Подробнее смотрите в man-странице slapo-rwm(5).

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

НАЛОЖЕНИЯ

С другой стороны, существует много наложений, которые лучше всего использовать совместно с механизмом манипуляции данными LDAP. Наложение proxycache позволяет кэшировать поисковые запросы LDAP в локальной базе данных (смотрите man-страницу slapo-pcache(5)). Наложение rwm обеспечивает возможности перезаписи DN и отображения атрибутов/объектных классов удалённой базы данных в требуемый вид (смотрите man-страницу slapo-rwm(5)).

ФАЙЛЫ

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

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

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

АВТОРЫ

Index

НАЗВАНИЕ

ОБЗОР

ОПИСАНИЕ

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

ОБРАТНАЯ СОВМЕСТИМОСТЬ

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

НАЛОЖЕНИЯ

ФАЙЛЫ

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

АВТОРЫ

Партнёры:

Хостинг: