SLAPO-DDS(5)

📦
version 2.7.2 · 24 versions
, in arch rolling

💖 slapo-dds — Dynamic Directory Services overlay to slapd 💖

okay bestie, this is a page from the File Formats Manual section, and it's literally all about making directory entries that just... poof 💨 when nobody's looking. let me walk you through it, no cap.

✨ SYNOPSIS ✨

/etc/openldap/slapd.conf

🌸 DESCRIPTION 🌸

the dds overlay for slapd(8) implements dynamic objects exactly the way RFC 2589 says to. and "dds"? it stands for Dynamic Directory Services, iykyk. it lets you define dynamic objects, and those are characterized by the dynamicObject objectClass. 💅

dynamic objects have a limited lifetime, determined by a time-to-live (TTL) that can be refreshed with a specific refresh extended operation. this operation lets you set the Client Refresh Period (CRP), which is literally the period between refreshes that is required to preserve the dynamic object from expiration. and how do you get the expiration time? you add the requested TTL to the current time. simple math, periodt. when dynamic objects reach the end of their lifetime without being refreshed, they get automatically deleted. but listen — there is no guarantee of immediate deletion, so clients should NOT count on it. don't do that. 🙈

dynamic objects can have subordinates — but only if those subordinates are also dynamic objects. now here's the thing: RFC 2589 does not specify what a dynamic directory service should do when a dynamic object with (dynamic) subordinates expires. and in this implementation? the lifetime of dynamic objects with subordinates is prolonged until all the dynamic subordinates expire. 👑

this slapd.conf(5) directive adds the dds overlay to the current database:

overlay dds
the database must have a rootdn specified. otherwise the dds overlay will not be able to delete expired objects. non-negotiable bestie.

the dds overlay may be used with any backend that implements the add, modify, search, and delete operations. and since using it may result in many internal entry lookups, adds and deletes, it should be best used in conjunction with backends that have reasonably good write performances. (fr fr, she's a busy girl.)

the config directives specific to the dds overlay are prefixed by dds-, so they don't fight with directives specific to the underlying database or to other stacked overlays. no drama in the overlay stack, we don't do that here. 🎀

  • dds-max-ttl <time> — specifies the max TTL value. this is also the default TTL newly created dynamic objects receive, unless dds-default-ttl is set. when the client with a refresh extended operation requests a TTL higher than it, sizeLimitExceeded is returned. this value must be between 86400 (1 day, the default) and 31557600 (1 year plus 6 hours, as per RFC 2589). 💀
  • dds-min-ttl <time> — specifies the min TTL value; clients requesting a lower TTL by means of the refresh extended operation actually obtain this value as CRP. if set to 0 (the default), no lower limit is set.
  • dds-default-ttl <time> — specifies the default TTL value that newly created dynamic objects get. if set to 0 (the default), the dds-max-ttl is used.
  • dds-interval <time> — specifies the interval between expiration checks; defaults to 1 hour. ⏰
  • dds-tolerance <time> — specifies an extra time that is added to the timer that actually wakes up the thread that will delete an expired dynamic object. so the nominal lifetime of the entry is that specified in the entryTtl attribute, but its lifetime will actually be entryTtl + tolerance. note that there is no guarantee that the lifetime of a dynamic object will be exactly the requested TTL; due to implementation details, it may be longer — which is allowed by RFC 2589. by default, tolerance is 0.
  • dds-max-dynamicObjects <num> — specifies the maximum number of dynamic objects that can simultaneously exist within a naming context. this allows one to limit the amount of resources (mostly in terms of run-queue size) that are used by dynamic objects. by default, no limit is set.
  • dds-state {TRUE|false} — specifies if the Dynamic Directory Services feature is enabled or not. by default it is; however, a proxy does not need to keep track of dynamic objects itself, it only needs to inform the frontend that support for dynamic objects is available. 🫶

🔐 ACCESS CONTROL 🔐

okay this part is important, bestie, listen up. the dds overlay restricts the refresh operation by requiring manage access to the entryTtl attribute (see slapd.access(5) for details about the manage access privilege). and since the entryTtl is an operational, NO-USER-MODIFICATION attribute, no direct write access to it is possible. so what does dds do? it turns the refresh extended operation into an internal modification to the value of the entryTtl attribute with the relax control set. sneaky. iconic. 💅

RFC 2589 recommends that anonymous clients should not be allowed to refresh a dynamic object. this can be implemented by appropriately crafting access control to obtain the desired effect.

example: restrict refresh to authenticated clients

access to attrs=entryTtl
     by users manage
     by * read

example: restrict refresh to the creator of the dynamic object

access to attrs=entryTtl
     by dnattr=creatorsName manage
     by * read

another suggested usage of dynamic objects is to implement dynamic meetings; in this case, all the participants to the meeting are allowed to refresh the meeting object, but only the creator can delete it (otherwise it will be deleted when the TTL expires). the drama of it all. 😭

example: assuming participant is a valid DN-valued attribute, allow users to start a meeting and to join it; restrict refresh to the participants; restrict delete to the creator

access to dn.base="cn=Meetings"
          attrs=children
     by users write

access to dn.onelevel="cn=Meetings"
          attrs=entry
     by dnattr=creatorsName write
     by * read

access to dn.onelevel="cn=Meetings"
          attrs=participant
     by dnattr=creatorsName write
     by users selfwrite
     by * read

access to dn.onelevel="cn=Meetings"
          attrs=entryTtl
     by dnattr=participant manage
     by * read

🦋 REPLICATION 🦋

this implementation of RFC 2589 provides a restricted interpretation of how dynamic objects replicate. only the provider takes care of handling dynamic object expiration, while consumers simply see the dynamic object as a plain object. that's the vibe. ✨

when replicating these objects, one needs to explicitly exclude the dynamicObject class and the entryTtl attribute. and this implementation of RFC 2589 introduces a new operational attribute, entryExpireTimestamp, that contains the expiration timestamp. this must be excluded from replication as well.

the quick and dirty solution is to set schemacheck=off in the syncrepl configuration and, optionally, exclude the operational attributes from replication, using:

syncrepl ...
     exattrs=entryTtl,entryExpireTimestamp

in any case the overlay must be either statically built in or run-time loaded by the consumer, so that it is aware of the entryExpireTimestamp operational attribute; however, it must not be configured in the shadow database. and currently, there is no means to remove the dynamicObject class from the entry — this may be seen as a feature, since it allows one to see the dynamic properties of the object. 💜

🎀 FILES 🎀

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

👑 SEE ALSO 👑

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

🌈 AUTHOR 🌈

Implemented by Pierangelo Masarati.

<div align="left">

and that's the whole page bestie!! this one came from OpenLDAP 2.7.2, dated 2026/10/21 — go forth and let your dynamic objects expire beautifully (or not, if you keep refreshing them like a good main character). 💖✨🌸🦋🫶

</div>

📦 where this page comes from