unixdev.net


Switch to SpeakEasy.net DSL

The Modular Manual Browser

Home Page
Manual: (Darwin-7.0.1-ppc)
Page:
Section:
Apropos / Subsearch:
optional field

SLAPD.ACCESS(5)               File Formats Manual              SLAPD.ACCESS(5)



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

SYNOPSIS
       /etc/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),  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.

       For  entries  not  held in any backend (such as a root DSE), the direc-
       tives of the first backend (and any 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 <&lt;what>&gt; [ by <&lt;who>&gt; <&lt;access>&gt; [ <&lt;control>&gt; ] ]+
              Grant  access (specified by <&lt;access>&gt;) to a set of entries and/or
              attributes (specified by  <&lt;what>&gt;)  by  one  or  more  requestors
              (specified by <&lt;who>&gt;).

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

            *
            [dn[.<dnstyle>]=<pattern>]
            [filter=<ldapfilter>]
            [attrs=<attrlist>]

       The wildcard * stands for all the entries.

       The statement dn=<&lt;pattern>&gt; selects the entries based  on  their  naming
       context.   The  optional  style  qualifier  <&lt;dnstyle>&gt; can be regex (the
       default) implies that pattern is a regular expression, as  detailed  in
       regex(7),  matching  a  normalized string representation of the entry's
       DN.  The regex form of the pattern does not support UTF-8 yet.

       For all other qualifiers, the pattern is a string representation of the
       entry's DN.  base or exact (an alias of base) indicates the entry whose
       DN is equal to the pattern.  one to indicate all  the  entries  immedi-
       ately below the pattern, subtree to indicate all entries in the subtree
       at the pattern, children to indicate all entries below (subordinate) to
       the pattern.  Note that dn=".*"  is equivalent to *.

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

       The statement attrs=<&lt;attrlist>&gt; selects the attributes the  access  con-
       trol 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.

       The last three 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  field  <&lt;who>&gt;  indicates  whom the access rules apply to.  Multiple
       <&lt;who>&gt; 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

            *
            anonymous
            users
            self

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

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

            aci=<attrname>

       They may be specified in combination.

       The wildcard * refers to everybody.

       The keyword anonymous means access is granted to unauthenticated users;
       it is moslty used to limit access to authentication resources (e.g. the
       userPassword attribute) to  unauthenticated  users  for  authentication
       purposes.

       The keyword users means access is granted to authenticated users.

       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=<&lt;pattern>&gt; means that access is granted to the matching
       DN.  The optional style qualifier dnstyle allows the  same  choices  of
       the  dn  form of the <&lt;what>&gt; field.  In addition, the regex form of pat-
       tern can exploit substring substitution of  submatches  in  the  <&lt;what>&gt;
       dn.regex  clause  by using the form $<&lt;digit>&gt;, with digit ranging from 1
       to 9.

       The  statement  dnattr=<&lt;attrname>&gt;  means  that  access  is  granted  to
       requests whose DN is listed in the entry being accessed under the attr-
       name attribute.

       The statement group=<&lt;pattern>&gt; means that access is granted to  requests
       whose  DN  is  listed  in the group entry whose DN is given by pattern.
       The optional parameters objectclass and attrname define the objectClass
       and  the  member  attributeType of the group entry.  The optional style
       qualifier style can be regex, which means that pattern will be expanded
       accorging  to  regex  (7),  and base or exact (an alias of base), which
       means that exact match will be used.

       The  statements  peername=<&lt;pattern>&gt;,  sockname=<&lt;pattern>&gt;,  domain=<&lt;pat-
       tern>&gt;, and sockurl=<&lt;pattern>&gt; mean that the contacting host IP for peer-
       name, 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.  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  domain  of  the  contacting  host  is
       determined by performing a DNS reverse lookup.  As this lookup can eas-
       ily be spoofed, use of the domain statement  is  strongly  discouraged.
       By default, reverse lookups are disabled.

       The statement set=<&lt;pattern>&gt; is undocumented yet.

       The  statement  aci=<&lt;attrname>&gt;  means that the access control is deter-
       mined by the values in the attrname of  the  entry  itself.   ACIs  are
       experimental; they must be enabled at compile time.

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

       The  field  <&lt;access>&gt;  ::=  [self]{<&lt;level>&gt;|<&lt;priv>&gt;} 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}+

       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 triv-
       ial, 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 users 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 w for write, r for read, s
       for search, c for compare, and x for  authentication.   More  than  one
       privilege can be added in one statement.

       The  optional field <&lt;control>&gt; controls the flow of access rule applica-
       tion.  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 <&lt;who>&gt; clauses  in  the  same
       <&lt;access>&gt;  clause to be considered, so that they may result in incremen-
       tally altering the privileges, while the break form  allows  for  other
       <&lt;access>&gt;  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.

CAVEATS
       It  is  strongly  recommended to explicitly use the most appropriate DN
       style, 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 adminisistrator might create a rule of the form:

            access to dn="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 ...

FILES
       /etc/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.



OpenLDAP 2.1.22                   06-26-2003                   SLAPD.ACCESS(5)