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
258 attributeType. Only LDAP URIs of the form
259 .B ldap:///<base>??<scope>?<filter>
260 will be evaluated in a dynamic group.
263 .BR peername=<peername> ,
264 .BR sockname=<sockname> ,
265 .BR domain=<domain> ,
267 .BR sockurl=<sockurl>
268 mean that the contacting host IP for
270 the named pipe file name for
272 the contacting host name for
274 and the contacting URL for
281 rules for pattern match described for the
286 clause also allows the
288 style, which succeeds when a fully qualified name exactly matches the
290 pattern, or its trailing part, after a
297 of the contacting host is determined by performing a DNS reverse lookup.
298 As this lookup can easily be spoofed, use of the
300 statement is strongly discouraged. By default, reverse lookups are disabled.
308 means that the access control is determined by the values in the
311 ACIs are experimental; they must be enabled at compile time.
315 .BR transport_ssf=<n> ,
319 set the required Security Strength Factor (ssf) required to grant access.
322 .B <access> ::= [self]{<level>|<priv>}
323 determines the access level or the specific access privileges the
326 Its component are defined as
329 <level> ::= none|auth|compare|search|read|write
330 <priv> ::= {=|+|-}{w|r|s|c|x}+
335 allows special operations like having a certain access level or privilege
336 only in case the operation involves the name of the user that's requesting
338 It implies the user that requests access is bound.
341 access to the member attribute of a group, which allows one to add/delete
342 its own DN from the member list of a group, without affecting other members.
346 access model relies on an incremental interpretation of the access
348 The possible levels are
356 Each access level implies all the preceding ones, thus
358 access will imply all accesses.
363 access means that one is allowed access to an attribute to perform
364 authentication/authorization operations (e.g.
366 with no other access.
367 This is useful to grant unauthenticated clients the least possible
368 access level to critical resources, like passwords.
372 access model relies on the explicit setting of access privileges
376 sign resets previously defined accesses; as a consequence, the final
377 access privileges will be only those defined by the clause.
382 signs add/remove access privileges to the existing ones.
394 More than one privilege can be added in one statement.
398 controls the flow of access rule application.
399 It can have the forms
409 the default, means access checking stops in case of match.
410 The other two forms are used to keep on processing access clauses.
413 form allows for other
417 clause to be considered, so that they may result in incrementally altering
418 the privileges, while the
420 form allows for other
422 clauses that match the same target to be processed.
423 Consider the (silly) example
426 access to dn.subtree="dc=example,dc=com" attrs=cn
429 access to dn.subtree="ou=People,dc=example,dc=com"
433 which allows search and compare privileges to everybody under
434 the "dc=example,dc=com" tree, with the second rule allowing
435 also read in the "ou=People" subtree,
436 or the (even more silly) example
439 access to dn.subtree="dc=example,dc=com" attrs=cn
444 which grants everybody search and compare privileges, and adds read
445 privileges to authenticated clients.
447 It is strongly recommended to explicitly use the most appropriate
450 to avoid possible incorrect specifications of the access rules as well
451 as for performance (avoid unrequired regex matching when an exact
452 match suffices) reasons.
454 An adminisistrator might create a rule of the form:
457 access to dn.regex="dc=example,dc=com"
461 expecting it to match all entries in the subtree "dc=example,dc=com".
462 However, this rule actually matches any DN which contains anywhere
463 the substring "dc=example,dc=com". That is, the rule matches both
464 "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
466 To match the desired subtree, the rule would be more precisely
470 access to dn.regex="^(.+,)?dc=example,dc=com$$"
474 For performance reasons, it would be better to use the subtree style.
477 access to dn.subtree="dc=example,dc=com"
484 default slapd configuration file
488 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
491 is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
493 is derived from University of Michigan LDAP 3.3 Release.
projects / openldap / blob