1SLAPO-DDS(5)                  File Formats Manual                 SLAPO-DDS(5)
2
3
4

NAME

6       slapo-dds - Dynamic Directory Services overlay to slapd
7

SYNOPSIS

9       /etc/openldap/slapd.conf
10

DESCRIPTION

12       The dds overlay to slapd(8) implements dynamic objects as per RFC 2589.
13       The name dds stands for Dynamic Directory Services.  It allows  one  to
14       define dynamic objects, characterized by the dynamicObject objectClass.
15
16       Dynamic  objects  have a limited lifetime, determined by a time-to-live
17       (TTL) that can be refreshed by means of a specific refresh extended op‐
18       eration.   This  operation  allows one to set the Client Refresh Period
19       (CRP), namely the period between refreshes that is required to preserve
20       the dynamic object from expiration.  The expiration time is computed by
21       adding the requested TTL to the current  time.   When  dynamic  objects
22       reach  the  end of their lifetime without being further refreshed, they
23       are automatically deleted.  There is no guarantee  of  immediate  dele‐
24       tion, so clients should not count on it.
25
26       Dynamic  objects can have subordinates, provided these also are dynamic
27       objects.  RFC 2589 does not specify what the behavior of a dynamic  di‐
28       rectory service should be when a dynamic object with (dynamic) subordi‐
29       nates expires.  In this implementation, the lifetime of dynamic objects
30       with  subordinates  is prolonged until all the dynamic subordinates ex‐
31       pire.
32
33
34       This slapd.conf(5) directive adds the dds overlay to the current  data‐
35       base:
36
37
38       overlay dds
39
40
41       The  database  must have a rootdn specified, otherwise, the dds overlay
42       will not be able to delete expired objects. The dds overlay may be used
43       with  any  backend  that implements the add, modify, search, and delete
44       operations.  Since its use may result in many internal  entry  lookups,
45       adds  and  deletes, it should be best used in conjunction with backends
46       that have reasonably good write performances.
47
48
49       The config directives that are specific to the dds overlay are prefixed
50       by  dds-,  to avoid potential conflicts with directives specific to the
51       underlying database or to other stacked overlays.
52
53
54       dds-max-ttl <time>
55              Specifies the max TTL value.  This is also the default TTL newly
56              created  dynamic objects receive, unless dds-default-ttl is set.
57              When the client with a refresh extended operation requests a TTL
58              higher  than it, sizeLimitExceeded is returned.  This value must
59              be between 86400 (1 day, the default) and 31557600 (1 year  plus
60              6 hours, as per RFC 2589).
61
62
63       dds-min-ttl <time>
64              Specifies  the  min TTL value; clients requesting a lower TTL by
65              means of the refresh extended  operation  actually  obtain  this
66              value as CRP.  If set to 0 (the default), no lower limit is set.
67
68
69       dds-default-ttl <time>
70              Specifies  the  default TTL value that newly created dynamic ob‐
71              jects get.  If set to 0 (the default), the dds-max-ttl is used.
72
73
74       dds-interval <time>
75              Specifies the interval between expiration checks; defaults to  1
76              hour.
77
78
79       dds-tolerance <time>
80              Specifies an extra time that is added to the timer that actually
81              wakes up the thread that will delete an expired dynamic  object.
82              So  the  nominal  lifetime of the entry is that specified in the
83              entryTtl attribute, but its lifetime will actually be entryTtl +
84              tolerance.  Note that there is no guarantee that the lifetime of
85              a dynamic object will be exactly the requested TTL; due  to  im‐
86              plementation  details, it may be longer, which is allowed by RFC
87              2589.  By default, tolerance is 0.
88
89
90       dds-max-dynamicObjects <num>
91              Specifies the maximum number of dynamic objects that can  simul‐
92              taneously  exist  within  a  naming context.  This allows one to
93              limit the amount of resources  (mostly  in  terms  of  run-queue
94              size) that are used by dynamic objects.  By default, no limit is
95              set.
96
97
98       dds-state {TRUE|false}
99              Specifies if the Dynamic Directory Services feature  is  enabled
100              or  not.   By  default  it is; however, a proxy does not need to
101              keep track of dynamic objects itself, it only  needs  to  inform
102              the frontend that support for dynamic objects is available.
103
104

ACCESS CONTROL

106       The dds overlay restricts the refresh operation by requiring manage ac‐
107       cess to the entryTtl attribute (see slapd.access(5) for  details  about
108       the  manage  access  privilege).  Since the entryTtl is an operational,
109       NO-USER-MODIFICATION attribute, no direct write access to it is  possi‐
110       ble.   So  the dds overlay turns refresh extended operation into an in‐
111       ternal modification to the value of the entryTtl attribute with the re‐
112       lax control set.
113
114       RFC 2589 recommends that anonymous clients should not be allowed to re‐
115       fresh a dynamic object.   This  can  be  implemented  by  appropriately
116       crafting access control to obtain the desired effect.
117
118       Example: restrict refresh to authenticated clients
119
120              access to attrs=entryTtl
121                   by users manage
122                   by * read
123
124       Example: restrict refresh to the creator of the dynamic object
125
126              access to attrs=entryTtl
127                   by dnattr=creatorsName manage
128                   by * read
129
130       Another  suggested  usage  of  dynamic  objects is to implement dynamic
131       meetings; in this case, all the participants to the meeting are allowed
132       to refresh the meeting object, but only the creator can delete it (oth‐
133       erwise it will be deleted when the TTL expires)
134
135       Example: assuming participant is a  valid  DN-valued  attribute,  allow
136       users  to  start a meeting and to join it; restrict refresh to the par‐
137       ticipants; restrict delete to the creator
138
139              access to dn.base="cn=Meetings"
140                        attrs=children
141                   by users write
142
143              access to dn.onelevel="cn=Meetings"
144                        attrs=entry
145                   by dnattr=creatorsName write
146                   by * read
147
148              access to dn.onelevel="cn=Meetings"
149                        attrs=participant
150                   by dnattr=creatorsName write
151                   by users selfwrite
152                   by * read
153
154              access to dn.onelevel="cn=Meetings"
155                        attrs=entryTtl
156                   by dnattr=participant manage
157                   by * read
158
159
160

REPLICATION

162       This implementation of RFC 2589 provides a restricted interpretation of
163       how  dynamic  objects  replicate.  Only the provider takes care of han‐
164       dling dynamic object expiration, while consumers simply see the dynamic
165       object as a plain object.
166
167       When replicating these objects, one needs to explicitly exclude the dy‐
168       namicObject class and the entryTtl attribute.  This  implementation  of
169       RFC  2589 introduces a new operational attribute, entryExpireTimestamp,
170       that contains the expiration timestamp.  This  must  be  excluded  from
171       replication as well.
172
173       The  quick and dirty solution is to set schemacheck=off in the syncrepl
174       configuration and, optionally, exclude the operational attributes  from
175       replication, using
176
177              syncrepl ...
178                   exattrs=entryTtl,entryExpireTimestamp
179
180       In  any case the overlay must be either statically built in or run-time
181       loaded by the consumer, so that it is aware of the entryExpireTimestamp
182       operational attribute; however, it must not be configured in the shadow
183       database.  Currently, there is no means  to  remove  the  dynamicObject
184       class  from  the  entry; this may be seen as a feature, since it allows
185       one to see the dynamic properties of the object.
186
187

FILES

189       /etc/openldap/slapd.conf
190              default slapd configuration file
191

SEE ALSO

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

AUTHOR

196       Implemented by Pierangelo Masarati.
197
198
199
200OpenLDAP 2.6.6                    2023/07/31                      SLAPO-DDS(5)
Impressum