Provided by: slapd_2.4.42+dfsg-2ubuntu3.13_amd64 bug


       slapo-translucent - Translucent Proxy overlay to slapd




       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.


       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.

              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

       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.

              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


       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.


              default slapd configuration file


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