SLAPO-TRANSLUCENT(5)

💖 SLAPO-TRANSLUCENT 💖

okay bestie, so this is SLAPO-TRANSLUCENT from the File Formats Manual, and it's literally the translucent proxy overlay for slapd — yes that's the whole vibe, let me spill 🫶

✨ NAME ✨

slapo-translucent — the Translucent Proxy overlay for slapd, no cap.

---

🎀 SYNOPSIS 🎀

/etc/openldap/slapd.conf

---

🌸 DESCRIPTION 🌸

so the Translucent Proxy overlay can be used with a backend database like slapd-mdb(5) to create what we call a "translucent proxy". and the way that works is: entries you pull from a remote LDAP server can have some or all of their attributes overridden, or brand new attributes added, by entries sitting in the local database — and then they get presented to the client. iconic behavior honestly 💅

A search operation gets populated with entries from the remote LDAP server first, and then those attributes get overridden with any attributes defined in the local database. The local overrides can be populated with the add, modify, and modrdn operations — and heads up, using those is restricted to the root user 🔐

A compare operation will do a comparison against attributes defined in the local database record (if any exists) before any comparison gets made against data in the remote database. order matters, periodt.

---

🌈 CONFIGURATION 🌈

The Translucent Proxy overlay uses a proxied database — typically a (set of) remote LDAP server(s) — which you configure with the options shown in slapd-ldap(5), slapd-meta(5), or something similar. but these slapd.conf options right here are the ones specific to the Translucent Proxy overlay, and they must appear after the overlay directive that instantiates the translucent overlay. no skipping the line, bestie 🚫

• translucent_strict — by default, attempts to delete attributes in either the local or the remote databases get silently ignored. the translucent_strict directive makes those modifications fail with a Constraint Violation instead. she does not let things slide 💀
• translucent_no_glue — this option disables the automatic creation of "glue" records for an add or modrdn operation, meaning all parents of an entry added to the local database must be created by hand. note that glue records are always created for a modify operation, no exceptions 💅
• 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 get split into a local portion and a remote portion, and local attributes get searched locally. splitting the filter, main character energy ✨
• 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. and yes, attributes may be specified as both local and remote if you want — she contains multitudes 🦋

okay so 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. but in any case, both the local and remote entries corresponding to a search result get merged before being returned to the client. merged and gorgeous, fr fr 💖

• 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 the 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. for read operations, it's delegated to the remote DSA(s) and to the frontend.

bestie listen — local access rules involving data returned by the remote DSA(s) should be designed with care. 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. so like. don't do that 🙈

---

🍓 FILES 🍓

• /etc/openldap/slapd.conf — default slapd configuration file

---

👑 SEE ALSO 👑

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

---

and that's the whole page, angel 💜 this one's from OpenLDAP 2.7.2, dated 2026/10/21 — go forth and proxy translucently, slay ✨🧚💅