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 according to regex (7), and
249 which means that exact match will be used.
251 For static groups, the specified attributeType must have
254 .B NameAndOptionalUID
255 syntax. For dynamic groups the attributeType must
261 .BR peername=<peername> ,
262 .BR sockname=<sockname> ,
263 .BR domain=<domain> ,
265 .BR sockurl=<sockurl>
266 mean that the contacting host IP for
268 the named pipe file name for
270 the contacting host name for
272 and the contacting URL for
279 rules for pattern match described for the
284 clause also allows the
286 style, which succeeds when a fully qualified name exactly matches the
288 pattern, or its trailing part, after a
295 of the contacting host is determined by performing a DNS reverse lookup.
296 As this lookup can easily be spoofed, use of the
298 statement is strongly discouraged. By default, reverse lookups are disabled.
306 means that the access control is determined by the values in the
309 ACIs are experimental; they must be enabled at compile time.
313 .BR transport_ssf=<n> ,
317 set the required Security Strength Factor (ssf) required to grant access.
320 .B <access> ::= [self]{<level>|<priv>}
321 determines the access level or the specific access privileges the
324 Its component are defined as
327 <level> ::= none|auth|compare|search|read|write
328 <priv> ::= {=|+|-}{w|r|s|c|x}+
333 allows special operations like having a certain access level or privilege
334 only in case the operation involves the name of the user that's requesting
336 It implies the user that requests access is bound.
339 access to the member attribute of a group, which allows one to add/delete
340 its own DN from the member list of a group, without affecting other members.
344 access model relies on an incremental interpretation of the access
346 The possible levels are
354 Each access level implies all the preceding ones, thus
356 access will imply all accesses.
361 access means that one is allowed access to an attribute to perform
362 authentication/authorization operations (e.g.
364 with no other access.
365 This is useful to grant unauthenticated clients the least possible
366 access level to critical resources, like passwords.
370 access model relies on the explicit setting of access privileges
374 sign resets previously defined accesses; as a consequence, the final
375 access privileges will be only those defined by the clause.
380 signs add/remove access privileges to the existing ones.
392 More than one privilege can be added in one statement.
396 controls the flow of access rule application.
397 It can have the forms
407 the default, means access checking stops in case of match.
408 The other two forms are used to keep on processing access clauses.
411 form allows for other
415 clause to be considered, so that they may result in incrementally altering
416 the privileges, while the
418 form allows for other
420 clauses that match the same target to be processed.
421 Consider the (silly) example
424 access to dn.subtree="dc=example,dc=com" attrs=cn
427 access to dn.subtree="ou=People,dc=example,dc=com"
431 which allows search and compare privileges to everybody under
432 the "dc=example,dc=com" tree, with the second rule allowing
433 also read in the "ou=People" subtree,
434 or the (even more silly) example
437 access to dn.subtree="dc=example,dc=com" attrs=cn
442 which grants everybody search and compare privileges, and adds read
443 privileges to authenticated clients.
445 It is strongly recommended to explicitly use the most appropriate
448 to avoid possible incorrect specifications of the access rules as well
449 as for performance (avoid unrequired regex matching when an exact
450 match suffices) reasons.
452 An adminisistrator might create a rule of the form:
455 access to dn.regex="dc=example,dc=com"
459 expecting it to match all entries in the subtree "dc=example,dc=com".
460 However, this rule actually matches any DN which contains anywhere
461 the substring "dc=example,dc=com". That is, the rule matches both
462 "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
464 To match the desired subtree, the rule would be more precisely
468 access to dn.regex="^(.+,)?dc=example,dc=com$$"
472 For performance reasons, it would be better to use the subtree style.
475 access to dn.subtree="dc=example,dc=com"
482 default slapd configuration file
486 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
489 is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
491 is derived from University of Michigan LDAP 3.3 Release.
projects / openldap / blob