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
19 options that apply to slapd as a whole (including all backends), fol‐
20 lowed by zero or more database backend definitions that contain infor‐
21 mation 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.,
42 "access to * by * read").
43 When dealing with an access list, because the global access list is
45 effectively appended to each per-database list, if the resulting list
46 is non-empty then the access list will end with an implicit access to *
47 by * 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
69 being 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
88 applies 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
116 (''extended'') regular expression pattern, as detailed in regex(7)
117 and/or re_format(7), matching a normalized string representation of the
118 entry's DN. The regex form of the pattern does not (yet) support
119 UTF-8.
120 The statement filter=<ldapfilter> selects the entries based on a valid
122 LDAP filter as described in RFC 4515. A filter of (objectClass=*) is
123 implied if no filter form is given.
124 The statement attrs=<attrlist> selects the attributes the access con‐
126 trol rule applies to. It is a comma-separated list of attribute types,
127 plus the special names entry, indicating access to the entry itself,
128 and children, indicating access to the entry's children. ObjectClass
129 names may also be specified in this list, which will affect all the
130 attributes that are required and/or allowed by that objectClass. Actu‐
131 ally, names in <attrlist> that are prefixed by @ are directly treated
132 as objectClass names. A name prefixed by ! is also treated as an
133 objectClass, but in this case the access rule affects the attributes
134 that are not required nor allowed by that objectClass. If no attrs
135 form is given, attrs=@extensibleObject is implied, i.e. all attributes
136 are addressed.
137 Using the form attrs=<attr> val[/matchingRule][.<attrstyle>]=<attrval>
139 specifies access to a particular value of a single attribute. In this
140 case, only a single attribute type may be given. The <attrstyle> exact
141 (the default) uses the attribute's equality matching rule to compare
142 the value, unless a different (and compatible) matching rule is speci‐
143 fied. If the <attrstyle> is regex, the provided value is used as a
144 POSIX (''extended'') regular expression pattern. If the attribute has
145 DN syntax, the <attrstyle> can be any of base, onelevel, subtree or
146 children, resulting in base, onelevel, subtree or children match,
147 respectively.
148 The dn, filter, and attrs statements are additive; they can be used in
150 sequence to select entities the access rule applies to based on naming
151 context, value and attribute type simultaneously. Submatches resulting
152 from regex matching can be dereferenced in the <who> field using the
153 syntax ${v<n>}, where <n> is the submatch number. The default syntax,
154 $<n>, is actually an alias for ${d<n>}, that corresponds to dereferenc‐
155 ing submatches from the dnpattern portion of the <what> field.
156
158 The field <who> indicates whom the access rules apply to. Multiple
159 <who> statements can appear in an access control statement, indicating
160 the different access privileges to the same resource that apply to dif‐
161 ferent accessee. It can have the forms
162 *
164 anonymous
165 users
166 self[.<selfstyle>]
167 dn[.<dnstyle>[,<modifier>]]=<DN>
169 dnattr=<attrname>
170 realanonymous
172 realusers
173 realself[.<selfstyle>]
174 realdn[.<dnstyle>[,<modifier>]]=<DN>
176 realdnattr=<attrname>
177 group[/<objectclass>[/<attrname>]]
179 [.<groupstyle>]=<group>
180 peername[.<peernamestyle>]=<peername>
181 sockname[.<style>]=<sockname>
182 domain[.<domainstyle>[,<modifier>]]=<domain>
183 sockurl[.<style>]=<sockurl>
184 set[.<setstyle>]=<pattern>
185 ssf=<n>
187 transport_ssf=<n>
188 tls_ssf=<n>
189 sasl_ssf=<n>
190 dynacl/<name>[/<options>][.<dynstyle>][=<pattern>]
192 with
194 <style>={exact|regex|expand}
196 <selfstyle>={level{<n>}}
197 <dnstyle>={{exact|base(object)}|regex
198 |one(level)|sub(tree)|children|level{<n>}}
199 <groupstyle>={exact|expand}
200 <peernamestyle>={<style>|ip|ipv6|path}
201 <domainstyle>={exact|regex|sub(tree)}
202 <setstyle>={exact|expand}
203 <modifier>={expand}
204 <name>=aci <pattern>=<attrname>]
205 They may be specified in combination.
207 The wildcard * refers to everybody.
209 The keywords prefixed by real act as their counterparts without prefix;
211 the checking respectively occurs with the authentication DN and the
212 authorization DN.
213 The keyword anonymous means access is granted to unauthenticated
215 clients; it is mostly used to limit access to authentication resources
216 (e.g. the userPassword attribute) to unauthenticated clients for
217 authentication purposes.
218 The keyword users means access is granted to authenticated clients.
220 The keyword self means access to an entry is allowed to the entry
222 itself (e.g. the entry being accessed and the requesting entry must be
223 the same). It allows the level{<n>} style, where <n> indicates what
224 ancestor of the DN is to be used in matches. A positive value indi‐
225 cates that the <n>-th ancestor of the user's DN is to be considered; a
226 negative value indicates that the <n>-th ancestor of the target is to
227 be considered. For example, a "by self.level{1} ..." clause would
228 match when the object "dc=example,dc=com" is accessed by
229 "cn=User,dc=example,dc=com". A "by self.level{-1} ..." clause would
230 match when the same user accesses the object "ou=Address
231 Book,cn=User,dc=example,dc=com".
232 The statement dn=<DN> means that access is granted to the matching DN.
234 The optional style qualifier dnstyle allows the same choices of the dn
235 form of the <what> field. In addition, the regex style can exploit
236 substring substitution of submatches in the <what> dn.regex clause by
237 using the form $<digit>, with digit ranging from 0 to 9 (where 0
238 matches the entire string), or the form ${<digit>+}, for submatches
239 higher than 9. Substring substitution from attribute value can be done
240 in using the form ${v<digit>+}. Since the dollar character is used to
241 indicate a substring replacement, the dollar character that is used to
242 indicate match up to the end of the string must be escaped by a second
243 dollar character, e.g.
244 access to dn.regex="^(.+,)?uid=([^,]+),dc=[^,]+,dc=com$"
246 by dn.regex="^uid=$2,dc=[^,]+,dc=com$$" write
247 The style qualifier allows an optional modifier. At present, the only
249 type allowed is expand, which causes substring substitution of sub‐
250 matches to take place even if dnstyle is not regex. Note that the
251 regex dnstyle in the above example may be of use only if the <by>
252 clause needs to be a regex; otherwise, if the value of the second (from
253 the right) dc= portion of the DN in the above example were fixed, the
254 form
255 access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
257 by dn.exact,expand="uid=$2,dc=example,dc=com" write
258 could be used; if it had to match the value in the <what> clause, the
260 form
261 access to dn.regex="^(.+,)?uid=([^,]+),dc=([^,]+),dc=com$"
263 by dn.exact,expand="uid=$2,dc=$3,dc=com" write
264 could be used.
266 Forms of the <what> clause other than regex may provide submatches as
268 well. The base(object), the sub(tree), the one(level), and the chil‐
269 dren forms provide $0 as the match of the entire string. The
270 sub(tree), the one(level), and the children forms also provide $1 as
271 the match of the rightmost part of the DN as defined in the <what>
272 clause. This may be useful, for instance, to provide access to all the
273 ancestors of a user by defining
274 access to dn.subtree="dc=com"
276 by dn.subtree,expand="$1" read
277 which means that only access to entries that appear in the DN of the
279 <by> clause is allowed.
280 The level{<n>} form is an extension and a generalization of the
282 onelevel form, which matches all DNs whose <n>-th ancestor is the pat‐
283 tern. So, level{1} is equivalent to onelevel, and level{0} is equiva‐
284 lent to base.
285 It is perfectly useless to give any access privileges to a DN that
287 exactly matches the rootdn of the database the ACLs apply to, because
288 it implicitly possesses write privileges for the entire tree of that
289 database. Actually, access control is bypassed for the rootdn, to
290 solve the intrinsic chicken-and-egg problem.
291 The statement dnattr=<attrname> means that access is granted to
293 requests whose DN is listed in the entry being accessed under the
294 <attrname> attribute.
295 The statement group=<group> means that access is granted to requests
297 whose DN is listed in the group entry whose DN is given by <group>.
298 The optional parameters <objectclass> and <attrname> define the object‐
299 Class and the member attributeType of the group entry. The defaults
300 are groupOfNames and member, respectively. The optional style quali‐
301 fier <style> can be expand, which means that <group> will be expanded
302 as a replacement string (but not as a regular expression) according to
303 regex(7) and/or re_format(7), and exact, which means that exact match
304 will be used. If the style of the DN portion of the <what> clause is
305 regex, the submatches are made available according to regex(7) and/or
306 re_format(7); other styles provide limited submatches as discussed
307 above about the DN form of the <by> clause.
308 For static groups, the specified attributeType must have Distinguished‐
310 Name or NameAndOptionalUID syntax. For dynamic groups the attributeType
311 must be a subtype of the labeledURI attributeType. Only LDAP URIs of
312 the form ldap:///<base>??<scope>?<filter> will be evaluated in a
313 dynamic group, by searching the local server only.
314 The statements peername=<peername>, sockname=<sockname>,
316 domain=<domain>, and sockurl=<sockurl> mean that the contacting host IP
317 (in the form IP=<ip>:<port> for IPv4, or IP=[<ipv6>]:<port> for IPv6)
318 or the contacting host named pipe file name (in the form PATH=<path> if
319 connecting through a named pipe) for peername, the named pipe file name
320 for sockname, the contacting host name for domain, and the contacting
321 URL for sockurl are compared against pattern to determine access. The
322 same style rules for pattern match described for the group case apply,
323 plus the regex style, which implies submatch expand and regex match of
324 the corresponding connection parameters. The exact style of the <peer‐
325 name> clause (the default) implies a case-exact match on the client's
326 IP, including the IP= prefix and the trailing :<port>, or the client's
327 path, including the PATH= prefix if connecting through a named pipe.
328 The special ip style interprets the pattern as <peer‐
329 name>=<ip>[%<mask>][{<n>}], where <ip> and <mask> are dotted digit rep‐
330 resentations of the IP and the mask, while <n>, delimited by curly
331 brackets, is an optional port. The same applies to IPv6 addresses when
332 the special ipv6 style is used. When checking access privileges, the
333 IP portion of the peername is extracted, eliminating the IP= prefix and
334 the :<port> part, and it is compared against the <ip> portion of the
335 pattern after masking with <mask>: ((peername & <mask>) == <ip>). As
336 an example, peername.ip=127.0.0.1 and peername.ipv6=::1 allow connec‐
337 tions only from localhost, peername.ip=192.168.1.0%255.255.255.0 allows
338 connections from any IP in the 192.168.1 class C domain, and peer‐
339 name.ip=192.168.1.16%255.255.255.240{9009} allows connections from any
340 IP in the 192.168.1.[16-31] range of the same domain, only if port 9009
341 is used. The special path style eliminates the PATH= prefix from the
342 peername when connecting through a named pipe, and performs an exact
343 match on the given pattern. The <domain> clause also allows the sub‐
344 tree style, which succeeds when a fully qualified name exactly matches
345 the domain pattern, or its trailing part, after a dot, exactly matches
346 the domain pattern. The expand style is allowed, implying an exact
347 match with submatch expansion; the use of expand as a style modifier is
348 considered more appropriate. As an example, domain.subtree=example.com
349 will match www.example.com, but will not match www.anotherexample.com.
350 The domain of the contacting host is determined by performing a DNS
351 reverse lookup. As this lookup can easily be spoofed, use of the
352 domain statement is strongly discouraged. By default, reverse lookups
353 are disabled. The optional domainstyle qualifier of the <domain>
354 clause allows a modifier option; the only value currently supported is
355 expand, which causes substring substitution of submatches to take place
356 even if the domainstyle is not regex, much like the analogous usage in
357 <dn> clause.
358 The statement set=<pattern> is undocumented yet.
360 The statement dynacl/<name>[/<options>][.<dynstyle>][=<pattern>] means
362 that access checking is delegated to the admin-defined method indicated
363 by <name>, which can be registered at run-time by means of the mod‐
364 uleload statement. The fields <options>, <dynstyle> and <pattern> are
365 optional, and are directly passed to the registered parsing routine.
366 Dynacl is experimental; it must be enabled at compile time.
367 The statement dynacl/aci[=<attrname>] means that the access control is
369 determined by the values in the attrname of the entry itself. The
370 optional <attrname> indicates what attributeType holds the ACI informa‐
371 tion in the entry. By default, the OpenLDAPaci operational attribute
372 is used. ACIs are experimental; they must be enabled at compile time.
373 The statements ssf=<n>, transport_ssf=<n>, tls_ssf=<n>, and
375 sasl_ssf=<n> set the minimum required Security Strength Factor (ssf)
376 needed to grant access. The value should be positive integer.
377
379 The optional field <access> ::= [[real]self]{<level>|<priv>} determines
380 the access level or the specific access privileges the who field will
381 have. Its component are defined as
382 <level> ::= none|disclose|auth|compare|search|read|{write|add|delete}|manage
384 <priv> ::= {=|+|-}{0|d|x|c|s|r|{w|a|z}|m}+
385 The modifier self allows special operations like having a certain
387 access level or privilege only in case the operation involves the name
388 of the user that's requesting the access. It implies the user that
389 requests access is authorized. The modifier realself refers to the
390 authenticated DN as opposed to the authorized DN of the self modifier.
391 An example is the selfwrite access to the member attribute of a group,
392 which allows one to add/delete its own DN from the member list of a
393 group, while being not allowed to affect other members.
394 The level access model relies on an incremental interpretation of the
396 access privileges. The possible levels are none, disclose, auth, com‐
397 pare, search, read, write, and manage. Each access level implies all
398 the preceding ones, thus manage grants all access including administra‐
399 tive access. The write access is actually the combination of add and
400 delete, which respectively restrict the write privilege to add or
401 delete the specified <what>.
402 The none access level disallows all access including disclosure on
405 error.
406 The disclose access level allows disclosure of information on error.
408 The auth access level means that one is allowed access to an attribute
410 to perform authentication/authorization operations (e.g. bind) with no
411 other access. This is useful to grant unauthenticated clients the
412 least possible access level to critical resources, like passwords.
413 The priv access model relies on the explicit setting of access privi‐
415 leges for each clause. The = sign resets previously defined accesses;
416 as a consequence, the final access privileges will be only those
417 defined by the clause. The + and - signs add/remove access privileges
418 to the existing ones. The privileges are m for manage, w for write, a
419 for add, z for delete, r for read, s for search, c for compare, x for
420 authentication, and d for disclose. More than one of the above privi‐
421 leges can be added in one statement. 0 indicates no privileges and is
422 used only by itself (e.g., +0). Note that +az is equivalent to +w.
423 If no access is given, it defaults to +0.
425
427 The optional field <control> controls the flow of access rule applica‐
428 tion. It can have the forms
429 stop
431 continue
432 break
433 where stop, the default, means access checking stops in case of match.
435 The other two forms are used to keep on processing access clauses. In
436 detail, the continue form allows for other <who> clauses in the same
437 <access> clause to be considered, so that they may result in incremen‐
438 tally altering the privileges, while the break form allows for other
439 <access> clauses that match the same target to be processed. Consider
440 the (silly) example
441 access to dn.subtree="dc=example,dc=com" attrs=cn
443 by * =cs break
444 access to dn.subtree="ou=People,dc=example,dc=com"
446 by * +r
447 which allows search and compare privileges to everybody under the
449 "dc=example,dc=com" tree, with the second rule allowing also read in
450 the "ou=People" subtree, or the (even more silly) example
451 access to dn.subtree="dc=example,dc=com" attrs=cn
453 by * =cs continue
454 by users +r
455 which grants everybody search and compare privileges, and adds read
457 privileges to authenticated clients.
458 One useful application is to easily grant write privileges to an updat‐
460 edn that is different from the rootdn. In this case, since the updat‐
461 edn needs write access to (almost) all data, one can use
462 access to *
464 by dn.exact="cn=The Update DN,dc=example,dc=com" write
465 by * break
466 as the first access rule. As a consequence, unless the operation is
468 performed with the updatedn identity, control is passed straight to the
469 subsequent rules.
470
473 Operations require different privileges on different portions of
474 entries. The following summary applies to primary database backends
475 such as the BDB and HDB backends. Requirements for other backends may
476 (and often do) differ.
477 The add operation requires add (=a) privileges on the pseudo-attribute
480 entry of the entry being added, and add (=a) privileges on the pseudo-
481 attribute children of the entry's parent. When adding the suffix entry
482 of a database, add access to children of the empty DN ("") is required.
483 Also if Add content ACL checking has been configured on the database
484 (see the slapd.conf(5) or slapd-config(5) manual page), add (=a) will
485 be required on all of the attributes being added.
486 The bind operation, when credentials are stored in the directory,
489 requires auth (=x) privileges on the attribute the credentials are
490 stored in (usually userPassword).
491 The compare operation requires compare (=c) privileges on the attribute
494 that is being compared.
495 The delete operation requires delete (=z) privileges on the pseudo-
498 attribute entry of the entry being deleted, and delete (=d) privileges
499 on the children pseudo-attribute of the entry's parent.
500 The modify operation requires write (=w) privileges on the attributes
503 being modified. In detail, add (=a) is required to add new values,
504 delete (=z) is required to delete existing values, and both delete and
505 add (=az), or write (=w), are required to replace existing values.
506 The modrdn operation requires write (=w) privileges on the pseudo-
509 attribute entry of the entry whose relative DN is being modified,
510 delete (=z) privileges on the pseudo-attribute children of the old
511 entry's parents, add (=a) privileges on the pseudo-attribute children
512 of the new entry's parents, and add (=a) privileges on the attributes
513 that are present in the new relative DN. Delete (=z) privileges are
514 also required on the attributes that are present in the old relative DN
515 if deleteoldrdn is set to 1.
516 The search operation, requires search (=s) privileges on the entry
519 pseudo-attribute of the searchBase (NOTE: this was introduced with
520 OpenLDAP 2.4). Then, for each entry, it requires search (=s) privi‐
521 leges on the attributes that are defined in the filter. The resulting
522 entries are finally tested for read (=r) privileges on the pseudo-
523 attribute entry (for read access to the entry itself) and for read (=r)
524 access on each value of each attribute that is requested. Also, for
525 each referral object used in generating continuation references, the
526 operation requires read (=r) access on the pseudo-attribute entry (for
527 read access to the referral object itself), as well as read (=r) access
528 to the attribute holding the referral information (generally the ref
529 attribute).
530 Some internal operations and some controls require specific access
533 privileges. The authzID mapping and the proxyAuthz control require
534 auth (=x) privileges on all the attributes that are present in the
535 search filter of the URI regexp maps (the right-hand side of the authz-
536 regexp directives). Auth (=x) privileges are also required on the
537 authzTo attribute of the authorizing identity and/or on the authzFrom
538 attribute of the authorized identity. In general, when an internal
539 lookup is performed for authentication or authorization purposes,
540 search-specific privileges (see the access requirements for the search
541 operation illustrated above) are relaxed to auth.
542 Access control to search entries is checked by the frontend, so it is
545 fully honored by all backends; for all other operations and for the
546 discovery phase of the search operation, full ACL semantics is only
547 supported by the primary backends, i.e. back-bdb(5), and back-hdb(5).
548 Some other backend, like back-sql(5), may fully support them; others
550 may only support a portion of the described semantics, or even differ
551 in some aspects. The relevant details are described in the backend-
552 specific man pages.
553
556 It is strongly recommended to explicitly use the most appropriate
557 <dnstyle> in <what> and <who> clauses, to avoid possible incorrect
558 specifications of the access rules as well as for performance (avoid
559 unnecessary regex matching when an exact match suffices) reasons.
560 An administrator might create a rule of the form:
562 access to dn.regex="dc=example,dc=com"
564 by ...
565 expecting it to match all entries in the subtree "dc=example,dc=com".
567 However, this rule actually matches any DN which contains anywhere the
568 substring "dc=example,dc=com". That is, the rule matches both
569 "uid=joe,dc=example,dc=com" and "dc=example,dc=com,uid=joe".
570 To match the desired subtree, the rule would be more precisely written:
572 access to dn.regex="^(.+,)?dc=example,dc=com$"
574 by ...
575 For performance reasons, it would be better to use the subtree style.
577 access to dn.subtree="dc=example,dc=com"
579 by ...
580 When writing submatch rules, it may be convenient to avoid unnecessary
582 regex <dnstyle> use; for instance, to allow access to the subtree of
583 the user that matches the <what> clause, one could use
584 access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
586 by dn.regex="^uid=$2,dc=example,dc=com$$" write
587 by ...
588 However, since all that is required in the <by> clause is substring
590 expansion, a more efficient solution is
591 access to dn.regex="^(.+,)?uid=([^,]+),dc=example,dc=com$"
593 by dn.exact,expand="uid=$2,dc=example,dc=com" write
594 by ...
595 In fact, while a <dnstyle> of regex implies substring expansion, exact,
597 as well as all the other DN specific <dnstyle> values, does not, so it
598 must be explicitly requested.
599
601 /etc/openldap/slapd.conf
602 default slapd configuration file
603
605 slapd(8), slapd-*[22m(5), slapacl(8), regex(7), re_format(7)
606 "OpenLDAP Administrator's Guide" (http://www.OpenLDAP.org/doc/admin/)
608
610 OpenLDAP Software is developed and maintained by The OpenLDAP Project
611 <http://www.openldap.org/>. OpenLDAP Software is derived from Univer‐
612 sity of Michigan LDAP 3.3 Release.
613OpenLDAP 2.4.23 2010/06/30 SLAPD.ACCESS(5)