Путеводитель по Руководству Linux

  User  |  Syst  |  Libr  |  Device  |  Files  |  Other  |  Admin  |  Head  |



   slapd-meta    ( 5 )

бэкэнд метакаталога для slapd (metadirectory backend to slapd)

Целевая спецификация (Target specification)

Target specification starts with a "uri" directive:

uri <protocol>://[<host>]/<naming context> [...] The <protocol> part can be anything ldap_initialize(3) accepts ({ldap|ldaps|ldapi} and variants); the <host> may be omitted, defaulting to whatever is set in ldap.conf(5). The <naming context> part is mandatory for the first URI, but it must be omitted for subsequent ones, if any. The naming context part must be within the naming context defined for the backend, e.g.:

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

The <naming context> part doesn't need to be unique across the targets; it may also match one of the values of the "suffix" directive. Multiple URIs may be defined in a single URI statement. The additional URIs must be separate arguments and must not have any <naming context> part. This causes the underlying library to contact the first server of the list that responds. For example, if l1.foo.com and l2.foo.com are shadows of the same server, the directive

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

causes l2.foo.com to be contacted whenever l1.foo.com does not respond. In that case, the URI list is internally rearranged, by moving unavailable URIs to the end, so that further connection attempts occur with respect to the last URI that succeeded.

acl-authcDN <administrative DN for access control purposes> DN which is used to query the target server for acl checking, as in the LDAP backend; it is supposed to have read access on the target server to attributes used on the proxy for acl checking. There is no risk of giving away such values; they are only used to check permissions. The acl-authcDN identity is by no means implicitly used by the proxy when the client connects anonymously.

acl-passwd <password> Password used with the acl-authcDN above.

bind-timeout <microseconds> This directive defines the timeout, in microseconds, used when polling for response after an asynchronous bind connection. The initial call to ldap_result(3) is performed with a trade-off timeout of 100000 us; if that results in a timeout exceeded, subsequent calls use the value provided with bind-timeout. The default value is used also for subsequent calls if bind-timeout is not specified. If set before any target specification, it affects all targets, unless overridden by any per-target directive.

chase-referrals {YES|no} enable/disable automatic referral chasing, which is delegated to the underlying libldap, with rebinding eventually performed if the rebind-as-user directive is used. The default is to chase referrals. If set before any target specification, it affects all targets, unless overridden by any per-target directive.

client-pr {accept-unsolicited|DISABLE|<size>} This feature allows one to use RFC 2696 Paged Results control when performing search operations with a specific target, irrespective of the client's request. When set to a numeric value, Paged Results control is always used with size as the page size. When set to accept-unsolicited, unsolicited Paged Results control responses are accepted and honored for compatibility with broken remote DSAs. The client is not exposed to paged results handling between slapd-meta(5) and the remote servers. By default (disabled), Paged Results control is not used and responses are not accepted. If set before any target specification, it affects all targets, unless overridden by any per-target directive.

default-target [<target>] The "default-target" directive can also be used during target specification. With no arguments it marks the current target as the default. The optional number marks target <target> as the default one, starting from 1. Target <target> must be defined.

filter <pattern> This directive allows specifying a regex(5) pattern to indicate what search filter terms are actually served by a target.

In a search request, if the search filter matches the pattern the target is considered while fulfilling the request; otherwise the target is ignored. There may be multiple occurrences of the filter directive for each target.

idassert-authzFrom <authz-regexp> if defined, selects what local identities are authorized to exploit the identity assertion feature. The string <authz-regexp> follows the rules defined for the authzFrom attribute. See slapd.conf(5), section related to authz-policy, for details on the syntax of this field.

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_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_ecname=<ciphers>] [tls_protocol_min=<major>[.<minor>]] [tls_crlcheck=none|peer|all] Allows one to define the parameters of the authentication method that is internally used by the proxy to authorize connections that are authenticated by other databases. The identity defined by this directive, according to the properties associated to the authentication method, is supposed to have auth access on the target server to attributes used on the proxy for authentication and authorization, and to be allowed to authorize the users. This requires to have proxyAuthz privileges on a wide set of DNs, e.g. authzTo=dn.subtree:"", and the remote server to have authz-policy set to to or both. See slapd.conf(5) for details on these statements and for remarks and drawbacks about their usage. The supported bindmethods are

none|simple|sasl

where none is the default, i.e. no identity assertion is performed.

The authz parameter is used to instruct the SASL bind to exploit native SASL authorization, if available; since connections are cached, this should only be used when authorizing with a fixed identity (e.g. by means of the authzDN or authzID parameters). Otherwise, the default proxyauthz is used, i.e. the proxyAuthz control (Proxied Authorization, RFC 4370) is added to all operations.

The supported modes are:

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

If <mode> is not present, and authzId is given, the proxy always authorizes that identity. <authorization ID> can be

u:<user>

[dn:]<DN>

The former is supposed to be expanded by the remote server according to the authz rules; see slapd.conf(5) for details. In the latter case, whether or not the dn: prefix is present, the string must pass DN validation and normalization.

The default mode is legacy, which implies that the proxy will either perform a simple bind as the authcDN or a SASL bind as the authcID and assert the client's identity when it is not anonymous. Direct binds are always proxied. The other modes imply that the proxy will always either perform a simple bind as the authcDN or a SASL bind as the authcID, unless restricted by idassert-authzFrom rules (see below), in which case the operation will fail; eventually, it will assert some other identity according to <mode>. Other identity assertion modes are anonymous and self, which respectively mean that the empty or the client's identity will be asserted; none, which means that no proxyAuthz control will be used, so the authcDN or the authcID identity will be asserted. For all modes that require the use of the proxyAuthz control, on the remote server the proxy identity must have appropriate authzTo permissions, or the asserted identities must have appropriate authzFrom permissions. Note, however, that the ID assertion feature is mostly useful when the asserted identities do not exist on the remote server. When bindmethod is SASL, the authcDN must be specified in addition to the authcID, although it is not used within the authentication process.

Flags can be

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

When the override flag is used, identity assertion takes place even when the database is authorizing for the identity of the client, i.e. after binding with the provided identity, and thus authenticating it, the proxy performs the identity assertion using the configured identity and authentication method.

When the prescriptive flag is used (the default), operations fail with inappropriateAuthentication for those identities whose assertion is not allowed by the idassert-authzFrom patterns. If the non-prescriptive flag is used, operations are performed anonymously for those identities whose assertion is not allowed by the idassert-authzFrom patterns.

When the proxy-authz-non-critical flag is used (the default), the proxyAuthz control is not marked as critical, in violation of RFC 4370. Use of proxy-authz-critical is recommended.

The TLS settings default to the same as the main slapd TLS settings, except for tls_reqcert which defaults to "demand", and tls_reqsan which defaults to "allow"..

The identity associated to this directive is also used for privileged operations whenever idassert-bind is defined and acl-bind is not. See acl-bind for details.

idle-timeout <time> This directive causes a cached connection to be dropped an recreated after it has been idle for the specified time. The value can be specified as

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

where <d>, <h>, <m> and <s> are respectively treated as days, hours, minutes and seconds. If set before any target specification, it affects all targets, unless overridden by any per-target directive.

keepalive <idle>:<probes>:<interval> The keepalive parameter sets the values of idle, probes, and interval used to check whether a socket is alive; idle is the number of seconds a connection needs to remain idle before TCP starts sending keepalive probes; probes is the maximum number of keepalive probes TCP should send before dropping the connection; interval is interval in seconds between individual keepalive probes. Only some systems support the customization of these values; the keepalive parameter is ignored otherwise, and system-wide settings are used.

tcp-user-timeout <milliseconds> If non-zero, corresponds to the TCP_USER_TIMEOUT set on the target connections, overriding the operating system setting. Only some systems support the customization of this parameter, it is ignored otherwise and system-wide settings are used.

map {attribute|objectclass} [<local name>|*] {<foreign name>|*} This maps object classes and attributes as in the LDAP backend. See slapd-ldap(5).

network-timeout <time> Sets the network timeout value after which poll(2)/select(2) following a connect(2) returns in case of no activity. The value is in seconds, and it can be specified as for idle-timeout. If set before any target specification, it affects all targets, unless overridden by any per-target directive.

nretries {forever|never|<nretries>} This directive defines how many times a bind should be retried in case of temporary failure in contacting a target. If defined before any target specification, it applies to all targets (by default, 3 times); the global value can be overridden by redefinitions inside each target specification.

rewrite* ... The rewrite options are described in the "REWRITING" section.

subtree-{exclude|include} <rule> This directive allows one to indicate what subtrees are actually served by a target. The syntax of the supported rules is

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

<style>: subtree|children|regex

When <style> is either subtree or children the <pattern> is a DN that must be within the naming context served by the target. When <style> is regex the <pattern> is a regex(5) pattern. If the dn.<style>: prefix is omitted, dn.subtree: is implicitly assumed for backward compatibility.

In the subtree-exclude form if the request DN matches at least one rule, the target is not considered while fulfilling the request; otherwise, the target is considered based on the value of the request DN. When the request is a search, also the scope is considered.

In the subtree-include form if the request DN matches at least one rule, the target is considered while fulfilling the request; otherwise the target is ignored.

| match | exclude | +---------+---------+-------------------+ | T | T | not candidate | | F | T | continue checking | +---------+---------+-------------------+ | T | F | candidate | | F | F | not candidate | +---------+---------+-------------------+

There may be multiple occurrences of the subtree-exclude or subtree-include directive for each of the targets, but they are mutually exclusive.

suffixmassage <virtual naming context> <real naming context> All the directives starting with "rewrite" refer to the rewrite engine that has been added to slapd. The "suffixmassage" directive was introduced in the LDAP backend to allow suffix massaging while proxying. It has been obsoleted by the rewriting tools. However, both for backward compatibility and for ease of configuration when simple suffix massage is required, it has been preserved. It wraps the basic rewriting instructions that perform suffix massaging. See the "REWRITING" section for a detailed list of the rewrite rules it implies.

t-f-support {NO|yes|discover} enable if the remote server supports absolute filters (see RFC 4526 for details). If set to discover, support is detected by reading the remote server's root DSE. If set before any target specification, it affects all targets, unless overridden by any per-target directive.

timeout [<op>=]<val> [...] This directive allows one to set per-operation timeouts. Operations can be

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

The overall duration of the search operation is controlled either by the timelimit parameter or by server-side enforced time limits (see timelimit and limits in slapd.conf(5) for details). This timeout parameter controls how long the target can be irresponsive before the operation is aborted. Timeout is meaningless for the remaining operations, unbind and abandon, which do not imply any response, while it is not yet implemented in currently supported extended operations. If no operation is specified, the timeout val affects all supported operations. If specified before any target definition, it affects all targets unless overridden by per-target directives.

Note: if the timeout is exceeded, the operation is cancelled (according to the cancel directive); the protocol does not provide any means to rollback operations, so the client will not be notified about the result of the operation, which may eventually succeeded or not. In case the timeout is exceeded during a bind operation, the connection is destroyed, according to RFC4511.

tls {none|[try-]start|[try-]propagate|ldaps} [starttls=no] [tls_cert=<file>] [tls_key=<file>] [tls_cacert=<file>] [tls_cacertdir=<path>] [tls_reqcert=never|allow|try|demand] [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>] [tls_ecname=<names>] [tls_crlcheck=none|peer|all] Specify TLS settings regular connections.

If the first parameter is not "none" then this configures the TLS settings to be used for regular connections. The StartTLS extended operation will be used when establishing the connection unless the URI directive protocol scheme is ldaps://. In that case this keyword may only be set to "ldaps" and the StartTLS operation will not be used.

propagate issues the StartTLS operation only if the original connection did. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is highly deprecated. The TLS settings default to the same as the main slapd TLS settings, except for tls_reqcert which defaults to "demand", tls_reqsan which defaults to "allow", and starttls which is overshadowed by the first keyword and thus ignored.

If set before any target specification, it affects all targets, unless overridden by any per-target directive.