SLAPO-DDS(5) File Formats Manual SLAPO-DDS(5)
NAME
slapo-dds - Dynamic Directory Services overlay to slapd
SYNOPSIS
/etc/ldap/slapd.conf
DESCRIPTION
The dds overlay to slapd(8) implements dynamic objects as per RFC 2589.
The name dds stands for Dynamic Directory Services. It allows one to
define dynamic objects, characterized by the dynamicObject objectClass.
Dynamic objects have a limited lifetime, determined by a time-to-live
(TTL) that can be refreshed by means of a specific refresh extended op-
eration. This operation allows one to set the Client Refresh Period
(CRP), namely the period between refreshes that is required to preserve
the dynamic object from expiration. The expiration time is computed by
adding the requested TTL to the current time. When dynamic objects
reach the end of their lifetime without being further refreshed, they
are automatically deleted. There is no guarantee of immediate dele-
tion, so clients should not count on it.
Dynamic objects can have subordinates, provided these also are dynamic
objects. RFC 2589 does not specify what the behavior of a dynamic di-
rectory service should be when a dynamic object with (dynamic) subordi-
nates expires. In this implementation, the lifetime of dynamic objects
with subordinates is prolonged until all the dynamic subordinates ex-
pire.
This slapd.conf(5) directive adds the dds overlay to the current data-
base:
overlay dds
The database must have a rootdn specified, otherwise, the dds overlay
will not be able to delete expired objects. The dds overlay may be used
with any backend that implements the add, modify, search, and delete
operations. Since its use 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.
The config directives that are specific to the dds overlay are prefixed
by dds-, to avoid potential conflicts with directives specific to the
underlying database or to other stacked overlays.
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 ob-
jects 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 im-
plementation 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 simul-
taneously 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
The dds overlay restricts the refresh operation by requiring manage ac-
cess to the entryTtl attribute (see slapd.access(5) for details about
the manage access privilege). Since the entryTtl is an operational,
NO-USER-MODIFICATION attribute, no direct write access to it is possi-
ble. So the dds overlay turns refresh extended operation into an in-
ternal modification to the value of the entryTtl attribute with the re-
lax control set.
RFC 2589 recommends that anonymous clients should not be allowed to re-
fresh 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 (oth-
erwise it will be deleted when the TTL expires)
Example: assuming participant is a valid DN-valued attribute, allow
users to start a meeting and to join it; restrict refresh to the par-
ticipants; 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 han-
dling dynamic object expiration, while consumers simply see the dynamic
object as a plain object.
When replicating these objects, one needs to explicitly exclude the dy-
namicObject class and the entryTtl attribute. 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. 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/ldap/slapd.conf
default slapd configuration file
SEE ALSO
slapd.conf(5), slapd-config(5), slapd(8).
AUTHOR
Implemented by Pierangelo Masarati.
OpenLDAP 2.5.13+dfsg-5 2022/07/14 SLAPO-DDS(5)
Generated by dwww version 1.15 on Tue Sep 2 02:41:15 CEST 2025.