Provided by: slapd_2.4.42+dfsg-2ubuntu3.13_amd64 bug


       slapo-dds - Dynamic Directory Services overlay to slapd




       The  dds  overlay  to  slapd(8)  implements dynamic objects as per RFC 2589.  The name dds
       stands for Dynamic Directory Services.  It allows 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 operation.  This operation allows 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 deletion, 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 directory service should be when a dynamic
       object  with  (dynamic)  subordinates  expires.   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. 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 <ttl>
              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 <ttl>
              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 <ttl>
              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 <ttl>
              Specifies the interval between expiration checks; defaults to 1 hour.

       dds-tolerance <ttl>
              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 to limit the amount of resources (mostly in
              terms of run-queue size) that are used by dynamic objects.  By default, no limit is

       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.


       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).  Since  the
       entryTtl  is  an operational, NO-USER-MODIFICATION attribute, no direct write access to it
       is possible.  So the dds  overlay  turns  refresh  extended  operation  into  an  internal
       modification to the value of the entryTtl attribute with the relax control set.

       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)

       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

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

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

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

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


       This  implementation  of  RFC  2589  provides  a  restricted interpretation of how dynamic
       objects replicate.  Only the master takes care  of  handling  dynamic  object  expiration,
       while replicas simply see the dynamic object as a plain object.

       When  replicating  these  objects, one needs to explicitly exclude the dynamicObject 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 ...

       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  to
       see the dynamic properties of the object.


              default slapd configuration file


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


       Implemented by Pierangelo Masarati.