Ubuntu Manpage: slapo-translucent - Translucent Proxy overlay to slapd

Provided by: slapd_2.6.9+dfsg-2ubuntu1_amd64

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-mdb(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 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.

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

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 identity
       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