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




     The slapd.conf(5) file  contains  configuration  information
     for  the  slapd(8)  daemon.  This configuration file is also
     used by the slurpd(8) replication daemon and  by  the  SLAPD
     tools slapadd(8), slapcat(8), and slapindex(8).

     The slapd.conf file consists of a series  of  global  confi-
     guration  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

     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 sec-
     tion   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 back-
     end  or  those  which  are  defined  are not applicable, the
     directives from the global configuration  section  are  then

     For entries not held in any backend (such as  a  root  DSE),
     the  directives  of the first backend (and any global direc-
     tives) 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>).

OpenLDAP LDVERSION  Last change: RELEASEDATE                    1



     The field <what> specifies the  entity  the  access  control
     directive applies to.  It can have the forms

          [attrs=<attrlist>[ val[.<style>]=<attrval>]]

     The wildcard * stands for all the entries.

     The statement dn=<DN> selects the  entries  based  on  their
     naming  context.   The pattern is a string representation of
     the entry's DN.  base, the default, or exact  (an  alias  of
     base)  indicates the entry whose DN is equal to the pattern;
     one (synonym of onelevel) indicates all the entries  immedi-
     ately  below the pattern, sub (synonym of subtree) indicates
     all entries in the subtree at the  pattern,  children  indi-
     cates all the entries below (subordinate to) the pattern.

     If the <dnstyle> qualifier is regex, then  the  value  is  a
     regular  expression pattern, as detailed in regex(7), match-
     ing a normalized string representation of  the  entry's  DN.
     The regex form of the pattern does not (yet) support UTF-8.

     The statement filter=<ldapfilter> selects the entries  based
     on a valid LDAP filter as described in RFC 2254.

     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, indi-
     cating  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 attri-
     butes 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.

     Using the form attrs=<attr> val[.<style>]=<value>  specifies
     access to a particular value of a single attribute.  In this
     case, only a single attribute type may  be  given.  A  value
     <style> of exact (the default) uses the attribute's equality
     matching rule to compare the value. If the value <style>  is
     regex,  the  provided  value is used as a regular expression
     pattern.  If the attribute has DN syntax, the value  <style>
     can be any of base, onelevel, subtree or children, resulting
     in base, onelevel, subtree or children match, respectively.

OpenLDAP LDVERSION  Last change: RELEASEDATE                    2


     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


     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





     They may be specified in combination.

     The wildcard * refers to everybody.

     The keyword anonymous means access is granted to unauthenti-
     cated  clients; it is mostly used to limit access to authen-
     tication resources  (e.g.  the  userPassword  attribute)  to
     unauthenticated clients for authentication purposes.

     The keyword users means access is granted  to  authenticated

     The keyword self means access to an entry is allowed to  the
     entry itself (e.g. the entry being accessed and the request-
     ing entry must be the same).

     The statement dn=<DN> means that access is  granted  to  the
     matching  DN.   The  optional style qualifier dnstyle allows

OpenLDAP LDVERSION  Last change: RELEASEDATE                    3


     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 1 to 9.  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.

     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 attribu-
     teType of the group entry.   The  optional  style  qualifier
     <style>  can  be  regex,  which  means  that <group> will be
     expanded as a replacement  string  (but  not  as  a  regular
     expression)  according  to  regex (7), and base or exact (an
     alias of base), which means that exact match will be used.

     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.

     The  statements  peername=<peername>,   sockname=<sockname>,
     domain=<domain>,  and  sockurl=<sockurl>  mean that the con-
     tacting host IP for peername, the named pipe file  name  for
     sockname,  the contacting host name for domain, and the con-
     tacting URL for sockurl  are  compared  against  pattern  to
     determine  access.   The  same style rules for pattern match
     described for the group case apply. The domain  clause  also
     allows the subtree style, which succeeds when a fully quali-
     fied name exactly matches the domain pattern, or its  trail-
     ing  part,  after a dot, exactly matches the domain pattern.
     The domain of the contacting host is determined by  perform-
     ing  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.

OpenLDAP LDVERSION  Last change: RELEASEDATE                    4


     The statement aci=<attrname> means that the  access  control
     is  determined  by  the  values in the attrname of the entry
     itself.  ACIs are experimental; they must be enabled at com-
     pile time.

     The statements ssf=<n>, transport_ssf=<n>, tls_ssf=<n>,  and
     sasl_ssf=<n> set the required Security Strength Factor (ssf)
     required to grant access.


     The field <access> ::= [self]{<level>|<priv>} determines the
     access level or the specific access privileges the who field
     will have.  Its component are defined as

          <level> ::= none|auth|compare|search|read|write
          <priv> ::= {=|+|-}{w|r|s|c|x|0}+

     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 bound.  An exam-
     ple 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, without affecting other members.

     The level access model relies on an incremental  interpreta-
     tion  of  the  access  privileges.   The possible levels are
     none, auth, compare, search, read, and write.   Each  access
     level implies all the preceding ones, thus write access will
     imply all accesses.  While  none  is  trivial,  auth  access
     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 previ-
     ously 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  w for write, r for read, s for
     search, c for compare, and x for authentication.  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.,

     The optional field <control> controls  the  flow  of  access
     rule application.  It can have the forms


OpenLDAP LDVERSION  Last change: RELEASEDATE                    5



     where stop, the default, means access checking stops in case
     of  match.  The other two forms are used to keep on process-
     ing access clauses.  In detail, the continue form allows for
     other  <who>  clauses in the same <access> clause to be con-
     sidered, 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.


     Operations require different privileges  on  different  por-
     tions  of entries.  The following summary applies to primary
     database backends such as the LDBM, BDB, and  HDB  backends.
     Requirements for other backends may (and often do) differ.

     The add operation requires  write  (=w)  privileges  on  the
     pseudo-attribute  entry  of the entry being added, and write
     (=w) privileges on  the  pseudo-attribute  children  of  the
     entry's parent.

     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 write (=w) privileges  on  the
     pseudo-attribute entry of the entry being deleted, and write
     (=w) privileges on  the  children  pseudo-attribute  of  the
     entry's parent.

OpenLDAP LDVERSION  Last change: RELEASEDATE                    6


     The modify operation requires write (=w) privileges  on  the
     attibutes being modified.

     The modrdn operation requires write (=w) privileges  on  the
     pseudo-attribute  entry  of  the  entry whose relative DN is
     being  modified,  write  (=w)  privileges  on  the   pseudo-
     attribute  children  of the old and new entry's parents, and
     write (=w) privileges on the attributes that are present  in
     the  new  relative  DN.   Write  (=w)  privileges  are  also
     required on the attributes that are present in the old rela-
     tive DN if deleteoldrdn is set to 1.

     The search operation, for each entry, requires  search  (=s)
     privileges on the attributes that are defined in the filter.
     Then,  the  resulting  entries  are  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 refer-
     ral information (generally the ref attribute).

     Some controls require specific access privileges.  The prox-
     yAuthz  control  requires  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 sasl-regexp direc-
     tives).  It  also  requires  auth  (=x)  privileges  on  the
     saslAuthzTo  attribute of the authorizing identity and/or on
     the saslAuthzFrom attribute of the authorized identity.


     It is  strongly  recommended  to  explicitly  use  the  most
     appropriate  <dnstyle>, to avoid possible incorrect specifi-
     cations of the access  rules  as  well  as  for  performance
     (avoid  unrequired  regex  matching when an exact match suf-
     fices) reasons.

     An adminisistrator 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  pre-
     cisely written:

OpenLDAP LDVERSION  Last change: RELEASEDATE                    7


          access to dn.regex="^(.+,)?dc=example,dc=com$$"
               by ...

     For performance reasons, it would be better to use the  sub-
     tree 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=$1,dc=example,dc=com$$" write
               by ...

     However, since all that is required in the to clause is sub-
     string expansion, a more efficient solution is

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

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


          default slapd configuration file



     "OpenLDAP               Administrator's               Guide"


     OpenLDAP is developed and maintained by The OpenLDAP Project
     (    OpenLDAP   is   derived  from
     University of Michigan LDAP 3.3 Release.

OpenLDAP LDVERSION  Last change: RELEASEDATE                    8

Man(1) output converted with man2html