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

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