Man Linux: Main Page and Category List


       slapd.access  -  access  configuration  for slapd, the stand-alone LDAP




       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),
       followed  by  zero  or  more  database backend definitions that contain
       information 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
       directives 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

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

       Lists  of  access  directives are evaluated in the order they appear in
       slapd.conf.  When a <what> clause matches the  datum  whose  access  is
       being evaluated, its <who> clause list is checked.  When a <who> clause
       matches the accessor's properties, its <access> and  <control>  clauses
       are evaluated.  Access control checking stops at the first match of the
       <what> and <who> clause, unless otherwise  dictated  by  the  <control>
       clause.  Each <who> clause list is implicitly terminated by a

            by * none stop

       clause  that  results  in  stopping  the  access control with no access
       privileges 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
       <dnpattern>;  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
       control  rule  applies  to.   It is a comma-separated list of attribute
       types, plus the special names entry, indicating  access  to  the  entry
       itself,  and  children,  indicating  access  to  the  entry's children.
       ObjectClass names may also be specified in this list, which will affect
       all   the   attributes   that  are  required  and/or  allowed  by  that
       objectClass.  Actually, names in <attrlist> that are prefixed by @  are
       directly  treated  as objectClass names.  A name prefixed by !  is also
       treated as an objectClass, but in this case the access rule affects the
       attributes  that  are not required nor allowed by that objectClass.  If
       no attrs form is given, attrs=@extensibleObject is  implied,  i.e.  all
       attributes are addressed.

       Using  the form attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval>
       specifies access to a particular value of a single attribute.  In  this
       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
       specified. 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
       dereferencing submatches from  the  dnpattern  portion  of  the  <what>


       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
       different accessee.  It can have the forms









            <name>=aci          <pattern>=<attrname>]

       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
       indicates  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
       submatches  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$"
               by dn.exact,expand="uid=$2,dc=example,dc=com" write

       could  be  used; if it had to match the value in the <what> clause, the

           access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$"
               by dn.exact,expand="uid=$2,dc=$3,dc=com" write

       could be used.

       Forms of the <what> clause other than regex may provide  submatches  as
       well.   The  base(object),  the  sub(tree),  the  one(level),  and  the
       children forms provide $0 as the  match  of  the  entire  string.   The
       sub(tree),  the  one(level),  and the children forms also provide $1 as
       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
       pattern.   So,  level{1}  is  equivalent  to  onelevel, and level{0} is
       equivalent 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
       objectClass  and  the  member  attributeType  of  the group entry.  The
       defaults are groupOfNames and member, respectively.  The optional style
       qualifier  <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
       DistinguishedName 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,
       plus  the regex style, which implies submatch expand and regex match of
       the corresponding  connection  parameters.   The  exact  style  of  the
       <peername>  clause  (the  default)  implies  a  case-exact match on the
       client's IP, including the IP= prefix and the trailing :<port>, or  the
       client's path, including the PATH= prefix if connecting through a named
       pipe.    The   special   ip   style   interprets   the    pattern    as
       <peername>=<ip>[%<mask>][{<n>}], where <ip> and <mask> are dotted digit
       representations of the IP and the mask, while <n>, delimited  by  curly
       brackets, is an optional port.  The same applies to IPv6 addresses when
       the special ipv6 style is used.  When checking access  privileges,  the
       IP portion of the peername is extracted, eliminating the IP= prefix and
       the :<port> part, and it is compared against the <ip>  portion  of  the
       pattern  after  masking with <mask>: ((peername & <mask>) == <ip>).  As
       an   example,   peername.ip=   and   peername.ipv6=::1   allow
       connections  only from localhost, peername.ip=
       allows connections from any IP in the 192.168.1  class  C  domain,  and
       peername.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
       subtree 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
       moduleload 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
       information  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
       requests access is authorized.  The modifier  realself  refers  to  the
       authenticated  DN as opposed to the authorized DN of the self modifier.
       An example is the selfwrite access to the member attribute of a  group,
       which  allows  one  to  add/delete its own DN from the member list of a
       group, while being not allowed to affect other members.

       The level access model relies on an incremental interpretation  of  the
       access  privileges.   The  possible  levels  are  none, disclose, auth,
       compare, search, read, write, and manage.  Each  access  level  implies
       all  the  preceding  ones,  thus  manage  grants  all  access including
       administrative access.  The write access is actually the combination of
       add  and delete, which respectively restrict the write privilege to add
       or delete the specified <what>.

       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
       privileges  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  privileges  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
       application.  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
       incrementally 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

       which grants everybody search and compare  privileges,  and  adds  read
       privileges to authenticated clients.

       One  useful  application  is  to  easily  grant  write privileges to an
       updatedn that is different from the rootdn.  In this  case,  since  the
       updatedn needs write access to (almost) all data, one can use

            access to *
                 by dn.exact="cn=The Update DN,dc=example,dc=com" write
                 by * break

       as  the  first  access rule.  As a consequence, unless the operation is
       performed with the updatedn identity, control is passed straight to the
       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)
       privileges on the attributes that  are  defined  in  the  filter.   The
       resulting  entries  are  finally tested for read (=r) privileges on the
       pseudo-attribute entry (for read access to the entry  itself)  and  for
       read  (=r)  access  on  each value of each attribute that is requested.
       Also,  for  each  referral  object  used  in  generating   continuation
       references,  the  operation  requires  read  (=r) access on the pseudo-
       attribute entry (for read access to the  referral  object  itself),  as
       well  as  read  (=r)  access  to  the  attribute  holding  the referral
       information (generally the ref attribute).

       Some internal operations and  some  controls  require  specific  access
       privileges.   The  authzID  mapping  and the proxyAuthz control require
       auth (=x) privileges on all the attributes  that  are  present  in  the
       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
                 by ...

       However,  since  all  that  is required in the <by> clause is substring
       expansion, a more efficient solution is

            access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
                 by dn.exact,expand="uid=$2,dc=example,dc=com" write
                 by ...

       In fact, while a <dnstyle> of regex implies substring expansion, exact,
       as  well as all the other DN specific <dnstyle> values, does not, so it
       must be explicitly requested.


              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
       University of Michigan LDAP 3.3 Release.