slapo-translucent(5) — Linux manual page


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

NAME         top

       slapo-translucent - Translucent Proxy overlay to slapd

SYNOPSIS         top


DESCRIPTION         top

       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.


       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

              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

       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

              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

ACCESS CONTROL         top

       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         top

       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

FILES         top

              default slapd configuration file

SEE ALSO         top

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

COLOPHON         top

       This page is part of the OpenLDAP (an open source implementation of
       the Lightweight Directory Access Protocol) project.  Information
       about the project can be found at ⟨⟩.  If you
       have a bug report for this manual page, see
       ⟨⟩.  This page was obtained from the
       project's upstream Git repository
       ⟨⟩ on 2020-11-01.  (At
       that time, the date of the most recent commit that was found in the
       repository was 2020-10-30.)  If you discover any rendering problems
       in this HTML version of the page, or you believe there is a better or
       more up-to-date source for the page, or you have corrections or im‐
       provements to the information in this COLOPHON (which is not part of
       the original manual page), send a mail to


Pages that refer to this page: slapd-ldap(5)slapd.overlays(5)