• Last 5 Forum Topics
    Last post

The Web Only This Site



  • MARC

    Mailing list ARChives
    - Search by -


    Computing Dictionary

  • Text Link Ads

  • LINUX man pages
  • Linux Man Page Viewer

    The following form allows you to view linux man pages.







           The slapd.conf(5)  file  contains  configuration  information  for  the
           slapd(8)  daemon.  This  configuration  file  is also used by the SLAPD
           tools  slapacl(8),  slapadd(8),  slapauth(8),  slapcat(8),   slapdn(8),
           slapindex(8), and slaptest(8).
           The  slapd.conf  file  consists  of  a  series  of global configuration
           options that apply to slapd as a whole (including all  backends),  fol-
           lowed  by zero or more database backend definitions that contain infor-
           mation specific to a backend instance.
           The general format of slapd.conf is as follows:
               # comment - these options apply to every database
               <global configuration options>
               # first database definition & configuration options
               database    <backend 1 type>
               <configuration options specific to backend 1>
               # subsequent database definitions & configuration options
           Both the global configuration and  each  backend-specific  section  can
           contain access information.  Backend-specific access control directives
           are used for those entries that belong to  the  backend,  according  to
           their naming context.  In case no access control directives are defined
           for a backend or those which are defined are not applicable, the direc-
           tives from the global configuration section are then used.
           If no access controls are present, the default policy allows anyone and
           everyone to read anything but  restricts  updates  to  rootdn.   (e.g.,
           "access to * by * read").
           When  dealing  with  an  access list, because the global access list is
           effectively appended to each per-database list, if the  resulting  list
           is non-empty then the access list will end with an implicit access to *
           by * none directive. If there are no access directives applicable to  a
           backend, then a default read is used.
           Be warned: the rootdn can always read and write EVERYTHING!
           For  entries  not  held in any backend (such as a root DSE), the global
           directives are used.
           Arguments that should be replaced by actual text are shown in  brackets


           The structure of the access control directives is
                by * none stop
           clause that results in stopping the access control with no access priv-
           ileges granted.  Each <what> clause list is implicitly terminated by a
                access to *
                     by * none
           clause that results in granting no access privileges  to  an  otherwise
           unspecified datum.


           The  field  <what>  specifies  the  entity the access control directive
           applies to.  It can have the forms
                attrs=<attrlist>[ val[/matchingRule][.<attrstyle>]=<attrval>]
           The statement dn=<dnpattern> selects the entries based on their  naming
           context.  The <dnpattern> is a string representation of the entry's DN.
           The wildcard * stands for all the entries, and it is implied if  no  dn
           form is given.
           The  <dnstyle> is optional; however, it is recommended to specify it to
           avoid ambiguities.  Base (synonym of baseObject), the default, or exact
           (an alias of base) indicates the entry whose DN is equal to the <dnpat-
           tern>; one (synonym of onelevel) indicates all the entries  immediately
           below  the  <dnpattern>, sub (synonym of subtree) indicates all entries
           in the subtree at the <dnpattern>, children indicates all  the  entries
           below (subordinate to) the <dnpattern>.
           If  the  <dnstyle>  qualifier  is  regex,  then  <dnpattern> is a POSIX
           (''extended'') regular expression  pattern,  as  detailed  in  regex(7)
           and/or re_format(7), matching a normalized string representation of the
           entry's DN.  The regex form of  the  pattern  does  not  (yet)  support
           The  statement filter=<ldapfilter> selects the entries based on a valid
           LDAP filter as described in RFC 4515.  A filter of  (objectClass=*)  is
           implied if no filter form is given.
           The  statement  attrs=<attrlist> selects the attributes the access con-
           case, only a single attribute type may be given. The <attrstyle>  exact
           (the  default)  uses  the attribute's equality matching rule to compare
           the value, unless a different (and compatible) matching rule is  speci-
           fied.  If  the  <attrstyle>  is  regex, the provided value is used as a
           POSIX (''extended'') regular expression pattern.  If the attribute  has
           DN  syntax,  the  <attrstyle>  can be any of base, onelevel, subtree or
           children, resulting in  base,  onelevel,  subtree  or  children  match,
           The  dn, filter, and attrs statements are additive; they can be used in
           sequence to select entities the access rule applies to based on  naming
           context, value and attribute type simultaneously.  Submatches resulting
           from regex matching can be dereferenced in the <who>  field  using  the
           syntax  ${v<n>}, where <n> is the submatch number.  The default syntax,
           $<n>, is actually an alias for ${d<n>}, that corresponds to dereferenc-
           ing submatches from the dnpattern portion of the <what> field.


           The  field  <who>  indicates  whom the access rules apply to.  Multiple
           <who> statements can appear in an access control statement,  indicating
           the different access privileges to the same resource that apply to dif-
           ferent accessee.  It can have the forms
           They may be specified in combination.
           The wildcard * refers to everybody.
           The keywords prefixed by real act as their counterparts without prefix;
           the  checking  respectively  occurs  with the authentication DN and the
           authorization DN.
           The keyword  anonymous  means  access  is  granted  to  unauthenticated
           clients;  it is mostly used to limit access to authentication resources
           (e.g.  the  userPassword  attribute)  to  unauthenticated  clients  for
           authentication purposes.
           The keyword users means access is granted to authenticated clients.
           The  keyword  self  means  access  to  an entry is allowed to the entry
           itself (e.g. the entry being accessed and the requesting entry must  be
           the  same).   It  allows the level{<n>} style, where <n> indicates what
           ancestor of the DN is to be used in matches.  A  positive  value  indi-
           cates  that the <n>-th ancestor of the user's DN is to be considered; a
           negative value indicates that the <n>-th ancestor of the target  is  to
           be  considered.   For  example,  a  "by self.level{1} ..." clause would
           match   when   the   object   "dc=example,dc=com"   is   accessed    by
           "cn=User,dc=example,dc=com".   A  "by  self.level{-1} ..." clause would
           match  when   the   same   user   accesses   the   object   "ou=Address
           The  statement dn=<DN> means that access is granted to the matching DN.
           The optional style qualifier dnstyle allows the same choices of the  dn
           form  of  the  <what>  field.  In addition, the regex style can exploit
           substring substitution of submatches in the <what> dn.regex  clause  by
           using  the  form  $<digit>,  with  digit  ranging  from 0 to 9 (where 0
           matches the entire string), or the  form  ${<digit>+},  for  submatches
           higher than 9.  Substring substitution from attribute value can be done
           in using the form ${v<digit>+}.  Since the dollar character is used  to
           indicate  a substring replacement, the dollar character that is used to
           indicate match up to the end of the string must be escaped by a  second
           dollar character, e.g.
               access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$"
                   by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write
           The  style qualifier allows an optional modifier.  At present, the only
           type allowed is expand, which causes  substring  substitution  of  sub-
           matches  to  take  place  even  if dnstyle is not regex.  Note that the
           regex dnstyle in the above example may be  of  use  only  if  the  <by>
           clause needs to be a regex; otherwise, if the value of the second (from
           the right) dc= portion of the DN in the above example were  fixed,  the
               access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
           the match of the rightmost part of the DN  as  defined  in  the  <what>
           clause.  This may be useful, for instance, to provide access to all the
           ancestors of a user by defining
               access to dn.subtree="dc=com"
                   by dn.subtree,expand="$1" read
           which means that only access to entries that appear in the  DN  of  the
           <by> clause is allowed.
           The  level{<n>}  form  is  an  extension  and  a  generalization of the
           onelevel form, which matches all DNs whose <n>-th ancestor is the  pat-
           tern.   So, level{1} is equivalent to onelevel, and level{0} is equiva-
           lent to base.
           It is perfectly useless to give any access  privileges  to  a  DN  that
           exactly  matches  the rootdn of the database the ACLs apply to, because
           it implicitly possesses write privileges for the entire  tree  of  that
           database.   Actually,  access  control  is  bypassed for the rootdn, to
           solve the intrinsic chicken-and-egg problem.
           The  statement  dnattr=<attrname>  means  that  access  is  granted  to
           requests  whose  DN  is  listed  in  the entry being accessed under the
           <attrname> attribute.
           The statement group=<group> means that access is  granted  to  requests
           whose  DN  is  listed  in the group entry whose DN is given by <group>.
           The optional parameters <objectclass> and <attrname> define the object-
           Class  and  the  member attributeType of the group entry.  The defaults
           are groupOfNames and member, respectively.  The optional  style  quali-
           fier  <style>  can be expand, which means that <group> will be expanded
           as a replacement string (but not as a regular expression) according  to
           regex(7)  and/or  re_format(7), and exact, which means that exact match
           will be used.  If the style of the DN portion of the <what>  clause  is
           regex,  the  submatches are made available according to regex(7) and/or
           re_format(7); other styles  provide  limited  submatches  as  discussed
           above about the DN form of the <by> clause.
           For static groups, the specified attributeType must have Distinguished-
           Name or NameAndOptionalUID syntax. For dynamic groups the attributeType
           must  be  a  subtype of the labeledURI attributeType. Only LDAP URIs of
           the  form  ldap:///<base>??<scope>?<filter>  will  be  evaluated  in  a
           dynamic group, by searching the local server only.
           The      statements      peername=<peername>,      sockname=<sockname>,
           domain=<domain>, and sockurl=<sockurl> mean that the contacting host IP
           (in  the  form IP=<ip>:<port> for IPv4, or IP=[<ipv6>]:<port> for IPv6)
           or the contacting host named pipe file name (in the form PATH=<path> if
           connecting through a named pipe) for peername, the named pipe file name
           for sockname, the contacting host name for domain, and  the  contacting
           URL  for sockurl are compared against pattern to determine access.  The
           same style rules for pattern match described for the group case  apply,
           tions only from localhost, peername.ip= allows
           connections from any IP in the 192.168.1  class  C  domain,  and  peer-
           name.ip={9009}  allows connections from any
           IP in the 192.168.1.[16-31] range of the same domain, only if port 9009
           is  used.   The special path style eliminates the PATH= prefix from the
           peername when connecting through a named pipe, and  performs  an  exact
           match  on  the given pattern.  The <domain> clause also allows the sub-
           tree style, which succeeds when a fully qualified name exactly  matches
           the  domain pattern, or its trailing part, after a dot, exactly matches
           the domain pattern.  The expand style is  allowed,  implying  an  exact
           match with submatch expansion; the use of expand as a style modifier is
           considered more appropriate.  As an example,
           will  match, but will not match
           The domain of the contacting host is determined  by  performing  a  DNS
           reverse  lookup.   As  this  lookup  can  easily be spoofed, use of the
           domain statement is strongly discouraged.  By default, reverse  lookups
           are  disabled.   The  optional  domainstyle  qualifier  of the <domain>
           clause allows a modifier option; the only value currently supported  is
           expand, which causes substring substitution of submatches to take place
           even if the domainstyle is not regex, much like the analogous usage  in
           <dn> clause.
           The statement set=<pattern> is undocumented yet.
           The  statement dynacl/<name>[/<options>][.<dynstyle>][=<pattern>] means
           that access checking is delegated to the admin-defined method indicated
           by  <name>,  which  can  be registered at run-time by means of the mod-
           uleload statement.  The fields <options>, <dynstyle> and <pattern>  are
           optional,  and  are  directly passed to the registered parsing routine.
           Dynacl is experimental; it must be enabled at compile time.
           The statement dynacl/aci[=<attrname>] means that the access control  is
           determined  by  the  values  in  the attrname of the entry itself.  The
           optional <attrname> indicates what attributeType holds the ACI informa-
           tion  in  the entry.  By default, the OpenLDAPaci operational attribute
           is used.  ACIs are experimental; they must be enabled at compile  time.
           The    statements    ssf=<n>,   transport_ssf=<n>,   tls_ssf=<n>,   and
           sasl_ssf=<n> set the minimum required Security  Strength  Factor  (ssf)
           needed to grant access.  The value should be positive integer.


           The optional field <access> ::= [[real]self]{<level>|<priv>} determines
           the access level or the specific access privileges the who  field  will
           have.  Its component are defined as
                <level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage
                <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
           The  modifier  self  allows  special  operations  like having a certain
           access level or privilege only in case the operation involves the  name
           of  the  user  that's  requesting the access.  It implies the user that
           The none access level disallows  all  access  including  disclosure  on
           The disclose access level allows disclosure of information on error.
           The  auth access level means that one is allowed access to an attribute
           to perform authentication/authorization operations (e.g.  bind) with no
           other  access.   This  is  useful  to grant unauthenticated clients the
           least possible access level to critical resources, like passwords.
           The priv access model relies on the explicit setting of  access  privi-
           leges  for each clause.  The = sign resets previously defined accesses;
           as a consequence, the  final  access  privileges  will  be  only  those
           defined  by the clause.  The + and - signs add/remove access privileges
           to the existing ones.  The privileges are m for manage, w for write,  a
           for  add,  z for delete, r for read, s for search, c for compare, x for
           authentication, and d for disclose.  More than one of the above  privi-
           leges  can be added in one statement.  0 indicates no privileges and is
           used only by itself (e.g., +0).  Note that +az is equivalent to +w.
           If no access is given, it defaults to +0.


           The optional field <control> controls the flow of access rule  applica-
           tion.  It can have the forms
           where  stop, the default, means access checking stops in case of match.
           The other two forms are used to keep on processing access clauses.   In
           detail,  the  continue  form allows for other <who> clauses in the same
           <access> clause to be considered, so that they may result in  incremen-
           tally  altering  the  privileges, while the break form allows for other
           <access> clauses that match the same target to be processed.   Consider
           the (silly) example
                access to dn.subtree="dc=example,dc=com" attrs=cn
                     by * =cs break
                access to dn.subtree="ou=People,dc=example,dc=com"
                     by * +r
           which  allows  search  and  compare  privileges  to everybody under the
           "dc=example,dc=com" tree, with the second rule allowing  also  read  in
           the "ou=People" subtree, or the (even more silly) example
                access to dn.subtree="dc=example,dc=com" attrs=cn
                     by * =cs continue
                     by users +r
           subsequent rules.


           Operations  require  different  privileges  on  different  portions  of
           entries.   The  following  summary applies to primary database backends
           such as the BDB and HDB backends.   Requirements for other backends may
           (and often do) differ.
           The  add operation requires add (=a) privileges on the pseudo-attribute
           entry of the entry being added, and add (=a) privileges on the  pseudo-
           attribute children of the entry's parent.  When adding the suffix entry
           of a database, add access to children of the empty DN ("") is required.
           Also  if  Add  content ACL checking has been configured on the database
           (see the slapd.conf(5) or slapd-config(5) manual page), add  (=a)  will
           be required on all of the attributes being added.
           The  bind  operation,  when  credentials  are  stored in the directory,
           requires auth (=x) privileges on  the  attribute  the  credentials  are
           stored in (usually userPassword).
           The compare operation requires compare (=c) privileges on the attribute
           that is being compared.
           The delete operation requires delete (=z)  privileges  on  the  pseudo-
           attribute  entry of the entry being deleted, and delete (=d) privileges
           on the children pseudo-attribute of the entry's parent.
           The modify operation requires write (=w) privileges on  the  attributes
           being  modified.   In  detail,  add (=a) is required to add new values,
           delete (=z) is required to delete existing values, and both delete  and
           add (=az), or write (=w), are required to replace existing values.
           The  modrdn  operation  requires  write  (=w) privileges on the pseudo-
           attribute entry of the entry  whose  relative  DN  is  being  modified,
           delete  (=z)  privileges  on  the  pseudo-attribute children of the old
           entry's parents, add (=a) privileges on the  pseudo-attribute  children
           of  the  new entry's parents, and add (=a) privileges on the attributes
           that are present in the new relative DN.  Delete  (=z)  privileges  are
           also required on the attributes that are present in the old relative DN
           if deleteoldrdn is set to 1.
           The search operation, requires search  (=s)  privileges  on  the  entry
           pseudo-attribute  of  the  searchBase  (NOTE:  this was introduced with
           OpenLDAP 2.4).  Then, for each entry, it requires  search  (=s)  privi-
           search filter of the URI regexp maps (the right-hand side of the authz-
           regexp  directives).   Auth  (=x)  privileges  are also required on the
           authzTo attribute of the authorizing identity and/or on  the  authzFrom
           attribute  of  the  authorized  identity.  In general, when an internal
           lookup is  performed  for  authentication  or  authorization  purposes,
           search-specific  privileges (see the access requirements for the search
           operation illustrated above) are relaxed to auth.
           Access control to search entries is checked by the frontend, so  it  is
           fully  honored  by  all  backends; for all other operations and for the
           discovery phase of the search operation, full  ACL  semantics  is  only
           supported  by the primary backends, i.e.  back-bdb(5), and back-hdb(5).
           Some other backend, like back-sql(5), may fully  support  them;  others
           may  only  support a portion of the described semantics, or even differ
           in some aspects.  The relevant details are described  in  the  backend-
           specific man pages.


           It  is  strongly  recommended  to  explicitly  use the most appropriate
           <dnstyle> in <what> and <who>  clauses,  to  avoid  possible  incorrect
           specifications  of  the  access rules as well as for performance (avoid
           unnecessary regex matching when an exact match suffices) reasons.
           An administrator might create a rule of the form:
                access to dn.regex="dc=example,dc=com"
                     by ...
           expecting it to match all entries in the  subtree  "dc=example,dc=com".
           However,  this rule actually matches any DN which contains anywhere the
           substring  "dc=example,dc=com".   That  is,  the  rule   matches   both
           "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
           To match the desired subtree, the rule would be more precisely written:
                access to dn.regex="^(.+,)?dc=example,dc=com$"
                     by ...
           For performance reasons, it would be better to use the subtree style.
                access to dn.subtree="dc=example,dc=com"
                     by ...
           When writing submatch rules, it may be convenient to avoid  unnecessary
           regex  <dnstyle>  use;  for instance, to allow access to the subtree of
           the user that matches the <what> clause, one could use
                access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
                     by dn.regex="^uid=$2,dc=example,dc=com$$" write


                  default slapd configuration file


           slapd(8), slapd-*(5), slapacl(8), regex(7), re_format(7)
           "OpenLDAP Administrator's Guide" (


           OpenLDAP  Software  is developed and maintained by The OpenLDAP Project
           <>.  OpenLDAP Software is derived from  Univer-
           sity of Michigan LDAP 3.3 Release.

    OpenLDAP 2.4.40 2014/09/20 SLAPD.ACCESS(5)


  • Linux

    The Distributions


    The Software


    The News


  • Toll Free
Copyright © 1999 - 2016 by LinuxGuruz