Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages


home | help
SLAPO-DDS(5)		      File Formats Manual		  SLAPO-DDS(5)

       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  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-

       This slapd.conf(5) directive adds the dds overlay to the	current	 data-

       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 ob-
	      jects 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

       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  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

       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 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"
		   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 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 ...

       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.

	      default slapd configuration file

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

       Implemented by Pierangelo Masarati.

OpenLDAP 2.4.57			  2021/01/18			  SLAPO-DDS(5)


Want to link to this manual page? Use this URL:

home | help