SLAPO-CHAIN(5)

📦
version 2.7.2 · 24 versions
, in arch rolling

💖 SLAPO-CHAIN 💖

okay bestie, gather round, because today we're talking about slapo-chain — the chain overlay to slapd. yes it's a real one, yes it's iconic, and yes you're gonna understand it. 🫶

✨ SYNOPSIS ✨

/etc/openldap/slapd.conf

🌸 DESCRIPTION 🌸

So the chain overlay for slapd(8) does automatic referral chasing. No cap. Any time a referral comes back (…except for bind operations, noted 💅), it gets chased by spinning up an instance of the ldap backend. And if operations are happening with an identity (i.e. after a bind), that identity can be asserted while chasing those referrals, using the identity assertion feature of back-ldap — see slapd-ldap(5) for the deets — which is basically built on the proxied authorization control [RFC 4370]. The client can also control referral chasing themselves by issuing the chaining control (peep draft-sermersheim-ldap-chaining for the details).

The config directives that belong specifically to the chain overlay are prefixed with chain-, so they don't start drama with directives that belong to the underlying database or to other stacked overlays. 🎀

There are, like, very few chain-overlay-specific directives. However, directives tied to the instances of the ldap backend that the overlay may implicitly instantiate can pick up a special meaning when they're used with this overlay. Those live in slapd-ldap(5), and heads up — they also need the chain- prefix. ⭐

no cap: this overlay is built into the ldap backend. It is not a separate module. remember that. 🧚
  • overlay chain — this is the one that adds the chain overlay to the current backend. The chain overlay can chill with any backend, but it's mainly meant for local storage backends that might hand back referrals. It's useless next to the slapd-ldap and slapd-meta backends, because those already exploit the libldap-specific referral chase feature. [Note: this might change in the future, since the ldap(5) and meta(5) backends might stop chasing referrals on their own.]
  • chain-cache-uri {FALSE|true} — tells the chain overlay to cache connections to URIs that get parsed out of referrals that aren't predefined, so they can be reused for later chaining. Those URIs inherit the properties configured for the underlying slapd-ldap(5) before any occurrence of the chain-uri directive; basically, they get chained anonymously. 🙈
  • chain-chaining [resolve=<r>] [continuation=<c>] [critical] — enables the chaining control (see draft-sermersheim-ldap-chaining) with the resolve and continuation behaviors and criticality you want. The resolve parameter = the behavior while discovering a resource, aka when accessing the object the request DN points at. The continuation parameter = the behavior while handling intermediate responses, which mostly matters for the search operation, but can also affect extended operations that return intermediate responses. The values r and c can be any of chainingPreferred, chainingRequired, referralsPreferred, referralsRequired. The critical flag affects the control criticality if provided. [This control is experimental and its support may change in the future. 👀]
  • chain-max-depth <n> — if a referral gets returned while referral chasing, further chasing only goes at most <n> levels deep. Set it to 1 (the default) to disable further referral chasing. periodt.
  • chain-return-error {FALSE|true} — if referral chasing fails, the real error gets returned instead of the original referral. And if multiple referral URIs are present, only the first error is returned. Tbh this behavior may not always be appropriate or desirable, since failures in referral chasing might be better resolved by the client (e.g. when they're caused by distributed authentication issues). 😭
  • chain-uri <ldapuri> — this directive instantiates a new underlying ldap database and tells it which URI to contact to chase referrals. And unlike what it says in slapd-ldap(5), only one URI can appear after this directive; all subsequent slapd-ldap(5) directives prefixed by chain- refer to this specific instance of a remote server. 💅

Directives for configuring the underlying ldap database might also be required, like so:

       overlay                 chain
       chain-rebind-as-user    FALSE

       chain-uri               "ldap://ldap1.example.com"
       chain-rebind-as-user    TRUE
       chain-idassert-bind     bindmethod="simple"
                               binddn="cn=Auth,dc=example,dc=com"
                               credentials="secret"
                               mode="self"

       chain-uri               "ldap://ldap2.example.com"
       chain-idassert-bind     bindmethod="simple"
                               binddn="cn=Auth,dc=example,dc=com"
                               credentials="secret"
                               mode="none"

Any valid directives for the ldap database may be used; see slapd-ldap(5) for details. The chain-uri directive can appear multiple times, so you can define multiple "trusted" URIs where operations with identity assertion get chained. All URIs that aren't listed in the config are chained anonymously. And all slapd-ldap(5) directives that appear before the first occurrence of chain-uri are inherited by all URIs, unless they're specifically overridden inside each URI's configuration. 🔥

🎀 FILES 🎀

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

🦋 SEE ALSO 🦋

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

👑 AUTHOR 👑

Originally implemented by Howard Chu; extended by Pierangelo Masarati.

and that's the whole vibe, bestie — this page is from OpenLDAP 2.7.2, dated 2026/10/21. go forth and chain responsibly 💖✨

📦 where this page comes from