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.
73 [dn[.<dnstyle>]=<pattern>]
80 stands for all the entries.
84 selects the entries based on their naming context.
85 The optional style qualifier
89 (the default) implies that
91 is a regular expression, as detailed in
93 matching a normalized string representation of the entry's DN.
94 The regex form of the pattern does not support UTF-8 yet.
96 For all other qualifiers, the pattern is a string representation of
103 indicates the entry whose DN is equal to the pattern.
105 indicates all the entries immediately below the
108 indicates all entries in the subtree at the pattern,
110 indicates all the entries below (subordinate to) the pattern.
117 .B filter=<ldapfilter>
118 selects the entries based on a valid LDAP filter as described in RFC 2254.
122 selects the attributes the access control rule applies to.
123 It is a comma-separated list of attribute types, plus the special names
125 indicating access to the entry itself, and
127 indicating access to the entry's children. ObjectClass names may also
128 be specified in this list, which will affect all the attributes that
129 are required and/or allowed by that objectClass.
131 The last three statements are additive; they can be used in sequence
132 to select entities the access rule applies to based on naming context,
133 value and attribute type simultaneously.
137 indicates whom the access rules apply to.
140 statements can appear in an access control statement, indicating the
141 different access privileges to the same resource that apply to different
143 It can have the forms
151 dn[.<dnstyle>[,<modifier>]]=<pattern>
153 group[/<objectclass>[/<attrname>]]
155 peername[.<style>]=<pattern>
156 sockname[.<style>]=<pattern>
157 domain[.<domainstyle>[,<modifier>]]=<pattern>
158 sockurl[.<style>]=<pattern>
159 set[.<style>]=<pattern>
169 They may be specified in combination.
180 means access is granted to unauthenticated clients; it is mostly used
181 to limit access to authentication resources (e.g. the
183 attribute) to unauthenticated clients for authentication purposes.
187 means access is granted to authenticated clients.
191 means access to an entry is allowed to the entry itself (e.g. the entry
192 being accessed and the requesting entry must be the same).
196 means that access is granted to the matching DN.
197 The optional style qualifier
199 allows the same choices of the dn form of the
201 field. In addition, the
205 can exploit substring substitution of submatches in the
207 dn.regex clause by using the form
215 means that access is granted to requests whose DN is listed in the
216 entry being accessed under the
222 means that access is granted to requests whose DN is listed
223 in the group entry whose DN is given by
225 The optional parameters
229 define the objectClass and the member attributeType of the group entry.
230 The optional style qualifier
236 will be expanded accorging to regex (7), and
242 which means that exact match will be used.
245 .BR peername=<pattern> ,
246 .BR sockname=<pattern> ,
247 .BR domain=<pattern> ,
249 .BR sockurl=<pattern>
250 mean that the contacting host IP for
252 the named pipe file name for
254 the contacting host name for
256 and the contacting URL for
263 rules for pattern match described for the
268 clause also allows the
270 style, which succeeds when a fully qualified name exactly matches the
272 pattern, or its trailing part, after a
279 of the contacting host is determined by performing a DNS reverse lookup.
280 As this lookup can easily be spoofed, use of the
282 statement is strongly discouraged. By default, reverse lookups are disabled.
290 means that the access control is determined by the values in the
293 ACIs are experimental; they must be enabled at compile time.
297 .BR transport_ssf=<n> ,
301 set the required Security Strength Factor (ssf) required to grant access.
304 .B <access> ::= [self]{<level>|<priv>}
305 determines the access level or the specific access privileges the
308 Its component are defined as
311 <level> ::= none|auth|compare|search|read|write
312 <priv> ::= {=|+|-}{w|r|s|c|x}+
317 allows special operations like having a certain access level or privilege
318 only in case the operation involves the name of the user that's requesting
320 It implies the user that requests access is bound.
323 access to the member attribute of a group, which allows one to add/delete
324 its own DN from the member list of a group, without affecting other members.
328 access model relies on an incremental interpretation of the access
330 The possible levels are
338 Each access level implies all the preceding ones, thus
340 access will imply all accesses.
345 access means that one is allowed access to an attribute to perform
346 authentication/authorization operations (e.g.
348 with no other access.
349 This is useful to grant unauthenticated clients the least possible
350 access level to critical resources, like passwords.
354 access model relies on the explicit setting of access privileges
358 sign resets previously defined accesses; as a consequence, the final
359 access privileges will be only those defined by the clause.
364 signs add/remove access privileges to the existing ones.
376 More than one privilege can be added in one statement.
380 controls the flow of access rule application.
381 It can have the forms
391 the default, means access checking stops in case of match.
392 The other two forms are used to keep on processing access clauses.
395 form allows for other
399 clause to be considered, so that they may result in incrementally altering
400 the privileges, while the
402 form allows for other
404 clauses that match the same target to be processed.
405 Consider the (silly) example
408 access to dn.subtree="dc=example,dc=com" attrs=cn
411 access to dn.subtree="ou=People,dc=example,dc=com"
415 which allows search and compare privileges to everybody under
416 the "dc=example,dc=com" tree, with the second rule allowing
417 also read in the "ou=People" subtree,
418 or the (even more silly) example
421 access to dn.subtree="dc=example,dc=com" attrs=cn
426 which grants everybody search and compare privileges, and adds read
427 privileges to authenticated clients.
429 It is strongly recommended to explicitly use the most appropriate
433 incorrect specifications of the access rules as well
434 as for performance (avoid unrequired regex matching when
435 an exact match suffices) reasons.
437 An adminisistrator might create a rule of the form:
440 access to dn="dc=example,dc=com"
444 expecting it to match all entries in the subtree "dc=example,dc=com".
445 However, this rule actually matches any DN which contains anywhere
446 the substring "dc=example,dc=com". That is, the rule matches both
447 "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
449 To match the desired subtree, the rule would be more precisely
453 access to dn.regex="^(.+,)?dc=example,dc=com$$"
457 For performance reasons, it would be better to use the subtree style.
460 access to dn.subtree="dc=example,dc=com"
467 default slapd configuration file
471 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
474 is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
476 is derived from University of Michigan LDAP 3.3 Release.
projects / openldap / blob