1SLAPD.ACCESS(5) File Formats Manual SLAPD.ACCESS(5)
2
6 slapd.access - access configuration for slapd, the stand-alone LDAP
7 daemon
8
10 /etc/openldap/slapd.conf
11
13 The slapd.conf(5) file contains configuration information for the
14 slapd(8) daemon. This configuration file is also used by the SLAPD
15 tools slapacl(8), slapadd(8), slapauth(8), slapcat(8), slapdn(8),
16 slapindex(8), slapmodify(8), and slaptest(8).
17 The slapd.conf file consists of a series of global configuration op‐
19 tions that apply to slapd as a whole (including all backends), followed
20 by zero or more database backend definitions that contain information
21 specific to a backend instance.
22 The general format of slapd.conf is as follows:
24 # comment - these options apply to every database
26 <global configuration options>
27 # first database definition & configuration options
28 database <backend 1 type>
29 <configuration options specific to backend 1>
30 # subsequent database definitions & configuration options
31 ...
32 Both the global configuration and each backend-specific section can
34 contain access information. Backend-specific access control directives
35 are used for those entries that belong to the backend, according to
36 their naming context. In case no access control directives are defined
37 for a backend or those which are defined are not applicable, the direc‐
38 tives from the global configuration section are then used.
39 If no access controls are present, the default policy allows anyone and
41 everyone to read anything but restricts updates to rootdn. (e.g., "ac‐
42 cess to * by * read").
43 When dealing with an access list, because the global access list is ef‐
45 fectively appended to each per-database list, if the resulting list is
46 non-empty then the access list will end with an implicit access to * by
47 * none directive. If there are no access directives applicable to a
48 backend, then a default read is used.
49 Be warned: the rootdn can always read and write EVERYTHING!
51 For entries not held in any backend (such as a root DSE), the global
53 directives are used.
54 Arguments that should be replaced by actual text are shown in brackets
56 <>.
57
59 The structure of the access control directives is
60 access to <what> [ by <who> [ <access> ] [ <control> ] ]+
62 Grant access (specified by <access>) to a set of entries and/or
63 attributes (specified by <what>) by one or more requestors
64 (specified by <who>).
65 Lists of access directives are evaluated in the order they appear in
68 slapd.conf. When a <what> clause matches the datum whose access is be‐
69 ing evaluated, its <who> clause list is checked. When a <who> clause
70 matches the accessor's properties, its <access> and <control> clauses
71 are evaluated.
72 Access control checking stops at the first match of the <what> and
75 <who> clause, unless otherwise dictated by the <control> clause. Each
76 <who> clause list is implicitly terminated by a
77 by * none stop
79 <control> clause. This implicit <control> stops access directive eval‐
81 uation with no more access privileges granted to anyone else. To stop
82 access directive evaluation only when both <who> and <what> match, add
83 an explicit
84 by * break
86 to the end of the <who> clause list.
88 Each <what> clause list is implicitly terminated by a
91 access to *
93 by * none
94 clause that results in granting no access privileges to an otherwise
96 unspecified datum.
97
99 The field <what> specifies the entity the access control directive ap‐
100 plies to. It can have the forms
101 dn[.<dnstyle>]=<dnpattern>
103 filter=<ldapfilter>
104 attrs=<attrlist>[ val[/matchingRule][.<attrstyle>]=<attrval>]
105 with
107 <dnstyle>={{exact|base(object)}|regex
109 |one(level)|sub(tree)|children}
110 <attrlist>={<attr>|[{!|@}]<objectClass>}[,<attrlist>]
111 <attrstyle>={{exact|base(object)}|regex
112 |one(level)|sub(tree)|children}
113 The statement dn=<dnpattern> selects the entries based on their naming
115 context. The <dnpattern> is a string representation of the entry's DN.
116 The wildcard * stands for all the entries, and it is implied if no dn
117 form is given.
118 The <dnstyle> is optional; however, it is recommended to specify it to
120 avoid ambiguities. Base (synonym of baseObject), the default, or exact
121 (an alias of base) indicates the entry whose DN is equal to the <dnpat‐
122 tern>; one (synonym of onelevel) indicates all the entries immediately
123 below the <dnpattern>, sub (synonym of subtree) indicates all entries
124 in the subtree at the <dnpattern>, children indicates all the entries
125 below (subordinate to) the <dnpattern>.
126 If the <dnstyle> qualifier is regex, then <dnpattern> is a POSIX (''ex‐
128 tended'') regular expression pattern, as detailed in regex(7) and/or
129 re_format(7), matching a normalized string representation of the en‐
130 try's DN. The regex form of the pattern does not (yet) support UTF-8.
131 The statement filter=<ldapfilter> selects the entries based on a valid
133 LDAP filter as described in RFC 4515. A filter of (objectClass=*) is
134 implied if no filter form is given.
135 The statement attrs=<attrlist> selects the attributes the access con‐
137 trol rule applies to. It is a comma-separated list of attribute types,
138 plus the special names entry, indicating access to the entry itself,
139 and children, indicating access to the entry's children. ObjectClass
140 names may also be specified in this list, which will affect all the at‐
141 tributes that are required and/or allowed by that objectClass. Actu‐
142 ally, names in <attrlist> that are prefixed by @ are directly treated
143 as objectClass names. A name prefixed by ! is also treated as an ob‐
144 jectClass, but in this case the access rule affects the attributes that
145 are not required nor allowed by that objectClass. If no attrs form is
146 given, attrs=@extensibleObject is implied, i.e. all attributes are ad‐
147 dressed.
148 Using the form attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval>
150 specifies access to a particular value of a single attribute. In this
151 case, only a single attribute type may be given. The <attrstyle> exact
152 (the default) uses the attribute's equality matching rule to compare
153 the value, unless a different (and compatible) matching rule is speci‐
154 fied. If the <attrstyle> is regex, the provided value is used as a
155 POSIX (''extended'') regular expression pattern. If the attribute has
156 DN syntax, the <attrstyle> can be any of base, onelevel, subtree or
157 children, resulting in base, onelevel, subtree or children match, re‐
158 spectively.
159 The dn, filter, and attrs statements are additive; they can be used in
161 sequence to select entities the access rule applies to based on naming
162 context, value and attribute type simultaneously. Submatches resulting
163 from regex matching can be dereferenced in the <who> field using the
164 syntax ${v<n>}, where <n> is the submatch number. The default syntax,
165 $<n>, is actually an alias for ${d<n>}, that corresponds to dereferenc‐
166 ing submatches from the dnpattern portion of the <what> field.
167
169 The field <who> indicates whom the access rules apply to. Multiple
170 <who> statements can appear in an access control statement, indicating
171 the different access privileges to the same resource that apply to dif‐
172 ferent accessee. It can have the forms
173 *
175 anonymous
176 users
177 self[.<selfstyle>]
178 dn[.<dnstyle>[,<modifier>]]=<DN>
180 dnattr=<attrname>
181 realanonymous
183 realusers
184 realself[.<selfstyle>]
185 realdn[.<dnstyle>[,<modifier>]]=<DN>
187 realdnattr=<attrname>
188 group[/<objectclass>[/<attrname>]]
190 [.<groupstyle>]=<group>
191 peername[.<peernamestyle>]=<peername>
192 sockname[.<style>]=<sockname>
193 domain[.<domainstyle>[,<modifier>]]=<domain>
194 sockurl[.<style>]=<sockurl>
195 set[.<setstyle>]=<pattern>
196 ssf=<n>
198 transport_ssf=<n>
199 tls_ssf=<n>
200 sasl_ssf=<n>
201 dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
203 with
205 <style>={exact|regex|expand}
207 <selfstyle>={level{<n>}}
208 <dnstyle>={{exact|base(object)}|regex
209 |one(level)|sub(tree)|children|level{<n>}}
210 <groupstyle>={exact|expand}
211 <peernamestyle>={<style>|ip|ipv6|path}
212 <domainstyle>={exact|regex|sub(tree)}
213 <setstyle>={exact|expand}
214 <modifier>={expand}
215 <name>=aci <pattern>=<attrname>]
216 They may be specified in combination.
218 The wildcard * refers to everybody.
220 The keywords prefixed by real act as their counterparts without prefix;
222 the checking respectively occurs with the authentication DN and the au‐
223 thorization DN.
224 The keyword anonymous means access is granted to unauthenticated
226 clients; it is mostly used to limit access to authentication resources
227 (e.g. the userPassword attribute) to unauthenticated clients for au‐
228 thentication purposes.
229 The keyword users means access is granted to authenticated clients.
231 The keyword self means access to an entry is allowed to the entry it‐
233 self (e.g. the entry being accessed and the requesting entry must be
234 the same). It allows the level{<n>} style, where <n> indicates what
235 ancestor of the DN is to be used in matches. A positive value indi‐
236 cates that the <n>-th ancestor of the user's DN is to be considered; a
237 negative value indicates that the <n>-th ancestor of the target is to
238 be considered. For example, a "by self.level{1} ..." clause would
239 match when the object "dc=example,dc=com" is accessed by
240 "cn=User,dc=example,dc=com". A "by self.level{-1} ..." clause would
241 match when the same user accesses the object "ou=Address
242 Book,cn=User,dc=example,dc=com".
243 The statement dn=<DN> means that access is granted to the matching DN.
245 The optional style qualifier dnstyle allows the same choices of the dn
246 form of the <what> field. In addition, the regex style can exploit
247 substring substitution of submatches in the <what> dn.regex clause by
248 using the form $<digit>, with digit ranging from 0 to 9 (where 0
249 matches the entire string), or the form ${<digit>+}, for submatches
250 higher than 9. Substring substitution from attribute value can be done
251 in using the form ${v<digit>+}. Since the dollar character is used to
252 indicate a substring replacement, the dollar character that is used to
253 indicate match up to the end of the string must be escaped by a second
254 dollar character, e.g.
255 access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$"
257 by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write
258 The style qualifier allows an optional modifier. At present, the only
260 type allowed is expand, which causes substring substitution of sub‐
261 matches to take place even if dnstyle is not regex. Note that the
262 regex dnstyle in the above example may be of use only if the <by>
263 clause needs to be a regex; otherwise, if the value of the second (from
264 the right) dc= portion of the DN in the above example were fixed, the
265 form
266 access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
268 by dn.exact,expand="uid=$2,dc=example,dc=com" write
269 could be used; if it had to match the value in the <what> clause, the
271 form
272 access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$"
274 by dn.exact,expand="uid=$2,dc=$3,dc=com" write
275 could be used.
277 Forms of the <what> clause other than regex may provide submatches as
279 well. The base(object), the sub(tree), the one(level), and the chil‐
280 dren forms provide $0 as the match of the entire string. The
281 sub(tree), the one(level), and the children forms also provide $1 as
282 the match of the rightmost part of the DN as defined in the <what>
283 clause. This may be useful, for instance, to provide access to all the
284 ancestors of a user by defining
285 access to dn.subtree="dc=com"
287 by dn.subtree,expand="$1" read
288 which means that only access to entries that appear in the DN of the
290 <by> clause is allowed.
291 The level{<n>} form is an extension and a generalization of the
293 onelevel form, which matches all DNs whose <n>-th ancestor is the pat‐
294 tern. So, level{1} is equivalent to onelevel, and level{0} is equiva‐
295 lent to base.
296 It is perfectly useless to give any access privileges to a DN that ex‐
298 actly matches the rootdn of the database the ACLs apply to, because it
299 implicitly possesses write privileges for the entire tree of that data‐
300 base. Actually, access control is bypassed for the rootdn, to solve
301 the intrinsic chicken-and-egg problem.
302 The statement dnattr=<attrname> means that access is granted to re‐
304 quests whose DN is listed in the entry being accessed under the <attr‐
305 name> attribute.
306 The statement group=<group> means that access is granted to requests
308 whose DN is listed in the group entry whose DN is given by <group>.
309 The optional parameters <objectclass> and <attrname> define the object‐
310 Class and the member attributeType of the group entry. The defaults
311 are groupOfNames and member, respectively. The optional style quali‐
312 fier <style> can be expand, which means that <group> will be expanded
313 as a replacement string (but not as a regular expression) according to
314 regex(7) and/or re_format(7), and exact, which means that exact match
315 will be used. If the style of the DN portion of the <what> clause is
316 regex, the submatches are made available according to regex(7) and/or
317 re_format(7); other styles provide limited submatches as discussed
318 above about the DN form of the <by> clause.
319 For static groups, the specified attributeType must have Distinguished‐
321 Name or NameAndOptionalUID syntax. For dynamic groups the attributeType
322 must be a subtype of the labeledURI attributeType. Only LDAP URIs of
323 the form ldap:///<base>??<scope>?<filter> will be evaluated in a dy‐
324 namic group, by searching the local server only.
325 The statements peername=<peername>, sockname=<sockname>, domain=<do‐
327 main>, and sockurl=<sockurl> mean that the contacting host IP (in the
328 form IP=<ip>:<port> for IPv4, or IP=[<ipv6>]:<port> for IPv6) or the
329 contacting host named pipe file name (in the form PATH=<path> if con‐
330 necting through a named pipe) for peername, the named pipe file name
331 for sockname, the contacting host name for domain, and the contacting
332 URL for sockurl are compared against pattern to determine access. The
333 same style rules for pattern match described for the group case apply,
334 plus the regex style, which implies submatch expand and regex match of
335 the corresponding connection parameters. The exact style of the <peer‐
336 name> clause (the default) implies a case-exact match on the client's
337 IP, including the IP= prefix and the trailing :<port>, or the client's
338 path, including the PATH= prefix if connecting through a named pipe.
339 The special ip style interprets the pattern as <peer‐
340 name>=<ip>[%<mask>][{<n>}], where <ip> and <mask> are dotted digit rep‐
341 resentations of the IP and the mask, while <n>, delimited by curly
342 brackets, is an optional port. The same applies to IPv6 addresses when
343 the special ipv6 style is used. When checking access privileges, the
344 IP portion of the peername is extracted, eliminating the IP= prefix and
345 the :<port> part, and it is compared against the <ip> portion of the
346 pattern after masking with <mask>: ((peername & <mask>) == <ip>). As
347 an example, peername.ip=127.0.0.1 and peername.ipv6=::1 allow connec‐
348 tions only from localhost, peername.ip=192.168.1.0%255.255.255.0 allows
349 connections from any IP in the 192.168.1 class C domain, and peer‐
350 name.ip=192.168.1.16%255.255.255.240{9009} allows connections from any
351 IP in the 192.168.1.[16-31] range of the same domain, only if port 9009
352 is used. The special path style eliminates the PATH= prefix from the
353 peername when connecting through a named pipe, and performs an exact
354 match on the given pattern. The <domain> clause also allows the sub‐
355 tree style, which succeeds when a fully qualified name exactly matches
356 the domain pattern, or its trailing part, after a dot, exactly matches
357 the domain pattern. The expand style is allowed, implying an exact
358 match with submatch expansion; the use of expand as a style modifier is
359 considered more appropriate. As an example, domain.subtree=example.com
360 will match www.example.com, but will not match www.anotherexample.com.
361 The domain of the contacting host is determined by performing a DNS re‐
362 verse lookup. As this lookup can easily be spoofed, use of the domain
363 statement is strongly discouraged. By default, reverse lookups are
364 disabled. The optional domainstyle qualifier of the <domain> clause
365 allows a modifier option; the only value currently supported is expand,
366 which causes substring substitution of submatches to take place even if
367 the domainstyle is not regex, much like the analogous usage in <dn>
368 clause.
369 The statement set=<pattern> is undocumented yet.
371 The statement dynacl/<name>[/<options>][.<dynstyle>][=<pattern>] means
373 that access checking is delegated to the admin-defined method indicated
374 by <name>, which can be registered at run-time by means of the mod‐
375 uleload statement. The fields <options>, <dynstyle> and <pattern> are
376 optional, and are directly passed to the registered parsing routine.
377 Dynacl is experimental; it must be enabled at compile time.
378 The statement dynacl/aci[=<attrname>] means that the access control is
380 determined by the values in the attrname of the entry itself. The op‐
381 tional <attrname> indicates what attributeType holds the ACI informa‐
382 tion in the entry. By default, the OpenLDAPaci operational attribute
383 is used. ACIs are experimental; they must be enabled at compile time.
384 The statements ssf=<n>, transport_ssf=<n>, tls_ssf=<n>, and
386 sasl_ssf=<n> set the minimum required Security Strength Factor (ssf)
387 needed to grant access. The value should be positive integer.
388
390 The optional field <access> ::= [[real]self]{<level>|<priv>} determines
391 the access level or the specific access privileges the who field will
392 have. Its component are defined as
393 <level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage
395 <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
396 The modifier self allows special operations like having a certain ac‐
398 cess level or privilege only in case the operation involves the name of
399 the user that's requesting the access. It implies the user that re‐
400 quests access is authorized. The modifier realself refers to the au‐
401 thenticated DN as opposed to the authorized DN of the self modifier.
402 An example is the selfwrite access to the member attribute of a group,
403 which allows one to add/delete its own DN from the member list of a
404 group, while being not allowed to affect other members.
405 The level access model relies on an incremental interpretation of the
407 access privileges. The possible levels are none, disclose, auth, com‐
408 pare, search, read, write, and manage. Each access level implies all
409 the preceding ones, thus manage grants all access including administra‐
410 tive access. This access allows some modifications which would other‐
411 wise be prohibited by the LDAP data model or the directory schema, e.g.
412 changing the structural objectclass of an entry, or modifying an opera‐
413 tional attribute that is defined as not user modifiable. The write ac‐
414 cess is actually the combination of add and delete, which respectively
415 restrict the write privilege to add or delete the specified <what>.
416 The none access level disallows all access including disclosure on er‐
419 ror.
420 The disclose access level allows disclosure of information on error.
422 The auth access level means that one is allowed access to an attribute
424 to perform authentication/authorization operations (e.g. bind) with no
425 other access. This is useful to grant unauthenticated clients the
426 least possible access level to critical resources, like passwords.
427 The priv access model relies on the explicit setting of access privi‐
429 leges for each clause. The = sign resets previously defined accesses;
430 as a consequence, the final access privileges will be only those de‐
431 fined by the clause. The + and - signs add/remove access privileges to
432 the existing ones. The privileges are m for manage, w for write, a for
433 add, z for delete, r for read, s for search, c for compare, x for au‐
434 thentication, and d for disclose. More than one of the above privi‐
435 leges can be added in one statement. 0 indicates no privileges and is
436 used only by itself (e.g., +0). Note that +az is equivalent to +w.
437 If no access is given, it defaults to +0.
439
441 The optional field <control> controls the flow of access rule applica‐
442 tion. It can have the forms
443 stop
445 continue
446 break
447 where stop, the default, means access checking stops in case of match.
449 The other two forms are used to keep on processing access clauses. In
450 detail, the continue form allows for other <who> clauses in the same
451 <access> clause to be considered, so that they may result in incremen‐
452 tally altering the privileges, while the break form allows for other
453 <access> clauses that match the same target to be processed. Consider
454 the (silly) example
455 access to dn.subtree="dc=example,dc=com" attrs=cn
457 by * =cs break
458 access to dn.subtree="ou=People,dc=example,dc=com"
460 by * +r
461 which allows search and compare privileges to everybody under the
463 "dc=example,dc=com" tree, with the second rule allowing also read in
464 the "ou=People" subtree, or the (even more silly) example
465 access to dn.subtree="dc=example,dc=com" attrs=cn
467 by * =cs continue
468 by users +r
469 which grants everybody search and compare privileges, and adds read
471 privileges to authenticated clients.
472 One useful application is to easily grant write privileges to an updat‐
474 edn that is different from the rootdn. In this case, since the updat‐
475 edn needs write access to (almost) all data, one can use
476 access to *
478 by dn.exact="cn=The Update DN,dc=example,dc=com" write
479 by * break
480 as the first access rule. As a consequence, unless the operation is
482 performed with the updatedn identity, control is passed straight to the
483 subsequent rules.
484
487 Operations require different privileges on different portions of en‐
488 tries. The following summary applies to primary MDB database backend.
489 Requirements for other backends may (and often do) differ.
490 The add operation requires add (=a) privileges on the pseudo-attribute
493 entry of the entry being added, and add (=a) privileges on the pseudo-
494 attribute children of the entry's parent. When adding the suffix entry
495 of a database, add access to children of the empty DN ("") is required.
496 Also if Add content ACL checking has been configured on the database
497 (see the slapd.conf(5) or slapd-config(5) manual page), add (=a) will
498 be required on all of the attributes being added.
499 The bind operation, when credentials are stored in the directory, re‐
502 quires auth (=x) privileges on the attribute the credentials are stored
503 in (usually userPassword).
504 The compare operation requires compare (=c) privileges on the attribute
507 that is being compared.
508 The delete operation requires delete (=z) privileges on the pseudo-at‐
511 tribute entry of the entry being deleted, and delete (=d) privileges on
512 the children pseudo-attribute of the entry's parent.
513 The modify operation requires write (=w) privileges on the attributes
516 being modified. In detail, add (=a) is required to add new values,
517 delete (=z) is required to delete existing values, and both delete and
518 add (=az), or write (=w), are required to replace existing values.
519 The modrdn operation requires write (=w) privileges on the pseudo-at‐
522 tribute entry of the entry whose relative DN is being modified, delete
523 (=z) privileges on the pseudo-attribute children of the old entry's
524 parents, add (=a) privileges on the pseudo-attribute children of the
525 new entry's parents, and add (=a) privileges on the attributes that are
526 present in the new relative DN. Delete (=z) privileges are also re‐
527 quired on the attributes that are present in the old relative DN if
528 deleteoldrdn is set to 1.
529 The search operation, requires search (=s) privileges on the entry
532 pseudo-attribute of the searchBase (NOTE: this was introduced with
533 OpenLDAP 2.4). Then, for each entry, it requires search (=s) privi‐
534 leges on the attributes that are defined in the filter. The resulting
535 entries are finally tested for read (=r) privileges on the pseudo-at‐
536 tribute entry (for read access to the entry itself) and for read (=r)
537 access on each value of each attribute that is requested. Also, for
538 each referral object used in generating continuation references, the
539 operation requires read (=r) access on the pseudo-attribute entry (for
540 read access to the referral object itself), as well as read (=r) access
541 to the attribute holding the referral information (generally the ref
542 attribute).
543 Some internal operations and some controls require specific access
546 privileges.
547 The SASL authzID mapping and the LDAP proxyAuthz control require auth
550 (=x) privileges on all the attributes that are present in the search
551 filter of the URI regexp maps (the right-hand side of the authz-regexp
552 directives). Auth (=x) privileges are also required on the authzTo at‐
553 tribute of the authorizing identity and/or on the authzFrom attribute
554 of the authorized identity. In both cases, it is the authorizing iden‐
555 tity that requires the privileges (i.e. the identity that has authenti‐
556 cated and is now trying to do some operation using another entity's
557 permissions).
558 In general, when an internal lookup is performed for authentication or
561 authorization purposes, search-specific privileges (see the access re‐
562 quirements for the search operation illustrated above) are relaxed to
563 auth.
564 Access control to search entries is checked by the frontend, so it is
567 fully honored by all backends; for all other operations and for the
568 discovery phase of the search operation, full ACL semantics is only
569 supported by the primary backends, i.e. slapd-mdb(5).
570 Some other backend, like slapd-sql(5), may fully support them; others
572 may only support a portion of the described semantics, or even differ
573 in some aspects. The relevant details are described in the backend-
574 specific man pages.
575
578 It is strongly recommended to explicitly use the most appropriate
579 <dnstyle> in <what> and <who> clauses, to avoid possible incorrect
580 specifications of the access rules as well as for performance (avoid
581 unnecessary regex matching when an exact match suffices) reasons.
582 An administrator might create a rule of the form:
584 access to dn.regex="dc=example,dc=com"
586 by ...
587 expecting it to match all entries in the subtree "dc=example,dc=com".
589 However, this rule actually matches any DN which contains anywhere the
590 substring "dc=example,dc=com". That is, the rule matches both
591 "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
592 To match the desired subtree, the rule would be more precisely written:
594 access to dn.regex="^(.+,)?dc=example,dc=com$"
596 by ...
597 For performance reasons, it would be better to use the subtree style.
599 access to dn.subtree="dc=example,dc=com"
601 by ...
602 When writing submatch rules, it may be convenient to avoid unnecessary
604 regex <dnstyle> use; for instance, to allow access to the subtree of
605 the user that matches the <what> clause, one could use
606 access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
608 by dn.regex="^uid=$2,dc=example,dc=com$$" write
609 by ...
610 However, since all that is required in the <by> clause is substring ex‐
612 pansion, a more efficient solution is
613 access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
615 by dn.exact,expand="uid=$2,dc=example,dc=com" write
616 by ...
617 In fact, while a <dnstyle> of regex implies substring expansion, exact,
619 as well as all the other DN specific <dnstyle> values, does not, so it
620 must be explicitly requested.
621
623 /etc/openldap/slapd.conf
624 default slapd configuration file
625
627 slapd(8), slapd-*[22m(5), slapacl(8), regex(7), re_format(7)
628 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
630
632 OpenLDAP Software is developed and maintained by The OpenLDAP Project
633 <http://www.openldap.org/>. OpenLDAP Software is derived from the Uni‐
634 versity of Michigan LDAP 3.3 Release.
635OpenLDAP 2.6.6 2023/07/31 SLAPD.ACCESS(5)