2 # Copyright 2005-2006 The OpenLDAP Foundation, All Rights Reserved.
3 # COPYING RESTRICTIONS APPLY, see COPYRIGHT.
7 Once the software has been built and installed, you are ready
8 to configure {{slapd}}(8) for use at your site. Unlike previous
9 OpenLDAP releases, the slapd(8) runtime configuration in 2.3 (and later)
10 is fully LDAP-enabled and can be managed using the standard LDAP
11 operations with data in {{TERM:LDIF}}. The LDAP configuration engine
12 allows all of slapd's configuration options to be changed on the fly,
13 generally without requiring a server restart for the changes
14 to take effect. The old style {{slapd.conf}}(5) file is still
15 supported, but must be converted to the new {{slapd-config}}(5) format
16 to allow runtime changes to be saved. While the old style
17 configuration uses a single file, normally installed as
18 {{F:/usr/local/etc/openldap/slapd.conf}}, the new style
19 uses a slapd backend database to store the configuration. The
20 configuration database normally resides in the
21 {{F:/usr/local/etc/openldap/slapd.d}} directory.
23 An alternate configuration directory (or file) can be specified via
24 a command-line option to {{slapd}}(8). This chapter describes the
25 general format of the configuration system, followed by a detailed
26 description of commonly used config settings.
28 Note: some of the backends and of the distributed overlays
29 do not support runtime configuration yet. In those cases,
30 the old style {{slapd.conf}}(5) file must be used.
32 Note: the current version of {{slurpd}} has not been updated for
33 compatibility with this new configuration engine. If you must use
34 slurpd for replication at your site, you will have to maintain an
35 old-style {{slapd.conf}} file for slurpd to use.
38 H2: Configuration Layout
40 The slapd configuration is stored as a special LDAP directory with
41 a predefined schema and DIT. There are specific objectClasses used to
42 carry global configuration options, schema definitions, backend and
43 database definitions, and assorted other items. A sample config tree
44 is shown in Figure 5.1.
46 !import "config_dit.gif"; align="center"; title="Sample configuration tree"
47 FT[align="Center"] Figure 5.1: Sample configuration tree.
49 Other objects may be part of the configuration but were omitted from
50 the illustration for clarity.
52 The {{slapd-config}} configuration tree has a very specific structure. The
53 root of the tree is named {{EX:cn=config}} and contains global configuration
54 settings. Additional settings are contained in separate child entries:
56 .. Usually these are just pathnames left over from a converted
57 {{EX:slapd.conf}} file.
58 .. Otherwise use of Include files is deprecated.
59 * Dynamically loaded modules
60 .. These may only be used if the {{EX:--enable-modules}} option was
61 used to configure the software.
63 .. The {{EX:cn=schema,cn=config}} entry contains the system schema (all
64 the schema that is hard-coded in slapd).
65 .. Child entries of {{EX:cn=schema,cn=config}} contain user schema as
66 loaded from config files or added at runtime.
67 * Backend-specific configuration
68 * Database-specific configuration
69 .. Overlays are defined in children of the Database entry.
70 .. Databases and Overlays may also have other miscellaneous children.
72 The usual rules for LDIF files apply to the configuration information:
73 Comment lines beginning with a '{{EX:#}}' character
74 are ignored. If a line begins with a single space, it is considered a
75 continuation of the previous line (even if the previous line is a
76 comment) and the single leading space is removed. Entries are separated by blank lines.
78 The general layout of the config LDIF is as follows:
80 > # global configuration settings
82 > objectClass: olcGlobal
84 > <global config settings>
86 > # schema definitions
87 > dn: cn=schema,cn=config
88 > objectClass: olcSchemaConfig
92 > dn: cn={X}core,cn=schema,cn=config
93 > objectClass: olcSchemaConfig
97 > # additional user-specified schema
100 > # backend definitions
101 > dn: olcBackend=<typeA>,cn=config
102 > objectClass: olcBackendConfig
103 > olcBackend: <typeA>
104 > <backend-specific settings>
106 > # database definitions
107 > dn: olcDatabase={X}<typeA>,cn=config
108 > objectClass: olcDatabaseConfig
109 > olcDatabase: {X}<typeA>
110 > <database-specific settings>
112 > # subsequent definitions and settings
115 Some of the entries listed above have a numeric index {{EX:"{X}"}} in
116 their names. While most configuration settings have an inherent ordering
117 dependency (i.e., one setting must take effect before a subsequent one
118 may be set), LDAP databases are inherently unordered. The numeric index
119 is used to enforce a consistent ordering in the configuration database,
120 so that all ordering dependencies are preserved. In most cases the index
121 does not have to be provided; it will be automatically generated based
122 on the order in which entries are created.
124 Configuration directives are specified as values of individual
126 Most of the attributes and objectClasses used in the slapd
127 configuration have a prefix of {{EX:"olc"}} (OpenLDAP Configuration)
128 in their names. Generally there is a one-to-one correspondence
129 between the attributes and the old-style {{EX:slapd.conf}} configuration
130 keywords, using the keyword as the attribute name, with the "olc"
133 A configuration directive may take arguments. If so, the arguments are
134 separated by white space. If an argument contains white space,
135 the argument should be enclosed in double quotes {{EX:"like this"}}.
136 In the descriptions that follow, arguments that should be replaced
137 by actual text are shown in brackets {{EX:<>}}.
139 The distribution contains an example configuration file that will
140 be installed in the {{F: /usr/local/etc/openldap}} directory.
141 A number of files containing schema definitions (attribute types
142 and object classes) are also provided in the
143 {{F: /usr/local/etc/openldap/schema}} directory.
146 H2: Configuration Directives
148 This section details commonly used configuration directives. For
149 a complete list, see the {{slapd-config}}(5) manual page. This section
150 will treat the configuration directives in a top-down order, starting
151 with the global directives in the {{EX:cn=config}} entry. Each
152 directive will be described along with its default value (if any) and
153 an example of its use.
158 Directives contained in this entry generally apply to the server as a whole.
159 Most of them are system or connection oriented, not database related. This
160 entry must have the {{EX:olcGlobal}} objectClass.
163 H4: olcIdleTimeout: <integer>
165 Specify the number of seconds to wait before forcibly closing
166 an idle client connection. A value of 0, the default,
167 disables this feature.
170 H4: olcLogLevel: <level>
172 This directive specifies the level at which debugging statements
173 and operation statistics should be syslogged (currently logged to
174 the {{syslogd}}(8) {{EX:LOG_LOCAL4}} facility). You must have
175 configured OpenLDAP {{EX:--enable-debug}} (the default) for this
176 to work (except for the two statistics levels, which are always
177 enabled). Log levels may be specified as integers or by keyword.
178 Multiple log levels may be used and the levels are additive.
179 To display what levels
180 correspond to what kind of debugging, invoke slapd with {{EX:-?}}
181 or consult the table below. The possible values for <level> are:
183 !block table; colaligns="RL"; align=Center; \
184 title="Table 5.1: Debugging Levels"
185 Level Keyword Description
186 -1 Any enable all debugging
188 1 Trace trace function calls
189 2 Packets debug packet handling
190 4 Args heavy trace debugging
191 8 Conns connection management
192 16 BER print out packets sent and received
193 32 Filter search filter processing
194 64 Config configuration processing
195 128 ACL access control list processing
196 256 Stats stats log connections/operations/results
197 512 Stats2 stats log entries sent
198 1024 Shell print communication with shell backends
199 2048 Parse print entry parsing debugging
200 4096 Cache database cache processing
201 8192 Index database indexing
202 16384 Sync syncrepl consumer processing
209 This will cause lots and lots of debugging information to be
212 E: olcLogLevel: Conns Filter
214 Just log the connection and search filter processing.
218 E: olcLogLevel: Stats
221 H4: olcReferral <URI>
223 This directive specifies the referral to pass back when slapd
224 cannot find a local database to handle a request.
228 > olcReferral: ldap://root.openldap.org
230 This will refer non-local queries to the global root LDAP server
231 at the OpenLDAP Project. Smart LDAP clients can re-ask their
232 query at that server, but note that most of these clients are
233 only going to know how to handle simple LDAP URLs that
234 contain a host part and optionally a distinguished name part.
240 >objectClass: olcGlobal
244 >olcReferral: ldap://root.openldap.org
250 An include entry holds the pathname of one include file. Include files
251 are part of the old style slapd.conf configuration system and must be in
252 slapd.conf format. Include files were commonly used to load schema
253 specifications. While they are still supported, their use is deprecated.
254 Include entries must have the {{EX:olcIncludeFile}} objectClass.
257 H4: olcInclude: <filename>
259 This directive specifies that slapd should read additional
260 configuration information from the given file.
262 Note: You should be careful when using this directive - there is
263 no small limit on the number of nested include directives, and no
264 loop detection is done.
269 >dn: cn=include{0},cn=config
270 >objectClass: olcIncludeFile
272 >olcInclude: ./schema/core.schema
274 >dn: cn=include{1},cn=config
275 >objectClass: olcIncludeFile
277 >olcInclude: ./schema/cosine.schema
282 If support for dynamically loaded modules was enabled when configuring
283 slapd, {{EX:cn=module}} entries may be used to specify sets of modules to load.
284 Module entries must have the {{EX:olcModuleList}} objectClass.
287 H4: olcModuleLoad: <filename>
289 Specify the name of a dynamically loadable module to load. The filename
290 may be an absolute path name or a simple filename. Non-absolute names
291 are searched for in the directories specified by the {{EX:olcModulePath}}
295 H4: olcModulePath: <pathspec>
297 Specify a list of directories to search for loadable modules. Typically the
298 path is colon-separated but this depends on the operating system.
303 >dn: cn=module{0},cn=config
304 >objectClass: olcModuleList
306 >olcModuleLoad: /usr/local/lib/smbk5pwd.la
308 >dn: cn=module{1},cn=config
309 >objectClass: olcModuleList
311 >olcModulePath: /usr/local/lib:/usr/local/lib/slapd
312 >olcModuleLoad: accesslog.la
313 >olcModuleLoad: pcache.la
318 The cn=schema entry holds all of the schema definitions that are hard-coded
319 in slapd. As such, the values in this entry are generated by slapd so no
320 schema values need to be provided in the config file. The entry must still
321 be defined though, to serve as a base for the user-defined schema to add
322 in underneath. Schema entries must have the {{EX:olcSchemaConfig}}
326 H4: olcAttributeTypes: <{{REF:RFC4512}} Attribute Type Description>
328 This directive defines an attribute type.
329 Please see the {{SECT:Schema Specification}} chapter
330 for information regarding how to use this directive.
333 H4: olcObjectClasses: <{{REF:RFC4512}} Object Class Description>
335 This directive defines an object class.
336 Please see the {{SECT:Schema Specification}} chapter for
337 information regarding how to use this directive.
342 >dn: cn=schema,cn=config
343 >objectClass: olcSchemaConfig
346 >dn: cn=test,cn=schema,cn=config
347 >objectClass: olcSchemaConfig
349 >olcAttributeTypes: ( 1.1.1
351 > EQUALITY integerMatch
352 > SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 )
353 >olcAttributeTypes: ( 1.1.2 NAME 'testTwo' EQUALITY caseIgnoreMatch
354 > SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.44 )
355 >olcObjectClasses: ( 1.1.3 NAME 'testObject'
356 > MAY ( testAttr $ testTwo ) AUXILIARY )
359 H3: Backend-specific Directives
361 Backend directives apply to all database instances of the
362 same type and, depending on the directive, may be overridden
363 by database directives. Backend entries must have the
364 {{EX:olcBackendConfig}} objectClass.
366 H4: olcBackend: <type>
368 This directive names a backend-specific configuration entry.
369 {{EX:<type>}} should be one of the
370 supported backend types listed in Table 5.2.
372 !block table; align=Center; coltags="EX,N"; \
373 title="Table 5.2: Database Backends"
375 bdb Berkeley DB transactional backend
376 config Slapd configuration backend
377 dnssrv DNS SRV backend
378 hdb Hierarchical variant of bdb backend
379 ldap Lightweight Directory Access Protocol (Proxy) backend
380 ldif Lightweight Data Interchange Format backend
381 meta Meta Directory backend
382 monitor Monitor backend
383 passwd Provides read-only access to {{passwd}}(5)
384 perl Perl Programmable backend
385 shell Shell (extern program) backend
386 sql SQL Programmable backend
393 There are no other directives defined for this entry. Specific backend
394 types may define additional attributes for their particular use but so
395 far none have ever been defined. As such, these directives usually do
396 not appear in any actual configurations.
401 > dn: olcBackend=bdb,cn=config
402 > objectClass: olcBackendConfig
406 H3: Database-specific Directives
408 Directives in this section are supported by every type of database.
409 Database entries must have the {{EX:olcDatabaseConfig}} objectClass.
411 H4: olcDatabase: [{<index>}]<type>
413 This directive names a specific database instance. The numeric {<index>} may
414 be provided to distinguish multiple databases of the same type. Usually the
415 index can be omitted, and slapd will generate it automatically.
416 {{EX:<type>}} should be one of the
417 supported backend types listed in Table 5.2 or the {{EX:frontend}} type.
419 The {{EX:frontend}} is a special database that is used to hold
420 database-level options that should be applied to all the other
421 databases. Subsequent database definitions may also override some
424 The {{EX:config}} database is also special; both the {{EX:config}} and
425 the {{EX:frontend}} databases are always created implicitly even if they
426 are not explicitly configured, and they are created before any other
433 This marks the beginning of a new {{TERM:BDB}} database instance.
436 H4: olcAccess: to <what> [ by <who> [<accesslevel>] [<control>] ]+
438 This directive grants access (specified by <accesslevel>) to a
439 set of entries and/or attributes (specified by <what>) by one or
440 more requesters (specified by <who>).
441 See the {{SECT:Access Control}} section of this chapter for a
442 summary of basic usage.
445 More detailed discussion of this directive can be found in the
446 {{SECT:Advanced Access Control}} chapter.
449 Note: If no {{EX:olcAccess}} directives are specified, the default
450 access control policy, {{EX:to * by * read}}, allows all
451 users (both authenticated and anonymous) read access.
453 Note: Access controls defined in the frontend are appended to all
454 other databases' controls.
457 H4: olcReadonly { TRUE | FALSE }
459 This directive puts the database into "read-only" mode. Any
460 attempts to modify the database will return an "unwilling to
470 > olcReplica: uri=ldap[s]://<hostname>[:<port>] | host=<hostname>[:<port>]
471 > [bindmethod={simple|sasl}]
474 > [authcid=<identity>]
475 > [authzid=<identity>]
476 > [credentials=<password>]
478 This directive specifies a replication site for this database for
480 {{EX:uri=}} parameter specifies a scheme, a host and optionally a port where
481 the slave slapd instance can be found. Either a domain name
482 or IP address may be used for <hostname>. If <port> is not
483 given, the standard LDAP port number (389 or 636) is used.
485 {{EX:host}} is deprecated in favor of the {{EX:uri}} parameter.
487 {{EX:uri}} allows the replica LDAP server to be specified as an LDAP
488 URI such as {{EX:ldap://slave.example.com:389}} or
489 {{EX:ldaps://slave.example.com:636}}.
491 The {{EX:binddn=}} parameter gives the DN to bind as for updates
492 to the slave slapd. It should be a DN which has read/write access
493 to the slave slapd's database. It must also match the {{EX:updatedn}}
494 directive in the slave slapd's config file. Generally, this DN
495 {{should not}} be the same as the {{EX:rootdn}} of the master
496 database. Since DNs are likely to contain embedded spaces, the
497 entire {{EX:"binddn=<DN>"}} string should be enclosed in double
500 The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}},
501 depending on whether simple password-based authentication
502 or {{TERM:SASL}} authentication is to be used when connecting
505 Simple authentication should not be used unless adequate data
506 integrity and confidentiality protections are in place (e.g. TLS
507 or IPSEC). Simple authentication requires specification of
508 {{EX:binddn}} and {{EX:credentials}} parameters.
510 SASL authentication is generally recommended. SASL authentication
511 requires specification of a mechanism using the {{EX:saslmech}} parameter.
512 Depending on the mechanism, an authentication identity and/or
513 credentials can be specified using {{EX:authcid}} and {{EX:credentials}}
514 respectively. The {{EX:authzid}} parameter may be used to specify
515 an authorization identity.
517 See the chapter entitled {{SECT:Replication with slurpd}} for more
518 information on how to use this directive.
521 H4: olcReplogfile: <filename>
523 This directive specifies the name of the replication log file to
524 which slapd will log changes. The replication log is typically
525 written by {{slapd}}(8) and read by {{slurpd}}(8). Normally, this
526 directive is only used if {{slurpd}}(8) is being used to replicate
527 the database. However, you can also use it to generate a transaction
528 log, if {{slurpd}}(8) is not running. In this case, you will need to
529 periodically truncate the file, since it will grow indefinitely
532 See the chapter entitled {{SECT:Replication with slurpd}} for more
533 information on how to use this directive.
538 This directive specifies the DN that is not subject to
539 access control or administrative limit restrictions for
540 operations on this database. The DN need not refer to
541 an entry in this database or even in the directory. The
542 DN may refer to a SASL identity.
546 > olcRootDN: "cn=Manager,dc=example,dc=com"
550 > olcRootDN: "uid=root,cn=example.com,cn=digest-md5,cn=auth"
552 See the {{SECT:SASL Authentication}} section for information on
553 SASL authentication identities.
556 H4: olcRootPW: <password>
558 This directive can be used to specify a password for the DN for
559 the rootdn (when the rootdn is set to a DN within the database).
565 It is also permissible to provide a hash of the password in
566 {{REF:RFC2307}} form. {{slappasswd}}(8) may be used to generate
571 > olcRootPW: {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
573 The hash was generated using the command {{EX:slappasswd -s secret}}.
576 H4: olcSizeLimit: <integer>
578 This directive specifies the maximum number of entries to return
579 from a search operation.
587 H4: olcSuffix: <dn suffix>
589 This directive specifies the DN suffix of queries that will be
590 passed to this backend database. Multiple suffix lines can be
591 given, and usually at least one is required for each database
592 definition. (Some backend types, such as {{EX:frontend}} and
593 {{EX:monitor}} use a hard-coded suffix which may not be overridden
594 in the configuration.)
598 > olcSuffix: "dc=example,dc=com"
600 Queries with a DN ending in "dc=example,dc=com"
601 will be passed to this backend.
603 Note: When the backend to pass a query to is selected, slapd
604 looks at the suffix value(s) in each database definition in the
605 order in which they were configured. Thus, if one database suffix is a
606 prefix of another, it must appear after it in the configuration.
611 > olcSyncrepl: rid=<replica ID>
612 > provider=ldap[s]://<hostname>[:port]
613 > [type=refreshOnly|refreshAndPersist]
614 > [interval=dd:hh:mm:ss]
615 > [retry=[<retry interval> <# of retries>]+]
616 > [searchbase=<base DN>]
617 > [filter=<filter str>]
618 > [scope=sub|one|base]
619 > [attrs=<attr list>]
621 > [sizelimit=<limit>]
622 > [timelimit=<limit>]
623 > [schemachecking=on|off]
624 > [bindmethod=simple|sasl]
627 > [authcid=<identity>]
628 > [authzid=<identity>]
629 > [credentials=<passwd>]
631 > [secprops=<properties>]
634 This directive specifies the current database as a replica of the
635 master content by establishing the current {{slapd}}(8) as a
636 replication consumer site running a syncrepl replication engine.
637 The master database is located at the replication provider site
638 specified by the {{EX:provider}} parameter. The replica database is
639 kept up-to-date with the master content using the LDAP Content
640 Synchronization protocol. See {{REF:RFC4533}}
641 for more information on the protocol.
643 The {{EX:rid}} parameter is used for identification of the current
644 {{EX:syncrepl}} directive within the replication consumer server,
645 where {{EX:<replica ID>}} uniquely identifies the syncrepl specification
646 described by the current {{EX:syncrepl}} directive. {{EX:<replica ID>}}
647 is non-negative and is no more than three decimal digits in length.
649 The {{EX:provider}} parameter specifies the replication provider site
650 containing the master content as an LDAP URI. The {{EX:provider}}
651 parameter specifies a scheme, a host and optionally a port where the
652 provider slapd instance can be found. Either a domain name or IP
653 address may be used for <hostname>. Examples are
654 {{EX:ldap://provider.example.com:389}} or {{EX:ldaps://192.168.1.1:636}}.
655 If <port> is not given, the standard LDAP port number (389 or 636) is used.
656 Note that the syncrepl uses a consumer-initiated protocol, and hence its
657 specification is located at the consumer site, whereas the {{EX:replica}}
658 specification is located at the provider site. {{EX:syncrepl}} and
659 {{EX:replica}} directives define two independent replication
660 mechanisms. They do not represent the replication peers of each other.
662 The content of the syncrepl replica is defined using a search
663 specification as its result set. The consumer slapd will
664 send search requests to the provider slapd according to the search
665 specification. The search specification includes {{EX:searchbase}},
666 {{EX:scope}}, {{EX:filter}}, {{EX:attrs}}, {{EX:attrsonly}},
667 {{EX:sizelimit}}, and {{EX:timelimit}} parameters as in the normal
668 search specification. The {{EX:searchbase}} parameter has no
669 default value and must always be specified. The {{EX:scope}} defaults
670 to {{EX:sub}}, the {{EX:filter}} defaults to {{EX:(objectclass=*)}},
671 {{EX:attrs}} defaults to {{EX:"*,+"}} to replicate all user and operational
672 attributes, and {{EX:attrsonly}} is unset by default. Both {{EX:sizelimit}}
673 and {{EX:timelimit}} default to "unlimited", and only positive integers
674 or "unlimited" may be specified.
676 The LDAP Content Synchronization protocol has two operation
677 types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}.
678 The operation type is specified by the {{EX:type}} parameter.
679 In the {{EX:refreshOnly}} operation, the next synchronization search operation
680 is periodically rescheduled at an interval time after each
681 synchronization operation finishes. The interval is specified
682 by the {{EX:interval}} parameter. It is set to one day by default.
683 In the {{EX:refreshAndPersist}} operation, a synchronization search
684 remains persistent in the provider slapd. Further updates to the
685 master replica will generate {{EX:searchResultEntry}} to the consumer slapd
686 as the search responses to the persistent synchronization search.
688 If an error occurs during replication, the consumer will attempt to reconnect
689 according to the retry parameter which is a list of the <retry interval>
690 and <# of retries> pairs. For example, retry="60 10 300 3" lets the consumer
691 retry every 60 seconds for the first 10 times and then retry every 300 seconds
692 for the next three times before stop retrying. + in <# of retries> means
693 indefinite number of retries until success.
695 The schema checking can be enforced at the LDAP Sync consumer site
696 by turning on the {{EX:schemachecking}} parameter.
697 If it is turned on, every replicated entry will be checked for its
698 schema as the entry is stored into the replica content.
699 Every entry in the replica should contain those attributes
700 required by the schema definition.
701 If it is turned off, entries will be stored without checking
702 schema conformance. The default is off.
704 The {{EX:binddn}} parameter gives the DN to bind as for the
705 syncrepl searches to the provider slapd. It should be a DN
706 which has read access to the replication content in the
709 The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}},
710 depending on whether simple password-based authentication or
711 {{TERM:SASL}} authentication is to be used when connecting
712 to the provider slapd.
714 Simple authentication should not be used unless adequate data
715 integrity and confidentiality protections are in place (e.g. TLS
716 or IPSEC). Simple authentication requires specification of {{EX:binddn}}
717 and {{EX:credentials}} parameters.
719 SASL authentication is generally recommended. SASL authentication
720 requires specification of a mechanism using the {{EX:saslmech}} parameter.
721 Depending on the mechanism, an authentication identity and/or
722 credentials can be specified using {{EX:authcid}} and {{EX:credentials}},
723 respectively. The {{EX:authzid}} parameter may be used to specify
724 an authorization identity.
726 The {{EX:realm}} parameter specifies a realm which a certain
727 mechanisms authenticate the identity within. The {{EX:secprops}}
728 parameter specifies Cyrus SASL security properties.
730 The syncrepl replication mechanism is supported by the
731 two native backends: back-bdb and back-hdb.
733 See the {{SECT:LDAP Sync Replication}} chapter of the admin guide
734 for more information on how to use this directive.
737 H4: olcTimeLimit: <integer>
739 This directive specifies the maximum number of seconds (in real
740 time) slapd will spend answering a search request. If a
741 request is not finished in this time, a result indicating an
742 exceeded timelimit will be returned.
749 H4: olcUpdateDN: <DN>
751 This directive is only applicable in a slave slapd. It specifies
752 the DN allowed to make changes to the replica. This may be the DN
753 {{slurpd}}(8) binds as when making changes to the replica or the DN
754 associated with a SASL identity.
758 > olcUpdateDN: "cn=Update Daemon,dc=example,dc=com"
762 > olcUpdateDN: "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
764 See the {{SECT:Replication with slurpd}} chapter for more information
765 on how to use this directive.
767 H4: olcUpdateref: <URL>
769 This directive is only applicable in a slave slapd. It
770 specifies the URL to return to clients which submit update
771 requests upon the replica.
772 If specified multiple times, each {{TERM:URL}} is provided.
776 > olcUpdateref: ldap://master.example.net
781 >dn: olcDatabase=frontend,cn=config
782 >objectClass: olcDatabaseConfig
783 >objectClass: olcFrontendConfig
784 >olcDatabase: frontend
787 >dn: olcDatabase=config,cn=config
788 >objectClass: olcDatabaseConfig
790 >olcRootDN: cn=Manager,dc=example,dc=com
793 H3: BDB and HDB Database Directives
795 Directives in this category apply to both the {{TERM:BDB}}
796 and the {{TERM:HDB}} database.
797 They are used in an olcDatabase entry in addition to the generic
798 database directives defined above. For a complete reference
799 of BDB/HDB configuration directives, see {{slapd-bdb}}(5). In
800 addition to the {{EX:olcDatabaseConfig}} objectClass, BDB and HDB
801 database entries must have the {{EX:olcBdbConfig}} and
802 {{EX:olcHdbConfig}} objectClass, respectively.
805 H4: olcDbDirectory: <directory>
807 This directive specifies the directory where the BDB files
808 containing the database and associated indices live.
812 > olcDbDirectory: /usr/local/var/openldap-data
815 H4: olcDbCachesize: <integer>
817 This directive specifies the size in entries of the in-memory
818 cache maintained by the BDB backend database instance.
822 > olcDbCachesize: 1000
825 H4: olcDbCheckpoint: <kbyte> <min>
827 This directive specifies how often to checkpoint the BDB transaction log.
828 A checkpoint operation flushes the database buffers to disk and writes a
829 checkpoint record in the log.
830 The checkpoint will occur if either <kbyte> data has been written or
831 <min> minutes have passed since the last checkpont. Both arguments default
832 to zero, in which case they are ignored. When the <min> argument is
833 non-zero, an internal task will run every <min> minutes to perform the
834 checkpoint. See the Berkeley DB reference guide for more details.
838 > olcDbCheckpoint: 1024 10
841 H4: olcDbConfig: <DB_CONFIG setting>
843 This attribute specifies a configuration directive to be placed in the
844 {{EX:DB_CONFIG}} file of the database directory. At server startup time, if
845 no such file exists yet, the {{EX:DB_CONFIG}} file will be created and the
846 settings in this attribute will be written to it. If the file exists,
847 its contents will be read and displayed in this attribute. The attribute
848 is multi-valued, to accomodate multiple configuration directives. No default
849 is provided, but it is essential to use proper settings here to get the
850 best server performance.
854 > olcDbConfig: set_cachesize 0 10485760 0
855 > olcDbConfig: set_lg_bsize 2097512
856 > olcDbConfig: set_lg_dir /var/tmp/bdb-log
857 > olcDbConfig: set_flags DB_LOG_AUTOREMOVE
859 In this example, the BDB cache is set to 10MB, the BDB transaction log
860 buffer size is set to 2MB, and the transaction log files are to be stored
861 in the /var/tmp/bdb-log directory. Also a flag is set to tell BDB to
862 delete transaction log files as soon as their contents have been
863 checkpointed and they are no longer needed. Without this setting the
864 transaction log files will continue to accumulate until some other
865 cleanup procedure removes them. See the SleepyCat documentation for the
866 {{EX:db_archive}} command for details.
868 Ideally the BDB cache must be
869 at least as large as the working set of the database, the log buffer size
870 should be large enough to accomodate most transactions without overflowing,
871 and the log directory must be on a separate physical disk from the main
872 database files. And both the database directory and the log directory
873 should be separate from disks used for regular system activities such as
874 the root, boot, or swap filesystems. See the FAQ-o-Matic and the SleepyCat
875 documentation for more details.
878 H4: olcDbNosync: { TRUE | FALSE }
880 This option causes on-disk database contents to not be immediately
881 synchronized with in memory changes upon change. Setting this option
882 to {{EX:TRUE}} may improve performance at the expense of data integrity. This
883 directive has the same effect as using
884 > olcDbConfig: set_flags DB_TXN_NOSYNC
887 H4: olcDbIDLcacheSize: <integer>
889 Specify the size of the in-memory index cache, in index slots. The
890 default is zero. A larger value will speed up frequent searches of
891 indexed entries. The optimal size will depend on the data and search
892 characteristics of the database, but using a number three times
893 the entry cache size is a good starting point.
897 > olcDbIDLcacheSize: 3000
900 H4: olcDbIndex: {<attrlist> | default} [pres,eq,approx,sub,none]
902 This directive specifies the indices to maintain for the given
903 attribute. If only an {{EX:<attrlist>}} is given, the default
904 indices are maintained.
908 > olcDbIndex: default pres,eq
910 > olcDbIndex: cn,sn pres,eq,sub
911 > olcDbIndex: objectClass eq
913 The first line sets the default set of indices to maintain to
914 present and equality. The second line causes the default (pres,eq)
915 set of indices to be maintained for the {{EX:uid}} attribute type.
916 The third line causes present, equality, and substring indices to
917 be maintained for {{EX:cn}} and {{EX:sn}} attribute types. The
918 fourth line causes an equality index for the {{EX:objectClass}}
921 By default, no indices are maintained. It is generally advised
922 that minimally an equality index upon objectClass be maintained.
924 > olcDbindex: objectClass eq
926 If this setting is changed while slapd is running, an internal task
927 will be run to generate the changed index data. All server operations
928 can continue as normal while the indexer does its work. If slapd is
929 stopped before the index task completes, indexing will have to be
930 manually completed using the slapindex tool.
933 H4: olcDbLinearIndex: { TRUE | FALSE }
935 If this setting is {{EX:TRUE}} slapindex will index one attribute
936 at a time. The default settings is {{EX:FALSE}} in which case all
937 indexed attributes of an entry are processed at the same time. When
938 enabled, each indexed attribute is processed individually, using
939 multiple passes through the entire database. This option improves
940 slapindex performance when the database size exceeds the BDB cache
941 size. When the BDB cache is large enough, this option is not needed
942 and will decrease performance. Also by default, slapadd performs
943 full indexing and so a separate slapindex run is not needed. With
944 this option, slapadd does no indexing and slapindex must be used.
947 H4: olcDbMode: <integer>
949 This directive specifies the file protection mode that newly
950 created database index files should have.
957 H4: olcDbSearchStack: <integer>
959 Specify the depth of the stack used for search filter evaluation.
960 Search filters are evaluated on a stack to accomodate nested {{EX:AND}} /
961 {{EX:OR}} clauses. An individual stack is allocated for each server thread.
962 The depth of the stack determines how complex a filter can be evaluated
963 without requiring any additional memory allocation. Filters that are
964 nested deeper than the search stack depth will cause a separate stack to
965 be allocated for that particular search operation. These separate allocations
966 can have a major negative impact on server performance, but specifying
967 too much stack will also consume a great deal of memory. Each search
968 uses 512K bytes per level on a 32-bit machine, or 1024K bytes per level
969 on a 64-bit machine. The default stack depth is 16, thus 8MB or 16MB
970 per thread is used on 32 and 64 bit machines, respectively. Also the
971 512KB size of a single stack slot is set by a compile-time constant which
972 may be changed if needed; the code must be recompiled for the change
977 > olcDbSearchStack: 16
980 H4: olcDbShmKey: <integer>
982 Specify a key for a shared memory BDB environment. By default the BDB
983 environment uses memory mapped files. If a non-zero value is specified,
984 it will be used as the key to identify a shared memory region that will
985 house the environment.
994 >dn: olcDatabase=hdb,cn=config
995 >objectClass: olcDatabaseConfig
996 >objectClass: olcHdbConfig
998 >olcSuffix: "dc=example,dc=com"
999 >olcDbDirectory: /usr/local/var/openldap-data
1000 >olcDbCacheSize: 1000
1001 >olcDbCheckpoint: 1024 10
1002 >olcDbConfig: set_cachesize 0 10485760 0
1003 >olcDbConfig: set_lg_bsize 2097152
1004 >olcDbConfig: set_lg_dir /var/tmp/bdb-log
1005 >olcDbConfig: set_flags DB_LOG_AUTOREMOVE
1006 >olcDbIDLcacheSize: 3000
1007 >olcDbIndex: objectClass eq
1012 Access to slapd entries and attributes is controlled by the
1013 olcAccess attribute, whose values are a sequence of access directives.
1014 The general form of the olcAccess configuration is:
1016 > olcAccess: <access directive>
1017 > <access directive> ::= to <what>
1018 > [by <who> [<access>] [<control>] ]+
1020 > [dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
1021 > [filter=<ldapfilter>] [attrs=<attrlist>]
1022 > <basic-style> ::= regex | exact
1023 > <scope-style> ::= base | one | subtree | children
1024 > <attrlist> ::= <attr> [val[.<basic-style>]=<regex>] | <attr> , <attrlist>
1025 > <attr> ::= <attrname> | entry | children
1026 > <who> ::= * | [anonymous | users | self
1027 > | dn[.<basic-style>]=<regex> | dn.<scope-style>=<DN>]
1028 > [dnattr=<attrname>]
1029 > [group[/<objectclass>[/<attrname>][.<basic-style>]]=<regex>]
1030 > [peername[.<basic-style>]=<regex>]
1031 > [sockname[.<basic-style>]=<regex>]
1032 > [domain[.<basic-style>]=<regex>]
1033 > [sockurl[.<basic-style>]=<regex>]
1036 > <access> ::= [self]{<level>|<priv>}
1037 > <level> ::= none | disclose | auth | compare | search | read | write | manage
1038 > <priv> ::= {=|+|-}{m|w|r|s|c|x|d|0}+
1039 > <control> ::= [stop | continue | break]
1041 where the <what> part selects the entries and/or attributes to which
1042 the access applies, the {{EX:<who>}} part specifies which entities
1043 are granted access, and the {{EX:<access>}} part specifies the
1044 access granted. Multiple {{EX:<who> <access> <control>}} triplets
1045 are supported, allowing many entities to be granted different access
1046 to the same set of entries and attributes. Not all of these access
1047 control options are described here; for more details see the
1048 {{slapd.access}}(5) man page.
1051 H3: What to control access to
1053 The <what> part of an access specification determines the entries
1054 and attributes to which the access control applies. Entries are
1055 commonly selected in two ways: by DN and by filter. The following
1056 qualifiers select entries by DN:
1059 > to dn[.<basic-style>]=<regex>
1060 > to dn.<scope-style>=<DN>
1062 The first form is used to select all entries. The second form may
1063 be used to select entries by matching a regular expression against
1064 the target entry's {{normalized DN}}. (The second form is not
1065 discussed further in this document.) The third form is used to
1066 select entries which are within the requested scope of DN. The
1067 <DN> is a string representation of the Distinguished Name, as
1068 described in {{REF:RFC4514}}.
1070 The scope can be either {{EX:base}}, {{EX:one}}, {{EX:subtree}},
1071 or {{EX:children}}. Where {{EX:base}} matches only the entry with
1072 provided DN, {{EX:one}} matches the entries whose parent is the
1073 provided DN, {{EX:subtree}} matches all entries in the subtree whose
1074 root is the provided DN, and {{EX:children}} matches all entries
1075 under the DN (but not the entry named by the DN).
1077 For example, if the directory contained entries named:
1080 > 1: cn=Manager,o=suffix
1081 > 2: ou=people,o=suffix
1082 > 3: uid=kdz,ou=people,o=suffix
1083 > 4: cn=addresses,uid=kdz,ou=people,o=suffix
1084 > 5: uid=hyc,ou=people,o=suffix
1087 . {{EX:dn.base="ou=people,o=suffix"}} match 2;
1088 . {{EX:dn.one="ou=people,o=suffix"}} match 3, and 5;
1089 . {{EX:dn.subtree="ou=people,o=suffix"}} match 2, 3, 4, and 5; and
1090 . {{EX:dn.children="ou=people,o=suffix"}} match 3, 4, and 5.
1093 Entries may also be selected using a filter:
1095 > to filter=<ldap filter>
1097 where <ldap filter> is a string representation of an LDAP
1098 search filter, as described in {{REF:RFC4515}}. For example:
1100 > to filter=(objectClass=person)
1102 Note that entries may be selected by both DN and filter by
1103 including both qualifiers in the <what> clause.
1105 > to dn.one="ou=people,o=suffix" filter=(objectClass=person)
1107 Attributes within an entry are selected by including a comma-separated
1108 list of attribute names in the <what> selector:
1110 > attrs=<attribute list>
1112 A specific value of an attribute is selected by using a single
1113 attribute name and also using a value selector:
1115 > attrs=<attribute> val[.<style>]=<regex>
1117 There are two special {{pseudo}} attributes {{EX:entry}} and
1118 {{EX:children}}. To read (and hence return) a target entry, the
1119 subject must have {{EX:read}} access to the target's {{entry}}
1120 attribute. To add or delete an entry, the subject must have
1121 {{EX:write}} access to the entry's {{EX:entry}} attribute AND must
1122 have {{EX:write}} access to the entry's parent's {{EX:children}}
1123 attribute. To rename an entry, the subject must have {{EX:write}}
1124 access to entry's {{EX:entry}} attribute AND have {{EX:write}}
1125 access to both the old parent's and new parent's {{EX:children}}
1126 attributes. The complete examples at the end of this section should
1127 help clear things up.
1129 Lastly, there is a special entry selector {{EX:"*"}} that is used to
1130 select any entry. It is used when no other {{EX:<what>}}
1131 selector has been provided. It's equivalent to "{{EX:dn=.*}}"
1134 H3: Who to grant access to
1136 The <who> part identifies the entity or entities being granted
1137 access. Note that access is granted to "entities" not "entries."
1138 The following table summarizes entity specifiers:
1140 !block table; align=Center; coltags="EX,N"; \
1141 title="Table 5.3: Access Entity Specifiers"
1143 *|All, including anonymous and authenticated users
1144 anonymous|Anonymous (non-authenticated) users
1145 users|Authenticated users
1146 self|User associated with target entry
1147 dn[.<basic-style>]=<regex>|Users matching a regular expression
1148 dn.<scope-style>=<DN>|Users within scope of a DN
1151 The DN specifier behaves much like <what> clause DN specifiers.
1153 Other control factors are also supported. For example, a {{EX:<who>}}
1154 can be restricted by an entry listed in a DN-valued attribute in
1155 the entry to which the access applies:
1157 > dnattr=<dn-valued attribute name>
1159 The dnattr specification is used to give access to an entry
1160 whose DN is listed in an attribute of the entry (e.g., give
1161 access to a group entry to whoever is listed as the owner of
1164 Some factors may not be appropriate in all environments (or any).
1165 For example, the domain factor relies on IP to domain name lookups.
1166 As these can easily spoofed, the domain factor should not be avoided.
1169 H3: The access to grant
1171 The kind of <access> granted can be one of the following:
1173 !block table; colaligns="LRL"; coltags="EX,EX,N"; align=Center; \
1174 title="Table 5.4: Access Levels"
1175 Level Privileges Description
1177 disclose =d needed for information disclosure on error
1178 auth =dx needed to authenticate (bind)
1179 compare =cdx needed to compare
1180 search =scdx needed to apply search filters
1181 read =rscdx needed to read search results
1182 write =wrscdx needed to modify/rename
1183 manage =mwrscdx needed to manage
1186 Each level implies all lower levels of access. So, for example,
1187 granting someone {{EX:write}} access to an entry also grants them
1188 {{EX:read}}, {{EX:search}}, {{EX:compare}}, {{EX:auth}} and
1189 {{EX:disclose}} access. However, one may use the privileges specifier
1190 to grant specific permissions.
1193 H3: Access Control Evaluation
1195 When evaluating whether some requester should be given access to
1196 an entry and/or attribute, slapd compares the entry and/or attribute
1197 to the {{EX:<what>}} selectors given in the configuration. For
1198 each entry, access controls provided in the database which holds
1199 the entry (or the first database if not held in any database) apply
1200 first, followed by the global access directives (which are held in
1201 the {{EX:frontend}} database definition). Within this priority,
1202 access directives are examined in the order in which they appear
1203 in the configuration attribute. Slapd stops with the first
1204 {{EX:<what>}} selector that matches the entry and/or attribute. The
1205 corresponding access directive is the one slapd will use to evaluate
1208 Next, slapd compares the entity requesting access to the {{EX:<who>}}
1209 selectors within the access directive selected above in the order
1210 in which they appear. It stops with the first {{EX:<who>}} selector
1211 that matches the requester. This determines the access the entity
1212 requesting access has to the entry and/or attribute.
1214 Finally, slapd compares the access granted in the selected
1215 {{EX:<access>}} clause to the access requested by the client. If
1216 it allows greater or equal access, access is granted. Otherwise,
1219 The order of evaluation of access directives makes their placement
1220 in the configuration file important. If one access directive is
1221 more specific than another in terms of the entries it selects, it
1222 should appear first in the configuration. Similarly, if one {{EX:<who>}}
1223 selector is more specific than another it should come first in the
1224 access directive. The access control examples given below should
1225 help make this clear.
1229 H3: Access Control Examples
1231 The access control facility described above is quite powerful. This
1232 section shows some examples of its use for descriptive purposes.
1236 > olcAccess: to * by * read
1238 This access directive grants read access to everyone.
1245 This directive allows the user to modify their entry, allows anonymous
1246 to authenticate against these entries, and allows all others to
1247 read these entries. Note that only the first {{EX:by <who>}} clause
1248 which matches applies. Hence, the anonymous users are granted
1249 {{EX:auth}}, not {{EX:read}}. The last clause could just as well
1250 have been "{{EX:by users read}}".
1252 It is often desirable to restrict operations based upon the level
1253 of protection in place. The following shows how security strength
1254 factors (SSF) can be used.
1257 > by ssf=128 self write
1258 > by ssf=64 anonymous auth
1259 > by ssf=64 users read
1261 This directive allows users to modify their own entries if security
1262 protections of strength 128 or better have been established,
1263 allows authentication access to anonymous users, and read access
1264 when strength 64 or better security protections have been established. If
1265 the client has not establish sufficient security protections, the
1266 implicit {{EX:by * none}} clause would be applied.
1268 The following example shows the use of style specifiers to select
1269 the entries by DN in two access directives where ordering is
1272 > olcAccess: to dn.children="dc=example,dc=com"
1274 > olcAccess: to dn.children="dc=com"
1277 Read access is granted to entries under the {{EX:dc=com}} subtree,
1278 except for those entries under the {{EX:dc=example,dc=com}} subtree,
1279 to which search access is granted. No access is granted to
1280 {{EX:dc=com}} as neither access directive matches this DN. If the
1281 order of these access directives was reversed, the trailing directive
1282 would never be reached, since all entries under {{EX:dc=example,dc=com}}
1283 are also under {{EX:dc=com}} entries.
1285 Also note that if no {{EX:olcAccess: to}} directive matches or no {{EX:by
1286 <who>}} clause, {{B:access is denied}}. That is, every {{EX:olcAccess:
1287 to}} directive ends with an implicit {{EX:by * none}} clause and
1288 every access list ends with an implicit {{EX:olcAccess: to * by * none}}
1291 The next example again shows the importance of ordering, both of
1292 the access directives and the {{EX:by <who>}} clauses. It also
1293 shows the use of an attribute selector to grant access to a specific
1294 attribute and various {{EX:<who>}} selectors.
1296 > olcAccess: to dn.subtree="dc=example,dc=com" attr=homePhone
1298 > by dn.children=dc=example,dc=com" search
1299 > by peername.regex=IP:10\..+ read
1300 > olcAccess: to dn.subtree="dc=example,dc=com"
1302 > by dn.children="dc=example,dc=com" search
1305 This example applies to entries in the "{{EX:dc=example,dc=com}}"
1306 subtree. To all attributes except {{EX:homePhone}}, an entry can
1307 write to itself, entries under {{EX:example.com}} entries can search
1308 by them, anybody else has no access (implicit {{EX:by * none}})
1309 excepting for authentication/authorization (which is always done
1310 anonymously). The {{EX:homePhone}} attribute is writable by the
1311 entry, searchable by entries under {{EX:example.com}}, readable by
1312 clients connecting from network 10, and otherwise not readable
1313 (implicit {{EX:by * none}}). All other access is denied by the
1314 implicit {{EX:access to * by * none}}.
1316 Sometimes it is useful to permit a particular DN to add or
1317 remove itself from an attribute. For example, if you would like to
1318 create a group and allow people to add and remove only
1319 their own DN from the member attribute, you could accomplish
1320 it with an access directive like this:
1322 > olcAccess: to attr=member,entry
1323 > by dnattr=member selfwrite
1325 The dnattr {{EX:<who>}} selector says that the access applies to
1326 entries listed in the {{EX:member}} attribute. The {{EX:selfwrite}} access
1327 selector says that such members can only add or delete their
1328 own DN from the attribute, not other values. The addition of
1329 the entry attribute is required because access to the entry is
1330 required to access any of the entry's attributes.
1334 H3: Access Control Ordering
1336 Since the ordering of {{EX:olcAccess}} directives is essential to their
1337 proper evaluation, but LDAP attributes normally do not preserve the
1338 ordering of their values, OpenLDAP uses a custom schema extension to
1339 maintain a fixed ordering of these values. This ordering is maintained
1340 by prepending a {{EX:"{X}"}} numeric index to each value, similarly to
1341 the approach used for ordering the configuration entries. These index
1342 tags are maintained automatically by slapd and do not need to be specified
1343 when originally defining the values. For example, when you create the
1346 > olcAccess: to attr=member,entry
1347 > by dnattr=member selfwrite
1348 > olcAccess: to dn.children="dc=example,dc=com"
1350 > olcAccess: to dn.children="dc=com"
1353 when you read them back using slapcat or ldapsearch they will contain
1355 > olcAccess: {0}to attr=member,entry
1356 > by dnattr=member selfwrite
1357 > olcAccess: {1}to dn.children="dc=example,dc=com"
1359 > olcAccess: {2}to dn.children="dc=com"
1362 The numeric index may be used to specify a particular value to change
1363 when using ldapmodify to edit the access rules. This index can be used
1364 instead of (or in addition to) the actual access value. Using this
1365 numeric index is very helpful when multiple access rules are being managed.
1367 For example, if we needed to change the second rule above to grant
1368 write access instead of search, we could try this LDIF:
1370 > changetype: modify
1372 > olcAccess: to dn.children="dc=example,dc=com" by * search
1375 > olcAccess: to dn.children="dc=example,dc=com" by * write
1378 But this example {{B:will not}} guarantee that the existing values remain in
1379 their original order, so it will most likely yield a broken security
1380 configuration. Instead, the numeric index should be used:
1382 > changetype: modify
1387 > olcAccess: {1}to dn.children="dc=example,dc=com" by * write
1390 This example deletes whatever rule is in value #1 of the {{EX:olcAccess}}
1391 attribute (regardless of its value) and adds a new value that is
1392 explicitly inserted as value #1. The result will be
1394 > olcAccess: {0}to attr=member,entry
1395 > by dnattr=member selfwrite
1396 > olcAccess: {1}to dn.children="dc=example,dc=com"
1398 > olcAccess: {2}to dn.children="dc=com"
1401 which is exactly what was intended.
1404 For more details on how to use the {{EX:access}} directive,
1405 consult the {{Advanced Access Control}} chapter.
1409 H2: Configuration Example
1411 The following is an example configuration, interspersed
1412 with explanatory text. It defines two databases to handle
1413 different parts of the {{TERM:X.500}} tree; both are {{TERM:BDB}}
1414 database instances. The line numbers shown are provided for
1415 reference only and are not included in the actual file. First, the
1416 global configuration section:
1418 E: 1. # example config file - global configuration entry
1420 E: 3. objectClass: olcGlobal
1422 E: 5. olcReferral: ldap://root.openldap.org
1425 Line 1 is a comment. Lines 2-4 identify this as the global
1426 configuration entry.
1427 The {{EX:olcReferral:}} directive on line 5
1428 means that queries not local to one of the databases defined
1429 below will be referred to the LDAP server running on the
1430 standard port (389) at the host {{EX:root.openldap.org}}.
1431 Line 6 is a blank line, indicating the end of this entry.
1433 E: 7. # internal schema
1434 E: 8. dn: cn=schema,cn=config
1435 E: 9. objectClass: olcSchemaConfig
1439 Line 7 is a comment. Lines 8-10 identify this as the root of
1440 the schema subtree. The actual schema definitions in this entry
1441 are hardcoded into slapd so no additional attributes are specified here.
1442 Line 11 is a blank line, indicating the end of this entry.
1444 E: 12. # include the core schema
1445 E: 13. include: file:///usr/local/etc/openldap/schema/core.ldif
1448 Line 12 is a comment. Line 13 is an LDIF include directive which
1449 accesses the {{core}} schema definitions in LDIF format. Line 14
1452 Next comes the database definitions. The first database is the
1453 special {{EX:frontend}} database whose settings are applied globally
1454 to all the other databases.
1456 E: 15. # global database parameters
1457 E: 16. dn: olcDatabase=frontend,cn=config
1458 E: 17. objectClass: olcDatabaseConfig
1459 E: 18. olcDatabase: frontend
1460 E: 19. olcAccess: to * by * read
1463 Line 15 is a comment. Lines 16-18 identify this entry as the global
1464 database entry. Line 19 is a global access control. It applies to all
1465 entries (after any applicable database-specific access controls).
1467 The next entry defines a BDB backend that will handle queries for things
1468 in the "dc=example,dc=com" portion of the tree. Indices are to be maintained
1469 for several attributes, and the {{EX:userPassword}} attribute is to be
1470 protected from unauthorized access.
1472 E: 21. # BDB definition for example.com
1473 E: 22. dn: olcDatabase=bdb,cn=config
1474 E: 23. objectClass: olcDatabaseConfig
1475 E: 24. objectClass: olcBdbConfig
1476 E: 25. olcDatabase: bdb
1477 E: 26. olcSuffix: "dc=example,dc=com"
1478 E: 27. olcDbDirectory: /usr/local/var/openldap-data
1479 E: 28. olcRootDN: "cn=Manager,dc=example,dc=com"
1480 E: 29. olcRootPW: secret
1481 E: 30. olcDbIndex: uid pres,eq
1482 E: 31. olcDbIndex: cn,sn,uid pres,eq,approx,sub
1483 E: 32. olcDbIndex: objectClass eq
1484 E: 33. olcAccess: to attr=userPassword
1485 E: 34. by self write
1486 E: 35. by anonymous auth
1487 E: 36. by dn.base="cn=Admin,dc=example,dc=com" write
1489 E: 38. olcAccess: to *
1490 E: 39. by self write
1491 E: 40. by dn.base="cn=Admin,dc=example,dc=com" write
1495 Line 21 is a comment. Lines 22-25 identify this entry as a BDB database
1496 configuration entry. Line 26 specifies the DN suffix
1497 for queries to pass to this database. Line 27 specifies the directory
1498 in which the database files will live.
1500 Lines 28 and 29 identify the database {{super-user}} entry and associated
1501 password. This entry is not subject to access control or size or
1502 time limit restrictions.
1504 Lines 30 through 32 indicate the indices to maintain for various
1507 Lines 33 through 41 specify access control for entries in this
1508 database. As this is the first database, the controls also apply
1509 to entries not held in any database (such as the Root DSE). For
1510 all applicable entries, the {{EX:userPassword}} attribute is writable
1511 by the entry itself and by the "admin" entry. It may be used for
1512 authentication/authorization purposes, but is otherwise not readable.
1513 All other attributes are writable by the entry and the "admin"
1514 entry, but may be read by all users (authenticated or not).
1516 Line 42 is a blank line, indicating the end of this entry.
1518 The next section of the example configuration file defines another
1519 BDB database. This one handles queries involving the
1520 {{EX:dc=example,dc=net}} subtree but is managed by the same entity
1521 as the first database. Note that without line 51, the read access
1522 would be allowed due to the global access rule at line 19.
1524 E: 42. # BDB definition for example.net
1525 E: 43. dn: olcDatabase=bdb,cn=config
1526 E: 44. objectClass: olcDatabaseConfig
1527 E: 45. objectClass: olcBdbConfig
1528 E: 46. olcDatabase: bdb
1529 E: 47. olcSuffix: "dc=example,dc=net"
1530 E: 48. olcDbDirectory: /usr/local/var/openldap-data-net
1531 E: 49. olcRootDN: "cn=Manager,dc=example,dc=com"
1532 E: 50. olcDbIndex: objectClass eq
1533 E: 51. olcAccess: to * by users read