slapd.access man page on OpenDarwin

Man page or keyword search:  
man Server   3202 pages
apropos Keyword Search (all sections)
Output format
OpenDarwin logo
[printable version]

SLAPD.ACCESS(5)						       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 <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  field  <what>  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=<pattern> selects the entries based  on	 their	naming
       context.	  The  optional	 style	qualifier  <dnstyle> 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=<ldapfilter> selects the entries based on a valid
       LDAP filter as described in RFC 2254.

       The statement attrs=<attrlist> 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  <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

	    *
	    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=<pattern> 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 form of pat‐
       tern 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  statement  dnattr=<attrname>  means	 that  access  is  granted  to
       requests whose DN is listed in the entry being accessed under the attr‐
       name attribute.

       The statement group=<pattern> 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=<pattern>,  sockname=<pattern>,  domain=<pat‐
       tern>, and sockurl=<pattern> 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=<pattern> is undocumented yet.

       The  statement  aci=<attrname>  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=<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}+

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

       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.X			  RELEASEDATE		       SLAPD.ACCESS(5)
[top]

List of man pages available for OpenDarwin

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net