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 At present, the only type allowed is
224 which causes substring substitution of submatches to take place
232 means that access is granted to requests whose DN is listed in the
233 entry being accessed under the
239 means that access is granted to requests whose DN is listed
240 in the group entry whose DN is given by
242 The optional parameters
246 define the objectClass and the member attributeType of the group entry.
247 The optional style qualifier
253 will be expanded as a replacement string (but not as a regular expression)
254 according to regex (7), and
260 which means that exact match will be used.
262 For static groups, the specified attributeType must have
265 .B NameAndOptionalUID
266 syntax. For dynamic groups the attributeType must
269 attributeType. Only LDAP URIs of the form
270 .B ldap:///<base>??<scope>?<filter>
271 will be evaluated in a dynamic group.
274 .BR peername=<peername> ,
275 .BR sockname=<sockname> ,
276 .BR domain=<domain> ,
278 .BR sockurl=<sockurl>
279 mean that the contacting host IP for
281 the named pipe file name for
283 the contacting host name for
285 and the contacting URL for
292 rules for pattern match described for the
297 clause also allows the
299 style, which succeeds when a fully qualified name exactly matches the
301 pattern, or its trailing part, after a
308 of the contacting host is determined by performing a DNS reverse lookup.
309 As this lookup can easily be spoofed, use of the
311 statement is strongly discouraged. By default, reverse lookups are disabled.
318 option; the only value currently supported is
320 which causes substring substitution of submatches to take place even if
325 much like the analogous usage in
335 means that the access control is determined by the values in the
338 ACIs are experimental; they must be enabled at compile time.
342 .BR transport_ssf=<n> ,
346 set the required Security Strength Factor (ssf) required to grant access.
349 .B <access> ::= [self]{<level>|<priv>}
350 determines the access level or the specific access privileges the
353 Its component are defined as
356 <level> ::= none|auth|compare|search|read|write
357 <priv> ::= {=|+|-}{w|r|s|c|x}+
362 allows special operations like having a certain access level or privilege
363 only in case the operation involves the name of the user that's requesting
365 It implies the user that requests access is bound.
368 access to the member attribute of a group, which allows one to add/delete
369 its own DN from the member list of a group, without affecting other members.
373 access model relies on an incremental interpretation of the access
375 The possible levels are
383 Each access level implies all the preceding ones, thus
385 access will imply all accesses.
390 access means that one is allowed access to an attribute to perform
391 authentication/authorization operations (e.g.
393 with no other access.
394 This is useful to grant unauthenticated clients the least possible
395 access level to critical resources, like passwords.
399 access model relies on the explicit setting of access privileges
403 sign resets previously defined accesses; as a consequence, the final
404 access privileges will be only those defined by the clause.
409 signs add/remove access privileges to the existing ones.
421 More than one privilege can be added in one statement.
425 controls the flow of access rule application.
426 It can have the forms
436 the default, means access checking stops in case of match.
437 The other two forms are used to keep on processing access clauses.
440 form allows for other
444 clause to be considered, so that they may result in incrementally altering
445 the privileges, while the
447 form allows for other
449 clauses that match the same target to be processed.
450 Consider the (silly) example
453 access to dn.subtree="dc=example,dc=com" attrs=cn
456 access to dn.subtree="ou=People,dc=example,dc=com"
460 which allows search and compare privileges to everybody under
461 the "dc=example,dc=com" tree, with the second rule allowing
462 also read in the "ou=People" subtree,
463 or the (even more silly) example
466 access to dn.subtree="dc=example,dc=com" attrs=cn
471 which grants everybody search and compare privileges, and adds read
472 privileges to authenticated clients.
474 It is strongly recommended to explicitly use the most appropriate
477 to avoid possible incorrect specifications of the access rules as well
478 as for performance (avoid unrequired regex matching when an exact
479 match suffices) reasons.
481 An adminisistrator might create a rule of the form:
484 access to dn.regex="dc=example,dc=com"
488 expecting it to match all entries in the subtree "dc=example,dc=com".
489 However, this rule actually matches any DN which contains anywhere
490 the substring "dc=example,dc=com". That is, the rule matches both
491 "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
493 To match the desired subtree, the rule would be more precisely
497 access to dn.regex="^(.+,)?dc=example,dc=com$$"
501 For performance reasons, it would be better to use the subtree style.
504 access to dn.subtree="dc=example,dc=com"
511 default slapd configuration file
515 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
518 is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
520 is derived from University of Michigan LDAP 3.3 Release.
projects / openldap / blob