SLAPO-RWM(5)

okay bestie, welcome to the SLAPO-RWM(5) man page, straight from the File Formats Manual section. it's all about the rwm overlay for slapd — and no cap, it's a whole vibe. it lets you rewrite and remap stuff like DNs and objectClasses/attributeTypes. let's get into it 💖✨

---

✨ NAME ✨

slapo-rwm — the rewrite/remap overlay to slapd. periodt. 💖

---

✨ SYNOPSIS ✨

/etc/openldap/slapd.conf

---

✨ DESCRIPTION ✨

The rwm overlay to slapd(8) does basic DN/data rewrite and objectClass/attributeType mapping. it's mostly used to give you virtual views of existing data, either remotely (with the proxy backend from slapd-ldap(5)) or locally (with the relay backend from slapd-relay(5)). 🦋

⚠️ heads up bestie: this overlay is experimental. no cap, it's still in its testing era. 💀

---

✨ MAPPING ✨

One of the main character features of the rwm overlay is mapping objectClasses and attributeTypes from your local set (or a subset) to a foreign set, and vice versa. it's done with the rwm-map directive. slay. ✨

• rwm-map {attribute | objectclass} [<local name> | *] {<foreign name> | *} — map attributeTypes and objectClasses from the foreign server to different values on your local slapd. why? because some attributes might not be in your local schema, or the names are different but do the same thing, etc. if the local or foreign name is *, the name stays as is. if the local name is omitted, the foreign name gets removed. unmapped names are preserved if both local and foreign names are *, and removed if the local name is omitted and the foreign name is *.

The local objectClasses and attributeTypes must be defined in your local schema. the foreign ones don't have to be, but you're encouraged to explicitly define the remote attributeTypes and objectClasses you plan to map. anyway, when you're remapping a remote server via back-ldap (slapd-ldap(5)) or back-meta (slapd-meta(5)), you can easily get their definition by querying the subschemaSubentry of the remote server. when remapping a local database, that problem shouldn't exist. but heads up: deciding whether to rewrite attributeTypes with distinguishedName syntax requires knowing the attributeType syntax. see the REWRITING section for details. 🧚

Also, when mapping DN-valued attributes from local to remote, first the DN is rewritten, then the attributeType is mapped. when mapping from remote to local, it's the other way around: first the attributeType is mapped, then the DN is rewritten. so it's important that your local attributeType is properly defined as using the distinguishedName syntax. and note: there are DN-related syntaxes (like compound types with a DN-valued portion), such as nameAndOptionalUID, whose values are currently not rewritten. 🙈

If the foreign type of an attribute mapping isn't defined on your local server, you might want to normalize the attribute values after mapping. not normalizing can lead to wrong results, especially when rwm is used with e.g. the pcache overlay. you can turn this on with 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 unknown to the local server. default is "no". 💅
• rwm-drop-unrequested-attrs {yes|no} — set this to "yes" if rwm should drop attributes not explicitly requested by a search operation. if it's "no", rwm leaves all attributes in place so later modules can manipulate them. either way, unrequested attributes will be omitted from search results by the frontend when the search entry response package is encoded. default is "yes". ✨

---

✨ SUFFIX MASSAGING ✨

A basic feature of rwm is suffix massaging between a virtual and a real naming context, via the rwm-suffixmassage directive. this, together with proxy backends slapd-ldap(5) and slapd-meta(5), or the relay backend slapd-relay(5), lets you create virtual views of databases. a distinguishing feature: when instantiated before any database, it can modify the DN of requests before database selection. for this reason, rules that rewrite the empty DN ("") or the subschemaSubentry DN (usually "cn=subschema") would prevent clients from reading the root DSE or the DSA's schema. 😭

• rwm-suffixmassage [<virtual naming context>] <real naming context> — shortcut to implement naming context rewriting. the trailing part of the DN is rewritten from the virtual to the real naming context in the bindDN, searchDN, searchFilterAttrDN, compareDN, compareAttrDN, addDN, addAttrDN, modifyDN, modifyAttrDN, modrDN, newSuperiorDN, deleteDN, exopPasswdDN rewrite contexts, and from the real to the virtual naming context in the searchEntryDN, searchAttrDN and matchedDN rewrite contexts. by default, no rewriting happens for the searchFilter and for the referralAttrDN and referralDN rewrite contexts. if no <virtual naming context> is given, the first suffix of the database is used — this requires the rwm-suffixmassage directive to be defined after the database suffix directive. the rwm-suffixmassage directive automatically sets rwm-rewriteEngine to ON. 🔥

see the REWRITING section for details. 💖

---

✨ REWRITING ✨

A string gets rewritten according to a set of rules, called a rewrite context. the rules are based on POSIX (''extended'') regular expressions with substring matching. basic variable substitution and map resolution of substrings are allowed by specific mechanisms detailed below. the behavior of pattern matching/substitution can be changed by a set of flags. 💅

<rewrite context> ::= <rewrite rule> [...]
<rewrite rule> ::= <pattern> <action> [<flags>]

The whole idea is to build a lightweight rewrite module for the slapd server (initially dedicated to the LDAP backend): 🧚

✨ Passes ✨

An incoming string is matched against a set of rewriteRules. rules are made of a regex match pattern, a substitution pattern, and a set of actions described by optional flags. if there's a match, string rewriting happens according to the substitution pattern, which lets you refer to substrings matched in the incoming string. the actions (if any) are finally performed. each rule is executed recursively unless altered by specific action flags; see "Action Flags" for details. there's a default limit on recursion level, and you can change it with the rwm-rewriteMaxPasses directive, as detailed in the "Additional Configuration Syntax" section. the substitution pattern allows map resolution of substrings. a map is a generic object that maps a substitution pattern to a value. the flags are divided into "Pattern Matching Flags" and "Action Flags"; the former alter the regex match pattern behavior, while the latter alter the actions taken after substitution. ✨

✨ Pattern Matching Flags ✨

• C — honors case in matching (default is case insensitive). 💅
• R — use POSIX ''basic'' regular expressions (default is ''extended''). 🦋
• M{n} — allow no more than n recursive passes for a specific rule; does not alter the max total count of passes, so it can only enforce a stricter limit for a specific rule. 🌸

✨ Action Flags ✨

• : — apply the rule once only (default is recursive). 💖
• @ — stop applying rules in case of match; the current rule is still applied recursively; combine with : to apply the current rule only once and then stop. 😭
• # — stop current operation if the rule matches, and issue an unwilling to perform error. 💀
• G{n} — jump n rules back and forth (watch for loops!). note that G{1} is implicit in every rule. 🔥
• I — ignores errors in rule; this means, in case of error, e.g. issued by a map, the error is treated as a missed match. the unwilling to perform is not overridden. 🙈
• U{n} — uses n as return code if the rule matches; the flag does not alter the recursive behavior of the rule, so to have it performed only once, it must be used in combination with :, e.g. :U{32} returns the value 32 (indicating noSuchObject) after exactly one execution of the rule, if the pattern matches. as a consequence, its behavior is equivalent to @, with the return code set to n; or, in other words, @ is equivalent to U{0}. positive errors are allowed, indicating the related LDAP error codes as specified in RFC4511. ✨

The ordering of the flags can be significant. for instance: IG{2} means ignore errors and jump two lines ahead both in case of match and in case of error, while G{2}I means ignore errors, but jump two lines ahead only in case of match. 👑

More flags (mainly Action Flags) will be added as needed. 💅

✨ Pattern Matching ✨

See regex(7) and/or re_format(7). 🌈

✨ Substitution Pattern Syntax ✨

okay bestie, grab your iced coffee because the $ is about to become your whole personality 💅 anything that starts with $ is asking for a substitution — no cap.

the one glaring exception, and honestly it's pretty obvious: $$ — that one just turns into a single $. tiny. iconic. moving on 🎀

the basic substitution is $<d>, where <d> is a digit. 0 means the whole string, while 1-9 is a submatch, exactly like regex(7) and/or re_format(7) explain it. iykyk.

and now the glow-up: a $ followed by a { invokes an advanced substitution 🦋 the pattern is:

`$' `{' [ <operator> ] <name> `(' <substitution> `)' `}'

where <name> must be a legal name for the map, i.e.

<name> ::= [a-z][a-z0-9]* (case insensitive)
<operator> ::= `>' `|' `&' `&&' `*' `**` `$'

and <substitution> must be a legal substitution pattern, with no limits on the nesting level — girl, nest as deep as you want, it's giving inception 🌀

The operators are:

• > — sub-context invocation; <name> must be a legal, already defined rewrite context name
• | — external command invocation; <name> must refer to a legal, already defined command name (NOT IMPLEMENTED YET)
• & — variable assignment; <name> defines a variable in the running operation structure which can be dereferenced later; operator & assigns a variable in the rewrite context scope; operator && assigns a variable that scopes the entire session, e.g. its value can be dereferenced later by other rewrite contexts 👑
• * — variable dereferencing; <name> must refer to a variable that is defined and assigned for the running operation; operator * dereferences a variable scoping the rewrite context; operator ** dereferences a variable scoping the whole session, e.g. the value is passed across rewrite contexts 💫
• $ — parameter dereferencing; <name> must refer to an existing parameter; the whole idea is to make some run-time parameters set by the system available to the rewrite engine, as the client host name, the bind DN if any, constant parameters initialized at config time, and so on; no parameter is currently set by either back-ldap or back-meta, but constant parameters can be defined in the configuration file by using the rewriteParam directive ✨

Now, the escaping tea ☕ — substitution escaping has been delegated to the $ symbol, which is used instead of \ in string substitution patterns because \ is already escaped by slapd's low level parsing routines 🙈 and as a consequence, regex escaping requires two \ symbols — e.g. .*\.foo\.bar must be written as .*\\.foo\\.bar. yes fr fr. double it. 💀

---

🌀 Rewrite Context 🌀

A rewrite context is a set of rules which are applied in sequence. The vibe is: an application initializes a rewrite engine (think of Apache's mod_rewrite ...) with a set of rewrite contexts; then whenever string rewriting is required, you invoke the appropriate rewrite context with the input string and you get the newly rewritten one back, if no errors occur. slay. 🔥

Each basic server operation is associated to a rewrite context; they're split into two main groups: client -> server and server -> client rewriting.

client -> server:

• (default) — if defined and no specific context is available
• bindDN — bind
• searchDN — search
• searchFilter — search
• searchFilterAttrDN — search
• compareDN — compare
• compareAttrDN — compare AVA
• addDN — add
• addAttrDN — add AVA (DN portion of "ref" excluded)
• modifyDN — modify
• modifyAttrDN — modify AVA (DN portion of "ref" excluded)
• referralAttrDN — add/modify DN portion of referrals (default to none)
• renameDN — modrdn (the old DN)
• newSuperiorDN — modrdn (the new parent DN, if any)
• newRDN — modrdn (the new relative DN)
• deleteDN — delete
• exopPasswdDN — password modify extended operation DN

server -> client:

• searchEntryDN — search (only if defined; no default; acts on DN of search entries)
• searchAttrDN — search AVA (only if defined; defaults to searchEntryDN; acts on DN-syntax attributes of search results)
• matchedDN — all ops (only if applicable; defaults to searchEntryDN)
• referralDN — all ops (only if applicable; defaults to none)

---

🛠️ Basic Configuration Syntax 🛠️

Heads up: all rewrite/remap directives start with the prefix rwm- 💅

• rwm-rewriteEngine { on | off } — if on, the requested rewriting is performed; if off, no rewriting takes place (an easy way to stop rewriting without altering too much the configuration file) 🙈
• rwm-rewriteContext <context name> [ alias <aliased context name> ] — <context name> is the name that identifies the context, i.e. the name used by the application to refer to the set of rules it contains. It's also used to reference sub contexts in string rewriting. A context may alias another one — in that case the alias context contains no rule, and any reference to it will result in accessing the aliased one. it's giving ✨pass-through energy✨
• rwm-rewriteRule <regex match pattern> <substitution pattern> [ <flags> ] — determines how a string can be rewritten if a pattern is matched. Examples are reported below (iykyk, keep reading 👀)

---

➕ Additional Configuration Syntax ➕

• rwm-rewriteMap <map type> <map name> [ <map attrs> ] — allows one to define a map that transforms substring rewriting into something else. The map is referenced inside the substitution pattern of a rule 🗺️
• rwm-rewriteParam <param name> <param value> — sets a value with global scope, that can be dereferenced by the command ${$paramName}. global queen behavior 👑
• rwm-rewriteMaxPasses <number of passes> [<number of passes per rule>] — sets the maximum number of total rewriting passes that can be performed in a single rewrite operation (to avoid loops 🌀). A safe default is set to 100; note that reaching this limit is still treated as a success — recursive invocation of rules is simply interrupted, no drama. The count applies to the rewriting operation as a whole, not to any single rule; an optional per-rule limit can be set. This limit is overridden by setting specific per-rule limits with the M{n} flag. 💅

---

🗺️ MAPS 🗺️

Currently, few maps are builtin but additional map types may be registered at runtime. the roster is growing, bestie 🫶

Supported maps are:

• LDAP <URI> [bindwhen=<when>] [version=<version>] [binddn=<DN>] [credentials=<cred>] — the LDAP map expands a value by performing a simple LDAP search. Its configuration is based on a mandatory URI, whose attrs portion must contain exactly one attribute (use entryDN to fetch the DN of an entry). If a multi-valued attribute is used, only the first value is considered. ngl, the rest get left on read.

The parameter bindwhen determines when the connection is established. It can take the values now, later, and everytime, respectively indicating that the connection should be created at startup, when required, or any time it is used. In the former two cases, the connection is cached, while in the latter a fresh new one is used all times. This is the default. (yes, everytime is the main character here 💅)

The parameters binddn and credentials represent the DN and the password that is used to perform an authenticated simple bind before performing the search operation; if not given, an anonymous connection is used. anonymous mode, no identity, we love a mystery 🎭

The parameter version can be 2 or 3 to indicate the protocol version that must be used. The default is 3. ✨

• slapd <URI> — the slapd map expands a value by performing an internal LDAP search. Its configuration is based on a mandatory URI, which must begin with ldap:/// (i.e., it must be an LDAP URI and it must not specify a host). As with the LDAP map, the attrs portion must contain exactly one attribute, and if a multi-valued attribute is used, only the first value is considered. internal search, so lowkey intimate 🔍
• escape [escape2dn|escape2filter|unescapedn|unescapefilter]... — the escape map makes it possible use DNs or their parts in filter strings and vice versa. It processes a value according to the operations listed in order. Supported operations include:
  • escape2dn — takes a string and escapes it so it can safely be pasted in a DN
  • escape2filter — takes a string and escapes it so it can safely be pasted in a filter
  • unescapedn — takes a string and undoes DN escaping
  • unescapefilter — takes a string and undoes filter escaping

It is advised that each escape map ends with an escape operation as that is the only safe way to handle arbitrary strings. 🚨 like genuinely, bestie, end it on an escape — that's the only safe way to handle arbitrary strings, periodt.

💖 REWRITE CONFIGURATION EXAMPLES 💖

okay bestie, this is the part where it all comes together. real receipts. actual config. grab a snack 🍓 because this is a whole saga and every single line matters. the comments inside the code are part of the package deal, so i'm leaving them exactly where they are — they're lowkey the narrator of this whole story. 💅

# set to `off' to disable rewriting
rwm-rewriteEngine on

# the rules the "suffixmassage" directive implies
rwm-rewriteEngine on
# all dataflow from client to server referring to DNs
rwm-rewriteContext default
rwm-rewriteRule "(.+,)?<virtualnamingcontext>$" "$1<realnamingcontext>" ":"
# empty filter rule
rwm-rewriteContext searchFilter
# all dataflow from server to client
rwm-rewriteContext searchEntryDN
rwm-rewriteRule "(.+,)?<realnamingcontext>$" "$1<virtualnamingcontext>" ":"
rwm-rewriteContext searchAttrDN alias searchEntryDN
rwm-rewriteContext matchedDN alias searchEntryDN
# misc empty rules
rwm-rewriteContext referralAttrDN
rwm-rewriteContext referralDN

# Everything defined here goes into the `default' context.
# This rule changes the naming context of anything sent
# to `dc=home,dc=net' to `dc=OpenLDAP, dc=org'

rwm-rewriteRule "(.+,)?dc=home,[ ]?dc=net$"
            "$1dc=OpenLDAP, dc=org"  ":"

# since a pretty/normalized DN does not include spaces
# after rdn separators, e.g. `,', this rule suffices:

rwm-rewriteRule "(.+,)?dc=home,dc=net$"
            "$1dc=OpenLDAP,dc=org"  ":"

# Start a new context (ends input of the previous one).
# This rule adds blanks between DN parts if not present.
rwm-rewriteContext  addBlanks
rwm-rewriteRule     "(.*),([^ ].*)" "$1, $2"

# This one eats blanks
rwm-rewriteContext  eatBlanks
rwm-rewriteRule     "(.*), (.*)" "$1,$2"

# Here control goes back to the default rewrite
# context; rules are appended to the existing ones.
# anything that gets here is piped into rule `addBlanks'
rwm-rewriteContext  default
rwm-rewriteRule     ".*" "${>addBlanks($0)}" ":"

# Rewrite the search base according to `default' rules.
rwm-rewriteContext  searchDN alias default

# Search results with OpenLDAP DN are rewritten back with
# `dc=home,dc=net' naming context, with spaces eaten.
rwm-rewriteContext  searchEntryDN
rwm-rewriteRule     "(.*[^ ],)?[ ]?dc=OpenLDAP,[ ]?dc=org$"
                "${>eatBlanks($1)}dc=home,dc=net"    ":"

# Transform a DN value such that it can be used in a filter
rwm-rewriteMap escape dn2filter unescapedn escape2filter

# Bind with email instead of full DN: we first need
# an ldap map that turns attributes into a DN (the
# argument used when invoking the map is appended to
# the URI and acts as the filter portion)
rwm-rewriteMap ldap attr2dn "ldap://host/dc=my,dc=org?dn?sub"

# Then we need to detect DN made up of a single email,
# e.g. `mail=someone@example.com'; note that the rule
# in case of match stops rewriting; in case of error,
# it is ignored.  In case we are mapping virtual
# to real naming contexts, we also need to rewrite
# regular DNs, because the definition of a bindDN
# rewrite context overrides the default definition.
#
# While actual email addresses tend not to contain filter
# special characters, the provided Bind DN has no such
# restrictions.
rwm-rewriteContext bindDN
rwm-rewriteRule "^(mail=)([^,]+@[^,]+)$"
                "${attr2dn($1${dn2filter($2)})}" ":@I"

# This is a rather sophisticated example. It massages a
# search filter in case who performs the search has
# administrative privileges.  First we need to keep
# track of the bind DN of the incoming request, which is
# stored in a variable called `binddn' with session scope,
# and left in place to allow regular binding:
rwm-rewriteContext  bindDN
rwm-rewriteRule     ".+" "${&&binddn($0)}$0" ":"

# A search filter containing `uid=' is rewritten only
# if an appropriate DN is bound.
# To do this, in the first rule the bound DN is
# dereferenced, while the filter is decomposed in a
# prefix, in the value of the `uid=<arg>' AVA, and
# in a suffix. A tag `<>' is appended to the DN.
# If the DN refers to an entry in the `ou=admin' subtree,
# the filter is rewritten OR-ing the `uid=<arg>' with
# `cn=<arg>'; otherwise it is left as is. This could be
# useful, for instance, to allow apache's auth_ldap-1.4
# module to authenticate users with both `uid' and
# `cn', but only if the request comes from a possible
# `cn=Web auth,ou=admin,dc=home,dc=net' user.
rwm-rewriteContext searchFilter
rwm-rewriteRule "(.*\\()uid=([a-z0-9_]+)(\\).*)"
  "${**binddn}<>${&prefix($1)}${&arg($2)}${&suffix($3)}"
  ":I"
rwm-rewriteRule "^[^,]+,ou=admin,dc=home,dc=net$"
  "${*prefix}|(uid=${*arg})(cn=${*arg})${*suffix}" ":@I"
rwm-rewriteRule ".*<>$" "${*prefix}uid=${*arg}${*suffix}" ":"

# This example shows how to strip unwanted DN-valued
# attribute values from a search result; the first rule
# matches DN values below "ou=People,dc=example,dc=com";
# in case of match the rewriting exits successfully.
# The second rule matches everything else and causes
# the value to be rejected.
rwm-rewriteContext searchEntryDN
rwm-rewriteRule ".+,ou=People,dc=example,dc=com$" "$0" ":@"
rwm-rewriteRule ".*" "" "#"

---

🦋 MAPPING EXAMPLES 🦋

and now the glow-up section ✨ these lil directives below are doing a whole identity transformation: the object class groupOfNames becomes groupOfUniqueNames, and the attribute type member becomes uniqueMember. it's giving makeover montage, fr fr. 💅

map objectclass groupOfNames groupOfUniqueNames
map attribute uniqueMember member

and this one? this one presents a limited attribute set from the foreign server. it's on a strict little diet:

map attribute cn *
map attribute sn *
map attribute manager *
map attribute description *
map attribute *

so what's the tea 🫖 — these lines map cn, sn, manager, and description to themselves (self-love, we stan), and literally any other attribute gets "removed" from the object before it's sent to the client (or sent up to the LDAP server). yes, bestie, the original put "removed" in quotes like that and we are keeping the quotes because they're iconic. it's an obviously simplistic example, but you get the point. no cap. 💖

---

🎀 FILES 🎀

• /etc/openldap/slapd.conf — the default slapd configuration file. the O.G. spot. 🏠

---

🌸 SEE ALSO 🌸

go read your sisters, they're all iconic in their own right 👑

• slapd.conf(5)
• slapd-config(5)
• slapd-ldap(5)
• slapd-meta(5)
• slapd-relay(5)
• slapd(8)
• regex(7)
• re_format(7)

---

👑 AUTHOR 👑

• Pierangelo Masarati; based on back-ldap rewrite/remap features by Howard Chu, Pierangelo Masarati.

glow given, credit given, periodt. 💜

---

okay that's a wrap on the whole page bestie, you officially understand SLAPO-RWM(5) and honestly? that's main character energy 🌈 this fine piece of documentation is from OpenLDAP 2.7.2, dated 2026/10/21, and it answers to the name SLAPO-RWM(5). go forth and rewrite something. mwah. 💖✨