]> git.sur5r.net Git - openldap/blob - doc/man/man5/slapd.access.5
4134cecab31cc4c95e1aa460444e96fb14bd55d5
[openldap] / doc / man / man5 / slapd.access.5
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.
4 .SH NAME
5 slapd.access \- access configuration for slapd, the stand-alone LDAP daemon
6 .SH SYNOPSIS
7 ETCDIR/slapd.conf
8 .SH DESCRIPTION
9 The 
10 .BR slapd.conf (5)
11 file contains configuration information for the
12 .BR slapd (8)
13 daemon. This configuration file is also used by the
14 .BR slurpd (8)
15 replication daemon and by the SLAPD tools
16 .BR slapadd (8),
17 .BR slapcat (8),
18 and
19 .BR slapindex (8).
20 .LP
21 The
22 .B slapd.conf
23 file consists of a series of global configuration options that apply to
24 .B slapd
25 as a whole (including all backends), followed by zero or more database
26 backend definitions that contain information specific to a backend
27 instance.
28 .LP
29 The general format of
30 .B slapd.conf
31 is as follows:
32 .LP
33 .nf
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
40     ...
41 .fi
42 .LP
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
49 are then used.
50 .LP
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
53 used.
54 .LP
55 Arguments that should be replaced by actual text are shown in
56 brackets <>.  The structure of the access control directives is
57 .TP
58 .B access to <what> "[ by <who> <access> [ <control> ] ]+"
59 Grant access (specified by 
60 .BR <access> ) 
61 to a set of entries and/or attributes (specified by 
62 .BR <what> ) 
63 by one or more requestors (specified by 
64 .BR <who> ).
65 .LP
66 The field
67 .BR <what>
68 specifies the entity the access control directive applies to.
69 It can have the forms
70 .LP
71 .nf
72         *
73         [dn[.<dnstyle>]=<DN>] 
74         [filter=<ldapfilter>]
75         [attrs=<attrlist>]
76 .fi
77 .LP
78 The wildcard
79 .B *
80 stands for all the entries.
81 .LP
82 The statement
83 .B dn=<DN>
84 selects the entries based on their naming context.
85 The pattern is a string representation of the entry's DN.
86 .BR base ,
87 the default,
88 or
89 .B exact 
90 (an alias of 
91 .BR base )
92 indicates the entry whose DN is equal to the pattern.
93 .B one
94 indicates all the entries immediately below the
95 .BR pattern ,
96 .B subtree
97 indicates all entries in the subtree at the pattern,
98 .B children
99 indicates all the entries below (subordinate to) the pattern.
100 .LP
101 If the
102 .B <dnstyle>
103 qualifier is
104 .BR regex ,
105 then the value is a regular expression pattern,
106 as detailed in
107 .BR regex (7),
108 matching a normalized string representation of the entry's DN.
109 The regex form of the pattern does not (yet) support UTF-8.
110 .LP
111 The statement
112 .B filter=<ldapfilter>
113 selects the entries based on a valid LDAP filter as described in RFC 2254.
114 .LP
115 The statement
116 .B attrs=<attrlist>
117 selects the attributes the access control rule applies to.
118 It is a comma-separated list of attribute types, plus the special names
119 .BR entry ,
120 indicating access to the entry itself, and
121 .BR children ,
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.
125 .LP
126 Using the form
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
130 .B <style>
131 of
132 .B exact
133 (the default) uses the attribute's equality matching rule to compare the
134 value. If the
135 .B <style>
136 is
137 .BR regex ,
138 the provided value is used as a regular expression pattern.
139 .LP
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.
143 .LP
144 The field
145 .B <who>
146 indicates whom the access rules apply to.
147 Multiple 
148 .B <who>
149 statements can appear in an access control statement, indicating the
150 different access privileges to the same resource that apply to different
151 accessee.
152 It can have the forms
153 .LP
154 .nf
155         *
156         anonymous
157         users
158         self
159
160         dn[.<dnstyle>[,<modifier>]]=<DN>
161         dnattr=<attrname>
162         group[/<objectclass>[/<attrname>]]
163                 [.<style>]=<group>
164         peername[.<style>]=<peername>
165         sockname[.<style>]=<sockname>
166         domain[.<domainstyle>[,<modifier>]]=<domain>
167         sockurl[.<style>]=<sockurl>
168         set[.<style>]=<pattern>
169
170         ssf=<n>
171         transport_ssf=<n>
172         tls_ssf=<n>
173         sasl_ssf=<n>
174
175         aci=<attrname>
176 .fi
177 .LP
178 They may be specified in combination.
179 .LP
180 .nf
181 .fi
182 .LP
183 The wildcard
184 .B *
185 refers to everybody.
186 .LP
187 The keyword
188 .B anonymous
189 means access is granted to unauthenticated clients; it is mostly used 
190 to limit access to authentication resources (e.g. the
191 .B userPassword
192 attribute) to unauthenticated clients for authentication purposes.
193 .LP
194 The keyword
195 .B users
196 means access is granted to authenticated clients.
197 .LP
198 The keyword
199 .B self
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).
202 .LP
203 The statement
204 .B dn=<DN>
205 means that access is granted to the matching DN.
206 The optional style qualifier
207 .B dnstyle
208 allows the same choices of the dn form of the
209 .B <what>
210 field.  In addition, the
211 .B regex
212 style can exploit substring substitution of submatches in the
213 .B <what>
214 dn.regex clause by using the form
215 .BR $<digit> ,
216 with 
217 .B digit
218 ranging from 1 to 9.
219 .LP
220 The statement
221 .B dnattr=<attrname>
222 means that access is granted to requests whose DN is listed in the
223 entry being accessed under the 
224 .B attrname
225 attribute.
226 .LP
227 The statement
228 .B group=<group>
229 means that access is granted to requests whose DN is listed
230 in the group entry whose DN is given by
231 .BR group .
232 The optional parameters
233 .B objectclass
234 and
235 .B attrname
236 define the objectClass and the member attributeType of the group entry.
237 The optional style qualifier
238 .B style
239 can be
240 .BR regex ,
241 which means that
242 .B pattern
243 will be expanded accorging to regex (7), and
244 .B base
245 or
246 .B exact
247 (an alias of
248 .BR base ),
249 which means that exact match will be used.
250 .LP
251 The statements
252 .BR peername=<peername> ,
253 .BR sockname=<sockname> ,
254 .BR domain=<domain> ,
255 and
256 .BR sockurl=<sockurl>
257 mean that the contacting host IP for
258 .BR peername ,
259 the named pipe file name for
260 .BR sockname ,
261 the contacting host name for
262 .BR domain ,
263 and the contacting URL for
264 .BR sockurl
265 are compared against
266 .B pattern
267 to determine access.
268 The same
269 .B style
270 rules for pattern match described for the
271 .B group
272 case apply. 
273 The
274 .BR domain 
275 clause also allows the
276 .B subtree
277 style, which succeeds when a fully qualified name exactly matches the
278 .BR domain
279 pattern, or its trailing part, after a 
280 .BR dot ,
281 exactly matches the 
282 .BR domain
283 pattern.
284 The
285 .B domain
286 of the contacting host is determined by performing a DNS reverse lookup.
287 As this lookup can easily be spoofed, use of the
288 .B domain
289 statement is strongly discouraged.  By default, reverse lookups are disabled.
290 .LP
291 The statement
292 .B set=<pattern>
293 is undocumented yet.
294 .LP
295 The statement
296 .B aci=<attrname>
297 means that the access control is determined by the values in the
298 .B attrname
299 of the entry itself.
300 ACIs are experimental; they must be enabled at compile time.
301 .LP
302 The statements
303 .BR ssf=<n> ,
304 .BR transport_ssf=<n> ,
305 .BR tls_ssf=<n> ,
306 and
307 .BR sasl_ssf=<n>
308 set the required Security Strength Factor (ssf) required to grant access.
309 .LP
310 The field
311 .B <access> ::= [self]{<level>|<priv>}
312 determines the access level or the specific access privileges the
313 .B who 
314 field will have.
315 Its component are defined as
316 .LP
317 .nf
318         <level> ::= none|auth|compare|search|read|write
319         <priv> ::= {=|+|-}{w|r|s|c|x}+
320 .fi
321 .LP
322 The modifier
323 .B self
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
326 the access.
327 It implies the user that requests access is bound.
328 An example is the
329 .B selfwrite
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.
332 .LP
333 The 
334 .B level 
335 access model relies on an incremental interpretation of the access
336 privileges.
337 The possible levels are
338 .BR none ,
339 .BR auth ,
340 .BR compare ,
341 .BR search ,
342 .BR read ,
343 and
344 .BR write .
345 Each access level implies all the preceding ones, thus 
346 .B write
347 access will imply all accesses.
348 While
349 .B none
350 is trivial, 
351 .B auth
352 access means that one is allowed access to an attribute to perform
353 authentication/authorization operations (e.g.
354 .BR bind )
355 with no other access.
356 This is useful to grant unauthenticated clients the least possible 
357 access level to critical resources, like passwords.
358 .LP
359 The
360 .B priv
361 access model relies on the explicit setting of access privileges
362 for each clause.
363 The
364 .B =
365 sign resets previously defined accesses; as a consequence, the final 
366 access privileges will be only those defined by the clause.
367 The 
368 .B +
369 and
370 .B -
371 signs add/remove access privileges to the existing ones.
372 The privileges are
373 .B w
374 for write,
375 .B r
376 for read,
377 .B s 
378 for search,
379 .B c 
380 for compare, and
381 .B x
382 for authentication.
383 More than one privilege can be added in one statement.
384 .LP
385 The optional field
386 .B <control>
387 controls the flow of access rule application.
388 It can have the forms
389 .LP
390 .nf
391         stop
392         continue
393         break
394 .fi
395 .LP
396 where
397 .BR stop ,
398 the default, means access checking stops in case of match.
399 The other two forms are used to keep on processing access clauses.
400 In detail, the
401 .B continue
402 form allows for other 
403 .B <who>
404 clauses in the same 
405 .B <access>
406 clause to be considered, so that they may result in incrementally altering
407 the privileges, while the
408 .B break
409 form allows for other
410 .B <access>
411 clauses that match the same target to be processed.
412 Consider the (silly) example
413 .LP
414 .nf
415         access to dn.subtree="dc=example,dc=com" attrs=cn
416                 by * =cs break
417
418         access to dn.subtree="ou=People,dc=example,dc=com"
419                 by * +r
420 .fi
421 .LP
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
426 .LP
427 .nf
428         access to dn.subtree="dc=example,dc=com" attrs=cn
429                 by * =cs continue
430                 by users +r
431 .fi
432 .LP
433 which grants everybody search and compare privileges, and adds read
434 privileges to authenticated clients.
435 .SH CAVEATS
436 It is strongly recommended to explicitly use the most appropriate
437 DN 
438 .BR style ,
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.
442 .LP
443 An adminisistrator might create a rule of the form:
444 .LP
445 .nf
446         access to dn.regex="dc=example,dc=com"
447                 by ...
448 .fi
449 .LP
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".
454 .LP
455 To match the desired subtree, the rule would be more precisely
456 written:
457 .LP
458 .nf
459         access to dn.regex="^(.+,)?dc=example,dc=com$$"
460                 by ...
461 .fi
462 .LP
463 For performance reasons, it would be better to use the subtree style.
464 .LP
465 .nf
466         access to dn.subtree="dc=example,dc=com"
467                 by ...
468 .fi
469 .LP
470 .SH FILES
471 .TP
472 ETCDIR/slapd.conf
473 default slapd configuration file
474 .SH SEE ALSO
475 .BR slapd (8),
476 .LP
477 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
478 .SH ACKNOWLEDGEMENTS
479 .B OpenLDAP
480 is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
481 .B OpenLDAP
482 is derived from University of Michigan LDAP 3.3 Release.