Provided by: ultrapossum-slapd_0.0.4+2.2.20sb3-1_i386 bug

NAME

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

SYNOPSIS

       /etc/ultrapossum/slapd/openldap/slapd.conf

DESCRIPTION

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

       For  entries  not  held  in  any  backend  (such  as  a  root DSE), the
       directives of the first backend (and any global directives) are used.

       Arguments that should be replaced by actual text are shown in  brackets
       <>.

THE ACCESS DIRECTIVE

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

THE <WHAT> FIELD

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

            *
            [dn[.<dnstyle>]=<DN>]
            [filter=<ldapfilter>]
            [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 immediately below the pattern, sub (synonym of subtree)
       indicates all entries in the subtree at the pattern, children indicates
       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), matching 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, 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.

       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.

       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.

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

            *
            anonymous
            users
            self

            dn[.<dnstyle>[,<modifier>]]=<DN>
            dnattr=<attrname>
            group[/<objectclass>[/<attrname>]]
                 [.<groupstyle>]=<group>
            peername[.<peernamestyle>]=<peername>
            sockname[.<style>]=<sockname>
            domain[.<domainstyle>[,<modifier>]]=<domain>
            sockurl[.<style>]=<sockurl>
            set[.<setstyle>]=<pattern>

            ssf=<n>
            transport_ssf=<n>
            tls_ssf=<n>
            sasl_ssf=<n>

            aci=<attrname>

       with

            <dnstyle>={{exact|base}|regex|sub(tree)|one(level)|children}
            <groupstyle>={exact|expand}
            <style>={exact|regex|expand}
            <peernamestyle>={<style>|ip|path}
            <domainstyle>={exact|regex|sub(tree)}
            <setstyle>={exact|regex}
            <modifier>={expand}

       They may be specified in combination.

       The wildcard * refers to everybody.

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

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

       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
       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 exact, 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, 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>)  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(7)  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.
       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>.  As an example, peername.ip=127.0.0.1  alows  connections  only
       from     localhost,     peername.ip=192.168.1.0%255.255.255.0    allows
       connections  from  any  IP  in  the  192.168.1  class  C  domain,   and
       peername.ip=192.168.1.16%255.255.255.240{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,
       domain.subtree=example.com  will  match  www.example.com,  but will not
       match www.anotherexample.com.  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   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 compile 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 <ACCESS> FIELD

       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 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, without affecting other members.

       The level access model relies on an incremental interpretation  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  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 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., +0).

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

            stop
            continue
            break

       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.

OPERATION REQUIREMENTS

       Operations  require  different  privileges  on  different  portions  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.

       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 relative  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 referral information (generally the ref
       attribute).

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

CAVEATS

       It  is  strongly  recommended  to  explicitly  use the most appropriate
       <dnstyle>, to avoid possible incorrect  specifications  of  the  access
       rules  as well as for performance (avoid unrequired 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=$1,dc=example,dc=com$$" write
                 by ...

       However, since all that is required  in  the  to  clause  is  substring
       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 expansion, exact,
       as well as all the other DN specific <dnstyle> values, does not, so  it
       must be explicitly requested.

FILES

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

SEE ALSO

       slapd(8),

       "OpenLDAP Administrator’s Guide" (http://www.OpenLDAP.org/doc/admin/)

ACKNOWLEDGEMENTS

       OpenLDAP   is   developed   and  maintained  by  The  OpenLDAP  Project
       (http://www.openldap.org/).  OpenLDAP is  derived  from  University  of
       Michigan LDAP 3.3 Release.