1 .TH SLAPD.ACCESS 5 "RELEASEDATE" "OpenLDAP LDVERSION"
2 .\" Copyright 1998-2003 The OpenLDAP Foundation All Rights Reserved.
3 .\" Copying restrictions apply. See COPYRIGHT/LICENSE.
5 slapd.access \- access configuration for slapd, the stand-alone LDAP daemon
11 file contains configuration information for the
13 daemon. This configuration file is also used by the
15 replication daemon and by the SLAPD tools
23 file consists of a series of global configuration options that apply to
25 as a whole (including all backends), followed by zero or more database
26 backend definitions that contain information specific to a backend
34 # comment - these options apply to every database
35 <global configuration options>
36 # first database definition & configuration options
37 database <backend 1 type>
38 <configuration options specific to backend 1>
39 # subsequent database definitions & configuration options
43 Both the global configuration and each backend-specific section can
44 contain access information. Backend-specific access control
45 directives are used for those entries that belong to the backend,
46 according to their naming context. In case no access control
47 directives are defined for a backend or those which are defined are
48 not applicable, the directives from the global configuration section
51 For entries not held in any backend (such as a root DSE), the
52 directives of the first backend (and any global directives) are
55 Arguments that should be replaced by actual text are shown in
56 brackets <>. The structure of the access control directives is
58 .B access to <what> "[ by <who> <access> [ <control> ] ]+"
59 Grant access (specified by
61 to a set of entries and/or attributes (specified by
63 by one or more requestors (specified by
68 specifies the entity the access control directive applies to.
80 stands for all the entries.
84 selects the entries based on their naming context.
85 The pattern is a string representation of the entry's DN.
92 indicates the entry whose DN is equal to the pattern.
94 indicates all the entries immediately below the
97 indicates all entries in the subtree at the pattern,
99 indicates all the entries below (subordinate to) the pattern.
105 then the value is a regular expression pattern,
108 matching a normalized string representation of the entry's DN.
109 The regex form of the pattern does not (yet) support UTF-8.
112 .B filter=<ldapfilter>
113 selects the entries based on a valid LDAP filter as described in RFC 2254.
117 selects the attributes the access control rule applies to.
118 It is a comma-separated list of attribute types, plus the special names
120 indicating access to the entry itself, and
122 indicating access to the entry's children. ObjectClass names may also
123 be specified in this list, which will affect all the attributes that
124 are required and/or allowed by that objectClass.
126 The last three statements are additive; they can be used in sequence
127 to select entities the access rule applies to based on naming context,
128 value and attribute type simultaneously.
132 indicates whom the access rules apply to.
135 statements can appear in an access control statement, indicating the
136 different access privileges to the same resource that apply to different
138 It can have the forms
146 dn[.<dnstyle>[,<modifier>]]=<DN>
148 group[/<objectclass>[/<attrname>]]
150 peername[.<style>]=<peername>
151 sockname[.<style>]=<sockname>
152 domain[.<domainstyle>[,<modifier>]]=<domain>
153 sockurl[.<style>]=<sockurl>
154 set[.<style>]=<pattern>
164 They may be specified in combination.
175 means access is granted to unauthenticated clients; it is mostly used
176 to limit access to authentication resources (e.g. the
178 attribute) to unauthenticated clients for authentication purposes.
182 means access is granted to authenticated clients.
186 means access to an entry is allowed to the entry itself (e.g. the entry
187 being accessed and the requesting entry must be the same).
191 means that access is granted to the matching DN.
192 The optional style qualifier
194 allows the same choices of the dn form of the
196 field. In addition, the
198 style can exploit substring substitution of submatches in the
200 dn.regex clause by using the form
208 means that access is granted to requests whose DN is listed in the
209 entry being accessed under the
215 means that access is granted to requests whose DN is listed
216 in the group entry whose DN is given by
218 The optional parameters
222 define the objectClass and the member attributeType of the group entry.
223 The optional style qualifier
229 will be expanded accorging to regex (7), and
235 which means that exact match will be used.
238 .BR peername=<peername> ,
239 .BR sockname=<sockname> ,
240 .BR domain=<domain> ,
242 .BR sockurl=<sockurl>
243 mean that the contacting host IP for
245 the named pipe file name for
247 the contacting host name for
249 and the contacting URL for
256 rules for pattern match described for the
261 clause also allows the
263 style, which succeeds when a fully qualified name exactly matches the
265 pattern, or its trailing part, after a
272 of the contacting host is determined by performing a DNS reverse lookup.
273 As this lookup can easily be spoofed, use of the
275 statement is strongly discouraged. By default, reverse lookups are disabled.
283 means that the access control is determined by the values in the
286 ACIs are experimental; they must be enabled at compile time.
290 .BR transport_ssf=<n> ,
294 set the required Security Strength Factor (ssf) required to grant access.
297 .B <access> ::= [self]{<level>|<priv>}
298 determines the access level or the specific access privileges the
301 Its component are defined as
304 <level> ::= none|auth|compare|search|read|write
305 <priv> ::= {=|+|-}{w|r|s|c|x}+
310 allows special operations like having a certain access level or privilege
311 only in case the operation involves the name of the user that's requesting
313 It implies the user that requests access is bound.
316 access to the member attribute of a group, which allows one to add/delete
317 its own DN from the member list of a group, without affecting other members.
321 access model relies on an incremental interpretation of the access
323 The possible levels are
331 Each access level implies all the preceding ones, thus
333 access will imply all accesses.
338 access means that one is allowed access to an attribute to perform
339 authentication/authorization operations (e.g.
341 with no other access.
342 This is useful to grant unauthenticated clients the least possible
343 access level to critical resources, like passwords.
347 access model relies on the explicit setting of access privileges
351 sign resets previously defined accesses; as a consequence, the final
352 access privileges will be only those defined by the clause.
357 signs add/remove access privileges to the existing ones.
369 More than one privilege can be added in one statement.
373 controls the flow of access rule application.
374 It can have the forms
384 the default, means access checking stops in case of match.
385 The other two forms are used to keep on processing access clauses.
388 form allows for other
392 clause to be considered, so that they may result in incrementally altering
393 the privileges, while the
395 form allows for other
397 clauses that match the same target to be processed.
398 Consider the (silly) example
401 access to dn.subtree="dc=example,dc=com" attrs=cn
404 access to dn.subtree="ou=People,dc=example,dc=com"
408 which allows search and compare privileges to everybody under
409 the "dc=example,dc=com" tree, with the second rule allowing
410 also read in the "ou=People" subtree,
411 or the (even more silly) example
414 access to dn.subtree="dc=example,dc=com" attrs=cn
419 which grants everybody search and compare privileges, and adds read
420 privileges to authenticated clients.
422 It is strongly recommended to explicitly use the most appropriate
425 to avoid possible incorrect specifications of the access rules as well
426 as for performance (avoid unrequired regex matching when an exact
427 match suffices) reasons.
429 An adminisistrator might create a rule of the form:
432 access to dn.regex="dc=example,dc=com"
436 expecting it to match all entries in the subtree "dc=example,dc=com".
437 However, this rule actually matches any DN which contains anywhere
438 the substring "dc=example,dc=com". That is, the rule matches both
439 "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
441 To match the desired subtree, the rule would be more precisely
445 access to dn.regex="^(.+,)?dc=example,dc=com$$"
449 For performance reasons, it would be better to use the subtree style.
452 access to dn.subtree="dc=example,dc=com"
459 default slapd configuration file
463 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
466 is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
468 is derived from University of Michigan LDAP 3.3 Release.