ldap.conf

package: openldap-common

title: ldap.conf(5)

text:
# ldap.conf(5)

## NAME
ldap.conf, .ldaprc - LDAP configuration file/environment variables

## SYNOPSIS
/etc/openldap/ldap.conf, ldaprc, .ldaprc, $LDAP<option-name>

## DESCRIPTION
If the environment variable LDAPNOINIT is defined, all defaulting is disabled.

The ldap.conf configuration file is used to set system-wide defaults to be applied when running ldap clients.

Users may create an optional configuration file, ldaprc or .ldaprc, in their home directory which will be used to override the system-wide defaults file. The file ldaprc in the current working directory is also used.

Additional configuration files can be specified using the LDAPCONF and LDAPRC environment variables. LDAPCONF may be set to the path of a configuration file. This path can be absolute or relative to the current working directory. The LDAPRC, if defined, should be the basename of a file in the current working directory or in the user's home directory.

Environmental variables may also be used to augment the file based defaults. The name of the variable is the option name with an added prefix of LDAP. For example, to define BASE via the environment, set the variable LDAPBASE to the desired value.

Some options are user-only. Such options are ignored if present in the ldap.conf (or file specified by LDAPCONF).

Thus the following files and variables are read, in order:

```
    variable     $LDAPNOINIT, and if that is not set:

    system file  /etc/openldap/ldap.conf,

    user files   $HOME/ldaprc,  $HOME/.ldaprc,  ./ldaprc,

    system file  $LDAPCONF,

    user files   $HOME/$LDAPRC, $HOME/.$LDAPRC, ./$LDAPRC,

    variables    $LDAP<uppercase option name>.
```

Settings late in the list override earlier ones.

## SYNTAX
The configuration options are case-insensitive; their value, on a case by case basis, may be case-sensitive.

Blank lines are ignored.

Lines beginning with a hash mark (`#') are comments, and ignored.

Valid lines are made of an option's name (a sequence of non-blanks, conventionally written in uppercase, although not required), followed by a value. The value starts with the first non-blank character after the option's name, and terminates at the end of the line, or at the last sequence of blanks before the end of the line. The tokenization of the value, if any, is delegated to the handler(s) for that option, if any. Quoting values that contain blanks may be incorrect, as the quotes would become part of the value. For example,

```
	# Wrong - erroneous quotes:
	URI     "ldap:// ldaps://"
	# Right - space-separated list of URIs, without quotes:
	URI     ldap:// ldaps://
	# Right - DN syntax needs quoting for Example, Inc:
	BASE    ou=IT staff,o="Example, Inc",c=US
	# or:
	BASE    ou=IT staff,o=Example\2C Inc,c=US
	# Wrong - comment on same line as option:
	DEREF   never           # Never follow aliases
```

A line cannot be longer than LINE_MAX, which should be more than 2000 bytes on all platforms. There is no mechanism to split a long line on multiple lines, either for beautification or to overcome the above limit.

## OPTIONS
The different configuration options are:

URI <ldap[si]://[name[:port]] ...>

Specifies the URI(s) of an LDAP server(s) to which the LDAP library should connect. The URI scheme may be any of ldap, ldaps or ldapi, which refer to LDAP over TCP, LDAP over SSL (TLS) and LDAP over IPC (UNIX domain sockets), respectively. Each server's name can be specified as a domain-style name or an IP address literal. Optionally, the server's name can followed by a ':' and the port number the LDAP server is listening on. If no port number is provided, the default port for the scheme is used (389 for ldap://, 636 for ldaps://). For LDAP over IPC, name is the name of the socket, and no port is required, nor allowed; note that directory separators must be URL-encoded, like any other characters that are special to URLs; so the socket /usr/local/var/ldapi

must be specified as

ldapi://%2Fusr%2Flocal%2Fvar%2Fldapi

A space separated list of URIs may be provided.

BASE <base>

Specifies the default base DN to use when performing ldap operations. The base must be specified as a Distinguished Name in LDAP format.

BINDDN <dn>

Specifies the default bind DN to use when performing ldap operations. The bind DN must be specified as a Distinguished Name in LDAP format. This is a user-only option.

DEREF <when>

Specifies how alias dereferencing is done when performing a search. The <when> can be specified as one of the following keywords:

never

Aliases are never dereferenced. This is the default.

searching

Aliases are dereferenced in subordinates of the base object, but not in locating the base object of the search.

finding

Aliases are only dereferenced when locating the base object of the search.

always

Aliases are dereferenced both in searching and in locating the base object of the search.

HOST <name[:port] ...>

Specifies the name(s) of an LDAP server(s) to which the LDAP library should connect. Each server's name can be specified as a domain-style name or an IP address and optionally followed by a ':' and the port number the ldap server is listening on. A space separated list of hosts may be provided. HOST is deprecated in favor of URI.

KEEPALIVE_IDLE

Sets/gets the number of seconds a connection needs to remain idle before TCP starts sending keepalive probes. Linux only.

KEEPALIVE_PROBES

Sets/gets the maximum number of keepalive probes TCP should send before dropping the connection. Linux only.

KEEPALIVE_INTERVAL

Sets/gets the interval in seconds between individual keepalive probes. Linux only.

NETWORK_TIMEOUT <integer>

Specifies the timeout (in seconds) after which the poll(2)/select(2) following a connect(2) returns in case of no activity.

PORT <port>

Specifies the default port used when connecting to LDAP servers(s). The port may be specified as a number. PORT is deprecated in favor of URI.

REFERRALS <on/true/yes/off/false/no>

Specifies if the client should automatically follow referrals returned by LDAP servers. The default is on. Note that the command line tools ldapsearch(1) &co always override this option.

SIZELIMIT <integer>

Specifies a size limit (number of entries) to use when performing searches. The number should be a non-negative integer. SIZELIMIT of zero (0) specifies a request for unlimited search size. Please note that the server may still apply any server-side limit on the amount of entries that can be returned by a search operation.

SOCKET_BIND_ADDRESSES <IP>

Specifies the source bind IP to be used for connecting to target LDAP server. Multiple IP addresses must be space separated. Only one valid IPv4 address and/or one valid IPv6 address are allowed in the list.

TIMELIMIT <integer>

Specifies a time limit (in seconds) to use when performing searches. The number should be a non-negative integer. TIMELIMIT of zero (0) specifies unlimited search time to be used. Please note that the server may still apply any server-side limit on the duration of a search operation.

VERSION {2|3}

Specifies what version of the LDAP protocol should be used.

TIMEOUT <integer>

Specifies a timeout (in seconds) after which calls to synchronous LDAP APIs will abort if no response is received. Also used for any ldap_result(3) calls where a NULL timeout parameter is supplied.

## SASL OPTIONS
If OpenLDAP is built with Simple Authentication and Security Layer support, there are more options you can specify.

SASL_MECH <mechanism>

Specifies the SASL mechanism to use.

SASL_REALM <realm>

Specifies the SASL realm.

SASL_AUTHCID <authcid>

Specifies the authentication identity. This is a user-only option.

SASL_AUTHZID <authcid>

Specifies the proxy authorization identity. This is a user-only option.

SASL_SECPROPS <properties>

Specifies Cyrus SASL security properties. The <properties> can be specified as a comma-separated list of the following:

none

(without any other properties) causes the properties defaults ("noanonymous,noplain") to be cleared.

noplain

disables mechanisms susceptible to simple passive attacks.

noactive

disables mechanisms susceptible to active attacks.

nodict

disables mechanisms susceptible to passive dictionary attacks.

noanonymous

disables mechanisms which support anonymous login.

forwardsec

requires forward secrecy between sessions.

passcred

requires mechanisms which pass client credentials (and allows mechanisms which can pass credentials to do so).

minssf=<factor>

specifies the minimum acceptable security strength factor as an integer approximate to effective key length used for encryption. 0 (zero) implies no protection, 1 implies integrity protection only, 128 allows RC4, Blowfish and other similar ciphers, 256 will require modern ciphers. The default is 0.

maxssf=<factor>

specifies the maximum acceptable security strength factor as an integer (see minssf description). The default is INT_MAX.

maxbufsize=<factor>

specifies the maximum security layer receive buffer size allowed. 0 disables security layers. The default is 65536.

SASL_NOCANON <on/true/yes/off/false/no>

Do not perform reverse DNS lookups to canonicalize SASL host names. The default is off.

SASL_CBINDING <none/tls-unique/tls-endpoint>

The channel-binding type to use, see also LDAP_OPT_X_SASL_CBINDING. The default is none.

## GSSAPI OPTIONS
If OpenLDAP is built with Generic Security Services Application Programming Interface support, there are more options you can specify.

GSSAPI_SIGN <on/true/yes/off/false/no>

Specifies if GSSAPI signing (GSS_C_INTEG_FLAG) should be used. The default is off.

GSSAPI_ENCRYPT <on/true/yes/off/false/no>

Specifies if GSSAPI encryption (GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG) should be used. The default is off.

GSSAPI_ALLOW_REMOTE_PRINCIPAL <on/true/yes/off/false/no>

Specifies if GSSAPI based authentication should try to form the target principal name out of the ldapServiceName or dnsHostName attribute of the targets RootDSE entry. The default is off.

## TLS OPTIONS
If OpenLDAP is built with Transport Layer Security support, there are more options you can specify. These options are used when an ldaps:// URI is selected (by default or otherwise) or when the application negotiates TLS by issuing the LDAP StartTLS operation.

TLS_CACERT <filename>

Specifies the file that contains certificates for all of the Certificate Authorities the client will recognize.

TLS_CACERTDIR <path>

Specifies the path of directories that contain Certificate Authority certificates in separate individual files. Multiple directories may be specified, separated by a semi-colon. The TLS_CACERT is always used before TLS_CACERTDIR.

TLS_CERT <filename>

Specifies the file that contains the client certificate. This is a user-only option.

TLS_ECNAME <name>

Specify the name of the curve(s) to use for Elliptic curve Diffie-Hellman ephemeral key exchange. This option is only used for OpenSSL. This option is not used with GnuTLS; the curves may be chosen in the GnuTLS ciphersuite specification.

TLS_KEY <filename>

Specifies the file that contains the private key that matches the certificate stored in the TLS_CERT file. Currently, the private key must not be protected with a password, so it is of critical importance that the key file is protected carefully. This is a user-only option.

TLS_CIPHER_SUITE <cipher-suite-spec>

Specifies acceptable cipher suite and preference order. <cipher-suite-spec> should be a cipher specification for the TLS library in use (OpenSSL or GnuTLS). Example:

OpenSSL:

TLS_CIPHER_SUITE HIGH:MEDIUM:+SSLv2

GnuTLS:

TLS_CIPHER_SUITE SECURE256:!AES-128-CBC

To check what ciphers a given spec selects in OpenSSL, use:

```
	openssl ciphers -v <cipher-suite-spec>
```

With GnuTLS the available specs can be found in the manual page of gnutls-cli(1) (see the description of the option --priority).

In older versions of GnuTLS, where gnutls-cli does not support the option --priority, you can obtain the — more limited — list of ciphers by calling:

```
	gnutls-cli -l
```

TLS_PROTOCOL_MIN <major>[.<minor>]

Specifies minimum SSL/TLS protocol version that will be negotiated. If the server doesn't support at least that version, the SSL handshake will fail. To require TLS 1.x or higher, set this option to 3.(x+1), e.g.,

```
	TLS_PROTOCOL_MIN 3.2
```

would require TLS 1.1. Specifying a minimum that is higher than that supported by the OpenLDAP implementation will result in it requiring the highest level that it does support. This parameter is ignored with GnuTLS.

TLS_RANDFILE <filename>

Specifies the file to obtain random bits from when /dev/[u]random is not available. Generally set to the name of the EGD/PRNGD socket. The environment variable RANDFILE can also be used to specify the filename. This parameter is ignored with GnuTLS.

TLS_REQCERT <level>

Specifies what checks to perform on server certificates in a TLS session. The <level> can be specified as one of the following keywords:

never

The client will not request or check any server certificate.

allow

The server certificate is requested. If a bad certificate is provided, it will be ignored and the session proceeds normally.

try

The server certificate is requested. If a bad certificate is provided, the session is immediately terminated.

demand | hard

These keywords are equivalent and the same as try. This is the default setting.

TLS_REQSAN <level>

Specifies what checks to perform on the subjectAlternativeName (SAN) extensions in a server certificate when validating the certificate name against the specified hostname of the server. The <level> can be specified as one of the following keywords:

never

The client will not check any SAN in the certificate.

allow

The SAN is checked against the specified hostname. If a SAN is present but none match the specified hostname, the SANs are ignored and the usual check against the certificate DN is used. This is the default setting.

try

The SAN is checked against the specified hostname. If no SAN is present in the server certificate, the usual check against the certificate DN is used. If a SAN is present but doesn't match the specified hostname, the session is immediately terminated. This setting may be preferred when a mix of certs with and without SANs are in use.

demand | hard

These keywords are equivalent. The SAN is checked against the specified hostname. If no SAN is present in the server certificate, or no SANs match, the session is immediately terminated. This setting should be used when only certificates with SANs are in use.

TLS_CRLCHECK <level>

Specifies if the Certificate Revocation List (CRL) of the CA should be used to verify if the server certificates have not been revoked. This requires TLS_CACERTDIR parameter to be set. This parameter is ignored with GnuTLS. <level> can be specified as one of the following keywords:

none

No CRL checks are performed

peer

Check the CRL of the peer certificate

all

Check the CRL for a whole certificate chain

TLS_CRLFILE <filename>

Specifies the file containing a Certificate Revocation List to be used to verify if the server certificates have not been revoked. This parameter is only supported with GnuTLS.

## ENVIRONMENT VARIABLES
LDAPNOINIT

disable all defaulting

LDAPCONF

path of a configuration file

LDAPRC

basename of ldaprc file in $HOME or $CWD

LDAP<option-name>

Set <option-name> as from ldap.conf

## FILES
/etc/openldap/ldap.conf

system-wide ldap configuration file

$HOME/ldaprc, $HOME/.ldaprc

user ldap configuration file

$CWD/ldaprc

local ldap configuration file

## SEE ALSO
ldap(3), ldap_set_option(3), ldap_result(3), openssl(1), sasl(3)

## AUTHOR
Kurt Zeilenga, The OpenLDAP Project

## ACKNOWLEDGEMENTS
OpenLDAP Software is developed and maintained by The OpenLDAP Project <http://www.openldap.org/>. OpenLDAP Software is derived from the University of Michigan LDAP 3.3 Release.


ldif

title: ldif(5)

summary: LDAP Data Interchange Format

text:
# ldif(5)

## NAME
ldif - LDAP Data Interchange Format

## DESCRIPTION
The LDAP Data Interchange Format (LDIF) is used to represent LDAP entries and change records in text form. LDAP tools, such as ldapadd(1) and ldapsearch(1), read and write LDIF entry records. ldapmodify(1) reads LDIF change records.

This manual page provides a basic description of LDIF. A formal specification of LDIF is published in RFC 2849.

## ENTRY RECORDS
LDIF entry records are used to represent directory entries. The basic form of an entry record is:

```
	dn: <distinguished name>
	<attrdesc>: <attrvalue>
	<attrdesc>: <attrvalue>
	<attrdesc>:: <base64-encoded-value>
	<attrdesc>:< <URL>
	...
```

The value may be specified as UTF-8 text or as base64 encoded data, or a URI may be provided to the location of the attribute value.

A line may be continued by starting the next line with a single space or tab, e.g.,

```
	dn: cn=Barbara J Jensen,dc=exam
	 ple,dc=com
```

Lines beginning with a sharp sign ('#') are ignored.

Multiple attribute values are specified on separate lines, e.g.,

```
	cn: Barbara J Jensen
	cn: Babs Jensen
```

If an value contains a non-printing character, or begins with a space or a colon ':', the <attrtype> is followed by a double colon and the value is encoded in base 64 notation. e.g., the value " begins with a space" would be encoded like this:

```
	cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U=
```

If the attribute value is located in a file, the <attrtype> is followed by a ':<' and a file: URI. e.g., the value contained in the file /tmp/value would be listed like this:

```
	cn:< file:///tmp/value
```

Other URI schemes (ftp,http) may be supported as well. Multiple entries within the same LDIF file are separated by blank lines.

## ENTRY RECORD EXAMPLE
Here is an example of an LDIF file containing three entries.

```
	dn: cn=Barbara J Jensen,dc=example,dc=com
	cn: Barbara J Jensen
	cn: Babs Jensen
	objectclass: person
	description:< file:///tmp/babs
	sn: Jensen
	dn: cn=Bjorn J Jensen,dc=example,dc=com
	cn: Bjorn J Jensen
	cn: Bjorn Jensen
	objectclass: person
	sn: Jensen
	dn: cn=Jennifer J Jensen,dc=example,dc=com
	cn: Jennifer J Jensen
	cn: Jennifer Jensen
	objectclass: person
	sn: Jensen
	jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD
	 A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ
	 ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG
	...
```

Note that the description in Barbara Jensen's entry is read from file:///tmp/babs and the jpegPhoto in Jennifer Jensen's entry is encoded using base 64.

## CHANGE RECORDS
LDIF change records are used to represent directory change requests. Each change record starts with line indicating the distinguished name of the entry being changed:

```
	dn: <distinguishedname>
```

```
	changetype: <[modify|add|delete|modrdn]>
```

Finally, the change information itself is given, the format of which depends on what kind of change was specified above. For a changetype of modify, the format is one or more of the following:

```
	add: <attributetype>
	<attrdesc>: <value1>
	<attrdesc>: <value2>
	...
	-
```

Or, for a replace modification:

```
	replace: <attributetype>
	<attrdesc>: <value1>
	<attrdesc>: <value2>
	...
	-
```

If no attributetype lines are given to replace, the entire attribute is to be deleted (if present).

Or, for a delete modification:

```
	delete: <attributetype>
	<attrdesc>: <value1>
	<attrdesc>: <value2>
	...
	-
```

If no attributetype lines are given to delete, the entire attribute is to be deleted.

For a changetype of add, the format is:

```
	<attrdesc1>: <value1>
	<attrdesc1>: <value2>
	...
	<attrdescN>: <value1>
	<attrdescN>: <value2>
```

For a changetype of modrdn or moddn, the format is:

```
	newrdn: <newrdn>
	deleteoldrdn: 0 | 1
	newsuperior: <DN>
```

where a value of 1 for deleteoldrdn means to delete the values forming the old rdn from the entry, and a value of 0 means to leave the values as non-distinguished attributes in the entry. The newsuperior line is optional and, if present, specifies the new superior to move the entry to.

For a changetype of delete, no additional information is needed in the record.

Note that attribute values may be presented using base64 or in files as described for entry records. Lines in change records may be continued in the manner described for entry records as well.

## CHANGE RECORD EXAMPLE
The following sample LDIF file contains a change record of each type of change.

```
	dn: cn=Babs Jensen,dc=example,dc=com
	changetype: add
	objectclass: person
	objectclass: extensibleObject
	cn: babs
	cn: babs jensen
	sn: jensen
	dn: cn=Babs Jensen,dc=example,dc=com
	changetype: modify
	add: givenName
	givenName: Barbara
	givenName: babs
	-
	replace: description
	description: the fabulous babs
	-
	delete: sn
	sn: jensen
	-
	dn: cn=Babs Jensen,dc=example,dc=com
	changetype: modrdn
	newrdn: cn=Barbara J Jensen
	deleteoldrdn: 0
	newsuperior: ou=People,dc=example,dc=com
	dn: cn=Barbara J Jensen,ou=People,dc=example,dc=com
	changetype: delete
```

## INCLUDE STATEMENT
The LDIF parser has been extended to support an include statement for referencing other LDIF files. The include statement must be separated from other records by a blank line. The referenced file is specified using a file: URI and all of its contents are incorporated as if they were part of the original LDIF file. As above, other URI schemes may be supported. For example:

```
	dn: dc=example,dc=com
	objectclass: domain
	dc: example
	include: file:///tmp/example.com.ldif
	dn: dc=example,dc=org
	objectclass: domain
	dc: example
```

This feature is not part of the LDIF specification in RFC 2849 but is expected to appear in a future revision of this spec. It is supported by the ldapadd(1), ldapmodify(1), and slapadd(8) commands.

## SEE ALSO
ldap(3), ldapsearch(1), ldapadd(1), ldapmodify(1), slapadd(8), slapcat(8), slapd-ldif(5).

"LDAP Data Interchange Format," Good, G., RFC 2849.

## ACKNOWLEDGEMENTS
OpenLDAP Software is developed and maintained by The OpenLDAP Project <http://www.openldap.org/>. OpenLDAP Software is derived from the University of Michigan LDAP 3.3 Release.

branch: sisyphus


lloadd.conf

package: openldap-servers

title: lloadd.conf(5)

text:
# lloadd.conf(5)

## NAME
lloadd.conf - configuration file for lloadd, the stand-alone LDAP daemon

## SYNOPSIS
/etc/openldap/lloadd.conf

## DESCRIPTION
The file /etc/openldap/lloadd.conf contains configuration information for the lloadd(8)daemon.

The lloadd.conf file consists of a series of global configuration options that apply to lloadd as a whole (including all backends), followed by zero or more backend definitions that contain information specific how a backend instance should be contacted. The configuration options are case-insensitive; their value, on a case by case basis, may be case-sensitive.

The general format of lloadd.conf is as follows:

```
    # The following two lines should only be present if configured as a

    # slapd module:

    backend lload

    listen <URIs to be managed by lloadd>

    # comment - these options apply to the server as a whole

    <global configuration options>

    # first tier definition

    tier <strategy>

    # first backend definition

    backend-server <backend 1 definition>

    # subsequent backend/tier definitions

    ...
```

As many tiers and backend servers may be configured as desired.

If a line begins with white space, it is considered a continuation of the previous line. No physical line should be over 2000 bytes long.

Blank lines and comment lines beginning with a `#' character are ignored. Note: continuation lines are unwrapped before comment processing is applied.

Arguments on configuration lines are separated by white space. If an argument contains white space, the argument should be enclosed in double quotes. If an argument contains a double quote (`"') or a backslash character (`\'), the character should be preceded by a backslash character.

The specific configuration options available are discussed below in the Global Configuration Options and General Backend Options. Refer to the "OpenLDAP Administrator's Guide" for more details on the lloadd configuration file.

## SLAPD INTEGRATION
Note that when lloadd is configured as a slapd module, any option that shares the same name as an option in slapd.conf(5), the slapd interpretation wins and the lloadd option mentioned is unavailable through slapd.conf(5) directly, instead, it would have to be configured via a dedicated attribute in cn=config. In particular, unless the TLSShareSlapdCTX option is set, lloadd keeps its own TLS context which cannot be configured except through the dynamic configuration.

An additional option is available when running as a slapd module:

listen <listen URIs>

The URIs the Load Balancer module should listen on. Must not overlap with the ones that slapd uses for its own listening sockets. The related cn=config attribute is olcBkLloadListen with each URI provided as a separate value. No changes to this attribute made after the server has started up will take effect until it is restarted.

## GLOBAL CONFIGURATION OPTIONS
Options described in this section apply to all backends. Arguments that should be replaced by actual text are shown in brackets <>.

argsfile <filename>

The (absolute) name of a file that will hold the lloadd server's command line (program name and options).

concurrency <integer>

Specify a desired level of concurrency. Provided to the underlying thread system as a hint. The default is not to provide any hint.

feature <feature> [...]

Switch additional features supported by the LDAP Load Balancer on. Supported features are:

proxyauthz

when proxying an operation, pass the client's authorized identity using the proxy authorization control (RFC 4370). No control is added to the operation if initiated by a client whose bound identity matches the identity configured in bindconf (no normalisation of the DN is attempted). If SASL binds are issued by clients and this feature is enabled, backend servers need to support LDAP Who Am I? extended operation for the Load Balancer to detect the correct authorization identity.

include <filename>

Read additional configuration information from the given file before continuing with the next line of the current file.

io-threads <integer>

Specify the number of threads to use for the connection manager. The default is 1 and this is typically adequate for up to 16 CPU cores. The value should be set to a power of 2. If modified after server starts up, a change to this option will not take effect until the server has been restarted.

logfile <filename>

Specify a file for recording lloadd debug messages. By default these messages only go to stderr, are not recorded anywhere else, and are unrelated to messages exposed by the

logfile-format debug | syslog-utc | syslog-localtime

Specify the prefix format for messages written to the logfile. The debug format is the normal format used for slapd debug messages, with a timestamp in hexadecimal, followed by a thread ID. The other options are to use syslog(3) style prefixes, with timestamps either in UTC or in the local timezone. The default is debug format. loglevel configuration parameter. Specifying a logfile copies messages to both stderr and the logfile.

logfile-only on | off

Specify that debug messages should only go to the configured logfile, and not to stderr.

logfile-rotate <max> <Mbytes> <hours>

Specify automatic rotation for the configured logfile as the maximum number of old logfiles to retain, a maximum size in megabytes to allow a logfile to grow before rotation, and a maximum age in hours for a logfile to be used before rotation. The maximum number must be in the range 1-99. Setting Mbytes or hours to zero disables the size or age check, respectively. At least one of Mbytes or hours must be non-zero. By default no automatic rotation will be performed.

loglevel <integer> [...]

Specify the level at which debugging statements and operation statistics should be syslogged (currently logged to the syslogd(8) LOG_LOCAL4 facility). They must be considered subsystems rather than increasingly verbose log levels. Some messages with higher priority are logged regardless of the configured loglevel as soon as any logging is configured. Log levels are additive, and available levels are:

1

(0x1 trace) trace function calls

2

(0x2 packets) debug packet handling

4

(0x4 args) heavy trace debugging (function args)

8

(0x8 conns) connection management

16

(0x10 BER) print out packets sent and received

64

(0x40 config) configuration file processing

256

(0x100 stats) connections, LDAP operations, results (recommended)

512

(0x200 stats2) stats log entries sent

32768

(0x8000 none) only messages that get logged whatever log level is set

The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation, as a list of integers (that are ORed internally), or as a list of the names that are shown between parentheses, such that

```
    loglevel 513

    loglevel 0x201

    loglevel 512 1

    loglevel 0x200 0x1

    loglevel stats trace
```

are equivalent. The keyword any can be used as a shortcut to enable logging at all levels (equivalent to -1). The keyword none, or the equivalent integer representation, causes those messages that are logged regardless of the configured loglevel to be logged. In fact, if loglevel is set to 0, no logging occurs, so at least the none level is required to have high priority messages logged.

The loglevel defaults to stats. This level should usually also be included when using other loglevels, to help analyze the logs.

pidfile <filename>

The (absolute) name of a file that will hold the lloadd server's process ID (see getpid(2)).

sockbuf_max_incoming_client <integer>

Specify the maximum LDAP PDU size accepted coming from clients. The default is 262143.

sockbuf_max_incoming_upstream <integer>

Specify the maximum LDAP PDU size accepted coming from upstream connections. The default is 4194303.

tcp-buffer [listener=<URL>] [{read|write}=]<size>

Specify the size of the TCP buffer. A global value for both read and write TCP buffers related to any listener is defined, unless the listener is explicitly specified, or either the read or write qualifiers are used. See tcp(7) for details. Note that some OS-es implement automatic TCP buffer tuning.

threads <integer>

Specify the maximum size of the primary thread pool. The default is 16; the minimum value is 2.

threadqueues <integer>

Specify the number of work queues to use for the primary thread pool. The default is 1 and this is typically adequate for up to 8 CPU cores. The value should not exceed the number of CPUs in the system.

max_pdus_per_cycle <integer>

If set to 0, PDUs are handled by the I/O threads directly, otherwise a task is queued to be picked up by the thread pool. This task will process PDUs from the connection until there is no more data to be read or this limit is reached when the I/O thread can pick it up again. Very high values have a potential to cause some connections to be starved in a very high-bandwidth environment. The default is 1000.

client_max_pending <integer>

Will cause the load balancer to limit the number unfinished operations for each client connection. The default is 0, unlimited.

iotimeout <integer>

Specify the number of milliseconds to wait before forcibly closing a connection with an outstanding write. This allows faster recovery from various network hang conditions. An iotimeout of 0 disables this feature. The default is 10000.

write_coherence <integer>

Specify the number of seconds after a write operation is finished that lloadd will direct operations exclusively to the last selected backend. A write operation is anything not handled internally (certain exops, abandon), except search, compare and bind operations. Bind operations also reset this restriction. The default is 0, write operations do not restrict selection. When negative, the restriction is not time limited and will persist until the next bind.

restrict_exop <OID> <action>

Tell lloadd that extended operation with a given OID should be handled in a specific way. OID 1.1 is special, setting a default (only for operations not handled internally). The meaning of the <action> argument is the same as in restrict_control below.

restrict_control <OID> <action>

Tell lloadd that a control with a given OID attached to any operation should be handled in a specific way according to the <action> argument. At the moment, only operations passed intact are inspected in this way, in particular, controls on bind and extended operations are not checked. In order of descending priority (the control with highest priority action wins), this is the action made:

reject

operations that carry this control will be rejected.

connection

once an upstream is selected, every future operation from this client will be directed to the same connection. Useful when state is shared between client and upstream that the load balancer doesn't track.

backend

like write except this does not time out.

write

this is treated like a write operation (see write_coherence) above.

ignore

does not influence restrictions, useful when changing the global exop default. This is the default handling for exops/controls not handled by the load balancer internally.

## TLS OPTIONS
If lloadd is built with support for Transport Layer Security, there are more options you can specify.

TLSShareSlapdCTX { on | off }

If set to no (the default), lloadd will use its own TLS context (needs to be configured via cn=config unless lloadd is run as a standalone daemon). If enabled, the options for slapd apply instead, since the slapd's TLS context is used then.

The following options are available only when compiled as a standalone daemon. When compiled as a slapd(8) module, the cn=config equivalents need to be used if a separate TLS context for the module is needed, otherwise use the TLSShareSlapdCTX option.

TLSCipherSuite <cipher-suite-spec>

Permits configuring what ciphers will be accepted and the preference order. <cipher-suite-spec> should be a cipher specification for the TLS library in use (OpenSSL, GnuTLS, or Mozilla NSS). Example:

OpenSSL:

TLSCipherSuite HIGH:MEDIUM:+SSLv2

GnuTLS:

TLSCiphersuite SECURE256:!AES-128-CBC

To check what ciphers a given spec selects in OpenSSL, use:

```
	openssl ciphers -v <cipher-suite-spec>
```

With GnuTLS the available specs can be found in the manual page of gnutls-cli(1) (see the description of the option --priority).

In older versions of GnuTLS, where gnutls-cli does not support the option --priority, you can obtain the — more limited — list of ciphers by calling:

```
	gnutls-cli -l
```

When using Mozilla NSS, the OpenSSL cipher suite specifications are used and translated into the format used internally by Mozilla NSS. There isn't an easy way to list the cipher suites from the command line. The authoritative list is in the source code for Mozilla NSS in the file sslinfo.c in the structure

```
        static const SSLCipherSuiteInfo suiteInfo[]
```

TLSCACertificateFile <filename>

Specifies the file that contains certificates for all of the Certificate Authorities that lloadd will recognize. The certificate for the CA that signed the server certificate must be included among these certificates. If the signing CA was not a top-level (root) CA, certificates for the entire sequence of CA's from the signing CA to the top-level CA should be present. Multiple certificates are simply appended to the file; the order is not significant.

TLSCACertificatePath <path>

Specifies the path of a directory that contains Certificate Authority certificates in separate individual files. Usually only one of this or the TLSCACertificateFile is used. This directive is not supported when using GnuTLS. When using Mozilla NSS, <path> may contain a Mozilla NSS cert/key database. If <path> contains a Mozilla NSS cert/key database and CA cert files, OpenLDAP will use the cert/key database and will ignore the CA cert files.

TLSCertificateFile <filename>

Specifies the file that contains the lloadd server certificate. When using Mozilla NSS, if using a cert/key database (specified with TLSCACertificatePath), TLSCertificateFile specifies the name of the certificate to use:

```
	TLSCertificateFile Server-Cert
```

If using a token other than the internal built in token, specify the token name first, followed by a colon:

```
	TLSCertificateFile my hardware device:Server-Cert
```

Use certutil -L to list the certificates by name:

```
	certutil -d /path/to/certdbdir -L
```

TLSCertificateKeyFile <filename>

Specifies the file that contains the lloadd server private key that matches the certificate stored in the TLSCertificateFile file. Currently, the private key must not be protected with a password, so it is of critical importance that it is protected carefully. When using Mozilla NSS, TLSCertificateKeyFile specifies the name of a file that contains the password for the key for the certificate specified with TLSCertificateFile. The modutil command can be used to turn off password protection for the cert/key database. For example, if TLSCACertificatePath specifies /etc/openldap/certdb as the location of the cert/key database, use modutil to change the password to the empty string:

```
	modutil -dbdir /etc/openldap/certdb -changepw 'NSS Certificate DB'
```

You must have the old password, if any. Ignore the WARNING about the running browser. Press 'Enter' for the new password.

TLSDHParamFile <filename>

This directive specifies the file that contains parameters for Diffie-Hellman ephemeral key exchange. This is required in order to use a DSA certificate on the server, or an RSA certificate missing the "key encipherment" key usage. Note that setting this option may also enable Anonymous Diffie-Hellman key exchanges in certain non-default cipher suites. Anonymous key exchanges should generally be avoided since they provide no actual client or server authentication and provide no protection against man-in-the-middle attacks. You should append "!ADH" to your cipher suites to ensure that these suites are not used. When using Mozilla NSS these parameters are always generated randomly so this directive is ignored.

TLSECName <name>

Specify the name of a curve to use for Elliptic curve Diffie-Hellman ephemeral key exchange. This is required to enable ECDHE algorithms in OpenSSL. This option is not used with GnuTLS; the curves may be chosen in the GnuTLS ciphersuite specification. This option is also ignored for Mozilla NSS.

TLSProtocolMin <major>[.<minor>]

Specifies minimum SSL/TLS protocol version that will be negotiated. If the server doesn't support at least that version, the SSL handshake will fail. To require TLS 1.x or higher, set this option to 3.(x+1), e.g.,

```
	TLSProtocolMin 3.2
```

would require TLS 1.1. Specifying a minimum that is higher than that supported by the OpenLDAP implementation will result in it requiring the highest level that it does support. This directive is ignored with GnuTLS.

TLSRandFile <filename>

Specifies the file to obtain random bits from when /dev/[u]random is not available. Generally set to the name of the EGD/PRNGD socket. The environment variable RANDFILE can also be used to specify the filename. This directive is ignored with GnuTLS and Mozilla NSS.

TLSVerifyClient <level>

Specifies what checks to perform on client certificates in an incoming TLS session, if any. The <level> can be specified as one of the following keywords:

never

This is the default. lloadd will not ask the client for a certificate.

allow

The client certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, it will be ignored and the session proceeds normally.

try

The client certificate is requested. If no certificate is provided, the session proceeds normally. If a bad certificate is provided, the session is immediately terminated.

demand | hard | true

These keywords are all equivalent, for compatibility reasons. The client certificate is requested. If no certificate is provided, or a bad certificate is provided, the session is immediately terminated.

TLSCRLCheck <level>

Specifies if the Certificate Revocation List (CRL) of the CA should be used to verify if the client certificates have not been revoked. This requires TLSCACertificatePath parameter to be set. This directive is ignored with GnuTLS and Mozilla NSS. <level> can be specified as one of the following keywords:

none

No CRL checks are performed

peer

Check the CRL of the peer certificate

all

Check the CRL for a whole certificate chain

TLSCRLFile <filename>

Specifies a file containing a Certificate Revocation List to be used for verifying that certificates have not been revoked. This directive is only valid when using GnuTLS and Mozilla NSS.

## BACKEND CONFIGURATION
Options in this section describe how the lloadd connects and authenticates to the backend servers. Backends are organised in groups (tiers). Backends in the first tier are tried first, if none of them are reachable, the following tier is tried in the same way. If there is a backend in the tier that has suitable connections, but they are busy, no further tier is consulted. This is useful in high availability scenarios where a group of servers (e.g. the local environment) should be contacted if possible.

It is assumed all backend servers serve the same data. On startup, the configured connections are set up and those not dedicated to handle bind requests are authenticated with the backend using the information in the bindconf option. The authentication configuration is shared between them.

bindconf

[bindmethod=simple|sasl] [binddn=<dn>] [saslmech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<passwd>] [realm=<realm>] [secprops=<properties>] [timeout=<seconds>] [network-timeout=<seconds>] [keepalive=<idle>:<probes>:<interval>] [tcp-user-timeout=<milliseconds>] [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_protocol_min=<major>[.<minor>]] Specifies the bind credentials lloadd uses when setting up its regular connections to all backends.

A bindmethod of simple requires the options binddn and credentials and should only be used when adequate security services (e.g. TLS or IPSEC) are in place. REMEMBER: simple bind credentials must be in cleartext! A bindmethod of sasl requires the option saslmech. Depending on the mechanism, an authentication identity and/or credentials can be specified using authcid and credentials. The authzid parameter may be used to specify an authorization identity. Specific security properties (as with the sasl-secprops keyword above) for a SASL bind can be set with the secprops option. A non default SASL realm can be set with the realm option.

The timeout parameter indicates how long an operation can be pending a response (result, search entry, ...) from the server in seconds. Due to how timeouts are detected, the timeout might not be detected and handled up to timeout seconds after it happens.

The network-timeout parameter sets how long the consumer will wait to establish a network connection to the provider. Once a connection is established, the timeout parameter determines how long the consumer will wait for the initial Bind request to complete.

Timeout set to 0 means no timeout is in effect and by default, no timeouts are in effect.

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.

The tcp-user-timeout parameter, if non-zero, corresponds to the TCP_USER_TIMEOUT set on the upstream 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.

## TIER OPTIONS
tier

<tier type> Groups servers which should be considered in the same try. If a viable connection is found even if busy, the load balancer does not proceed to the next tier. The process of selection a connection within a tier depends on the tier's type.

Available types are:

roundrobin

Servers are tried in order and if one is selected successfully, the following search will try from the one next on the list.

weighted

Backend servers accept a new option weight=<int> which indicates how often it should be selected. If unspecified, weight defaults to 0 and such backends have a slight chance of being selected even when a non-zero weight backend is configured in the tier. The selection process is along the lines of RFC2782.

bestof

Like with weighted, backends accept the weight=<int> option. Average latency multiplied by weight is measured over time. The selection process chooses 2 backends at random, compares their weighted latencies and the backend with a better (lower) score is tried. If the backend is not available (or is busy), the other backend is tried, then backends are chosen in a round-robin order. Note that unlike weighted, the higher the weight, the higher the "effective" latency and lower the chance a backend is selected.

## BACKEND OPTIONS
backend-server

uri=ldap[s]://<hostname>[:port] [retry=<retry interval in ms>] [starttls=yes|critical] [numconns=<conns>] [bindconns=<conns>] [max-pending-ops=<ops>] [conn-max-pending=<ops>] Marks the beginning of a backend definition.

uri specifies the backend as an LDAP URI. If <port> is not given, the standard LDAP port number (389 or 636) is used.

Lloadd will attempt to maintain numconns active connections and also bindconns active connections dedicated to handling client bind requests.

If an error occurs on a working connection, a new connection attempt is made immediately, if one happens on establishing a new connection to this backend, lloadd will wait before a new reconnect attempt is made according to the retry parameter (default is 5 seconds).

Operations will be distributed across the backend's connections (upstreams).

The parameter conn-max-pending unless set to 0 (the default), will limit the number unfinished operations per upstream connection. Similarly, max-pending-ops will limit the total number or unfinished operations across all backend's connections, 0, the default, means no limit will be imposed for this backend.

The starttls parameter specifies use of the StartTLS extended operation to establish a TLS session before Binding to the provider. If the critical argument is supplied, the session will be aborted if the StartTLS request fails. Otherwise the syncrepl session continues without TLS. The tls_reqcert setting defaults to "demand" and the other TLS settings default to the same as the main slapd TLS settings.

## EXAMPLES
Here is a short example of a configuration file:

```
argsfile  /var/run/lloadd.args
pidfile   /var/run/lloadd.pid
# cancel not supported yet
restrict_exop 1.3.6.1.1.8 reject
# turn not supported
restrict_exop 1.3.6.1.1.19 reject
# TXN Exop if desired, otherwise reject
restrict_exop 1.3.6.1.1.21.1 connection
# Paged results control
restrict_control 1.2.840.113556.1.4.319 connection
# VLV control
restrict_control 2.16.840.1.113730.3.4.9 connection
bindconf

    bindmethod=simple

    binddn=cn=test

    credentials=pass
tier weighted
backend-server

    uri=ldap://ldap1.example.com

    numconns=3

    bindconns=2

    retry=5000

    max-pending-ops=5

    conn-max-pending=3

    weight=5
backend-server

    uri=ldap://ldap2.example.com

    numconns=3

    bindconns=2

    retry=5000

    max-pending-ops=5

    conn-max-pending=3

    weight=10
```

"OpenLDAP Administrator's Guide" contains a longer annotated example of a configuration file. The original /etc/openldap/lloadd.conf is another example.

## LIMITATIONS
Support for proxying SASL Binds is limited to the EXTERNAL mechanism (and only to extract the DN of a client TLS certificate if used during the last renegotiation) and mechanisms that rely neither on connection metadata (as Kerberos does) nor establish a SASL integrity/confidentialiy layer (again, some Kerberos mechanisms, DIGEST-MD5 can negotiate this).

## FILES
/etc/openldap/lloadd.conf

default lloadd configuration file

## SEE ALSO
ldap(3), gnutls-cli(1), slapd.conf(5), tcp(7), lloadd(8), slapd(8).

"OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)

## ACKNOWLEDGEMENTS
OpenLDAP Software is developed and maintained by The OpenLDAP Project <http://www.openldap.org/>. OpenLDAP Software is derived from the University of Michigan LDAP 3.3 Release.


slapd-asyncmeta

title: slapd-asyncmeta(5)

text:
# slapd-asyncmeta(5)

## NAME
slapd-asyncmeta - asynchronous metadirectory backend to slapd

## SYNOPSIS
/etc/openldap/slapd.conf

## DESCRIPTION
The asyncmeta backend to slapd(8) performs basic LDAP proxying with respect to a set of remote LDAP servers, called "targets". The information contained in these servers can be presented as belonging to a single Directory Information Tree (DIT).

A good knowledge of the functionality of the slapd-meta(5) backend is recommended. This backend has been designed as an asynchronous version of the meta backend. Unlike meta , the operation handling threads are no longer pending on the response from the remote server, thus decreasing the number of threads necessary to handle the same load. While asyncmeta maintains the functionality of meta and has a largely similar codebase, some changes in operation and some new configuration directives have been added. Some configuration options, such as conn-pool-max , conn-ttl , single-conn , and use-temporary-conn have been removed, as they are no longer relevant.

New connection handling:

Unlike meta, which caches bound connections, the asyncmeta works with a configured maximum number of connections per target. For each request redirected to a target, a different connection is selected. Each connection has a queue, to which the request is added before it is sent to the remote server, and is removed after the last response for that request is received.

For each new request, a new connection is chosen using round-robin scheduling.

Overlays:

Due to implementation specifics, there is no guarantee that any of the existing OpenLDAP overlays will work with asyncmeta backend.

## EXAMPLES
Refer to slapd-meta(5) for configuration examples.

## CONFIGURATION
These slapd.conf options apply to the ASYNCMETA backend database. That is, they must follow a "database asyncmeta" line and come before any subsequent "backend" or "database" lines. Other database options are described in the slapd.conf(5) manual page.

## SPECIAL CONFIGURATION DIRECTIVES
Target configuration starts with the "uri" directive. All the configuration directives that are not specific to targets should be defined first for clarity, including those that are common to all backends. They are:

default-target none

This directive forces the backend to reject all those operations that must resolve to a single target in case none or multiple targets are selected. They include: add, delete, modify, modrdn; compare is not included, as well as bind since, as they don't alter entries, in case of multiple matches an attempt is made to perform the operation on any candidate target, with the constraint that at most one must succeed. This directive can also be used when processing targets to mark a specific target as default.

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

This directive sets the time-to-live of the DN cache. This caches the target that holds a given DN to speed up target selection in case multiple targets would result from an uncached search; forever means cache never expires; disabled means no DN caching; otherwise a valid ( > 0 ) ttl is required, in the format illustrated for the idle-timeout directive.

onerr {CONTINUE|report|stop}

This directive allows one to select the behavior in case an error is returned by one target during a search. The default, continue, consists in continuing the operation, trying to return as much data as possible. If the value is set to stop, the search is terminated as soon as an error is returned by one target, and the error is immediately propagated to the client. If the value is set to report, the search is continued to the end but, in case at least one target returned an error code, the first non-success error code is returned.

max-timeout-ops <number>

Specify the number of consecutive timed out requests, after which the connection will be considered faulty and dropped.

max-pending-ops <number>

The maximum number of pending requests stored in a connection's queue. The default is 128. When this number is exceeded, LDAP_BUSY will be returned to the client.

max-target-conns <number>

The maximum number of connections per target. Unlike slapd-meta(5), no new connections will be created once this number is reached. The default value is 255.

norefs <NO|yes>

If yes, do not return search reference responses. By default, they are returned unless request is LDAPv2. If set before any target specification, it affects all targets, unless overridden by any per-target directive.

noundeffilter <NO|yes>

If yes, return success instead of searching if a filter is undefined or contains undefined portions. By default, the search is propagated after replacing undefined portions with (!(objectClass=*)), which corresponds to the empty result set. If set before any target specification, it affects all targets, unless overridden by any per-target directive.

protocol-version {0,2,3}

This directive indicates what protocol version must be used to contact the remote server. If set to 0 (the default), the proxy uses the same protocol version used by the client, otherwise the requested protocol is used. The proxy returns unwillingToPerform if an operation that is incompatible with the requested protocol is attempted. If set before any target specification, it affects all targets, unless overridden by any per-target directive.

pseudoroot-bind-defer {YES|no}

This directive, when set to yes, causes the authentication to the remote servers with the pseudo-root identity (the identity defined in each idassert-bind directive) to be deferred until actually needed by subsequent operations. Otherwise, all binds as the rootdn are propagated to the targets.

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

Turns on quarantine of URIs that returned LDAP_UNAVAILABLE, so that an attempt to reconnect only occurs at given intervals instead of any time a client requests an operation. The pattern is: retry only after at least interval seconds elapsed since last attempt, for exactly num times; then use the next pattern. If num for the last pattern is "+", it retries forever; otherwise, no more retries occur. This directive must appear before any target specification; it affects all targets with the same pattern.

rebind-as-user {NO|yes}

If this option is given, the client's bind credentials are remembered for rebinds, when trying to re-establish a broken connection, or when chasing a referral, if chase-referrals is set to yes.

session-tracking-request {NO|yes}

Adds session tracking control for all requests. The client's IP and hostname, and the identity associated to each request, if known, are sent to the remote server for informational purposes. This directive is incompatible with setting protocol-version to 2. If set before any target specification, it affects all targets, unless overridden by any per-target directive.

## TARGET SPECIFICATION
Target specification starts with a "uri" directive:

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

Identical to meta. See slapd-meta(5) for details.

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. See slapd-meta(5) for details.

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. See slapd-meta(5) for details.

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=<names>] [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. See slapd-meta(5) for details.

idle-timeout <time>

This directive causes a a persistent connection to be dropped after it has been idle for the specified time. The connection will be re-created the next time it is selected for use. A connection is considered idle if no attempts have been made by the backend to use it to send a request to the backend server. If there are still pending requests in its queue, the connection will be dropped after the last request one has either received a result or has timed out. [<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 while sending an operation to the remote target. The value is in milliseconds, 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 forwarding an operation should be retried in case of temporary failure in contacting a target. The number of retries is per operation, so if a bind to the target is necessary first, the remaining number is decremented. 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.

subtree-{exclude|include} <rule>

This directive allows one to indicate what subtrees are actually served by a target. See slapd-meta(5) for details.

suffixmassage <local suffix> <remote suffix>

slapd-asyncmeta does not support the rewrite engine used by the LDAP and META backends. suffixmassage can be used to perform DN suffix rewriting, the same way as the obsoleted suffixmassage directive previously used by the LDAP backend.

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

By default, the timeout for all operations is 2 seconds.

See slapd-meta(5) for details.

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

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

With propagate, the proxy issues the StartTLS operation only if the original connection has a TLS layer set up. The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is not recommended.

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.

## SCENARIOS
See slapd-meta(5) for configuration scenarios.

## ACLs
ACL behavior is identical to meta. See slapd-meta(5).

## ACCESS CONTROL
The asyncmeta backend does not honor all ACL semantics as described in slapd.access(5). In general, access checking is delegated to the remote server(s). Only read (=r) access to the entry pseudo-attribute and to the other attribute values of the entries returned by the search operation is honored, which is performed by the frontend.

## FILES
/etc/openldap/slapd.conf

default slapd configuration file

## SEE ALSO
slapd.conf(5), slapd-ldap(5), slapd-meta(5), slapo-pcache(5), slapd(8), regex(7), re_format(7).

## AUTHOR
Nadezhda Ivanova, based on back-meta by Pierangelo Masarati.