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

FreeBSD Manual Pages


home | help
SLAPD-CONFIG(5)		      File Formats Manual	       SLAPD-CONFIG(5)

       slapd-config - configuration backend to slapd


       The config backend manages all of the configuration information for the
       slapd(8)	daemon.	 This configuration information	is also	 used  by  the
       SLAPD tools slapacl(8), slapadd(8), slapauth(8),	slapcat(8), slapdn(8),
       slapindex(8), and slaptest(8).

       The config backend is backward compatible with the older	 slapd.conf(5)
       file  but  provides the ability to change the configuration dynamically
       at runtime. If slapd is run with	only a slapd.conf file dynamic changes
       will  be	allowed	but they will not persist across a server restart. Dy-
       namic changes are only saved when slapd is running from a slapd.d  con-
       figuration directory.

       Unlike  other  backends,	 there	can only be one	instance of the	config
       backend,	and most of its	structure is predefined. The root of the data-
       base is hardcoded to cn=config and this root entry contains global set-
       tings for slapd.	Multiple child entries underneath the root  entry  are
       used to carry various other settings:

		     dynamically loaded	modules

		     schema definitions

		     backend-specific settings

		     database-specific settings

       The  cn=Module  entries	will only appear in configurations where slapd
       was built with support for dynamically loaded  modules.	There  can  be
       multiple	 entries, one for each configured module path. Within each en-
       try there will be values	recorded for each module  loaded  on  a	 given
       path. These entries have	no children.

       The cn=Schema entry contains all	of the hardcoded schema	elements.  The
       children	of this	entry contain all user-defined	schema	elements.   In
       schema  that  were  loaded  from	include	files, the child entry will be
       named after the include file from which the schema was  loaded.	 Typi-
       cally the first child in	this subtree will be cn=core,cn=schema,cn=con-

       olcBackend entries are for storing settings specific to a single	 back-
       end  type (and thus global to all database instances of that type).  At
       present there are no backends that implement settings of	 this  nature,
       so usually there	will not be any	olcBackend entries.

       olcDatabase  entries  store  settings specific to a single database in-
       stance. These entries may have olcOverlay child	entries	 corresponding
       to  any overlays	configured on the database. The	olcDatabase and	olcOv-
       erlay entries may also have miscellaneous child entries for other  set-
       tings as	needed.	There are two special database entries that are	prede-
       fined - one is an entry for the config database itself, and  the	 other
       is  for	the "frontend" database. Settings in the frontend database are
       inherited by the	other databases, unless	they are explicitly overridden
       in a specific database.

       The specific configuration options available are	discussed below	in the
       Global Configuration Options,  General  Backend	Options,  and  General
       Database	Options. Options are set by defining LDAP attributes with spe-
       cific values.  In general the names of the LDAP attributes are the same
       as the corresponding slapd.conf keyword,	with an	"olc" prefix added on.

       The parser for many of these attributes is the same as used for parsing
       the slapd.conf keywords.	As such, slapd.conf keywords that allow	multi-
       ple  items  to  be specified on one line, separated by whitespace, will
       allow multiple items to be specified in one attribute  value.  However,
       when  reading the attribute via LDAP, the items will be returned	as in-
       dividual	attribute values.

       Backend-specific	options	are discussed in the slapd-<backend>(5)	manual
       pages.	Refer to the "OpenLDAP Administrator's Guide" for more details
       on configuring slapd.

       Options described in this section apply to the server as	a whole.   Ar-
       guments	that  should  be replaced by actual text are shown in brackets

       These options may only be specified in the cn=config entry. This	 entry
       must have an objectClass	of olcGlobal.

       olcAllows: <features>
	      Specify  a set of	features to allow (default none).  bind_v2 al-
	      lows acceptance of LDAPv2	bind  requests.	  Note	that  slapd(8)
	      does  not	 truly	implement LDAPv2 (RFC 1777), now Historic (RFC
	      3494).  bind_anon_cred allows anonymous  bind  when  credentials
	      are  not	empty  (e.g.   when DN is empty).  bind_anon_dn	allows
	      unauthenticated (anonymous) bind when  DN	 is  not  empty.   up-
	      date_anon	 allows	 unauthenticated (anonymous) update operations
	      to be processed (subject to access controls and  other  adminis-
	      trative	limits).    proxy_authz_anon   allows  unauthenticated
	      (anonymous) proxy	authorization control to be processed (subject
	      to  access controls, authorization and other administrative lim-

       olcArgsFile: <filename>
	      The (absolute) name of a file that will hold the slapd  server's
	      command line (program name and options).

       olcAttributeOptions: <option-name>...
	      Define  tagging  attribute options or option tag/range prefixes.
	      Options must not end with	`-', prefixes must end with `-'.   The
	      `lang-'  prefix  is  predefined.	If you use the olcAttributeOp-
	      tions directive, `lang-' will no longer be defined and you  must
	      specify it explicitly if you want	it defined.

	      An  attribute  description with a	tagging	option is a subtype of
	      that attribute description without the option.  Except for that,
	      options  defined	this  way have no special semantics.  Prefixes
	      defined this way work like the `lang-' options:  They  define  a
	      prefix  for  tagging options starting with the prefix.  That is,
	      if you define the	 prefix	 `x-foo-',  you	 can  use  the	option
	      `x-foo-bar'.   Furthermore,  in a	search or compare, a prefix or
	      range name (with a trailing `-') matches	all  options  starting
	      with  that  name,	as well	as the option with the range name sans
	      the trailing `-'.	 That is, `x-foo-bar-' matches `x-foo-bar' and

	      RFC 4520 reserves	options	beginning with `x-' for	private	exper-
	      iments.  Other options should be registered with IANA,  see  RFC
	      4520  section  3.5.  OpenLDAP also has the `binary' option built
	      in, but this is a	transfer option, not a tagging option.

       olcAuthIDRewrite: <rewrite-rule>
	      Used by the authentication  framework  to	 convert  simple  user
	      names  to	 an LDAP DN used for authorization purposes.  Its pur-
	      pose is analogous	to that	of olcAuthzRegexp  (see	 below).   The
	      rewrite-rule  is	a set of rules analogous to those described in
	      slapo-rwm(5) for data rewriting (after stripping the  rwm-  pre-
	      fix).   olcAuthIDRewrite and olcAuthzRegexp should not be	inter-

       olcAuthzPolicy: <policy>
	      Used to specify which rules  to  use  for	 Proxy	Authorization.
	      Proxy  authorization  allows  a  client  to  authenticate	to the
	      server using one user's credentials,  but	 specify  a  different
	      identity	to  use	for authorization and access control purposes.
	      It essentially allows user A to login as user B, using user  A's
	      password.	  The  none flag disables proxy	authorization. This is
	      the default setting.  The	from flag will use rules  in  the  au-
	      thzFrom attribute	of the authorization DN.  The to flag will use
	      rules in the authzTo attribute of	the  authentication  DN.   The
	      any  flag, an alias for the deprecated value of both, will allow
	      any of the above,	whatever succeeds first	(checked in  to,  from
	      sequence.	 The all flag requires both authorizations to succeed.

	      The rules	are mechanisms to specify which	identities are allowed
	      to perform proxy authorization.  The authzFrom attribute	in  an
	      entry  specifies which other users are allowed to	proxy login to
	      this entry. The authzTo attribute	in an  entry  specifies	 which
	      other  users  this  user can authorize as.  Use of authzTo rules
	      can be easily abused if users are	 allowed  to  write  arbitrary
	      values to	this attribute.	 In general the	authzTo	attribute must
	      be protected with	ACLs such that only privileged users can  mod-
	      ify  it.	 The value of authzFrom	and authzTo describes an iden-
	      tity or a	set of identities; it can take five forms:



	      The first	form is	a valid	LDAP URI where the _host_:_port_,  the
	      _attrs_  and  the	 _extensions_ portions must be absent, so that
	      the search occurs	locally	on either authzFrom or	authzTo.   The
	      second  form  is	a DN, with the optional	style modifiers	exact,
	      onelevel,	children, and subtree for  exact,  onelevel,  children
	      and  subtree matches, which cause	_pattern_ to be	normalized ac-
	      cording to the DN	normalization  rules,  or  the	special	 regex
	      style,  which  causes  the  _pattern_  to	 be treated as a POSIX
	      (''extended'') regular  expression,  as  discussed  in  regex(7)
	      and/or re_format(7).  A pattern of * means any non-anonymous DN.
	      The third	form is	a SASL id, with	the optional fields _mech_ and
	      _realm_ that allow to specify a SASL mechanism, and eventually a
	      SASL realm, for those mechanisms that support one.  The need  to
	      allow  the  specification	 of  a mechanism is still debated, and
	      users are	strongly discouraged to	rely on	this possibility.  The
	      fourth  form is a	group specification, consisting	of the keyword
	      group, optionally	followed by the	specification of the group ob-
	      jectClass	and member attributeType.  The group with DN <pattern>
	      is searched with base scope, and in case of match, the values of
	      the  member attributeType	are searched for the asserted DN.  For
	      backwards	compatibility, if no identity type is  provided,  i.e.
	      only  <pattern>  is present, an exact DN is assumed; as a	conse-
	      quence, <pattern>	is subjected to	DN normalization.   Since  the
	      interpretation  of  authzFrom  and  authzTo can impact security,
	      users are	strongly encouraged to	explicitly  set	 the  type  of
	      identity	specification  that  is	being used.  A subset of these
	      rules can	be used	as third arg in	the  olcAuthzRegexp  statement
	      (see below); significantly, the URI and the dn.exact:_dn_	forms.

       olcAuthzRegexp: <match> <replace>
	      Used  by	the  authentication  framework	to convert simple user
	      names, such as provided by SASL subsystem, to an	LDAP  DN  used
	      for authorization	purposes.  Note	that the resultant DN need not
	      refer to an existing entry to be considered valid.  When an  au-
	      thorization  request  is	received  from the SASL	subsystem, the
	      SASL USERNAME, REALM, and	MECHANISM are taken,  when  available,
	      and combined into	a name of the form


	      This  name  is  then  compared  against  the  match POSIX	(''ex-
	      tended'')	regular	expression, and	if the	match  is  successful,
	      the  name	 is  replaced  with  the replace string.  If there are
	      wildcard strings in the match regular expression	that  are  en-
	      closed in	parenthesis, e.g.


	      then  the	 portion of the	name that matched the wildcard will be
	      stored in	the numbered placeholder variable  $1.	If  there  are
	      other wildcard strings in	parenthesis, the matching strings will
	      be in $2,	$3, etc. up to $9. The placeholders can	then  be  used
	      in the replace string, e.g.


	      The  replaced name can be	either a DN, i.e. a string prefixed by
	      "dn:", or	an LDAP	URI.  If the latter, the server	will  use  the
	      URI to search its	own database(s)	and, if	the search returns ex-
	      actly one	entry, the name	is replaced by the DN of  that	entry.
	      The  LDAP	URI must have no hostport, attrs, or extensions	compo-
	      nents, but the filter is mandatory, e.g.


	      The protocol portion of the URI must  be	strictly  ldap.	  Note
	      that  this  search is subject to access controls.	 Specifically,
	      the authentication identity must have "auth" access in the  sub-

	      Multiple	olcAuthzRegexp	values	can  be	specified to allow for
	      multiple matching	and replacement	patterns.  The	matching  pat-
	      terns  are  checked  in  the order they appear in	the attribute,
	      stopping at the first successful match.

       olcConcurrency: <integer>
	      Specify a	desired	level of concurrency.  Provided	to the	under-
	      lying  thread  system  as	a hint.	 The default is	not to provide
	      any hint.	This setting is	 only  meaningful  on  some  platforms
	      where  there  is	not  a	one to one correspondence between user
	      threads and kernel threads.

       olcConnMaxPending: <integer>
	      Specify the maximum number of pending requests for an  anonymous
	      session.	 If  requests are submitted faster than	the server can
	      process them, they will be queued	up to this limit. If the limit
	      is exceeded, the session is closed. The default is 100.

       olcConnMaxPendingAuth: <integer>
	      Specify  the maximum number of pending requests for an authenti-
	      cated session.  The default is 1000.

       olcDisallows: <features>
	      Specify a	set of features	to disallow (default none).  bind_anon
	      disables	acceptance of anonymous	bind requests.	Note that this
	      setting does not prohibit	anonymous directory access  (See  "re-
	      quire  authc").	bind_simple disables simple (bind) authentica-
	      tion.  tls_2_anon	disables forcing session to  anonymous	status
	      (see also	tls_authc) upon	StartTLS operation receipt.  tls_authc
	      disallows	the StartTLS  operation	 if  authenticated  (see  also

       olcGentleHUP: { TRUE | FALSE }
	      A	 SIGHUP	 signal	 will  only cause a 'gentle' shutdown-attempt:
	      Slapd will stop listening	for  new  connections,	but  will  not
	      close  the connections to	the current clients.  Future write op-
	      erations return unwilling-to-perform, though.  Slapd  terminates
	      when  all	 clients  have	closed their connections (if they ever
	      do), or -	as before - if it receives a SIGTERM signal.  This can
	      be  useful  if  you wish to terminate the	server and start a new
	      slapd server with	another	database, without disrupting the  cur-
	      rently  active  clients.	The default is FALSE.  You may wish to
	      use olcIdleTimeout along with this option.

       olcIdleTimeout: <integer>
	      Specify the number of seconds to wait before forcibly closing an
	      idle  client  connection.	 A setting of 0	disables this feature.
	      The default is 0.	You may	also want to set  the  olcWriteTimeout

       olcIndexIntLen: <integer>
	      Specify  the  key	 length	 for ordered integer indices. The most
	      significant bytes	of the binary integer will be used  for	 index
	      keys.  The default value is 4, which provides exact indexing for
	      31 bit values.  A	floating point representation is used to index
	      too large	values.

       olcIndexSubstrIfMaxlen: <integer>
	      Specify  the maximum length for subinitial and subfinal indices.
	      Only this	many characters	of an attribute	 value	will  be  pro-
	      cessed  by the indexing functions; any excess characters are ig-
	      nored. The default is 4.

       olcIndexSubstrIfMinlen: <integer>
	      Specify the minimum length for subinitial	and subfinal  indices.
	      An  attribute  value  must have at least this many characters in
	      order to be processed by the indexing functions. The default  is

       olcIndexSubstrAnyLen: <integer>
	      Specify  the  length used	for subany indices. An attribute value
	      must have	at least this many characters  in  order  to  be  pro-
	      cessed.  Attribute  values  longer than this length will be pro-
	      cessed in	segments of this length. The default is	4. The	subany
	      index will also be used in subinitial and	subfinal index lookups
	      when the filter string is	longer than the	olcIndexSubstrIfMaxlen

       olcIndexSubstrAnyStep: <integer>
	      Specify  the steps used in subany	index lookups. This value sets
	      the offset for the segments of a filter  string  that  are  pro-
	      cessed for a subany index	lookup.	The default is 2. For example,
	      with the default values, a search	using this filter  "cn=*abcde-
	      fgh*"  would  generate  index  lookups  for  "abcd", "cdef", and

       Note: Indexing support depends on the particular	backend	in use.	 Also,
       changing	 these	settings  will	generally require deleting any indices
       that depend on these parameters and recreating them with	slapindex(8).

       olcListenerThreads: <integer>
	      Specify the number of threads to use for the connection manager.
	      The default is 1 and this	is typically adequate for up to	16 CPU
	      cores.  The value	should be set to a power of 2.

       olcLocalSSF: <SSF>
	      Specifies	the Security Strength Factor (SSF) to be  given	 local
	      LDAP  sessions,  such  as	those to the ldapi:// listener.	 For a
	      description of SSF values, see olcSaslSecProps's	minssf	option
	      description.  The	default	is 71.

       olcLogFile: <filename>
	      Specify  a  file	for  recording	debug log messages. By default
	      these messages only go to	stderr and are not  recorded  anywhere
	      else.  Specifying	 a  logfile copies messages to both stderr and
	      the logfile.

       olcLogLevel: <integer> [...]
	      Specify the level	at which debugging  statements	and  operation
	      statistics  should  be  syslogged	 (currently logged to the sys-
	      logd(8) LOG_LOCAL4 facility).  They must be  considered  subsys-
	      tems rather than increasingly verbose log	levels.	 Some messages
	      with higher priority are logged  regardless  of  the  configured
	      loglevel	as  soon as any	logging	is configured.	Log levels are
	      additive,	and available levels are:
		     1	    (0x1 trace)	trace function calls
		     2	    (0x2 packets) debug	packet handling
		     4	    (0x4 args) heavy trace debugging (function args)
		     8	    (0x8 conns)	connection management
		     16	    (0x10 BER) print out packets sent and received
		     32	    (0x20 filter) search filter	processing
		     64	    (0x40 config) configuration	file processing
		     128    (0x80 ACL) access control list processing
		     256    (0x100 stats) stats	log connections/operations/re-
		     512    (0x200 stats2) stats log entries sent
		     1024   (0x400 shell) print	communication with shell back-
		     2048   (0x800 parse) entry	parsing

		     16384  (0x4000 sync) LDAPSync replication
		     32768  (0x8000 none) only messages	that get logged	 what-
			    ever log level is set
	      The desired log level can	be input as a single integer that com-
	      bines the	(ORed) desired levels, both in decimal or in hexadeci-
	      mal  notation, as	a list of integers (that are ORed internally),
	      or as a list of the names	that are  shown	 between  parenthesis,
	      such that

		  olcLogLevel: 129
		  olcLogLevel: 0x81
		  olcLogLevel: 128 1
		  olcLogLevel: 0x80 0x1
		  olcLogLevel: acl trace

	      are  equivalent.	 The  keyword any can be used as a shortcut to
	      enable logging at	all levels (equivalent to  -1).	  The  keyword
	      none,  or	 the  equivalent  integer representation, causes those
	      messages that  are  logged  regardless  of  the  configured  ol-
	      cLogLevel	 to  be	 logged.   In  fact, if	no olcLogLevel (or a 0
	      level) is	defined, no logging occurs, so at least	the none level
	      is required to have high priority	messages logged.

       olcPasswordCryptSaltFormat: <format>
	      Specify  the format of the salt passed to	crypt(3) when generat-
	      ing {CRYPT} passwords (see olcPasswordHash) during processing of
	      LDAP Password Modify Extended Operations (RFC 3062).

	      This string needs	to be in sprintf(3) format and may include one
	      (and only	one) %s	conversion.  This conversion will  be  substi-
	      tuted  with  a  string  of random	characters from	[A-Za-z0-9./].
	      For example, "%.2s" provides a two character salt	and  "$1$%.8s"
	      tells some versions of crypt(3) to use an	MD5 algorithm and pro-
	      vides 8 random characters	of salt.  The default is  "%s",	 which
	      provides 31 characters of	salt.

       olcPidFile: <filename>
	      The  (absolute) name of a	file that will hold the	slapd server's
	      process ID (see getpid(2)).

       olcPluginLogFile: <filename>
	      The ( absolute ) name of a file that will	contain	 log  messages
	      from SLAPI plugins. See slapd.plugin(5) for details.

       olcReferral: <url>
	      Specify  the  referral  to pass back when	slapd(8) cannot	find a
	      local database to	handle a  request.   If	 multiple  values  are
	      specified, each url is provided.

       olcReverseLookup: TRUE |	FALSE
	      Enable/disable client name unverified reverse lookup (default is
	      FALSE if compiled	with --enable-rlookups).

       olcRootDSE: <file>
	      Specify the name of an LDIF(5) file containing user defined  at-
	      tributes for the root DSE.  These	attributes are returned	in ad-
	      dition to	the attributes normally	produced by slapd.

	      The root DSE is an entry with information	about the  server  and
	      its  capabilities,  in operational attributes.  It has the empty
	      DN, and can be read with e.g.:
		  ldapsearch -x	-b "" -s base "+"
	      See RFC 4512 section 5.1 for details.

       olcSaslAuxprops:	<plugin> [...]
	      Specify which auxprop plugins to use for authentication lookups.
	      The  default is empty, which just	uses slapd's internal support.
	      Usually no other auxprop plugins are needed.

       olcSaslHost: <fqdn>
	      Used to specify the fully	qualified domain name  used  for  SASL

       olcSaslRealm: <realm>
	      Specify SASL realm.  Default is empty.

       olcSaslSecProps:	<properties>
	      Used  to	specify	Cyrus SASL security properties.	 The none flag
	      (without any other properties) causes the	 flag  properties  de-
	      fault,  "noanonymous,noplain",  to be cleared.  The noplain flag
	      disables mechanisms susceptible to simple	passive	attacks.   The
	      noactive flag disables mechanisms	susceptible to active attacks.
	      The nodict flag disables mechanisms susceptible to passive  dic-
	      tionary attacks.	The noanonymous	flag disables mechanisms which
	      support anonymous	login.	The forwardsec	flag  require  forward
	      secrecy between sessions.	 The passcred require mechanisms which
	      pass client credentials (and allow  mechanisms  which  can  pass
	      credentials  to  do so).	The minssf=<factor> property specifies
	      the minimum acceptable security strength factor  as  an  integer
	      approximate  to  effective  key  length  used for	encryption.  0
	      (zero) implies no	protection,  1	implies	 integrity  protection
	      only, 56 allows DES or other weak	ciphers, 112 allows triple DES
	      and other	strong ciphers,	128 allows  RC4,  Blowfish  and	 other
	      modern  strong  ciphers.	The default is 0.  The maxssf=<factor>
	      property specifies the maximum acceptable	security strength fac-
	      tor  as  an  integer  (see  minssf description).	The default is
	      INT_MAX.	The maxbufsize=<size> property specifies  the  maximum
	      security layer receive buffer size allowed.  0 disables security
	      layers.  The default is 65536.

       olcServerID: <integer> [<URL>]
	      Specify an integer ID from 0 to 4095 for this server (limited to
	      3	 hexadecimal digits).  The ID may also be specified as a hexa-
	      decimal ID by prefixing the value	with "0x".  Non-zero  IDs  are
	      required when using multi-provider replication and each provider
	      must have	a unique non-zero ID. Note that	this requirement  also
	      applies  to  separate  providers	contributing to	a glued	set of
	      databases.  If the URL is	provided, this directive may be	speci-
	      fied  multiple times, providing a	complete list of participating
	      servers and their	IDs. The  fully	 qualified  hostname  of  each
	      server  should be	used in	the supplied URLs. The IDs are used in
	      the "replica id" field of	all CSNs generated  by	the  specified
	      server.  The default value is zero, which	is only	valid for sin-
	      gle provider replication.	 Example:

	    olcServerID: 1 ldap://
	    olcServerID: 2 ldap://

       olcSockbufMaxIncoming: <integer>
	      Specify the maximum incoming LDAP	PDU size  for  anonymous  ses-
	      sions.  The default is 262143.

       olcSockbufMaxIncomingAuth: <integer>
	      Specify  the  maximum  incoming  LDAP PDU	size for authenticated
	      sessions.	 The default is	4194303.

       olcTCPBuffer [listener=<URL>] [{read|write}=]<size>
	      Specify the size of the TCP buffer.  A  global  value  for  both
	      read  and	 write TCP buffers related to any listener is defined,
	      unless the listener is explicitly	specified, or either the  read
	      or  write	 qualifiers  are  used.	 See tcp(7) for	details.  Note
	      that some	OS-es implement	automatic TCP buffer tuning.

       olcThreads: <integer>
	      Specify the maximum size of the primary thread  pool.   The  de-
	      fault is 16; the minimum value is	2.

       olcToolThreads: <integer>
	      Specify the maximum number of threads to use in tool mode.  This
	      should not be greater than the number of	CPUs  in  the  system.
	      The default is 1.

       olcWriteTimeout:	<integer>
	      Specify  the number of seconds to	wait before forcibly closing a
	      connection with an outstanding write.  This allows recovery from
	      various  network	hang conditions.  A setting of 0 disables this
	      feature.	The default is 0.

       If slapd	is built with support for Transport Layer Security, there  are
       more options you	can specify.

       olcTLSCipherSuite: <cipher-suite-spec>
	      Permits  configuring what	ciphers	will be	accepted and the pref-
	      erence order.  <cipher-suite-spec> should	be a cipher specifica-
	      tion  for	 the  TLS  library in use (OpenSSL, GnuTLS, or Mozilla
	      NSS).  Example:

			    olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2

			    olcTLSCiphersuite: SECURE256:!AES-128-CBC

	      To check what ciphers a given spec selects in OpenSSL, use:

		   openssl ciphers -v <cipher-suite-spec>

	      With GnuTLS the available	specs can be found in the manual  page
	      of gnutls-cli(1) (see the	description of the option --priority).

	      In  older	 versions of GnuTLS, where gnutls-cli does not support
	      the option --priority, you can obtain the	 --  more  limited  --
	      list of ciphers by calling:

		   gnutls-cli -l

	      When  using Mozilla NSS, the OpenSSL cipher suite	specifications
	      are used and translated  into  the  format  used	internally  by
	      Mozilla  NSS.  There isn't an easy way to	list the cipher	suites
	      from the command line.  The authoritative	list is	in the	source
	      code for Mozilla NSS in the file sslinfo.c in the	structure
		      static const SSLCipherSuiteInfo suiteInfo[]

       olcTLSCACertificateFile:	<filename>
	      Specifies	 the  file  that  contains certificates	for all	of the
	      Certificate Authorities that slapd will recognize.

       olcTLSCACertificatePath:	<path>
	      Specifies	the path of a directory	that contains Certificate  Au-
	      thority  certificates in separate	individual files. Usually only
	      one of this or the olcTLSCACertificateFile is defined.  If  both
	      are  specified,  both  locations will be used. This directive is
	      not supported when using GnuTLS.

	      When using  Mozilla  NSS,	 <path>	 may  contain  a  Mozilla  NSS
	      cert/key	database.   If	<path> contains	a Mozilla NSS cert/key
	      database and CA cert files, OpenLDAP will	use the	cert/key data-
	      base and will ignore the CA cert files.

       olcTLSCertificateFile: <filename>
	      Specifies	the file that contains the slapd server	certificate.

	      When  using Mozilla NSS, if using	a cert/key database (specified
	      with olcTLSCACertificatePath),  olcTLSCertificateFile  specifies
	      the name of the certificate to use:
		   olcTLSCertificateFile: Server-Cert
	      If using a token other than the internal built in	token, specify
	      the token	name first, followed by	a colon:
		   olcTLSCertificateFile: my hardware device:Server-Cert
	      Use certutil -L to list the certificates by name:
		   certutil -d /path/to/certdbdir -L

       olcTLSCertificateKeyFile: <filename>
	      Specifies	the file that contains the slapd  server  private  key
	      that matches the certificate stored in the olcTLSCertificateFile
	      file. If the private key is protected with a password, the pass-
	      word  must  be manually typed in when slapd starts.  Usually the
	      private key is not protected with	a password, to allow slapd  to
	      start  without  manual intervention, so it is of critical	impor-
	      tance that the file is protected carefully.

	      When using Mozilla NSS, olcTLSCertificateKeyFile	specifies  the
	      name  of	a  file	that contains the password for the key for the
	      certificate specified with olcTLSCertificateFile.	  The  modutil
	      command  can  be	used  to  turn off password protection for the
	      cert/key	database.   For	 example,  if  olcTLSCACertificatePath
	      specifes	/etc/openldap/certdb  as  the location of the cert/key
	      database,	use modutil  to	 change	 the  password	to  the	 empty
		   modutil -dbdir /etc/openldap/certdb -changepw 'NSS Certificate DB'
	      You  must	 have  the  old	 password, if any.  Ignore the WARNING
	      about the	running	browser.  Press	'Enter'	for the	new password.

       olcTLSDHParamFile: <filename>
	      This directive specifies the file	that contains  parameters  for
	      Diffie-Hellman  ephemeral	key exchange.  This is required	in or-
	      der to use a DSA certificate on the server, or an	 RSA  certifi-
	      cate  missing  the "key encipherment" key	usage.	Note that set-
	      ting this	option may also	enable	Anonymous  Diffie-Hellman  key
	      exchanges	 in  certain non-default cipher	suites.	 Anonymous key
	      exchanges	should generally be avoided since they provide no  ac-
	      tual  client  or server authentication and provide no protection
	      against man-in-the-middle	attacks.  You should append "!ADH"  to
	      your  cipher  suites  to	ensure that these suites are not used.
	      When using Mozilla NSS these  parameters	are  always  generated
	      randomly so this directive is ignored.

       olcTLSECName: <name>
	      Specify  the  name  of  the  curve(s)  to	use for	Elliptic curve
	      Diffie-Hellman ephemeral key exchange.  This option is only used
	      for  OpenSSL.   This  option is not used with GnuTLS; the	curves
	      may be chosen in the GnuTLS ciphersuite specification. This  op-
	      tion is also ignored for Mozilla NSS.

       olcTLSProtocolMin: <major>[.<minor>]
	      Specifies	 minimum SSL/TLS protocol version that will be negoti-
	      ated.  If	the server doesn't support at least that version,  the
	      SSL handshake will fail.	To require TLS 1.x or higher, set this
	      option to	3.(x+1), e.g.,

		   olcTLSProtocolMin: 3.2

	      would require TLS	1.1.  Specifying a minimum that	is higher than
	      that  supported by the OpenLDAP implementation will result in it
	      requiring	the highest level that it does support.	  This	direc-
	      tive is ignored with GnuTLS.

       olcTLSRandFile: <filename>
	      Specifies	 the file to obtain random bits	from when /dev/[u]ran-
	      dom is  not  available.	Generally  set	to  the	 name  of  the
	      EGD/PRNGD	socket.	 The environment variable RANDFILE can also be
	      used to specify the filename.  This directive  is	 ignored  with
	      GnuTLS and Mozilla NSS.

       olcTLSVerifyClient: <level>
	      Specifies	 what  checks  to perform on client certificates in an
	      incoming TLS session, if any.  The <level> can be	 specified  as
	      one of the following keywords:

	      never  This is the default.  slapd will not ask the client for a

	      allow  The client	certificate is requested.  If  no  certificate
		     is	 provided,  the	 session  proceeds normally.  If a bad
		     certificate is provided, it will be ignored and the  ses-
		     sion proceeds normally.

	      try    The  client  certificate is requested.  If	no certificate
		     is	provided, the session proceeds	normally.   If	a  bad
		     certificate  is provided, the session is immediately ter-

	      demand | hard | true
		     These keywords are	all equivalent,	for compatibility rea-
		     sons.   The  client certificate is	requested.  If no cer-
		     tificate is provided, or a	bad certificate	 is  provided,
		     the session is immediately	terminated.

		     Note that a valid client certificate is required in order
		     to	use the	SASL EXTERNAL authentication mechanism with  a
		     TLS  session.   As	such, a	non-default olcTLSVerifyClient
		     setting must be chosen to enable SASL EXTERNAL  authenti-

       olcTLSCRLCheck: <level>
	      Specifies	 if  the  Certificate  Revocation List (CRL) of	the CA
	      should be	used to	verify if the  client  certificates  have  not
	      been revoked. This requires olcTLSCACertificatePath parameter to
	      be set. This parameter is	ignored	with GnuTLS and	 Mozilla  NSS.
	      <level> can be specified as one of the following keywords:

	      none   No	CRL checks are performed

	      peer   Check the CRL of the peer certificate

	      all    Check the CRL for a whole certificate chain

       olcTLSCRLFile: <filename>
	      Specifies	 a file	containing a Certificate Revocation List to be
	      used for verifying that certificates have	not been revoked. This
	      parameter	is only	valid when using GnuTLS	or Mozilla NSS.

       If  slapd is compiled with --enable-modules then	the module-related en-
       tries will be available.	These entries are named	cn=module{x},cn=config
       and  must  have the olcModuleList objectClass. One entry	should be cre-
       ated per	olcModulePath.	Normally the config engine generates the "{x}"
       index  in  the  RDN  automatically, so it can be	omitted	when initially
       loading these entries.

       olcModuleLoad: <filename>
	      Specify the name of a dynamically	loadable module	to  load.  The
	      filename may be an absolute path name or a simple	filename. Non-
	      absolute names are searched for in the directories specified  by
	      the olcModulePath	option.

       olcModulePath: <pathspec>
	      Specify  a  list	of directories to search for loadable modules.
	      Typically	the path is colon-separated but	this  depends  on  the
	      operating	 system.   The default is /usr/local/libexec/openldap,
	      which is where the standard OpenLDAP install will	place its mod-

       Schema  definitions  are	 created as entries in the cn=schema,cn=config
       subtree.	These entries must have	the olcSchemaConfig  objectClass.   As
       noted above, the	actual cn=schema,cn=config entry is predefined and any
       values specified	for it are ignored.

       olcAttributetypes:    ( <oid>	[NAME <name>]	  [DESC	<description>]
	      [OBSOLETE]    [SUP <oid>]	   [EQUALITY <oid>]   [ORDERING	<oid>]
	      [SUBSTR <oid>]  [SYNTAX <oidlen>]	 [SINGLE-VALUE]	  [COLLECTIVE]
	      [NO-USER-MODIFICATION] [USAGE <attributeUsage>] )
	      Specify an attribute type	using the LDAPv3 syntax	defined	in RFC
	      4512.  The slapd parser  extends	the  RFC  4512	definition  by
	      allowing string forms as well as numeric OIDs to be used for the
	      attribute	  OID	and   attribute	  syntax   OID.	   (See	   the
	      olcObjectIdentifier description.)

       olcDitContentRules:    (	<oid>	 [NAME <name>]	  [DESC	<description>]
	      [OBSOLETE]     [AUX <oids>]      [MUST <oids>]	  [MAY <oids>]
	      [NOT <oids>] )
	      Specify  an  DIT Content Rule using the LDAPv3 syntax defined in
	      RFC 4512.	 The slapd parser extends the RFC 4512	definition  by
	      allowing string forms as well as numeric OIDs to be used for the
	      attribute	  OID	and   attribute	  syntax   OID.	   (See	   the
	      olcObjectIdentifier description.)

       olcObjectClasses: ( <oid> [NAME <name>] [DESC <description>] [OBSOLETE]
	      [SUP <oids>]  [{	ABSTRACT   |   STRUCTURAL   |	AUXILIARY   }]
	      [MUST <oids>] [MAY <oids>] )
	      Specify  an  objectclass	using the LDAPv3 syntax	defined	in RFC
	      4512.  The slapd parser  extends	the  RFC  4512	definition  by
	      allowing string forms as well as numeric OIDs to be used for the
	      object class OID.	 (See  the  olcObjectIdentifier	 description.)
	      Object classes are "STRUCTURAL" by default.

       olcObjectIdentifier: <name> { <oid> | <name>[:<suffix>] }
	      Define  a	 string	name that equates to the given OID. The	string
	      can be used in place of  the  numeric  OID  in  objectclass  and
	      attribute	 definitions.  The name	can also be used with a	suffix
	      of the form ":xx"	in which case the value	"oid.xx" will be used.

       Options in these	entries	only apply to the configuration	 of  a	single
       type  of	 backend.  All backends	may support this class of options, but
       currently     none     do.      The     entry	 must	  be	 named
       olcBackend=<databasetype>,cn=config  and	must have the olcBackendConfig
       objectClass.  <databasetype> should be one of bdb, config, dnssrv, hdb,
       ldap,  ldif, mdb, meta, monitor,	ndb, null, passwd, perl, relay,	shell,
       or sql.	At present, no backend implements any options of this type, so
       this entry should not be	used.

       Database	     options	  are	   set	    in	    entries	 named
       olcDatabase={x}<databasetype>,cn=config	  and	 must	  have	   the
       olcDatabaseConfig objectClass. Normally the config engine generates the
       "{x}" index in the  RDN	automatically,	so  it	can  be	 omitted  when
       initially loading these entries.

       The  special frontend database is always	numbered "{-1}"	and the	config
       database	is always numbered "{0}".

       Options in this section may be set in the special  "frontend"  database
       and  inherited in all the other databases. These	options	may be altered
       by further settings in each specific database. The frontend entry  must
       be    named    olcDatabase=frontend,cn=config   and   must   have   the
       olcFrontendConfig objectClass.

       olcAccess: to <what> [ by <who> <access>	<control> ]+
	      Grant access (specified by <access>) to a	set of entries	and/or
	      attributes  (specified  by  <what>)  by  one  or more requestors
	      (specified by <who>).  If	no access controls  are	 present,  the
	      default  policy  allows anyone and everyone to read anything but
	      restricts	updates	to rootdn.   (e.g.,  "olcAccess:  to  *	 by  *
	      read").	See  slapd.access(5) and the "OpenLDAP Administrator's
	      Guide" for details.

	      Access controls set in the frontend are appended to  any	access
	      controls	set  on	 the  specific	databases.   The  rootdn  of a
	      database can always read and write EVERYTHING in that database.

	      Extra special care must be taken with the	access controls	on the
	      config  database.	Unlike other databases,	the default policy for
	      the config database is to	 only  allow  access  to  the  rootdn.
	      Regular  users  should  not  have	 read access, and write	access
	      should be	granted	very carefully to privileged administrators.

       olcDefaultSearchBase: <dn>
	      Specify a	default	search base to use when	client submits a  non-
	      base  search  request with an empty base DN.  Base scoped	search
	      requests with an empty base DN are not affected.	 This  setting
	      is only allowed in the frontend entry.

       olcExtraAttrs: <attr>
	      Lists  what  attributes  need  to	 be  added to search requests.
	      Local storage backends return the	entire entry to	the  frontend.
	      The   frontend  takes  care  of  only  returning	the  requested
	      attributes that are allowed by  ACLs.   However,	features  like
	      access checking and so may need specific attributes that are not
	      automatically returned by	remote storage	backends,  like	 proxy
	      backends	and  so	on.  <attr> is an attribute that is needed for
	      internal purposes	and thus always	needs to  be  collected,  even
	      when  not	 explicitly  requested	by clients.  This attribute is

       olcPasswordHash:	<hash> [<hash>...]
	      This option  configures  one  or	more  hashes  to  be  used  in
	      generation   of	user  passwords	 stored	 in  the  userPassword
	      attribute	during processing of  LDAP  Password  Modify  Extended
	      Operations (RFC 3062).  The <hash> must be one of	{SSHA},	{SHA},
	      {SMD5}, {MD5}, {CRYPT}, and {CLEARTEXT}.	The default is {SSHA}.

	      {SHA} and	{SSHA} use  the	 SHA-1	algorithm  (FIPS  160-1),  the
	      latter with a seed.

	      {MD5}  and  {SMD5}  use the MD5 algorithm	(RFC 1321), the	latter
	      with a seed.

	      {CRYPT} uses the crypt(3).

	      {CLEARTEXT} indicates that the new password should be  added  to
	      userPassword as clear text.

	      Note   that   this   option  does	 not  alter  the  normal  user
	      applications handling of userPassword during LDAP	 Add,  Modify,
	      or  other	 LDAP operations.  This	setting	is only	allowed	in the
	      frontend entry.

       olcReadOnly: TRUE | FALSE
	      This option  puts	 the  database	into  "read-only"  mode.   Any
	      attempts	to  modify  the	 database will return an "unwilling to
	      perform" error.  By default, olcReadOnly	is  FALSE.  Note  that
	      when this	option is set TRUE on the frontend, it cannot be reset
	      without restarting the  server,  since  further  writes  to  the
	      config database will be rejected.

       olcRequires: <conditions>
	      Specify  a  set  of  conditions  to require (default none).  The
	      directive	 may  be  specified  globally	and/or	 per-database;
	      databases	   inherit    global   conditions,   so	  per-database
	      specifications are additive.  bind requires bind operation prior
	      to  directory  operations.   LDAPv3 requires session to be using
	      LDAP  version  3.	  authc	 requires  authentication   prior   to
	      directory	 operations.   SASL requires SASL authentication prior
	      to directory operations.	strong requires	strong	authentication
	      prior  to	 directory  operations.	  The  strong  keyword	allows
	      protected	  "simple"   authentication   as    well    as	  SASL
	      authentication.	none  may  be  used  to	 require no conditions
	      (useful to clear out globally set	conditions within a particular
	      database); it must occur first in	the list of conditions.

       olcRestrict: <oplist>
	      Specify  a list of operations that are restricted.  Restrictions
	      on  a  specific  database	  override   any   frontend   setting.
	      Operations   can	 be   any   of	add,  bind,  compare,  delete,
	      extended[=<OID>],	modify,	rename,	search,	or the special pseudo-
	      operations read and write, which respectively summarize read and
	      write operations.	 The use of restrict write  is	equivalent  to
	      olcReadOnly:  TRUE (see above).  The extended keyword allows one
	      to indicate the OID of the specific operation to be restricted.

       olcSchemaDN: <dn>
	      Specify the distinguished	name for the subschema	subentry  that
	      controls	 the   entries	 on   this  server.   The  default  is

       olcSecurity: <factors>
	      Specify a	set of security	strength factors (separated  by	 white
	      space)  to  require  (see	 olcSaslSecprops's minssf option for a
	      description of security strength factors).  The directive	may be
	      specified	 globally  and/or per-database.	 ssf=<n> specifies the
	      overall security strength	factor.	 transport=<n>	specifies  the
	      transport	 security  strength factor.  tls=<n> specifies the TLS
	      security strength	factor.	 sasl=<n> specifies the	SASL  security
	      strength	factor.	 update_ssf=<n>	specifies the overall security
	      strength	 factor	  to   require	  for	 directory    updates.
	      update_transport=<n>  specifies  the transport security strength
	      factor  to  require  for	directory   updates.	update_tls=<n>
	      specifies	 the  TLS  security  strength  factor  to  require for
	      directory	updates.  update_sasl=<n> specifies the	SASL  security
	      strength	  factor    to	  require   for	  directory   updates.
	      simple_bind=<n> specifies	the security strength factor  required
	      for  simple  username/password  authentication.	Note  that the
	      transport	 factor	 is  measure  of  security  provided  by   the
	      underlying  transport, e.g. ldapi:// (and	eventually IPSEC).  It
	      is not normally used.

       olcSizeLimit: {<integer>|unlimited}

       olcSizeLimit: size[.{soft|hard|unchecked}]=<integer> [...]
	      Specify the maximum number of entries to return  from  a	search
	      operation.   The	default	 size  limit is	500.  Use unlimited to
	      specify no limits.   The	second	format	allows	a  fine	 grain
	      setting of the size limits.  Extra args can be added in the same
	      value or as additional values.  See olcLimits for	an explanation
	      of the different flags.

       olcSortVals: <attr> [...]
	      Specify  a  list	of  multi-valued  attributes whose values will
	      always be	maintained in sorted order.  Using  this  option  will
	      allow   Modify,	Compare,   and	filter	evaluations  on	 these
	      attributes to be performed more efficiently. The resulting  sort
	      order  depends  on the attributes' syntax	and matching rules and
	      may not correspond to lexical order or  any  other  recognizable
	      order.  This setting is only allowed in the frontend entry.

       olcTimeLimit: {<integer>|unlimited}

       olcTimeLimit: time[.{soft|hard}]=<integer> [...]
	      Specify  the maximum number of seconds (in real time) slapd will
	      spend answering a	search request.	 The  default  time  limit  is
	      3600.   Use  unlimited  to specify no limits.  The second	format
	      allows a fine grain setting of the time limits.  Extra args  can
	      be  added	 in  the  same	value  or  as  additional values.  See
	      olcLimits	for an explanation of the different flags.

       Options in this section only apply to the specific database  for	 which
       they  are defined.  They	are supported by every type of backend.	All of
       the Global Database Options may also be used here.

       olcAddContentAcl: TRUE |	FALSE
	      Controls whether Add operations will perform ACL checks  on  the
	      content  of the entry being added. This check is off by default.
	      See the slapd.access(5) manual page  for	more  details  on  ACL
	      requirements for Add operations.

       olcHidden: TRUE | FALSE
	      Controls	whether	the database will be used to answer queries. A
	      database that is hidden will never be  selected  to  answer  any
	      queries,	and  any  suffix  configured  on  the database will be
	      ignored  in  checks  for	conflicts  with	 other	databases.  By
	      default, olcHidden is FALSE.

       olcLastMod: TRUE	| FALSE
	      Controls	 whether   slapd   will	  automatically	 maintain  the
	      modifiersName,	  modifyTimestamp,	creatorsName,	   and
	      createTimestamp  attributes  for	entries.  It also controls the
	      entryCSN and entryUUID  attributes,  which  are  needed  by  the
	      syncrepl provider. By default, olcLastMod	is TRUE.

       olcLimits: <selector> <limit> [<limit> [...]]
	      Specify  time and	size limits based on the operation's initiator
	      or base DN.  The argument	<selector> can be any of

		     anonymous	  |    users	|    [<dnspec>=]<pattern>    |


		     <dnspec> ::= dn[.<type>][.<style>]

		     <type>  ::= self |	this

		     <style>  ::= exact	| base | onelevel | subtree | children
		     | regex | anonymous

	      DN type self is the default and means the	bound user, while this
	      means  the base DN of the	operation.  The	term anonymous matches
	      all  unauthenticated  clients.   The  term  users	 matches   all
	      authenticated  clients; otherwise	an exact dn pattern is assumed
	      unless otherwise specified  by  qualifying  the  (optional)  key
	      string dn	with exact or base (which are synonyms), to require an
	      exact match; with	onelevel, to  require  exactly	one  level  of
	      depth  match;  with  subtree, to allow any level of depth	match,
	      including	the exact match; with children,	to allow any level  of
	      depth  match,  not  including  the exact match; regex explicitly
	      requires the  (default)  match  based  on	 POSIX	(''extended'')
	      regular  expression pattern.  Finally, anonymous matches unbound
	      operations; the pattern field is ignored.	 The same behavior  is
	      obtained	by  using the anonymous	form of	the <selector> clause.
	      The  term	 group,	 with  the   optional	objectClass   oc   and
	      attributeType  at	 fields,  followed by pattern, sets the	limits
	      for any DN listed	in the values of  the  at  attribute  (default
	      member) of the oc	group objectClass (default groupOfNames) whose
	      DN exactly matches pattern.

	      The currently supported limits are size and time.

	      The syntax  for  time  limits  is	 time[.{soft|hard}]=<integer>,
	      where  integer  is  the  number  of  seconds  slapd  will	 spend
	      answering	a search request.  If  no  time	 limit	is  explicitly
	      requested	 by  the  client,  the	soft  limit  is	 used;	if the
	      requested	time limit exceeds the hard limit, the	value  of  the
	      limit  is	used instead.  If the hard limit is set	to the keyword
	      soft, the	soft limit is used in either case; if it is set	to the
	      keyword unlimited, no hard limit is enforced.  Explicit requests
	      for time limits smaller or equal to the hard limit are  honored.
	      If  no limit specifier is	set, the value is assigned to the soft
	      limit, and the hard limit	 is  set  to  soft,  to	 preserve  the
	      original behavior.

	      The	 syntax	       for	  size	      limits	    is
	      size[.{soft|hard|unchecked}]=<integer>,  where  integer  is  the
	      maximum  number  of entries slapd	will return answering a	search
	      request.	If no  size  limit  is	explicitly  requested  by  the
	      client,  the  soft  limit	 is  used; if the requested size limit
	      exceeds the hard limit, the value	of the limit is	used  instead.
	      If  the hard limit is set	to the keyword soft, the soft limit is
	      used in either case; if it is set	to the keyword	unlimited,  no
	      hard  limit  is  enforced.   Explicit  requests  for size	limits
	      smaller or equal to the hard limit are honored.	The  unchecked
	      specifier	 sets  a  limit	 on  the number	of candidates a	search
	      request is allowed to examine.  The rationale behind it is  that
	      searches for non-properly	indexed	attributes may result in large
	      sets of candidates,  which  must	be  examined  by  slapd(8)  to
	      determine	 whether  they	match  the  search filter or not.  The
	      unchecked	limit provides a means to drop such operations	before
	      they  are	 even  started.	 If the	selected candidates exceed the
	      unchecked	 limit,	 the  search  will  abort  with	 Unwilling  to
	      perform.	 If  it	 is  set to the	keyword	unlimited, no limit is
	      applied (the default).  If it is set to disable, the  search  is
	      not  even	performed; this	can be used to disallow	searches for a
	      specific set of users.  If no limit specifier is set, the	 value
	      is  assigned  to	the  soft  limit, and the hard limit is	set to
	      soft, to preserve	the original behavior.

	      In case of no match, the global limits are  used.	  The  default
	      values  are  the	same  as for olcSizeLimit and olcTimeLimit; no
	      limit is set on unchecked.

	      If pagedResults control is requested, the	 hard  size  limit  is
	      used  by default,	because	the request of a specific page size is
	      considered an explicit request for a limitation on the number of
	      entries  to be returned.	However, the size limit	applies	to the
	      total count of entries returned within the search, and not to  a
	      single page.  Additional size limits may be enforced; the	syntax
	      is{<integer>|noEstimate|unlimited},  where  integer  is
	      the  max	page  size  if	no  explicit limit is set; the keyword
	      noEstimate inhibits the server from returning an estimate	of the
	      total  number  of	 entries  that	might  be  returned (note: the
	      current implementation  does  not	 return	 any  estimate).   The
	      keyword  unlimited  indicates  that  no  limit is	applied	to the
	      pagedResults     control	   page	    size.      The	syntax
	      size.prtotal={<integer>|unlimited|disabled}  allows one to set a
	      limit on the total  number  of  entries  that  the  pagedResults
	      control  will  return.   By default it is	set to the hard	limit.
	      When set,	integer	is the max number of entries  that  the	 whole
	      search  with  pagedResults control can return.  Use unlimited to
	      allow unlimited number of	entries	to be returned,	e.g. to	 allow
	      the  use	of  the	 pagedResults control as a means to circumvent
	      size limitations	on  regular  searches;	the  keyword  disabled
	      disables	the  control,  i.e.  no	paged results can be returned.
	      Note  that  the  total  number  of  entries  returned  when  the
	      pagedResults  control  is	 requested cannot exceed the hard size
	      limit of regular searches	unless extended	by the prtotal switch.

       olcMaxDerefDepth: <depth>
	      Specifies	the maximum number  of	aliases	 to  dereference  when
	      trying  to resolve an entry, used	to avoid infinite alias	loops.
	      The default is 15.

       olcMirrorMode: TRUE | FALSE
	      This option puts a consumer database into	"mirror" mode.	Update
	      operations  will	be  accepted  from  any	 user,	not  just  the
	      updatedn.	 The database must already be configured  as  syncrepl
	      consumer	before	this  keyword  may  be	set.   This  mode also
	      requires	a  olcServerID	(see  above)  to  be  configured.   By
	      default, this setting is FALSE.

       olcPlugin: <plugin_type>	<lib_path> <init_function> [<arguments>]
	      Configure	 a  SLAPI  plugin. See the slapd.plugin(5) manpage for
	      more details.

       olcRootDN: <dn>
	      Specify the distinguished	name that is  not  subject  to	access
	      control  or  administrative limit	restrictions for operations on
	      this database.  This DN may or may not  be  associated  with  an
	      entry.   An empty	root DN	(the default) specifies	no root	access
	      is to be granted.	 It is recommended that	 the  rootdn  only  be
	      specified	 when  needed  (such  as  when	initially populating a
	      database).  If the rootdn	is within a namingContext (suffix)  of
	      the  database, a simple bind password may	also be	provided using
	      the olcRootPW directive. Note that the rootdn is	always	needed
	      when  using  syncrepl.   The olcRootDN of	the cn=config database
	      defaults to cn=config itself.

       olcRootPW: <password>
	      Specify a	password (or hash of the  password)  for  the  rootdn.
	      The  password  can  only	be  set	 if  the  rootdn is within the
	      namingContext (suffix) of	the database.  This option accepts all
	      RFC   2307   userPassword	 formats  known	 to  the  server  (see
	      olcPasswordHash	description)	as    well    as    cleartext.
	      slappasswd(8)  may  be  used  to	generate a hash	of a password.
	      Cleartext	and {CRYPT} passwords are not recommended.   If	 empty
	      (the  default),  authentication of the root DN is	by other means
	      (e.g. SASL).  Use	of SASL	is encouraged.

       olcSubordinate: [TRUE | FALSE | advertise]
	      Specify that the current backend database	is  a  subordinate  of
	      another  backend database. A subordinate	database may have only
	      one suffix. This option may be used to glue  multiple  databases
	      into  a  single  namingContext.	If  the	 suffix	of the current
	      database is within the namingContext  of	a  superior  database,
	      searches against the superior database will be propagated	to the
	      subordinate as well. All of  the	databases  associated  with  a
	      single namingContext should have identical rootdns.  Behavior of
	      other  LDAP  operations  is  unaffected  by  this	 setting.   In
	      particular,  it  is  not	possible to use	moddn to move an entry
	      from  one	 subordinate  to  another   subordinate	  within   the

	      If  the  optional	advertise flag is supplied, the	naming context
	      of this database is advertised in	the root DSE. The  default  is
	      to hide this database context, so	that only the superior context
	      is visible.

	      If the slap tools	slapcat(8), slapadd(8),	 or  slapindex(8)  are
	      used  on	the  superior  database,  any  glued subordinates that
	      support these tools are opened as	well.

	      Databases	that are glued together	should usually	be  configured
	      with the same indices (assuming they support indexing), even for
	      attributes that only  exist  in  some  of	 these	databases.  In
	      general,	all  of	 the  glued  databases should be configured as
	      similarly	as possible,  since  the  intent  is  to  provide  the
	      appearance of a single directory.

	      Note   that   the	  subordinate	functionality  is  implemented
	      internally by the	glue overlay and as  such  its	behavior  will
	      interact	with  other  overlays  in  use.	 By  default, the glue
	      overlay is automatically configured as the last overlay  on  the
	      superior	 database.   Its  position  on	the  database  can  be
	      explicitly configured by setting an overlay  glue	 directive  at
	      the  desired  position. This explicit configuration is necessary
	      e.g.  when using the syncprov overlay,  which  needs  to	follow
	      glue in order to work over all of	the glued databases. E.g.
		   dn: olcDatabase={1}mdb,cn=config
		   olcSuffix: dc=example,dc=com

		   dn: olcOverlay={0}glue,olcDatabase={1}mdb,cn=config

		   dn: olcOverlay={1}syncprov,olcDatabase={1}mdb,cn=config
       See the Overlays	section	below for more details.

       olcSuffix: <dn suffix>
	      Specify  the  DN	suffix	of queries that	will be	passed to this
	      backend database.	 Multiple suffix lines can  be	given  and  at
	      least one	is required for	each database definition.

	      If  the  suffix of one database is "inside" that of another, the
	      database	with  the  inner  suffix  must	come  first   in   the
	      configuration  file.   You  may also want	to glue	such databases
	      together with the	olcSubordinate attribute.

       olcSyncUseSubentry: TRUE	| FALSE
	      Store the	syncrepl contextCSN  in	 a  subentry  instead  of  the
	      context  entry  of  the  database.  The  subentry's  RDN will be
	      "cn=ldapsync". The default is FALSE, meaning the	contextCSN  is
	      stored in	the context entry.

       olcSyncrepl:   rid=<replica   ID>  provider=ldap[s]://<hostname>[:port]
	      searchbase=<base	  DN>	  [type=refreshOnly|refreshAndPersist]
	      [interval=dd:hh:mm:ss]	[retry=[<retry	  interval>    <#   of
	      retries>]+]  [filter=<filter  str>]  [scope=sub|one|base|subord]
	      [attrs=<attr    list>]	[exattrs=<attr	  list>]   [attrsonly]
	      [sizelimit=<limit>] [timelimit=<limit>]  [schemachecking=on|off]
	      [network-timeout=<seconds>]		   [timeout=<seconds>]
	      [bindmethod=simple|sasl]	   [binddn=<dn>]     [saslmech=<mech>]
	      [authcid=<identity>] [authzid=<identity>]	[credentials=<passwd>]
	      [realm=<realm>]			       [secprops=<properties>]
	      [keepalive=<idle>:<probes>:<interval>]   [starttls=yes|critical]
	      [tls_cert=<file>]	     [tls_key=<file>]	   [tls_cacert=<file>]
	      [tls_cacertdir=<path>]	  [tls_reqcert=never|allow|try|demand]
	      [tls_reqsan=never|allow|try|demand] [tls_cipher_suite=<ciphers>]
	      [tls_ecname=<names>]		  [tls_crlcheck=none|peer|all]
	      [tls_protocol_min=<major>[.<minor>]]  [suffixmassage=<real  DN>]
	      [logbase=<base	    DN>]	[logfilter=<filter	 str>]
	      Specify the current database as a	consumer which is kept	up-to-
	      date  with  the  provider	 content  by  establishing the current
	      slapd(8) as a  replication  consumer  site  running  a  syncrepl
	      replication  engine.   The consumer content is kept synchronized
	      to the provider content using the	LDAP  Content  Synchronization
	      protocol.	 Refer	to  the	 "OpenLDAP  Administrator's Guide" for
	      detailed information on setting up a replicated slapd  directory
	      service using the	syncrepl replication engine.

	      rid   identifies	the  current  syncrepl	directive  within  the
	      replication consumer site.  It is	a non-negative integer	having
	      no more than three decimal digits.

	      provider	specifies the replication provider site	containing the
	      provider content as an LDAP URI. If <port>  is  not  given,  the
	      standard LDAP port number	(389 or	636) is	used.

	      The  content  of the syncrepl consumer is	defined	using a	search
	      specification as its result set. The consumer  slapd  will  send
	      search  requests	to  the	provider slapd according to the	search
	      specification. The  search  specification	 includes  searchbase,
	      scope,   filter,	attrs,	attrsonly,  sizelimit,	and  timelimit
	      parameters as in the normal search  specification.  The  exattrs
	      option  may  also	 be  used to specify attributes	that should be
	      omitted from incoming entries.  The scope	defaults to  sub,  the
	      filter  defaults	to  (objectclass=*),  and  there is no default
	      searchbase. The attrs list defaults to "*,+" to return all  user
	      and  operational attributes, and attrsonly and exattrs are unset
	      by default.  The sizelimit and timelimit only accept "unlimited"
	      and  positive  integers, and both	default	to "unlimited".	 Note,
	      however, that  any  provider-side	 limits	 for  the  replication
	      identity	will  be  enforced  by	the provider regardless	of the
	      limits requested by the LDAP Content Synchronization  operation,
	      much like	for any	other search operation.

	      The  LDAP	 Content  Synchronization  protocol  has two operation
	      types.  In the refreshOnly operation, the	 next  synchronization
	      search operation is periodically rescheduled at an interval time
	      (specified by interval parameter;	1 day by default)  after  each
	      synchronization  operation  finishes.   In the refreshAndPersist
	      operation, a synchronization search remains  persistent  in  the
	      provider	slapd.	 Further updates to the	provider will generate
	      searchResultEntry	to the consumer	slapd as the search  responses
	      to  the persistent synchronization search. If the	initial	search
	      fails due	to an error, the next synchronization search operation
	      is  periodically	rescheduled  at	an interval time (specified by
	      interval parameter; 1 day	by default)

	      If an error occurs during	replication, the consumer will attempt
	      to reconnect according to	the retry parameter which is a list of
	      the <retry interval> and <# of  retries>	pairs.	 For  example,
	      retry="60	10 300 3" lets the consumer retry every	60 seconds for
	      the first	10 times and then retry	every 300 seconds for the next
	      3	 times	before	stop retrying. The `+' in <# of	retries> means
	      indefinite number	of retries until success.

	      The schema checking can be enforced at the  LDAP	Sync  consumer
	      site  by turning on the schemachecking parameter.	The default is

	      The network-timeout parameter sets how long  the	consumer  will
	      wait  to	establish a network connection to the provider.	Once a
	      connection is established, the timeout parameter determines  how
	      long  the	 consumer  will	 wait  for the initial Bind request to
	      complete.	 The  defaults	for   these   parameters   come	  from

	      A	  bindmethod   of  simple  requires  the  options  binddn  and
	      credentials and should  only  be	used  when  adequate  security
	      services (e.g. TLS or IPSEC) are in place.  A bindmethod of sasl
	      requires the option saslmech.  Depending on  the	mechanism,  an
	      authentication  identity	and/or	credentials  can  be specified
	      using authcid and	credentials.  The  authzid  parameter  may  be
	      used  to	specify	 an authorization identity.  Specific security
	      properties (as with the sasl-secprops keyword above) for a  SASL
	      bind  can	 be  set  with the secprops option. A non default SASL
	      realm can	be set with the	realm  option.	 The  provider,	 other
	      than allow authentication	of the syncrepl	identity, should grant
	      that identity appropriate	access privileges to the data that  is
	      being  replicated	 (access  directive), and appropriate time and
	      size limits (limits directive).

	      The keepalive parameter sets the values  of  idle,  probes,  and
	      interval	used  to  check	whether	a socket is alive; idle	is the
	      number of	seconds	a connection needs to remain idle  before  TCP
	      starts sending keepalive probes; probes is the maximum number of
	      keepalive	probes TCP should send before dropping the connection;
	      interval	is  interval  in  seconds between individual keepalive
	      probes.  Only some systems support the  customization  of	 these
	      values;  the  keepalive  parameter  is  ignored  otherwise,  and
	      system-wide settings are used.

	      The starttls parameter specifies use of  the  StartTLS  extended
	      operation	 to  establish	a  TLS	session	 before	Binding	to the
	      provider.	If the critical	argument is supplied, the session will
	      be aborted if the	StartTLS request fails.	Otherwise the syncrepl
	      session continues	without	TLS. The tls_reqcert setting  defaults
	      to "demand", the tls_reqsan setting defaults to "allow", and the
	      other TLS	settings default to the	same as	 the  main  slapd  TLS

	      The  suffixmassage parameter allows the consumer to pull entries
	      from a remote directory whose DN suffix differs from  the	 local
	      directory.  The  portion of the remote entries' DNs that matches
	      the searchbase will be replaced with the suffixmassage DN.

	      Rather than replicating whole entries, the  consumer  can	 query
	      logs  of	data modifications. This mode of operation is referred
	      to as delta syncrepl. In addition	to the above  parameters,  the
	      logbase  and  logfilter parameters must be set appropriately for
	      the log that will	be used. The syncdata parameter	must be	set to
	      either "accesslog" if the	log conforms to	the slapo-accesslog(5)
	      log format, or "changelog" if the	log conforms to	 the  obsolete
	      changelog	format.	If the syncdata	parameter is omitted or	set to
	      "default"	then the log parameters	are ignored.

       olcUpdateDN: <dn>
	      This option is  only  applicable	in  a  replica	database.   It
	      specifies	  the  DN  permitted  to  update  (subject  to	access
	      controls)	the replica.  It is only needed	in  certain  push-mode
	      replication  scenarios.	Generally,  this  DN should not	be the
	      same as the rootdn used at the provider.

       olcUpdateRef: <url>
	      Specify the referral to pass back	 when  slapd(8)	 is  asked  to
	      modify  a	 replicated  local  database.	If multiple values are
	      specified, each url is provided.

       Each database  may  allow  specific  configuration  options;  they  are
       documented   separately	 in   the  backends'  manual  pages.  See  the
       slapd.backends(5) manual	page for an overview of	available backends.

       An overlay is a piece of	code that intercepts  database	operations  in
       order  to  extend or change them. Overlays are pushed onto a stack over
       the database, and so they will execute in the reverse of	the  order  in
       which they were configured and the database itself will receive control
       last of all.

       Overlays	must be	configured as child entries of	a  specific  database.
       The entry's RDN must be of the form olcOverlay={x}<overlaytype> and the
       entry must have the olcOverlayConfig objectClass. Normally  the	config
       engine generates	the "{x}" index	in the RDN automatically, so it	can be
       omitted when initially loading these entries.

       See the slapd.overlays(5) manual	page  for  an  overview	 of  available

       Here  is	 a  short  example of a	configuration in LDIF suitable for use
       with slapadd(8) :

	      dn: cn=config
	      objectClass: olcGlobal
	      cn: config
	      olcPidFile: /var/db/run/
	      olcAttributeOptions: x-hidden lang-

	      dn: cn=schema,cn=config
	      objectClass: olcSchemaConfig
	      cn: schema

	      include: file:///usr/local/etc/openldap/schema/core.ldif

	      dn: olcDatabase=frontend,cn=config
	      objectClass: olcDatabaseConfig
	      objectClass: olcFrontendConfig
	      olcDatabase: frontend
	      #	Subtypes of "name" (e.g. "cn" and "ou")	with the
	      #	option ";x-hidden" can be searched for/compared,
	      #	but are	not shown.  See	slapd.access(5).
	      olcAccess: to attrs=name;x-hidden	by * =cs
	      #	Protect	passwords.  See	slapd.access(5).
	      olcAccess: to attrs=userPassword	by * auth
	      #	Read access to other attributes	and entries.
	      olcAccess: to * by * read

	      #	set a rootpw for the config database so	we can bind.
	      #	deny access to everyone	else.
	      dn: olcDatabase=config,cn=config
	      objectClass: olcDatabaseConfig
	      olcDatabase: config
	      olcRootPW: {SSHA}XKYnrjvGT3wZFQrDD5040US592LxsdLy
	      olcAccess: to * by * none

	      dn: olcDatabase=bdb,cn=config
	      objectClass: olcDatabaseConfig
	      objectClass: olcBdbConfig
	      olcDatabase: bdb
	      olcSuffix: "dc=our-domain,dc=com"
	      #	The database directory MUST exist prior	to
	      #	running	slapd AND should only be accessible
	      #	by the slapd/tools. Mode 0700 recommended.
	      olcDbDirectory: /var/db/openldap-data
	      #	Indices	to maintain
	      olcDbIndex:     objectClass  eq
	      olcDbIndex:     cn,sn,mail   pres,eq,approx,sub

	      #	We serve small clients that do not handle referrals,
	      #	so handle remote lookups on their behalf.
	      dn: olcDatabase=ldap,cn=config
	      objectClass: olcDatabaseConfig
	      objectClass: olcLdapConfig
	      olcDatabase: ldap
	      olcSuffix: ""
	      olcDbUri:	ldap://

       Assuming	the above data was saved in a file named "config.ldif" and the
       /usr/local/etc/openldap/slapd.d	 directory   has  been	created,  this
       command will initialize the configuration:
	      slapadd -F /usr/local/etc/openldap/slapd.d -n 0 -l config.ldif

       "OpenLDAP Administrator's Guide"	contains a longer annotated example of
       a slapd configuration.

       Alternatively,  an existing slapd.conf file can be converted to the new
       format using slapd or any of the	slap tools:
	      slaptest -f /usr/local/etc/openldap/slapd.conf -F	/usr/local/etc/openldap/slapd.d

	      default slapd configuration file

	      default slapd configuration directory

       ldap(3),	ldif(5),  gnutls-cli(1),  slapd.access(5),  slapd.backends(5),
       slapd.conf(5),	  slapd.overlays(5),	 slapd.plugin(5),    slapd(8),
       slapacl(8),    slapadd(8),    slapauth(8),    slapcat(8),    slapdn(8),
       slapindex(8), slappasswd(8), slaptest(8).

       "OpenLDAP Administrator's Guide"	(

       OpenLDAP	 Software  is developed	and maintained by The OpenLDAP Project
       <>.  OpenLDAP  Software	is  derived  from  the
       University of Michigan LDAP 3.3 Release.

OpenLDAP 2.4.57			  2021/01/18		       SLAPD-CONFIG(5)


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

home | help