|By default, attempts to delete attributes in either the local or remote databases will be silently ignored. The translucent_strict directive causes these modifications to fail with a Constraint Violation.|
|This configuration option disables the automatic creation of "glue" records for an add or modrdn operation, such that all parents of an entry added to the local database must be created by hand. Glue records are always created for a modify operation.|
|Specify a list of attributes that should be searched for in the local database when used in a search filter. By default, search filters are only handled by the remote database. With this directive, search filters will be split into a local and remote portion, and local attributes will be searched locally.|
|Specify a list of attributes that should be searched for in the remote database when used in a search filter. This directive complements the translucent_local directive. Attributes may be specified as both local and remote if desired.|
translucent_remote are specified, the default behavior is to search the remote database with the
complete search filter. If only
translucent_local is specified, searches will only be run on the local database. Likewise, if only
translucent_remote is specified, searches will only be run on the remote database. In any case, both
the local and remote entries corresponding to a search result will be merged
before being returned to the client.
Enable looking for locally stored credentials for simple bind when binding
to the remote database fails. Disabled by default.
Enable RFC 3062 Password Modification extended operation on locally stored
credentials. The operation only applies to entries that exist in the remote
database. Disabled by default.
Access control is delegated to either the remote DSA(s) or to the local database backend for auth and write operations. It is delegated to the remote DSA(s) and to the frontend for read operations. Local access rules involving data returned by the remote DSA(s) should be designed with care. In fact, entries are returned by the remote DSA(s) only based on the remote fraction of the data, based on the identity the operation is performed as. As a consequence, local rules might only be allowed to see a portion of the remote data.
The Translucent Proxy overlay will disable schema checking in the local database, so that an entry consisting of overlay attributes need not adhere to the complete schema.
Because the translucent overlay does not perform any DN rewrites, the local and remote database instances must have the same suffix. Other configurations will probably fail with No Such Object and other errors.
/usr/local/etc/openldap/slapd.conf default slapd configuration file
|OpenLDAP 2.4.44||SLAPO-TRANSLUCENT (5)||2016/02/05|