]> git.sur5r.net Git - openldap/blobdiff - doc/guide/admin/slapdconfig.sdf
Added LDAP_FILTER_EXT case to filter_free()
[openldap] / doc / guide / admin / slapdconfig.sdf
index e6c92626c3161f915e353de06d602d303aed6c85..c37150ff616d586f582f9927701800c642160459 100644 (file)
@@ -475,18 +475,27 @@ This directive specifies the indexes to maintain for the given
 attribute. If only an {{EX:<attrlist>}} is given, the default
 indexes are maintained.
 
-
 \Example:
 
 >      index default pres,eq
->      index objectClass,uid
->      index cn,sn eq,sub,approx
+>      index uid
+>      index cn,sn pres,eq,sub
+>      index objectClass eq
+
+The first line sets the default set of indices to maintain to
+present and equality.  The second line causes the default (pres,eq)
+set of indices to be maintained for the {{EX:uid}} attribute type.
+The third line causes present, equality, and substring indices to
+be maintained for {{EX:cn}} and {{EX:sn}} attribute types.  The
+fourth line causes an equality index for the {{EX:objectClass}}
+attribute type.
+
+By default, no indices are maintained.  It is generally advised
+that minimally an equality index upon objectClass be maintained.
+
+>      index objectClass eq
+
 
-The first line sets the default set of indices to maintain to present
-and equality.  The second line causes the default (pres,eq) set
-of indices to be maintained for {{EX:objectClass}} and {{EX:uid}} attribute
-types.  The third line causes equality, substring, and approximate
-indices to be maintained for {{EX:cn}} and {{EX:sn}} attribute types.
 
 H4: mode <integer>
 
@@ -563,12 +572,12 @@ matching the entry's distinguished name:
 
 >      dn=<regular expression>
 
-Note: The DN pattern specified should be "normalized",
-meaning that there should be no extra spaces, and commas
-should be used to separate components. An example
-normalized DN is "cn=Babs Jensen,dc=example,dc=com".
-An example of a non-normalized DN is
-"cn=Babs Jensen,dc=example,dc=com".
+Note: The DN pattern specified should be "normalized" to the RFC2253
+restricted DN form.  In particular, there should be no extra spaces
+and commas should be used to separate components.  An example
+normalized DN is "{{EX:cn=Babs Jensen,dc=example,dc=com}}".  An
+example of a non-normalized DN is "{{EX:cn=Babs Jensen; dc=example;
+dc=com}}".
 
 Or, entries may be selected by a filter matching some
 attribute(s) in the entry:
@@ -622,9 +631,8 @@ separate RDN components.
 
 Other control factors are also supported.
 For example, a {{EX:<what>}} can be restricted by a
-regular expression matching the client's IP address or domain name:
+regular expression matching the client's domain name:
 
->      addr=<regular expression>
 >      domain=<regular expression>
 
 or by an entry listed in a DN-valued attribute in the entry to
@@ -664,36 +672,35 @@ to grant specific permissions.
 
 H3: Access Control Evaluation
 
-When evaluating whether some requester should be given
-access to an entry and/or attribute, slapd compares the entry
-and/or attribute to the {{EX:<what>}} selectors given in the
-configuration file. Access directives local to the current
-database are examined first, followed by global access
-directives. Within this priority, access directives are
-examined in the order in which they appear in the config file.
-Slapd stops with the first {{EX:<what>}} selector that matches the
-entry and/or attribute. The corresponding access directive is
-the one slapd will use to evaluate access.
-
-Next, slapd compares the entity requesting access to the
-{{EX:<who>}} selectors within the access directive selected above
-in the order in which they appear. It stops with the first {{EX:<who>}}
-selector that matches the requester. This determines the
-access the entity requesting access has to the entry and/or
-attribute.
+When evaluating whether some requester should be given access to
+an entry and/or attribute, slapd compares the entry and/or attribute
+to the {{EX:<what>}} selectors given in the configuration file.
+For each entry, access control provided in the database which holds
+the entry (or the first database if not held in any database) apply
+first, followed by the global access directivies.  Within this
+priority, access directives are examined in the order in which they
+appear in the config file.  Slapd stops with the first {{EX:<what>}}
+selector that matches the entry and/or attribute. The corresponding
+access directive is the one slapd will use to evaluate access.
+
+Next, slapd compares the entity requesting access to the {{EX:<who>}}
+selectors within the access directive selected above in the order
+in which they appear. It stops with the first {{EX:<who>}} selector
+that matches the requester. This determines the access the entity
+requesting access has to the entry and/or attribute.
 
 Finally, slapd compares the access granted in the selected
-{{EX:<access>}} clause to the access requested by the client. If it
-allows greater or equal access, access is granted. Otherwise,
+{{EX:<access>}} clause to the access requested by the client. If
+it allows greater or equal access, access is granted. Otherwise,
 access is denied.
 
-The order of evaluation of access directives makes their
-placement in the configuration file important. If one access
-directive is more specific than another in terms of the entries
-it selects, it should appear first in the config file. Similarly, if
-one {{EX:<who>}} selector is more specific than another it should
-come first in the access directive. The access control
-examples given below should help make this clear.
+The order of evaluation of access directives makes their placement
+in the configuration file important. If one access directive is
+more specific than another in terms of the entries it selects, it
+should appear first in the config file. Similarly, if one {{EX:<who>}}
+selector is more specific than another it should come first in the
+access directive. The access control examples given below should
+help make this clear.
 
 
 
@@ -759,7 +766,7 @@ to a specific attribute and various {{EX:<who>}} selectors.
 This example applies to entries in the "{{EX:dc=example,dc=com}}"
 subtree. To all attributes except {{EX:homePhone}}, the entry itself
 can write them, other {{EX:example.com}} entries can search by them,
-anybody else has no access ((implicit {{EX:by * none}}) excepting for
+anybody else has no access (implicit {{EX:by * none}}) excepting for
 authentication/authorization (which is always done anonymously).
 The {{EX:homePhone}} attribute is writable by the entry, searchable
 by other {{EX:example.com}} entries, readable by clients connecting
@@ -810,10 +817,9 @@ means that queries not local to one of the databases defined
 below will be referred to the LDAP server running on the
 standard port (389) at the host {{EX:root.openldap.org}}.
 
-Line 4 is a global access control.  It is used only if
-no database access controls match or when the target
-objects are not under the control of any database (such as
-the Root DSE).
+Line 4 is a global access control.  It applies to all
+entries (after any applicable database-specific access
+controls).
 
 The next section of the configuration file defines an LDBM
 backend that will handle queries for things in the
@@ -852,44 +858,46 @@ E: 30.            by self write
 E: 31.         by dn="cn=Admin,dc=example,dc=com" write
 E: 32.         by * read
 
-Line 5 is a comment. The start of the database definition is
-marked by the database keyword on line 6. Line 7 specifies
-the DN suffix for queries to pass to this database. Line 8
-specifies the directory in which the database files will live.
-
-Lines 9 and 10 identify the database "super user" entry and
-associated password. This entry is not subject to access
-control or size or time limit restrictions.
-
-Lines 11 through 18 are for replication. Line 11 specifies the
-replication log file (where changes to the database are logged
-\- this file is written by slapd and read by slurpd). Lines 12 
-through 14 specify the hostname and port for a replicated
-host, the DN to bind as when performing updates, the bind
-method (simple) and the credentials (password) for the
-binddn. Lines 15 through 18 specify a second replication site.
-See the {{SECT:Replication with slurpd}} chapter for more
-information on these directives.
-
-Lines 20 through 22 indicate the indexes to maintain for
-various attributes.
-
-Lines 24 through 32 specify access control for entries in the
-database. For all entries, the {{EX:userPassword}} attribute is
-writable by the entry itself and by the "admin" entry.  It may be
-used for authentication/authorization purposes, but is otherwise
-not readable.  All other attributes are writable by the entry and
-the "admin" entry, but may be read by authenticated users.
-
-The next section of the example configuration file defines
-another LDBM database. This one handles queries involving
-the {{EX:dc=example,dc=net}} subtree.  Note that without
-line 38, the read access would be allowed due to the
-global access rule at line 4.
+Line 5 is a comment. The start of the database definition is marked
+by the database keyword on line 6. Line 7 specifies the DN suffix
+for queries to pass to this database. Line 8 specifies the directory
+in which the database files will live.
+
+Lines 9 and 10 identify the database "super user" entry and associated
+password. This entry is not subject to access control or size or
+time limit restrictions.
+
+Lines 11 through 18 are for replication. Line 12 specifies the
+replication log file (where changes to the database are logged \-
+this file is written by slapd and read by slurpd). Lines 13 through
+15 specify the hostname and port for a replicated host, the DN to
+bind as when performing updates, the bind method (simple) and the
+credentials (password) for the binddn. Lines 16 through 18 specify
+a second replication site.  See the {{SECT:Replication with slurpd}}
+chapter for more information on these directives.
+
+Lines 20 through 22 indicate the indexes to maintain for various
+attributes.
+
+Lines 24 through 32 specify access control for entries in the this
+database.  As this is the first database, the controls also apply
+to entries not held in any database (such as the Root DSE).  For
+all applicable entries, the {{EX:userPassword}} attribute is writable
+by the entry itself and by the "admin" entry.  It may be used for
+authentication/authorization purposes, but is otherwise not readable.
+All other attributes are writable by the entry and the "admin"
+entry, but may be read by all users (authenticated or not).
+
+The next section of the example configuration file defines another
+LDBM database. This one handles queries involving the
+{{EX:dc=example,dc=net}} subtree but is managed by the same entity
+as the first database.  Note that without line 39, the read access
+would be allowed due to the global access rule at line 4.
 
 E: 33. # ldbm definition for example.net
 E: 34. database ldbm
 E: 35. suffix "dc=example,dc=net"
 E: 36. directory /usr/local/var/ldbm-example-net
 E: 37. rootdn "cn=Manager,dc=example,dc=com"
-E: 38. access to * by users read
+E: 38. index objectClass eq
+E: 39. access to * by users read