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.
127 .B attrs=<attr> val[.<style>]=<value>
128 specifies access to a particular value of a single attribute.
129 In this case, only a single attribute type may be given. A value
133 (the default) uses the attribute's equality matching rule to compare the
138 the provided value is used as a regular expression pattern.
140 The dn, filter, and attrs statements are additive; they can be used in sequence
141 to select entities the access rule applies to based on naming context,
142 value and attribute type simultaneously.
146 indicates whom the access rules apply to.
149 statements can appear in an access control statement, indicating the
150 different access privileges to the same resource that apply to different
152 It can have the forms
160 dn[.<dnstyle>[,<modifier>]]=<DN>
162 group[/<objectclass>[/<attrname>]]
164 peername[.<style>]=<peername>
165 sockname[.<style>]=<sockname>
166 domain[.<domainstyle>[,<modifier>]]=<domain>
167 sockurl[.<style>]=<sockurl>
168 set[.<style>]=<pattern>
178 They may be specified in combination.
189 means access is granted to unauthenticated clients; it is mostly used
190 to limit access to authentication resources (e.g. the
192 attribute) to unauthenticated clients for authentication purposes.
196 means access is granted to authenticated clients.
200 means access to an entry is allowed to the entry itself (e.g. the entry
201 being accessed and the requesting entry must be the same).
205 means that access is granted to the matching DN.
206 The optional style qualifier
208 allows the same choices of the dn form of the
210 field. In addition, the
212 style can exploit substring substitution of submatches in the
214 dn.regex clause by using the form
222 means that access is granted to requests whose DN is listed in the
223 entry being accessed under the
229 means that access is granted to requests whose DN is listed
230 in the group entry whose DN is given by
232 The optional parameters
236 define the objectClass and the member attributeType of the group entry.
237 The optional style qualifier
243 will be expanded accorging to regex (7), and
249 which means that exact match will be used.
252 .BR peername=<peername> ,
253 .BR sockname=<sockname> ,
254 .BR domain=<domain> ,
256 .BR sockurl=<sockurl>
257 mean that the contacting host IP for
259 the named pipe file name for
261 the contacting host name for
263 and the contacting URL for
270 rules for pattern match described for the
275 clause also allows the
277 style, which succeeds when a fully qualified name exactly matches the
279 pattern, or its trailing part, after a
286 of the contacting host is determined by performing a DNS reverse lookup.
287 As this lookup can easily be spoofed, use of the
289 statement is strongly discouraged. By default, reverse lookups are disabled.
297 means that the access control is determined by the values in the
300 ACIs are experimental; they must be enabled at compile time.
304 .BR transport_ssf=<n> ,
308 set the required Security Strength Factor (ssf) required to grant access.
311 .B <access> ::= [self]{<level>|<priv>}
312 determines the access level or the specific access privileges the
315 Its component are defined as
318 <level> ::= none|auth|compare|search|read|write
319 <priv> ::= {=|+|-}{w|r|s|c|x}+
324 allows special operations like having a certain access level or privilege
325 only in case the operation involves the name of the user that's requesting
327 It implies the user that requests access is bound.
330 access to the member attribute of a group, which allows one to add/delete
331 its own DN from the member list of a group, without affecting other members.
335 access model relies on an incremental interpretation of the access
337 The possible levels are
345 Each access level implies all the preceding ones, thus
347 access will imply all accesses.
352 access means that one is allowed access to an attribute to perform
353 authentication/authorization operations (e.g.
355 with no other access.
356 This is useful to grant unauthenticated clients the least possible
357 access level to critical resources, like passwords.
361 access model relies on the explicit setting of access privileges
365 sign resets previously defined accesses; as a consequence, the final
366 access privileges will be only those defined by the clause.
371 signs add/remove access privileges to the existing ones.
383 More than one privilege can be added in one statement.
387 controls the flow of access rule application.
388 It can have the forms
398 the default, means access checking stops in case of match.
399 The other two forms are used to keep on processing access clauses.
402 form allows for other
406 clause to be considered, so that they may result in incrementally altering
407 the privileges, while the
409 form allows for other
411 clauses that match the same target to be processed.
412 Consider the (silly) example
415 access to dn.subtree="dc=example,dc=com" attrs=cn
418 access to dn.subtree="ou=People,dc=example,dc=com"
422 which allows search and compare privileges to everybody under
423 the "dc=example,dc=com" tree, with the second rule allowing
424 also read in the "ou=People" subtree,
425 or the (even more silly) example
428 access to dn.subtree="dc=example,dc=com" attrs=cn
433 which grants everybody search and compare privileges, and adds read
434 privileges to authenticated clients.
436 It is strongly recommended to explicitly use the most appropriate
439 to avoid possible incorrect specifications of the access rules as well
440 as for performance (avoid unrequired regex matching when an exact
441 match suffices) reasons.
443 An adminisistrator might create a rule of the form:
446 access to dn.regex="dc=example,dc=com"
450 expecting it to match all entries in the subtree "dc=example,dc=com".
451 However, this rule actually matches any DN which contains anywhere
452 the substring "dc=example,dc=com". That is, the rule matches both
453 "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
455 To match the desired subtree, the rule would be more precisely
459 access to dn.regex="^(.+,)?dc=example,dc=com$$"
463 For performance reasons, it would be better to use the subtree style.
466 access to dn.subtree="dc=example,dc=com"
473 default slapd configuration file
477 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
480 is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
482 is derived from University of Michigan LDAP 3.3 Release.