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.
 119 .LP
 120 The last three statements are additive; they can be used in sequence
 121 to select entities the access rule applies to based on naming context,
 122 value and attribute type simultaneously.
 123 .LP
 124 The field
 125 .B <who>
 126 indicates whom the access rules apply to.
 127 Multiple
 128 .B <who>
 129 statements can appear in an access control statement, indicating the
 130 different access privileges to the same resource that apply to different
 131 accessee.
 132 It can have the forms
 133 .LP
 134 .nf
 135         *
 136         anonymous
 137         users
 138         self
 139
 140         dn[.<dnstyle>]=<pattern>
 141         dnattr=<attrname>
 142         group[/<objectclass>[/<attrname>]]
 143                 [.<style>]=<pattern>
 144         peername[.<style>]=<pattern>
 145         sockname[.<style>]=<pattern>
 146         domain[.<style>]=<pattern>
 147         sockurl[.<style>]=<pattern>
 148         set[.<style>]=<pattern>
 149
 150         ssf=<n>
 151         transport_ssf=<n>
 152         tls_ssf=<n>
 153         sasl_ssf=<n>
 154
 155         aci=<attrname>
 156 .fi
 157 .LP
 158 They may be specified in combination.
 159 .LP
 160 .nf
 161 .fi
 162 .LP
 163 The wildcard
 164 .B *
 165 refers to everybody.
 166 .LP
 167 The keyword
 168 .B anonymous
 169 means access is granted to unauthenticated users; it is moslty used
 170 to limit access to authentication resources (e.g. the
 171 .B userPassword
 172 attribute) to unauthenticated users for authentication purposes.
 173 .LP
 174 The keyword
 175 .B users
 176 means access is granted to authenticated users.
 177 .LP
 178 The keyword
 179 .B self
 180 means access to an entry is allowed to the entry itself (e.g. the entry
 181 being accessed and the requesting entry must be the same).
 182 .LP
 183 The statement
 184 .B dn=<pattern>
 185 means that access is granted to the matching dn.
 186 The optional style qualificator
 187 .B dnstyle
 188 allows the same choices of the dn form of the
 189 .B <what>
 190 field.
 191 In detail, the
 192 .B regex
 193 form of
 194 .B pattern
 195 can exploit substring substitution of submatches in the
 196 .B <what>
 197 dn by using the form
 198 .BR $<digit> ,
 199 with
 200 .B digit
 201 ranging from 1 to 9.
 202 .LP
 203 The statement
 204 .B dnattr=<attrname>
 205 means that access is granted to requests whose dn is listed in the
 206 entry being accessed under the
 207 .B attrname
 208 attribute.
 209 .LP
 210 The statement
 211 .B group=<pattern>
 212 means that access is granted to requests whose dn is listed
 213 in the group entry whose dn is given by
 214 .BR pattern .
 215 The optional parameters
 216 .B objectclass
 217 and
 218 .B attrname
 219 define the objectClass and the member attributeType of the group entry.
 220 The optional style qualificator
 221 .B style
 222 can be
 223 .BR regex ,
 224 which means that
 225 .B pattern
 226 will be expanded accorging to regex (7), and
 227 .B base
 228 or
 229 .B exact
 230 (an alias of
 231 .BR base ),
 232 which means that an exact match will be used.
 233 .LP
 234 The statements
 235 .BR peername=<pattern> ,
 236 .BR sockname=<pattern> ,
 237 .BR domain=<pattern> ,
 238 and
 239 .BR sockurl=<pattern>
 240 mean that the contacting host IP for
 241 .BR peername ,
 242 the named pipe file name for
 243 .BR sockname ,
 244 the contacting host name for
 245 .BR domain ,
 246 and the contacting URL for
 247 .BR sockurl
 248 are compared against
 249 .B pattern
 250 to determine access.
 251 The same
 252 .B style
 253 rules for pattern match described for the
 254 .B group
 255 case apply.
 256 .LP
 257 The statement
 258 .B set=<pattern>
 259 is undocumented yet.
 260 .LP
 261 The statement
 262 .B aci=<attrname>
 263 means that the access control is determined by the values in the
 264 .B attrname
 265 of the entry itself.
 266 ACIs are experimental; they must be enabled at compile time.
 267 .LP
 268 The statements
 269 .BR ssf=<n> ,
 270 .BR transport_ssf=<n> ,
 271 .BR tls_ssf=<n> ,
 272 and
 273 .BR sasl_ssf=<n>
 274 set the required Security Strength Factor (ssf) required to grant access.
 275 .LP
 276 The field
 277 .B <access> ::= [self]{<level>|<priv>}
 278 determines the access level or the specific access privileges the
 279 .B who
 280 field will have.
 281 Its component are defined as
 282 .LP
 283 .nf
 284         <level> ::= none|auth|compare|search|read|write
 285         <priv> ::= {=|+|-}{w|r|s|c|x}+
 286 .fi
 287 .LP
 288 The modifier
 289 .B self
 290 allows special operations like having a certain access level or privilege
 291 only in case the operation involves the name of the user that's requesting
 292 the access.
 293 It implies the user that requests access is bound.
 294 An example is the
 295 .B selfwrite
 296 access to the member attribute of a group, which allows one to add/delete
 297 its own DN from the member list of a group, without affecting other members.
 298 .LP
 299 The
 300 .B level
 301 access model relies on an incremental interpretation of the access
 302 privileges.
 303 The possible levels are
 304 .BR none ,
 305 .BR auth ,
 306 .BR compare ,
 307 .BR search ,
 308 .BR read ,
 309 and
 310 .BR write .
 311 Each access level implies all the preceding ones, thus
 312 .B write
 313 access will imply all accesses.
 314 While
 315 .B none
 316 is trivial,
 317 .B auth
 318 access means that one is allowed access to an attribute to perform
 319 authentication/authorization operations (e.g.
 320 .BR bind )
 321 with no other access.
 322 This is useful to grant unauthenticated users the least possible
 323 access level to critical resources, like passwords.
 324 .LP
 325 The
 326 .B priv
 327 access model relies on the explicit setting of access privileges
 328 for each clause.
 329 The
 330 .B =
 331 sign resets previously defined accesses; as a consequence, the final
 332 access privileges will be only those defined by the clause.
 333 The
 334 .B +
 335 and
 336 .B -
 337 signs add/remove access privileges to the existing ones.
 338 The privileges are
 339 .B w
 340 for write,
 341 .B r
 342 for read,
 343 .B s
 344 for search,
 345 .B c
 346 for compare, and
 347 .B x
 348 for authentication.
 349 More than one privilege can be added in one statement.
 350 .LP
 351 The optional field
 352 .B <control>
 353 controls the flow of access rule application.
 354 It can have the forms
 355 .LP
 356 .nf
 357         stop
 358         continue
 359         break
 360 .fi
 361 .LP
 362 where
 363 .BR stop ,
 364 the default, means access checking stops in case of match.
 365 The other two forms are used to keep on processing access clauses.
 366 In detail, the
 367 .B continue
 368 form allows for other
 369 .B <who>
 370 clauses in the same
 371 .B <access>
 372 clause to be considered, so that they may result in incrementally altering
 373 the privileges, while the
 374 .B break
 375 form allows for other
 376 .B <access>
 377 clauses that match the same target to be processed.
 378 Consider the (silly) example
 379 .LP
 380 .nf
 381         access to dn.subtree="dc=example,dc=com" attrs=cn
 382                 by * =cs break
 383
 384         access to dn.subtree="ou=People,dc=example,dc=com"
 385                 by * +r
 386 .fi
 387 .LP
 388 which allows search and compare privileges to everybody under
 389 the "dc=example,dc=com" tree, with the seconf rule allowing
 390 also read in the "ou=People" subtree,
 391 or the (even more silly) example
 392 .LP
 393 .nf
 394         access to dn.subtree="dc=example,dc=com" attrs=cn
 395                 by * =cs continue
 396                 by users +r
 397 .fi
 398 .LP
 399 which grants everybody search and compare privileges, and adds read
 400 privileges to authenticated users.
 401 .SH FILES
 402 ETCDIR/slapd.conf
 403 .SH SEE ALSO
 404 .BR slapd (8),
 405 .LP
 406 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
 407 .SH ACKNOWLEDGEMENTS
 408 .B OpenLDAP
 409 is developed and maintained by The OpenLDAP Project (http://www.openldap.org/).
 410 .B OpenLDAP
 411 is derived from University of Michigan LDAP 3.3 Release.