git.sur5r.net Git - openldap/blob - doc/man/man5/slapd.access.5

   1 .TH SLAPD.ACCESS 5 "30 April 2002" "OpenLDAP LDVERSION"
   2 .\" Copyright 1998-2002 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 sub
  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 (7) 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 .LP
 270 The statement
 271 .B set=<pattern>
 272 is undocumented yet.
 273 .LP
 274 The statement
 275 .B aci=<attrname>
 276 means that the access control is determined by the values in the
 277 .B attrname
 278 of the entry itself.
 279 ACIs are experimental; they must be enabled at compile time.
 280 .LP
 281 The statements
 282 .BR ssf=<n> ,
 283 .BR transport_ssf=<n> ,
 284 .BR tls_ssf=<n> ,
 285 and
 286 .BR sasl_ssf=<n>
 287 set the required Security Strength Factor (ssf) required to grant access.
 288 .LP
 289 The field
 290 .B <access> ::= [self]{<level>|<priv>}
 291 determines the access level or the specific access privileges the
 292 .B who
 293 field will have.
 294 Its component are defined as
 295 .LP
 296 .nf
 297         <level> ::= none|auth|compare|search|read|write
 298         <priv> ::= {=|+|-}{w|r|s|c|x}+
 299 .fi
 300 .LP
 301 The modifier
 302 .B self
 303 allows special operations like having a certain access level or privilege
 304 only in case the operation involves the name of the user that's requesting
 305 the access.
 306 It implies the user that requests access is bound.
 307 An example is the
 308 .B selfwrite
 309 access to the member attribute of a group, which allows one to add/delete
 310 its own DN from the member list of a group, without affecting other members.
 311 .LP
 312 The
 313 .B level
 314 access model relies on an incremental interpretation of the access
 315 privileges.
 316 The possible levels are
 317 .BR none ,
 318 .BR auth ,
 319 .BR compare ,
 320 .BR search ,
 321 .BR read ,
 322 and
 323 .BR write .
 324 Each access level implies all the preceding ones, thus
 325 .B write
 326 access will imply all accesses.
 327 While
 328 .B none
 329 is trivial,
 330 .B auth
 331 access means that one is allowed access to an attribute to perform
 332 authentication/authorization operations (e.g.
 333 .BR bind )
 334 with no other access.
 335 This is useful to grant unauthenticated users the least possible
 336 access level to critical resources, like passwords.
 337 .LP
 338 The
 339 .B priv
 340 access model relies on the explicit setting of access privileges
 341 for each clause.
 342 The
 343 .B =
 344 sign resets previously defined accesses; as a consequence, the final
 345 access privileges will be only those defined by the clause.
 346 The
 347 .B +
 348 and
 349 .B -
 350 signs add/remove access privileges to the existing ones.
 351 The privileges are
 352 .B w
 353 for write,
 354 .B r
 355 for read,
 356 .B s
 357 for search,
 358 .B c
 359 for compare, and
 360 .B x
 361 for authentication.
 362 More than one privilege can be added in one statement.
 363 .LP
 364 The optional field
 365 .B <control>
 366 controls the flow of access rule application.
 367 It can have the forms
 368 .LP
 369 .nf
 370         stop
 371         continue
 372         break
 373 .fi
 374 .LP
 375 where
 376 .BR stop ,
 377 the default, means access checking stops in case of match.
 378 The other two forms are used to keep on processing access clauses.
 379 In detail, the
 380 .B continue
 381 form allows for other
 382 .B <who>
 383 clauses in the same
 384 .B <access>
 385 clause to be considered, so that they may result in incrementally altering
 386 the privileges, while the
 387 .B break
 388 form allows for other
 389 .B <access>
 390 clauses that match the same target to be processed.
 391 Consider the (silly) example
 392 .LP
 393 .nf
 394         access to dn.subtree="dc=example,dc=com" attrs=cn
 395                 by * =cs break
 396
 397         access to dn.subtree="ou=People,dc=example,dc=com"
 398                 by * +r
 399 .fi
 400 .LP
 401 which allows search and compare privileges to everybody under
 402 the "dc=example,dc=com" tree, with the second rule allowing
 403 also read in the "ou=People" subtree,
 404 or the (even more silly) example
 405 .LP
 406 .nf
 407         access to dn.subtree="dc=example,dc=com" attrs=cn
 408                 by * =cs continue
 409                 by users +r
 410 .fi
 411 .LP
 412 which grants everybody search and compare privileges, and adds read
 413 privileges to authenticated users.
 414 .SH FILES
 415 .TP
 416 ETCDIR/slapd.conf
 417 default slapd configuration file
 418 .SH SEE ALSO
 419 .BR slapd (8),
 420 .LP
 421 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
 422 .SH ACKNOWLEDGEMENTS
 423 .B OpenLDAP
 424 is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
 425 .B OpenLDAP
 426 is derived from University of Michigan LDAP 3.3 Release.