перезаписать / переназначить оверлей на slapd  (rewrite/remap overlay to slapd)
  
MAPPING
An important feature of the rwm overlay is the capability to map
       objectClasses and attributeTypes from the local set (or a subset
       of it) to a foreign set, and vice versa.  This is accomplished by
       means of the rwm-map directive.
       rwm-map {attribute | objectclass} [<local name> | *] {<foreign
       name> | *}
              Map attributeTypes and objectClasses from the foreign
              server to different values on the local slapd.  The reason
              is that some attributes might not be part of the local
              slapd's schema, some attribute names might be different
              but serve the same purpose, etc.  If local or foreign name
              is `*', the name is preserved.  If local name is omitted,
              the foreign name is removed.  Unmapped names are preserved
              if both local and foreign name are `*', and removed if
              local name is omitted and foreign name is `*'.
       The local objectClasses and attributeTypes must be defined in the
       local schema; the foreign ones do not have to, but users are
       encouraged to explicitly define the remote attributeTypes and the
       objectClasses they intend to map.  All in all, when remapping a
       remote server via back-ldap (slapd-ldap(5)) or back-meta (‐
       slapd-meta(5)) their definition can be easily obtained by
       querying the subschemaSubentry of the remote server; the problem
       should not exist when remapping a local database.  Note, however,
       that the decision whether to rewrite or not attributeTypes with
       distinguishedName syntax, requires the knowledge of the
       attributeType syntax.  See the REWRITING section for details.
       Note that when mapping DN-valued attributes from local to remote,
       first the DN is rewritten, and then the attributeType is mapped;
       while mapping from remote to local, first the attributeType is
       mapped, and then the DN is rewritten.  As such, it is important
       that the local attributeType is appropriately defined as using
       the distinguishedName syntax.  Also, note that there are DN-
       related syntaxes (i.e. compound types with a portion that is DN-
       valued), like nameAndOptionalUID, whose values are currently not
       rewritten.
       If the foreign type of an attribute mapping is not defined on the
       local server, it might be desirable to have the attribute values
       normalized after the mapping process. Not normalizing the values
       can lead to wrong results, when the rwm overlay is used together
       with e.g. the pcache overlay. This normalization can be enabled
       by means of the rwm-normalize-mapped-attrs directive.
       rwm-normalize-mapped-attrs {yes|no}
              Set this to "yes", if the rwm overlay should try to
              normalize the values of attributes that are mapped from an
              attribute type that is unknown to the local server. The
              default value of this setting is "no".
       rwm-drop-unrequested-attrs {yes|no}
              Set this to "yes", if the rwm overlay should drop
              attributes that are not explicitly requested by a search
              operation.  When this is set to "no", the rwm overlay will
              leave all attributes in place, so that subsequent modules
              can further manipulate them.  In any case, unrequested
              attributes will be omitted from search results by the
              frontend, when the search entry response package is
              encoded.  The default value of this setting is "yes".