Go to main content

man pages section 5: File Formats

Exit Print View

Updated: Thursday, June 13, 2019
 
 

slapo-dds (5oldap)

Name

slapo-dds - Dynamic Directory Services overlay to slapd

Synopsis

/etc/openldap/slapd.conf

Description

SLAPO-DDS(5oldap)                                            SLAPO-DDS(5oldap)



NAME
       slapo-dds - Dynamic Directory Services overlay to slapd

SYNOPSIS
       /etc/openldap/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
       operation.   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
       directory service should be when a dynamic object with (dynamic) subor-
       dinates expires.  In  this  implementation,  the  lifetime  of  dynamic
       objects  with  subordinates is prolonged until all the dynamic subordi-
       nates expire.


       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 <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 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
       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 possi-
       ble.  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 (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 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 ...
                   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/openldap/slapd.conf
              default slapd configuration file


ATTRIBUTES
       See attributes(7) for descriptions of the following attributes:


       +---------------+-------------------------------+
       |ATTRIBUTE TYPE |       ATTRIBUTE VALUE         |
       +---------------+-------------------------------+
       |Availability   | service/network/ldap/openldap |
       +---------------+-------------------------------+
       |Stability      | Pass-through uncommitted      |
       +---------------+-------------------------------+
SEE ALSO
       slapd.conf(5), slapd-config(5), slapd(8).

AUTHOR
       Implemented by Pierangelo Masarati.



NOTES
       This     software     was    built    from    source    available    at
       https://github.com/oracle/solaris-userland.   The  original   community
       source  was downloaded from  ftp://ftp.openldap.org/pub/OpenLDAP/openl-
       dap-release/openldap-2.4.46.tgz

       Further information about this software can be found on the open source
       community website at http://www.openldap.org/.



OpenLDAP 2.4.46                   2018/03/22                 SLAPO-DDS(5oldap)