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), 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. Access control checking stops at the first match of the
72 <what> and <who> clause, unless otherwise dictated by the <control>
73 clause. Each <who> clause list is implicitly terminated by a
74 by * none stop
76 clause that results in stopping the access control with no access priv‐
78 ileges granted. Each <what> clause list is implicitly terminated by a
79 access to *
81 by * none
82 clause that results in granting no access privileges to an otherwise
84 unspecified datum.
85
87 The field <what> specifies the entity the access control directive ap‐
88 plies to. It can have the forms
89 dn[.<dnstyle>]=<dnpattern>
91 filter=<ldapfilter>
92 attrs=<attrlist>[ val[/matchingRule][.<attrstyle>]=<attrval>]
93 with
95 <dnstyle>={{exact|base(object)}|regex
97 |one(level)|sub(tree)|children}
98 <attrlist>={<attr>|[{!|@}]<objectClass>}[,<attrlist>]
99 <attrstyle>={{exact|base(object)}|regex
100 |one(level)|sub(tree)|children}
101 The statement dn=<dnpattern> selects the entries based on their naming
103 context. The <dnpattern> is a string representation of the entry's DN.
104 The wildcard * stands for all the entries, and it is implied if no dn
105 form is given.
106 The <dnstyle> is optional; however, it is recommended to specify it to
108 avoid ambiguities. Base (synonym of baseObject), the default, or exact
109 (an alias of base) indicates the entry whose DN is equal to the <dnpat‐
110 tern>; one (synonym of onelevel) indicates all the entries immediately
111 below the <dnpattern>, sub (synonym of subtree) indicates all entries
112 in the subtree at the <dnpattern>, children indicates all the entries
113 below (subordinate to) the <dnpattern>.
114 If the <dnstyle> qualifier is regex, then <dnpattern> is a POSIX (''ex‐
116 tended'') regular expression pattern, as detailed in regex(7) and/or
117 re_format(7), matching a normalized string representation of the en‐
118 try's DN. The regex form of the pattern does not (yet) support UTF-8.
119 The statement filter=<ldapfilter> selects the entries based on a valid
121 LDAP filter as described in RFC 4515. A filter of (objectClass=*) is
122 implied if no filter form is given.
123 The statement attrs=<attrlist> selects the attributes the access con‐
125 trol rule applies to. It is a comma-separated list of attribute types,
126 plus the special names entry, indicating access to the entry itself,
127 and children, indicating access to the entry's children. ObjectClass
128 names may also be specified in this list, which will affect all the at‐
129 tributes that are required and/or allowed by that objectClass. Actu‐
130 ally, names in <attrlist> that are prefixed by @ are directly treated
131 as objectClass names. A name prefixed by ! is also treated as an ob‐
132 jectClass, but in this case the access rule affects the attributes that
133 are not required nor allowed by that objectClass. If no attrs form is
134 given, attrs=@extensibleObject is implied, i.e. all attributes are ad‐
135 dressed.
136 Using the form attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval>
138 specifies access to a particular value of a single attribute. In this
139 case, only a single attribute type may be given. The <attrstyle> exact
140 (the default) uses the attribute's equality matching rule to compare
141 the value, unless a different (and compatible) matching rule is speci‐
142 fied. If the <attrstyle> is regex, the provided value is used as a
143 POSIX (''extended'') regular expression pattern. If the attribute has
144 DN syntax, the <attrstyle> can be any of base, onelevel, subtree or
145 children, resulting in base, onelevel, subtree or children match, re‐
146 spectively.
147 The dn, filter, and attrs statements are additive; they can be used in
149 sequence to select entities the access rule applies to based on naming
150 context, value and attribute type simultaneously. Submatches resulting
151 from regex matching can be dereferenced in the <who> field using the
152 syntax ${v<n>}, where <n> is the submatch number. The default syntax,
153 $<n>, is actually an alias for ${d<n>}, that corresponds to dereferenc‐
154 ing submatches from the dnpattern portion of the <what> field.
155
157 The field <who> indicates whom the access rules apply to. Multiple
158 <who> statements can appear in an access control statement, indicating
159 the different access privileges to the same resource that apply to dif‐
160 ferent accessee. It can have the forms
161 *
163 anonymous
164 users
165 self[.<selfstyle>]
166 dn[.<dnstyle>[,<modifier>]]=<DN>
168 dnattr=<attrname>
169 realanonymous
171 realusers
172 realself[.<selfstyle>]
173 realdn[.<dnstyle>[,<modifier>]]=<DN>
175 realdnattr=<attrname>
176 group[/<objectclass>[/<attrname>]]
178 [.<groupstyle>]=<group>
179 peername[.<peernamestyle>]=<peername>
180 sockname[.<style>]=<sockname>
181 domain[.<domainstyle>[,<modifier>]]=<domain>
182 sockurl[.<style>]=<sockurl>
183 set[.<setstyle>]=<pattern>
184 ssf=<n>
186 transport_ssf=<n>
187 tls_ssf=<n>
188 sasl_ssf=<n>
189 dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
191 with
193 <style>={exact|regex|expand}
195 <selfstyle>={level{<n>}}
196 <dnstyle>={{exact|base(object)}|regex
197 |one(level)|sub(tree)|children|level{<n>}}
198 <groupstyle>={exact|expand}
199 <peernamestyle>={<style>|ip|ipv6|path}
200 <domainstyle>={exact|regex|sub(tree)}
201 <setstyle>={exact|expand}
202 <modifier>={expand}
203 <name>=aci <pattern>=<attrname>]
204 They may be specified in combination.
206 The wildcard * refers to everybody.
208 The keywords prefixed by real act as their counterparts without prefix;
210 the checking respectively occurs with the authentication DN and the au‐
211 thorization DN.
212 The keyword anonymous means access is granted to unauthenticated
214 clients; it is mostly used to limit access to authentication resources
215 (e.g. the userPassword attribute) to unauthenticated clients for au‐
216 thentication purposes.
217 The keyword users means access is granted to authenticated clients.
219 The keyword self means access to an entry is allowed to the entry it‐
221 self (e.g. the entry being accessed and the requesting entry must be
222 the same). It allows the level{<n>} style, where <n> indicates what
223 ancestor of the DN is to be used in matches. A positive value indi‐
224 cates that the <n>-th ancestor of the user's DN is to be considered; a
225 negative value indicates that the <n>-th ancestor of the target is to
226 be considered. For example, a "by self.level{1} ..." clause would
227 match when the object "dc=example,dc=com" is accessed by
228 "cn=User,dc=example,dc=com". A "by self.level{-1} ..." clause would
229 match when the same user accesses the object "ou=Address
230 Book,cn=User,dc=example,dc=com".
231 The statement dn=<DN> means that access is granted to the matching DN.
233 The optional style qualifier dnstyle allows the same choices of the dn
234 form of the <what> field. In addition, the regex style can exploit
235 substring substitution of submatches in the <what> dn.regex clause by
236 using the form $<digit>, with digit ranging from 0 to 9 (where 0
237 matches the entire string), or the form ${<digit>+}, for submatches
238 higher than 9. Substring substitution from attribute value can be done
239 in using the form ${v<digit>+}. Since the dollar character is used to
240 indicate a substring replacement, the dollar character that is used to
241 indicate match up to the end of the string must be escaped by a second
242 dollar character, e.g.
243 access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$"
245 by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write
246 The style qualifier allows an optional modifier. At present, the only
248 type allowed is expand, which causes substring substitution of sub‐
249 matches to take place even if dnstyle is not regex. Note that the
250 regex dnstyle in the above example may be of use only if the <by>
251 clause needs to be a regex; otherwise, if the value of the second (from
252 the right) dc= portion of the DN in the above example were fixed, the
253 form
254 access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
256 by dn.exact,expand="uid=$2,dc=example,dc=com" write
257 could be used; if it had to match the value in the <what> clause, the
259 form
260 access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$"
262 by dn.exact,expand="uid=$2,dc=$3,dc=com" write
263 could be used.
265 Forms of the <what> clause other than regex may provide submatches as
267 well. The base(object), the sub(tree), the one(level), and the chil‐
268 dren forms provide $0 as the match of the entire string. The
269 sub(tree), the one(level), and the children forms also provide $1 as
270 the match of the rightmost part of the DN as defined in the <what>
271 clause. This may be useful, for instance, to provide access to all the
272 ancestors of a user by defining
273 access to dn.subtree="dc=com"
275 by dn.subtree,expand="$1" read
276 which means that only access to entries that appear in the DN of the
278 <by> clause is allowed.
279 The level{<n>} form is an extension and a generalization of the
281 onelevel form, which matches all DNs whose <n>-th ancestor is the pat‐
282 tern. So, level{1} is equivalent to onelevel, and level{0} is equiva‐
283 lent to base.
284 It is perfectly useless to give any access privileges to a DN that ex‐
286 actly matches the rootdn of the database the ACLs apply to, because it
287 implicitly possesses write privileges for the entire tree of that data‐
288 base. Actually, access control is bypassed for the rootdn, to solve
289 the intrinsic chicken-and-egg problem.
290 The statement dnattr=<attrname> means that access is granted to re‐
292 quests whose DN is listed in the entry being accessed under the <attr‐
293 name> attribute.
294 The statement group=<group> means that access is granted to requests
296 whose DN is listed in the group entry whose DN is given by <group>.
297 The optional parameters <objectclass> and <attrname> define the object‐
298 Class and the member attributeType of the group entry. The defaults
299 are groupOfNames and member, respectively. The optional style quali‐
300 fier <style> can be expand, which means that <group> will be expanded
301 as a replacement string (but not as a regular expression) according to
302 regex(7) and/or re_format(7), and exact, which means that exact match
303 will be used. If the style of the DN portion of the <what> clause is
304 regex, the submatches are made available according to regex(7) and/or
305 re_format(7); other styles provide limited submatches as discussed
306 above about the DN form of the <by> clause.
307 For static groups, the specified attributeType must have Distinguished‐
309 Name or NameAndOptionalUID syntax. For dynamic groups the attributeType
310 must be a subtype of the labeledURI attributeType. Only LDAP URIs of
311 the form ldap:///<base>??<scope>?<filter> will be evaluated in a dy‐
312 namic group, by searching the local server only.
313 The statements peername=<peername>, sockname=<sockname>, domain=<do‐
315 main>, and sockurl=<sockurl> mean that the contacting host IP (in the
316 form IP=<ip>:<port> for IPv4, or IP=[<ipv6>]:<port> for IPv6) or the
317 contacting host named pipe file name (in the form PATH=<path> if con‐
318 necting through a named pipe) for peername, the named pipe file name
319 for sockname, the contacting host name for domain, and the contacting
320 URL for sockurl are compared against pattern to determine access. The
321 same style rules for pattern match described for the group case apply,
322 plus the regex style, which implies submatch expand and regex match of
323 the corresponding connection parameters. The exact style of the <peer‐
324 name> clause (the default) implies a case-exact match on the client's
325 IP, including the IP= prefix and the trailing :<port>, or the client's
326 path, including the PATH= prefix if connecting through a named pipe.
327 The special ip style interprets the pattern as <peer‐
328 name>=<ip>[%<mask>][{<n>}], where <ip> and <mask> are dotted digit rep‐
329 resentations of the IP and the mask, while <n>, delimited by curly
330 brackets, is an optional port. The same applies to IPv6 addresses when
331 the special ipv6 style is used. When checking access privileges, the
332 IP portion of the peername is extracted, eliminating the IP= prefix and
333 the :<port> part, and it is compared against the <ip> portion of the
334 pattern after masking with <mask>: ((peername & <mask>) == <ip>). As
335 an example, peername.ip=127.0.0.1 and peername.ipv6=::1 allow connec‐
336 tions only from localhost, peername.ip=192.168.1.0%255.255.255.0 allows
337 connections from any IP in the 192.168.1 class C domain, and peer‐
338 name.ip=192.168.1.16%255.255.255.240{9009} allows connections from any
339 IP in the 192.168.1.[16-31] range of the same domain, only if port 9009
340 is used. The special path style eliminates the PATH= prefix from the
341 peername when connecting through a named pipe, and performs an exact
342 match on the given pattern. The <domain> clause also allows the sub‐
343 tree style, which succeeds when a fully qualified name exactly matches
344 the domain pattern, or its trailing part, after a dot, exactly matches
345 the domain pattern. The expand style is allowed, implying an exact
346 match with submatch expansion; the use of expand as a style modifier is
347 considered more appropriate. As an example, domain.subtree=example.com
348 will match www.example.com, but will not match www.anotherexample.com.
349 The domain of the contacting host is determined by performing a DNS re‐
350 verse lookup. As this lookup can easily be spoofed, use of the domain
351 statement is strongly discouraged. By default, reverse lookups are
352 disabled. The optional domainstyle qualifier of the <domain> clause
353 allows a modifier option; the only value currently supported is expand,
354 which causes substring substitution of submatches to take place even if
355 the domainstyle is not regex, much like the analogous usage in <dn>
356 clause.
357 The statement set=<pattern> is undocumented yet.
359 The statement dynacl/<name>[/<options>][.<dynstyle>][=<pattern>] means
361 that access checking is delegated to the admin-defined method indicated
362 by <name>, which can be registered at run-time by means of the mod‐
363 uleload statement. The fields <options>, <dynstyle> and <pattern> are
364 optional, and are directly passed to the registered parsing routine.
365 Dynacl is experimental; it must be enabled at compile time.
366 The statement dynacl/aci[=<attrname>] means that the access control is
368 determined by the values in the attrname of the entry itself. The op‐
369 tional <attrname> indicates what attributeType holds the ACI informa‐
370 tion in the entry. By default, the OpenLDAPaci operational attribute
371 is used. ACIs are experimental; they must be enabled at compile time.
372 The statements ssf=<n>, transport_ssf=<n>, tls_ssf=<n>, and
374 sasl_ssf=<n> set the minimum required Security Strength Factor (ssf)
375 needed to grant access. The value should be positive integer.
376
378 The optional field <access> ::= [[real]self]{<level>|<priv>} determines
379 the access level or the specific access privileges the who field will
380 have. Its component are defined as
381 <level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage
383 <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
384 The modifier self allows special operations like having a certain ac‐
386 cess level or privilege only in case the operation involves the name of
387 the user that's requesting the access. It implies the user that re‐
388 quests access is authorized. The modifier realself refers to the au‐
389 thenticated DN as opposed to the authorized DN of the self modifier.
390 An example is the selfwrite access to the member attribute of a group,
391 which allows one to add/delete its own DN from the member list of a
392 group, while being not allowed to affect other members.
393 The level access model relies on an incremental interpretation of the
395 access privileges. The possible levels are none, disclose, auth, com‐
396 pare, search, read, write, and manage. Each access level implies all
397 the preceding ones, thus manage grants all access including administra‐
398 tive access. The write access is actually the combination of add and
399 delete, which respectively restrict the write privilege to add or
400 delete the specified <what>.
401 The none access level disallows all access including disclosure on er‐
404 ror.
405 The disclose access level allows disclosure of information on error.
407 The auth access level means that one is allowed access to an attribute
409 to perform authentication/authorization operations (e.g. bind) with no
410 other access. This is useful to grant unauthenticated clients the
411 least possible access level to critical resources, like passwords.
412 The priv access model relies on the explicit setting of access privi‐
414 leges for each clause. The = sign resets previously defined accesses;
415 as a consequence, the final access privileges will be only those de‐
416 fined by the clause. The + and - signs add/remove access privileges to
417 the existing ones. The privileges are m for manage, w for write, a for
418 add, z for delete, r for read, s for search, c for compare, x for au‐
419 thentication, and d for disclose. More than one of the above privi‐
420 leges can be added in one statement. 0 indicates no privileges and is
421 used only by itself (e.g., +0). Note that +az is equivalent to +w.
422 If no access is given, it defaults to +0.
424
426 The optional field <control> controls the flow of access rule applica‐
427 tion. It can have the forms
428 stop
430 continue
431 break
432 where stop, the default, means access checking stops in case of match.
434 The other two forms are used to keep on processing access clauses. In
435 detail, the continue form allows for other <who> clauses in the same
436 <access> clause to be considered, so that they may result in incremen‐
437 tally altering the privileges, while the break form allows for other
438 <access> clauses that match the same target to be processed. Consider
439 the (silly) example
440 access to dn.subtree="dc=example,dc=com" attrs=cn
442 by * =cs break
443 access to dn.subtree="ou=People,dc=example,dc=com"
445 by * +r
446 which allows search and compare privileges to everybody under the
448 "dc=example,dc=com" tree, with the second rule allowing also read in
449 the "ou=People" subtree, or the (even more silly) example
450 access to dn.subtree="dc=example,dc=com" attrs=cn
452 by * =cs continue
453 by users +r
454 which grants everybody search and compare privileges, and adds read
456 privileges to authenticated clients.
457 One useful application is to easily grant write privileges to an updat‐
459 edn that is different from the rootdn. In this case, since the updat‐
460 edn needs write access to (almost) all data, one can use
461 access to *
463 by dn.exact="cn=The Update DN,dc=example,dc=com" write
464 by * break
465 as the first access rule. As a consequence, unless the operation is
467 performed with the updatedn identity, control is passed straight to the
468 subsequent rules.
469
472 Operations require different privileges on different portions of en‐
473 tries. The following summary applies to primary MDB database backend
474 and the deprecated BDB and HDB backends. Requirements for other back‐
475 ends may (and often do) differ.
476 The add operation requires add (=a) privileges on the pseudo-attribute
479 entry of the entry being added, and add (=a) privileges on the pseudo-
480 attribute children of the entry's parent. When adding the suffix entry
481 of a database, add access to children of the empty DN ("") is required.
482 Also if Add content ACL checking has been configured on the database
483 (see the slapd.conf(5) or slapd-config(5) manual page), add (=a) will
484 be required on all of the attributes being added.
485 The bind operation, when credentials are stored in the directory, re‐
488 quires auth (=x) privileges on the attribute the credentials are stored
489 in (usually userPassword).
490 The compare operation requires compare (=c) privileges on the attribute
493 that is being compared.
494 The delete operation requires delete (=z) privileges on the pseudo-at‐
497 tribute entry of the entry being deleted, and delete (=d) privileges on
498 the children pseudo-attribute of the entry's parent.
499 The modify operation requires write (=w) privileges on the attributes
502 being modified. In detail, add (=a) is required to add new values,
503 delete (=z) is required to delete existing values, and both delete and
504 add (=az), or write (=w), are required to replace existing values.
505 The modrdn operation requires write (=w) privileges on the pseudo-at‐
508 tribute entry of the entry whose relative DN is being modified, delete
509 (=z) privileges on the pseudo-attribute children of the old entry's
510 parents, add (=a) privileges on the pseudo-attribute children of the
511 new entry's parents, and add (=a) privileges on the attributes that are
512 present in the new relative DN. Delete (=z) privileges are also re‐
513 quired on the attributes that are present in the old relative DN if
514 deleteoldrdn is set to 1.
515 The search operation, requires search (=s) privileges on the entry
518 pseudo-attribute of the searchBase (NOTE: this was introduced with
519 OpenLDAP 2.4). Then, for each entry, it requires search (=s) privi‐
520 leges on the attributes that are defined in the filter. The resulting
521 entries are finally tested for read (=r) privileges on the pseudo-at‐
522 tribute entry (for read access to the entry itself) and for read (=r)
523 access on each value of each attribute that is requested. Also, for
524 each referral object used in generating continuation references, the
525 operation requires read (=r) access on the pseudo-attribute entry (for
526 read access to the referral object itself), as well as read (=r) access
527 to the attribute holding the referral information (generally the ref
528 attribute).
529 Some internal operations and some controls require specific access
532 privileges. The authzID mapping and the proxyAuthz control require
533 auth (=x) privileges on all the attributes that are present in the
534 search filter of the URI regexp maps (the right-hand side of the authz-
535 regexp directives). Auth (=x) privileges are also required on the au‐
536 thzTo attribute of the authorizing identity and/or on the authzFrom at‐
537 tribute of the authorized identity. In general, when an internal
538 lookup is performed for authentication or authorization purposes,
539 search-specific privileges (see the access requirements for the search
540 operation illustrated above) are relaxed to auth.
541 Access control to search entries is checked by the frontend, so it is
544 fully honored by all backends; for all other operations and for the
545 discovery phase of the search operation, full ACL semantics is only
546 supported by the primary backends, i.e. back-bdb(5), and back-hdb(5).
547 Some other backend, like back-sql(5), may fully support them; others
549 may only support a portion of the described semantics, or even differ
550 in some aspects. The relevant details are described in the backend-
551 specific man pages.
552
555 It is strongly recommended to explicitly use the most appropriate
556 <dnstyle> in <what> and <who> clauses, to avoid possible incorrect
557 specifications of the access rules as well as for performance (avoid
558 unnecessary regex matching when an exact match suffices) reasons.
559 An administrator might create a rule of the form:
561 access to dn.regex="dc=example,dc=com"
563 by ...
564 expecting it to match all entries in the subtree "dc=example,dc=com".
566 However, this rule actually matches any DN which contains anywhere the
567 substring "dc=example,dc=com". That is, the rule matches both
568 "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
569 To match the desired subtree, the rule would be more precisely written:
571 access to dn.regex="^(.+,)?dc=example,dc=com$"
573 by ...
574 For performance reasons, it would be better to use the subtree style.
576 access to dn.subtree="dc=example,dc=com"
578 by ...
579 When writing submatch rules, it may be convenient to avoid unnecessary
581 regex <dnstyle> use; for instance, to allow access to the subtree of
582 the user that matches the <what> clause, one could use
583 access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
585 by dn.regex="^uid=$2,dc=example,dc=com$$" write
586 by ...
587 However, since all that is required in the <by> clause is substring ex‐
589 pansion, a more efficient solution is
590 access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
592 by dn.exact,expand="uid=$2,dc=example,dc=com" write
593 by ...
594 In fact, while a <dnstyle> of regex implies substring expansion, exact,
596 as well as all the other DN specific <dnstyle> values, does not, so it
597 must be explicitly requested.
598
600 /etc/openldap/slapd.conf
601 default slapd configuration file
602
604 slapd(8), slapd-*[22m(5), slapacl(8), regex(7), re_format(7)
605 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
607
609 OpenLDAP Software is developed and maintained by The OpenLDAP Project
610 <http://www.openldap.org/>. OpenLDAP Software is derived from the Uni‐
611 versity of Michigan LDAP 3.3 Release.
612OpenLDAP 2021/06/03 SLAPD.ACCESS(5)