SLAPO-TRANSLUCENT(5)						File Formats Manual					      SLAPO-TRANSLUCENT(5)

NAME

       slapo-translucent - Translucent Proxy overlay to slapd

SYNOPSIS

       /etc/ldap/slapd.conf

DESCRIPTION

       The  Translucent Proxy overlay can be used with a backend database such as slapd-bdb(5) to create a "translucent proxy".  Entries retrieved
       from a remote LDAP server may have some or all attributes overridden, or new attributes added, by entries  in  the  local  database  before
       being presented to the client.

       A  search  operation  is  first	populated  with  entries from the remote LDAP server, the attributes of which are then overridden with any
       attributes defined in the local database. Local overrides may be populated with the add, modify , and modrdn operations, the use  of  which
       is restricted to the root user.

       A  compare  operation will perform a comparison with attributes defined in the local database record (if any) before any comparison is made
       with data in the remote database.

CONFIGURATION

       The Translucent Proxy overlay uses a proxied database, typically a (set of) remote LDAP server(s), which is  configured	with  the  options
       shown in slapd-ldap(5), slapd-meta(5) or similar.  These slapd.conf options are specific to the Translucent Proxy overlay; they must appear
       after the overlay directive that instantiates the translucent overlay.

       translucent_strict
	      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.

       translucent_no_glue
	      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.

       translucent_local <attr[,attr...]>
	      Specify a list of attributes that should be searched for in the local database when used in a search filter. By default, search fil-
	      ters 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.

       translucent_remote <attr[,attr...]>
	      Specify a list of attributes that should be searched for in the remote database when used in a search filter. This directive comple-
	      ments the translucent_local directive. Attributes may be specified as both local and remote if desired.

       If  neither translucent_local nor 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  translu-
       cent_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.

       translucent_bind_local
	      Enable looking for locally stored credentials for simple bind when binding to the remote database fails.	Disabled by default.

       translucent_pwmod_local
	      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

       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 iden-
       tity the operation is performed as.  As a consequence, local rules might only be allowed to see a portion of the remote data.

CAVEATS

       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.

FILES

       /etc/ldap/slapd.conf
	      default slapd configuration file

SEE ALSO

       slapd.conf(5), slapd-config(5), slapd-ldap(5).

OpenLDAP							    2012/04/23						      SLAPO-TRANSLUCENT(5)