Welcome to Linux Knowledge Base and Tutorial
"The place where you learn linux"
International Rescue Committe

 Create an AccountHome | Submit News | Your Account  

Tutorial Menu
Linux Tutorial Home
Table of Contents

· Introduction to Operating Systems
· Linux Basics
· Working with the System
· Shells and Utilities
· Editing Files
· Basic Administration
· The Operating System
· The X Windowing System
· The Computer Itself
· Networking
· System Monitoring
· Solving Problems
· Security
· Installing and Upgrading
· Linux and Windows

Glossary
MoreInfo
Man Pages
Linux Topics
Test Your Knowledge

Site Menu
Site Map
FAQ
Copyright Info
Terms of Use
Privacy Info
Disclaimer
WorkBoard
Thanks
Donations
Advertising
Masthead / Impressum
Your Account

Communication
Feedback
Forums
Private Messages
Surveys

Features
HOWTOs
News Archive
Submit News
Topics
User Articles
Web Links

Google
Google


The Web
linux-tutorial.info

Who's Online
There are currently, 172 guest(s) and 0 member(s) that are online.

You are an Anonymous user. You can register for free by clicking here

  

slapd.access




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 config­
       uration 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 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>).

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

            *

       sentation  of  the entry's DN.  base or exact (an alias of
       base) indicates the entry whose DN is equal  to  the  pat­
       tern.   one  to indicate all the entries immediately below
       the pattern, subtree to indicate all entries in  the  sub­
       tree  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  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, indi­
       cating 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 simulta­
       neously.

       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>]]=<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>

       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 pattern 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 attrname 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=<pattern>, and sockurl=<pattern> mean that the con­
       tacting host IP 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.  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
       easily 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  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.
       own  DN from the member list of a group, without affecting
       other members.

       The level access model relies on an incremental  interpre­
       tation  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 unau­
       thenticated users the least possible access level to crit­
       ical resources, like passwords.

       The  priv  access  model relies on the explicit setting of
       access privileges for each clause.  The = sign resets pre­
       viously  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 authentica­
       tion.  More than one privilege can be added in one  state­
       ment.

       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

            access to dn="dc=example,dc=com"
                 by ...

       expecting it to match all entries in the subtree "dc=exam­
       ple,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:

            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.OpenL­
       DAP.org/doc/admin/)


ACKNOWLEDGEMENTS

       OpenLDAP is developed and maintained by The OpenLDAP  Pro­
       ject (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)

An undefined database error occurred. SELECT distinct pages.pagepath,pages.pageid FROM pages, page2command WHERE pages.pageid = page2command.pageid AND commandid =


  

More information about the site can be found in the FAQ


Login
Nickname

Password

Security Code
Security Code
Type Security Code


Don't have an account yet? You can create one. As a registered user you have some advantages like theme manager, comments configuration and post comments with your name.

Help if you can!


Amazon Wish List

Did You Know?
The Linux Tutorial can use your help.


Friends



Tell a Friend About Us

Bookmark and Share



Web site powered by PHP-Nuke

Is this information useful? At the very least you can help by spreading the word to your favorite newsgroups, mailing lists and forums.
All logos and trademarks in this site are property of their respective owner. The comments are property of their posters. Articles are the property of their respective owners. Unless otherwise stated in the body of the article, article content (C) 1994-2013 by James Mohr. All rights reserved. The stylized page/paper, as well as the terms "The Linux Tutorial", "The Linux Server Tutorial", "The Linux Knowledge Base and Tutorial" and "The place where you learn Linux" are service marks of James Mohr. All rights reserved.
The Linux Knowledge Base and Tutorial may contain links to sites on the Internet, which are owned and operated by third parties. The Linux Tutorial is not responsible for the content of any such third-party site. By viewing/utilizing this web site, you have agreed to our disclaimer, terms of use and privacy policy. Use of automated download software ("harvesters") such as wget, httrack, etc. causes the site to quickly exceed its bandwidth limitation and are therefore expressly prohibited. For more details on this, take a look here

PHP-Nuke Copyright © 2004 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.04 Seconds