]> git.sur5r.net Git - openldap/blob - doc/man/man5/slapd.access.5
b23acb64c728b811b1c979aa213c17a20b2c92af
[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 contain
44 access information.
45 Backend-specific access control directives are used for those entries
46 that belong to the backend, according to their naming context.
47 In case no access control directives are defined for a backend, 
48 the appropriate directives from the global configuration section
49 are used.
50 .LP
51 Arguments that should be replaced by actual text are shown in brackets <>.
52 The structure of the access control directives is
53 .TP
54 .B access to <what> "[ by <who> <access> [ <control> ] ]+"
55 Grant access (specified by 
56 .BR <access> ) 
57 to a set of entries and/or attributes (specified by 
58 .BR <what> ) 
59 by one or more requestors (specified by 
60 .BR <who> ).
61 .LP
62 The field
63 .BR <what>
64 specifies the entity the access control directive applies to.
65 It can have the forms
66 .LP
67 .nf
68         *
69         [dn[.<dnstyle>]=<pattern>] 
70         [filter=<ldapfilter>]
71         [attrs=<attrlist>]
72 .fi
73 .LP
74 The wildcard
75 .B *
76 stands for all the entries.
77 .LP
78 The statement
79 .B dn=<pattern>
80 selects the entries based on their naming context.
81 The optional style qualificator
82 .B <dnstyle>
83 can be 
84 .BR regex ,
85 which implies a regular expression pattern, as detailed in
86 .BR regex (7),
87 will be used (the default),
88 .B base
89 or
90 .B exact 
91 (an alias of 
92 .BR base )
93 for an exact match of the entry,
94 .B one
95 to indicate all the entries immediately below the
96 .BR pattern ,
97 .B subtree
98 to indicate all the subentries of an entry including the entry itself,
99 .B children
100 to indicate all the subentries of an entry not including the entry itself.
101 Note that 
102 .B dn=".*"
103 is equivalent to
104 .BR * .
105 The regex form of the pattern does not support UTF-8 yet.
106 .LP
107 The statement
108 .B filter=<ldapfilter>
109 selects the entries based on a valid LDAP filter as described in RFC 2254.
110 .LP
111 The statement
112 .B attrs=<attrlist>
113 selects the attributes the access control rule applies to.
114 It is a comma-separated list of attribute types, plus the special names
115 .BR entry ,
116 indicating access to the entry itself, and
117 .BR children ,
118 indicating access to the entry's children. ObjectClass names may also
119 be specified in this list, which will affect all the attributes that
120 are required and/or allowed by that objectClass.
121 .LP
122 The last three statements are additive; they can be used in sequence 
123 to select entities the access rule applies to based on naming context,
124 value and attribute type simultaneously.
125 .LP
126 The field
127 .B <who>
128 indicates whom the access rules apply to.
129 Multiple 
130 .B <who>
131 statements can appear in an access control statement, indicating the
132 different access privileges to the same resource that apply to different
133 accessee.
134 It can have the forms
135 .LP
136 .nf
137         *
138         anonymous
139         users
140         self
141
142         dn[.<dnstyle>[,<modifier>]]=<pattern>
143         dnattr=<attrname>
144         group[/<objectclass>[/<attrname>]]
145                 [.<style>]=<pattern>
146         peername[.<style>]=<pattern>
147         sockname[.<style>]=<pattern>
148         domain[.<domainstyle>[,<modifier>]]=<pattern>
149         sockurl[.<style>]=<pattern>
150         set[.<style>]=<pattern>
151
152         ssf=<n>
153         transport_ssf=<n>
154         tls_ssf=<n>
155         sasl_ssf=<n>
156
157         aci=<attrname>
158 .fi
159 .LP
160 They may be specified in combination.
161 .LP
162 .nf
163 .fi
164 .LP
165 The wildcard
166 .B *
167 refers to everybody.
168 .LP
169 The keyword
170 .B anonymous
171 means access is granted to unauthenticated users; it is moslty used 
172 to limit access to authentication resources (e.g. the
173 .B userPassword
174 attribute) to unauthenticated users for authentication purposes.
175 .LP
176 The keyword
177 .B users
178 means access is granted to authenticated users.
179 .LP
180 The keyword
181 .B self
182 means access to an entry is allowed to the entry itself (e.g. the entry
183 being accessed and the requesting entry must be the same).
184 .LP
185 The statement
186 .B dn=<pattern>
187 means that access is granted to the matching dn.
188 The optional style qualificator
189 .B dnstyle
190 allows the same choices of the dn form of the
191 .B <what>
192 field.
193 In detail, the
194 .B regex
195 form of
196 .B pattern
197 can exploit substring substitution of submatches in the
198 .B <what>
199 dn by using the form
200 .BR $<digit> ,
201 with 
202 .B digit
203 ranging from 1 to 9.
204 .LP
205 The statement
206 .B dnattr=<attrname>
207 means that access is granted to requests whose dn is listed in the
208 entry being accessed under the 
209 .B attrname
210 attribute.
211 .LP
212 The statement
213 .B group=<pattern>
214 means that access is granted to requests whose dn is listed
215 in the group entry whose dn is given by
216 .BR pattern .
217 The optional parameters
218 .B objectclass
219 and
220 .B attrname
221 define the objectClass and the member attributeType of the group entry.
222 The optional style qualificator
223 .B style
224 can be
225 .BR regex ,
226 which means that
227 .B pattern
228 will be expanded accorging to regex (7), and
229 .B base
230 or
231 .B exact
232 (an alias of
233 .BR base ),
234 which means that an exact match will be used.
235 .LP
236 The statements
237 .BR peername=<pattern> ,
238 .BR sockname=<pattern> ,
239 .BR domain=<pattern> ,
240 and
241 .BR sockurl=<pattern>
242 mean that the contacting host IP for
243 .BR peername ,
244 the named pipe file name for
245 .BR sockname ,
246 the contacting host name for
247 .BR domain ,
248 and the contacting URL for
249 .BR sockurl
250 are compared against
251 .B pattern
252 to determine access.
253 The same
254 .B style
255 rules for pattern match described for the
256 .B group
257 case apply. 
258 The
259 .BR domain 
260 clause also allows the
261 .B subtree
262 style, which succeeds when a fully qualified name exactly matches the
263 .BR domain
264 pattern, or its trailing part, after a 
265 .BR dot ,
266 exactly matches the 
267 .BR domain
268 pattern.
269 The
270 .B domain
271 of the contacting host is determined by performing a DNS reverse lookup.
272 As this lookup can easily be spoofed, use of the
273 .B domain
274 statement is strongly discouraged.  By default, reverse lookups are disabled.
275 .LP
276 The statement
277 .B set=<pattern>
278 is undocumented yet.
279 .LP
280 The statement
281 .B aci=<attrname>
282 means that the access control is determined by the values in the
283 .B attrname
284 of the entry itself.
285 ACIs are experimental; they must be enabled at compile time.
286 .LP
287 The statements
288 .BR ssf=<n> ,
289 .BR transport_ssf=<n> ,
290 .BR tls_ssf=<n> ,
291 and
292 .BR sasl_ssf=<n>
293 set the required Security Strength Factor (ssf) required to grant access.
294 .LP
295 The field
296 .B <access> ::= [self]{<level>|<priv>}
297 determines the access level or the specific access privileges the
298 .B who 
299 field will have.
300 Its component are defined as
301 .LP
302 .nf
303         <level> ::= none|auth|compare|search|read|write
304         <priv> ::= {=|+|-}{w|r|s|c|x}+
305 .fi
306 .LP
307 The modifier
308 .B self
309 allows special operations like having a certain access level or privilege
310 only in case the operation involves the name of the user that's requesting
311 the access.
312 It implies the user that requests access is bound.
313 An example is the
314 .B selfwrite
315 access to the member attribute of a group, which allows one to add/delete
316 its own DN from the member list of a group, without affecting other members.
317 .LP
318 The 
319 .B level 
320 access model relies on an incremental interpretation of the access
321 privileges.
322 The possible levels are
323 .BR none ,
324 .BR auth ,
325 .BR compare ,
326 .BR search ,
327 .BR read ,
328 and
329 .BR write .
330 Each access level implies all the preceding ones, thus 
331 .B write
332 access will imply all accesses.
333 While
334 .B none
335 is trivial, 
336 .B auth
337 access means that one is allowed access to an attribute to perform
338 authentication/authorization operations (e.g.
339 .BR bind )
340 with no other access.
341 This is useful to grant unauthenticated users the least possible 
342 access level to critical resources, like passwords.
343 .LP
344 The
345 .B priv
346 access model relies on the explicit setting of access privileges
347 for each clause.
348 The
349 .B =
350 sign resets previously defined accesses; as a consequence, the final 
351 access privileges will be only those defined by the clause.
352 The 
353 .B +
354 and
355 .B -
356 signs add/remove access privileges to the existing ones.
357 The privileges are
358 .B w
359 for write,
360 .B r
361 for read,
362 .B s 
363 for search,
364 .B c 
365 for compare, and
366 .B x
367 for authentication.
368 More than one privilege can be added in one statement.
369 .LP
370 The optional field
371 .B <control>
372 controls the flow of access rule application.
373 It can have the forms
374 .LP
375 .nf
376         stop
377         continue
378         break
379 .fi
380 .LP
381 where
382 .BR stop ,
383 the default, means access checking stops in case of match.
384 The other two forms are used to keep on processing access clauses.
385 In detail, the
386 .B continue
387 form allows for other 
388 .B <who>
389 clauses in the same 
390 .B <access>
391 clause to be considered, so that they may result in incrementally altering
392 the privileges, while the
393 .B break
394 form allows for other
395 .B <access>
396 clauses that match the same target to be processed.
397 Consider the (silly) example
398 .LP
399 .nf
400         access to dn.subtree="dc=example,dc=com" attrs=cn
401                 by * =cs break
402
403         access to dn.subtree="ou=People,dc=example,dc=com"
404                 by * +r
405 .fi
406 .LP
407 which allows search and compare privileges to everybody under
408 the "dc=example,dc=com" tree, with the second rule allowing
409 also read in the "ou=People" subtree,
410 or the (even more silly) example
411 .LP
412 .nf
413         access to dn.subtree="dc=example,dc=com" attrs=cn
414                 by * =cs continue
415                 by users +r
416 .fi
417 .LP
418 which grants everybody search and compare privileges, and adds read
419 privileges to authenticated users.
420 .SH FILES
421 .TP
422 ETCDIR/slapd.conf
423 default slapd configuration file
424 .SH SEE ALSO
425 .BR slapd (8),
426 .LP
427 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
428 .SH ACKNOWLEDGEMENTS
429 .B OpenLDAP
430 is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
431 .B OpenLDAP
432 is derived from University of Michigan LDAP 3.3 Release.