slapd-config man page on AIX

Man page or keyword search:  
man Server   4752 pages
apropos Keyword Search (all sections)
Output format
AIX logo
[printable version]

SLAPD-CONFIG(5)						       SLAPD-CONFIG(5)

NAME
       slapd-config - configuration backend to slapd

SYNOPSIS
       /etc/openldap/slapd.d

DESCRIPTION
       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.
       Dynamic changes are only saved when slapd is  running  from  a  slapd.d
       configuration 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:

	      cn=Module
		     dynamically loaded modules

	      cn=Schema
		     schema definitions

	      olcBackend=xxx
		     backend-specific settings

	      olcDatabase=xxx
		     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
       entry 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‐
       fig.

       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
       instance. 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
       individual 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.

GLOBAL CONFIGURATION OPTIONS
       Options described in this section apply	to  the	 server	 as  a	whole.
       Arguments  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
	      allows 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.
	      update_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‐
	      its).

       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
	      `x-foo-bar-baz'.

	      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‐
	      mixed.

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

		     ldap:///<base>??[<scope>]?<filter>
		     dn[.<dnstyle>]:<pattern>
		     u[<mech>[<realm>]]:<pattern>
		     group[/objectClass[/attributeType]]:<pattern>
		     <pattern>

		     <dnstyle>:={exact|onelevel|children|subtree|regex}

	      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
	      according	 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
	      objectClass and member attributeType.  The group with  DN	 <pat‐
	      tern>  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 pro‐
	      vided, i.e. only <pattern> is present, an exact DN  is  assumed;
	      as  a  consequence,  <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
	      authorization  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

		     UID=<username>[[,CN=<realm>],CN=<mechanism>],CN=auth

	      This   name   is	 then	compared   against   the  match	 POSIX
	      (''extended'') regular expression, and if the match is  success‐
	      ful, the name is replaced with the replace string.  If there are
	      wildcard strings	in  the	 match	regular	 expression  that  are
	      enclosed in parenthesis, e.g.

		     UID=([^,]*),CN=.*

	      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.

		     UID=$1,OU=Accounts,DC=example,DC=com

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

		     ldap:///OU=Accounts,DC=example,DC=com??one?(UID=$1)

	      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‐
	      ject.

	      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
	      "require	authc").  bind_simple disables simple (bind) authenti‐
	      cation.  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
	      tls_2_anon).

       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
	      operations return unwilling-to-perform,  though.	 Slapd	termi‐
	      nates  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
	      currently	 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
	      option.

       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
	      ignored. 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
	      2.

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

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

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

       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/opera‐
			    tions/results
		     512    (0x200 stats2) stats log entries sent
		     1024   (0x400 shell) print communication with shell back‐
			    ends
		     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 brackets,  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
	      olcLogLevel  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
	      attributes  for  the root DSE.  These attributes are returned in
	      addition 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
	      processing.

       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
	      default, "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".   These  IDs  are
	      required when using multimaster replication and each master must
	      have a unique ID. Note that this	requirement  also  applies  to
	      separate	masters	 contributing to a glued set of databases.  If
	      the URL is provided, this directive may  be  specified  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.  Example:

	    olcServerID: 1 ldap://ldap1.example.com
	    olcServerID: 2 ldap://ldap2.example.com

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

TLS OPTIONS
       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 OpenSSL.	 Example:

	      olcTLSCipherSuite: HIGH:MEDIUM:+SSLv2

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

		   openssl ciphers -v <cipher-suite-spec>

	      To obtain the list of ciphers in GNUtls use:

		   gnutls-cli -l

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

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

       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.

       olcTLSDHParamFile: <filename>
	      This  directive  specifies the file that contains parameters for
	      Diffie-Hellman ephemeral key  exchange.	This  is  required  in
	      order  to	 use a DSA certificate on the server. If multiple sets
	      of parameters are present in the file, all of them will be  pro‐
	      cessed.  Note that setting this option may also enable Anonymous
	      Diffie-Hellman  key  exchanges  in  certain  non-default	cipher
	      suites.	You  should append "!ADH" to your cipher suites if you
	      have changed them from the  default,  otherwise  no  certificate
	      exchanges	 or verification will be done. When using GNUtls these
	      parameters are always generated randomly so  this	 directive  is
	      ignored.

       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.

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

	      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‐
		     minated.

	      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‐
		     cation.

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

DYNAMIC MODULE OPTIONS
       If  slapd  is  compiled	with  --enable-modules then the module-related
       entries will be available. These entries are named cn=module{x},cn=con‐
       fig  and	 must  have the olcModuleList objectClass. One entry should be
       created per olcModulePath.  Normally the config	engine	generates  the
       "{x}"  index  in	 the RDN automatically, so it can be omitted when ini‐
       tially 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 /opt/freeware/lib/openldap,
	      which is where the standard OpenLDAP install will place its mod‐
	      ules.

SCHEMA OPTIONS
       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.

GENERAL BACKEND OPTIONS
       Options in these entries only apply to the configuration	 of  a	single
       type  of	 backend. All backends may support this class of options.  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, meta,  monitor,	 null,	passwd,	 perl,
       relay, shell, or sql.  At present, no backend implements any options of
       this type.

DATABASE OPTIONS
       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}".

GLOBAL DATABASE OPTIONS
       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.

       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 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
	      "cn=Subschema".

       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.

GENERAL DATABASE OPTIONS
       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>    |
		     group[/oc[/at]]=<pattern>

	      with

		     <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 size.pr={<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  to	set  a
	      limit on the total number of entries that a pagedResults control
	      allows to 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 replica 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
	      namingContext.

	      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}bdb,cn=config
		   olcSuffix: dc=example,dc=com
		   ...

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

		   dn: olcOverlay={1}syncprov,olcDatabase={1}bdb,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_ciphersuite=<ciphers>]	  [tls_crlcheck=none|peer|all]
	      [logbase=<base	    DN>]	[logfilter=<filter	 str>]
	      [syncdata=default|accesslog|changelog]
	      Specify the current database as a replica which is  kept	up-to-
	      date  with  the  master  content	by  establishing  the  current
	      slapd(8) as a  replication  consumer  site  running  a  syncrepl
	      replication engine.  The replica content is kept synchronized to
	      the  master  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
	      master 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 replica 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 master replica will
	      generate searchResultEntry to the consumer slapd as  the	search
	      responses to the persistent synchronization search.

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

	      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
	      ldap.conf(5).

	      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" and the other TLS settings default to	 the  same  as
	      the main slapd TLS settings.

	      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	 slave	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 master.

       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.

DATABASE-SPECIFIC OPTIONS
       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.

OVERLAYS
       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
       overlays.

EXAMPLES
       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/run/slapd.pid
	      olcAttributeOptions: x-hidden lang-

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

	      include: /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/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://ldap.some-server.com/

       Assuming the above data was saved in a file named "config.ldif" and the
       /etc/openldap/slapd.d directory has been	 created,  this	 command  will
       initialize the configuration:
	      slapadd -F /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 /etc/openldap/slapd.conf -F /etc/openldap/slapd.d

FILES
       /etc/openldap/slapd.conf
	      default slapd configuration file

       /etc/openldap/slapd.d
	      default slapd configuration directory

SEE ALSO
       ldap(3),	 ldif(5),  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" (http://www.OpenLDAP.org/doc/admin/)

ACKNOWLEDGEMENTS
       OpenLDAP Software is developed and maintained by The  OpenLDAP  Project
       <http://www.openldap.org/>.    OpenLDAP	 Software   is	 derived  from
       University of Michigan LDAP 3.3 Release.

OpenLDAP 2.4.23			  2010/06/30		       SLAPD-CONFIG(5)
[top]
                             _         _         _ 
                            | |       | |       | |     
                            | |       | |       | |     
                         __ | | __ __ | | __ __ | | __  
                         \ \| |/ / \ \| |/ / \ \| |/ /  
                          \ \ / /   \ \ / /   \ \ / /   
                           \   /     \   /     \   /    
                            \_/       \_/       \_/ 
More information is available in HTML format for server AIX

List of man pages available for AIX

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net