# $OpenLDAP$ # Copyright 1999-2022 The OpenLDAP Foundation, All Rights Reserved. # COPYING RESTRICTIONS APPLY, see COPYRIGHT. H1: The slapd Configuration File This chapter describes configuring {{slapd}}(8) via the {{slapd.conf}}(5) configuration file. {{slapd.conf}}(5) has been deprecated and should only be used if your site requires one of the backends that hasn't yet been updated to work with the newer {{slapd-config}}(5) system. Configuring {{slapd}}(8) via {{slapd-config}}(5) is described in the previous chapter. The {{slapd.conf}}(5) file is normally installed in the {{EX:/usr/local/etc/openldap}} directory. An alternate configuration file location can be specified via a command-line option to {{slapd}}(8). H2: Configuration File Format The {{slapd.conf}}(5) file consists of three types of configuration information: global, backend specific, and database specific. Global information is specified first, followed by information associated with a particular backend type, which is then followed by information associated with a particular database instance. Global directives can be overridden in backend and/or database directives, and backend directives can be overridden by database directives. Blank lines and comment lines beginning with a '{{EX:#}}' character are ignored. If a line begins with whitespace, it is considered a continuation of the previous line (even if the previous line is a comment). The general format of slapd.conf is as follows: > # global configuration directives > > > # backend definition > backend > > > # first database definition & config directives > database > > > # second database definition & config directives > database > > > # second database definition & config directives > database > > > # subsequent backend & database definitions & config directives > ... A configuration directive may take arguments. If so, they are separated by whitespace. If an argument contains whitespace, the argument should be enclosed in double quotes {{EX:"like this"}}. If an argument contains a double quote or a backslash character `{{EX:\}}', the character should be preceded by a backslash character `{{EX:\}}'. The distribution contains an example configuration file that will be installed in the {{F: /usr/local/etc/openldap}} directory. A number of files containing schema definitions (attribute types and object classes) are also provided in the {{F: /usr/local/etc/openldap/schema}} directory. H2: Configuration File Directives This section details commonly used configuration directives. For a complete list, see the {{slapd.conf}}(5) manual page. This section separates the configuration file directives into global, backend-specific and data-specific categories, describing each directive and its default value (if any), and giving an example of its use. H3: Global Directives Directives described in this section apply to all backends and databases unless specifically overridden in a backend or database definition. Arguments that should be replaced by actual text are shown in brackets {{EX:<>}}. H4: access to [ by [] [] ]+ This directive grants access (specified by ) to a set of entries and/or attributes (specified by ) by one or more requestors (specified by ). See the {{SECT:Access Control}} section of this guide for basic usage. !if 0 More details discussion of this directive can be found in the {{SECT:Advanced Access Control}} chapter. !endif Note: If no {{EX:access}} directives are specified, the default access control policy, {{EX:access to * by * read}}, allows all both authenticated and anonymous users read access. H4: attributetype <{{REF:RFC4512}} Attribute Type Description> This directive defines an attribute type. Please see the {{SECT:Schema Specification}} chapter for information regarding how to use this directive. H4: idletimeout Specify the number of seconds to wait before forcibly closing an idle client connection. An idletimeout of 0, the default, disables this feature. H4: include This directive specifies that slapd should read additional configuration information from the given file before continuing with the next line of the current file. The included file should follow the normal slapd config file format. The file is commonly used to include files containing schema specifications. Note: You should be careful when using this directive - there is no small limit on the number of nested include directives, and no loop detection is done. H4: loglevel This directive specifies the level at which log statements and operation statistics should be sent to syslog (currently logged to the {{syslogd}}(8) {{EX:LOG_LOCAL4}} facility). You must have configured OpenLDAP {{EX:--enable-debug}} (the default) for this to work, except for the two statistics levels, which are always enabled. Log levels may be specified as integers or by keyword. Multiple log levels may be used and the levels are additive. The possible values for are: !block table; colaligns="RL"; align=Center; \ title="Table 6.1: Logging Levels" Level Keyword Description -1 any enable all debugging 0 no debugging 1 (0x1 trace) trace function calls 2 (0x2 packets) debug packet handling 4 (0x4 args) heavy trace debugging 8 (0x8 conns) connection management 16 (0x10 BER) print out packets sent and received 32 (0x20 filter) search filter processing 64 (0x40 config) configuration processing 128 (0x80 ACL) access control list processing 256 (0x100 stats) stats log connections/operations/results 512 (0x200 stats2) stats log entries sent 1024 (0x400 shell) print communication with shell backends 2048 (0x800 parse) print entry parsing debugging 16384 (0x4000 sync) syncrepl consumer processing 32768 (0x8000 none) only messages that get logged regardless of configured log level !endblock The desired log level can be input as a single integer that combines the (ORed) desired levels, both in decimal or in hexadecimal notation, as a list of integers (that are ORed internally), or as a list of the names that are shown between brackets, such that > loglevel 129 > loglevel 0x81 > loglevel 128 1 > loglevel 0x80 0x1 > loglevel acl trace are equivalent. \Examples: E: loglevel -1 This will enable all log levels. E: loglevel conns filter Just log the connection and search filter processing. E: loglevel none Log those messages that are logged regardless of the configured loglevel. This differs from setting the log level to 0, when no logging occurs. At least the {{EX:None}} level is required to have high priority messages logged. \Default: E: loglevel stats Basic stats logging is configured by default. H4: objectclass <{{REF:RFC4512}} Object Class Description> This directive defines an object class. Please see the {{SECT:Schema Specification}} chapter for information regarding how to use this directive. H4: referral This directive specifies the referral to pass back when slapd cannot find a local database to handle a request. \Example: > referral ldap://root.openldap.org This will refer non-local queries to the global root LDAP server at the OpenLDAP Project. Smart LDAP clients can re-ask their query at that server, but note that most of these clients are only going to know how to handle simple LDAP URLs that contain a host part and optionally a distinguished name part. H4: sizelimit This directive specifies the maximum number of entries to return from a search operation. \Default: > sizelimit 500 See the {{SECT:Limits}} section of this guide and {{slapd.conf}}(5) for more details. H4: timelimit This directive specifies the maximum number of seconds (in real time) slapd will spend answering a search request. If a request is not finished in this time, a result indicating an exceeded timelimit will be returned. \Default: > timelimit 3600 See the {{SECT:Limits}} section of this guide and {{slapd.conf}}(5) for more details. H3: General Backend Directives Directives in this section apply only to the backend in which they are defined. They are supported by every type of backend. Backend directives apply to all databases instances of the same type and, depending on the directive, may be overridden by database directives. H4: backend This directive marks the beginning of a backend declaration. {{EX:}} should be one of the supported backend types listed in Table 6.2. !block table; align=Center; coltags="EX,N"; \ title="Table 6.2: Database Backends" Types Description asyncmeta Asynchronous Metadirectory backend config Slapd configuration backend dnssrv DNS SRV backend ldap Lightweight Directory Access Protocol (Proxy) backend ldif Lightweight Data Interchange Format backend mdb Memory-Mapped DB backend meta Metadirectory backend monitor Monitor backend null Null backend passwd Provides read-only access to {{passwd}}(5) perl Perl Programmable backend relay Relay backend sock Socket backend sql SQL Programmable backend wt WiredTiger backend !endblock \Example: > backend mdb > idlexp 16 This marks the beginning of a new {{TERM:MDB}} backend definition. At present, only back-mdb implements any options of this type, so this setting is not needed for any other backends. H3: General Database Directives Directives in this section apply only to the database in which they are defined. They are supported by every type of database. H4: database This directive marks the beginning of a database instance declaration. {{EX:}} should be one of the supported backend types listed in Table 6.2. \Example: > database mdb This marks the beginning of a new {{TERM:MDB}} database instance declaration. H4: limits [ [...]] Specify time and size limits based on the operation's initiator or base DN. See the {{SECT:Limits}} section of this guide and {{slapd.conf}}(5) for more details. H4: readonly { on | off } This directive puts the database into "read-only" mode. Any attempts to modify the database will return an "unwilling to perform" error. If set on a consumer, modifications sent by syncrepl will still occur. \Default: > readonly off H4: rootdn This directive specifies the DN that is not subject to access control or administrative limit restrictions for operations on this database. The DN need not refer to an entry in this database or even in the directory. The DN may refer to a SASL identity. Entry-based Example: > rootdn "cn=Manager,dc=example,dc=com" SASL-based Example: > rootdn "uid=root,cn=example.com,cn=digest-md5,cn=auth" See the {{SECT:SASL Authentication}} section for information on SASL authentication identities. H4: rootpw This directive can be used to specifies a password for the DN for the rootdn (when the rootdn is set to a DN within the database). \Example: > rootpw secret It is also permissible to provide hash of the password in {{REF:RFC2307}} form. {{slappasswd}}(8) may be used to generate the password hash. \Example: > rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN The hash was generated using the command {{EX:slappasswd -s secret}}. H4: suffix This directive specifies the DN suffix of queries that will be passed to this backend database. Multiple suffix lines can be given, and at least one is required for each database definition. \Example: > suffix "dc=example,dc=com" Queries with a DN ending in "dc=example,dc=com" will be passed to this backend. Note: When the backend to pass a query to is selected, slapd looks at the suffix line(s) in each database definition in the order they appear in the file. Thus, if one database suffix is a prefix of another, it must appear after it in the config file. H4: syncrepl > syncrepl rid= > provider=ldap[s]://[:port] > searchbase= > [type=refreshOnly|refreshAndPersist] > [interval=dd:hh:mm:ss] > [retry=[ <# of retries>]+] > [filter=] > [scope=sub|one|base] > [attrs=] > [exattrs=] > [attrsonly] > [sizelimit=] > [timelimit=] > [schemachecking=on|off] > [network-timeout=] > [timeout=] > [bindmethod=simple|sasl] > [binddn=] > [saslmech=] > [authcid=] > [authzid=] > [credentials=] > [realm=] > [secprops=] > [keepalive=::] > [starttls=yes|critical] > [tls_cert=] > [tls_key=] > [tls_cacert=] > [tls_cacertdir=] > [tls_reqcert=never|allow|try|demand] > [tls_cipher_suite=] > [tls_crlcheck=none|peer|all] > [tls_protocol_min=[.]] > [suffixmassage=] > [logbase=] > [logfilter=] > [syncdata=default|accesslog|changelog] This directive specifies the current database as a consumer of the provider content by establishing the current {{slapd}}(8) as a replication consumer site running a syncrepl replication engine. The provider database is located at the replication provider site specified by the {{EX:provider}} parameter. The consumer database is kept up-to-date with the provider content using the LDAP Content Synchronization protocol. See {{REF:RFC4533}} for more information on the protocol. The {{EX:rid}} parameter is used for identification of the current {{EX:syncrepl}} directive within the replication consumer server, where {{EX:}} uniquely identifies the syncrepl specification described by the current {{EX:syncrepl}} directive. {{EX:}} is non-negative and is no more than three decimal digits in length. The {{EX:provider}} parameter specifies the replication provider site containing the provider content as an LDAP URI. The {{EX:provider}} parameter specifies a scheme, a host and optionally a port where the provider slapd instance can be found. Either a domain name or IP address may be used for . Examples are {{EX:ldap://provider.example.com:389}} or {{EX:ldaps://192.168.1.1:636}}. If is not given, the standard LDAP port number (389 or 636) is used. Note that the syncrepl uses a consumer-initiated protocol, and hence its specification is located on the consumer. The content of the syncrepl consumer is defined using a search specification as its result set. The consumer slapd will send search requests to the provider slapd according to the search specification. The search specification includes {{EX:searchbase}}, {{EX:scope}}, {{EX:filter}}, {{EX:attrs}}, {{EX:exattrs}}, {{EX:attrsonly}}, {{EX:sizelimit}}, and {{EX:timelimit}} parameters as in the normal search specification. The {{EX:searchbase}} parameter has no default value and must always be specified. The {{EX:scope}} defaults to {{EX:sub}}, the {{EX:filter}} defaults to {{EX:(objectclass=*)}}, {{EX:attrs}} defaults to {{EX:"*,+"}} to replicate all user and operational attributes, and {{EX:attrsonly}} is unset by default. Both {{EX:sizelimit}} and {{EX:timelimit}} default to "unlimited", and only positive integers or "unlimited" may be specified. The {{EX:exattrs}} option may also be used to specify attributes that should be omitted from incoming entries. The {{TERM[expand]LDAP Sync}} protocol has two operation types: {{EX:refreshOnly}} and {{EX:refreshAndPersist}}. The operation type is specified by the {{EX:type}} parameter. In the {{EX:refreshOnly}} operation, the next synchronization search operation is periodically rescheduled at an interval time after each synchronization operation finishes. The interval is specified by the {{EX:interval}} parameter. It is set to one day by default. In the {{EX:refreshAndPersist}} operation, a synchronization search remains persistent in the provider {{slapd}} instance. Further updates to the provider will generate {{EX:searchResultEntry}} to the consumer slapd as the search responses to the persistent synchronization search. If an error occurs during replication, the consumer will attempt to reconnect according to the retry parameter which is a list of the and <# of retries> pairs. For example, retry="60 10 300 3" lets the consumer retry every 60 seconds for the first 10 times and then retry every 300 seconds for the next three times before stop retrying. + in <# of retries> means indefinite number of retries until success. The schema checking can be enforced at the LDAP Sync consumer site by turning on the {{EX:schemachecking}} parameter. If it is turned on, every replicated entry will be checked for its schema as the entry is stored on the consumer. Every entry in the consumer should contain those attributes required by the schema definition. If it is turned off, entries will be stored without checking schema conformance. The default is off. The {{EX:network-timeout}} parameter sets how long the consumer will wait to establish a network connection to the provider. Once a connection is established, the {{EX:timeout}} parameter determines how long the consumer will wait for the initial Bind request to complete. The defaults for these parameters come from {{ldap.conf}}(5). The {{EX:binddn}} parameter gives the DN to bind as for the syncrepl searches to the provider slapd. It should be a DN which has read access to the replication content in the provider database. The {{EX:bindmethod}} is {{EX:simple}} or {{EX:sasl}}, depending on whether simple password-based authentication or {{TERM:SASL}} authentication is to be used when connecting to the provider {{slapd}} instance. Simple authentication should not be used unless adequate data integrity and confidentiality protections are in place (e.g. TLS or IPsec). Simple authentication requires specification of {{EX:binddn}} and {{EX:credentials}} parameters. SASL authentication is generally recommended. SASL authentication requires specification of a mechanism using the {{EX:saslmech}} parameter. Depending on the mechanism, an authentication identity and/or credentials can be specified using {{EX:authcid}} and {{EX:credentials}}, respectively. The {{EX:authzid}} parameter may be used to specify an authorization identity. The {{EX:realm}} parameter specifies a realm which a certain mechanisms authenticate the identity within. The {{EX:secprops}} parameter specifies Cyrus SASL security properties. The {{EX:keepalive}} parameter sets the values of idle, probes, and interval used to check whether a socket is alive; idle is the number of seconds a connection needs to remain idle before TCP starts sending keepalive probes; probes is the maximum number of keepalive probes TCP should send before dropping the connection; interval is interval in seconds between individual keepalive probes. Only some systems support the customization of these values; the keepalive parameter is ignored otherwise, and system-wide settings are used. For example, keepalive="240:10:30" will send a keepalive probe 10 times, every 30 seconds, after 240 seconds of idle activity. If no response to the probes is received, the connection will be dropped. The {{EX:starttls}} parameter specifies use of the StartTLS extended operation to establish a TLS session before authenticating to the provider. If the {{EX:critical}} argument is supplied, the session will be aborted if the StartTLS request fails. Otherwise the syncrepl session continues without TLS. The tls_reqcert setting defaults to {{EX:"demand"}} and the other TLS settings default to the same as the main slapd TLS settings. The {{EX:suffixmassage}} parameter allows the consumer to pull entries from a remote directory whose DN suffix differs from the local directory. The portion of the remote entries' DNs that matches the searchbase will be replaced with the suffixmassage DN. Rather than replicating whole entries, the consumer can query logs of data modifications. This mode of operation is referred to as {{delta syncrepl}}. In addition to the above parameters, the {{EX:logbase}} and {{EX:logfilter}} parameters must be set appropriately for the log that will be used. The {{EX:syncdata}} parameter must be set to either {{EX:"accesslog"}} if the log conforms to the {{slapo-accesslog}}(5) log format, or {{EX:"changelog"}} if the log conforms to the obsolete {{changelog}} format. If the {{EX:syncdata}} parameter is omitted or set to {{EX:"default"}} then the log parameters are ignored. The {{syncrepl}} replication mechanism is supported by the {{mdb}} backend. See the {{SECT:LDAP Sync Replication}} chapter of this guide for more information on how to use this directive. H4: updateref This directive is only applicable in a {{replica}} (or {{shadow}}) {{slapd}}(8) instance. It specifies the URL to return to clients which submit update requests upon the replica. If specified multiple times, each {{TERM:URL}} is provided. \Example: > updateref ldap://provider.example.net H3: MDB Backend Directives Directives in this category only apply to the {{TERM:MDB}} database backend. They will apply to all "database mdb" instances in the configuration. For a complete reference of MDB backend configuration directives, see {{slapd-mdb}}(5). H4: idlexp Specify a power of 2 for the maximum size of an index slot. The default is 16, yielding a maximum slot size of 2^16 or 65536. The specified value must be in the range of 16-30. This setting helps with the case where certain search filters are slow to return results due to an index slot having collapsed to a range value. This occurs when the number of candidate entries that match the filter for the index slot exceed the configured slot size. If this setting is decreased on a server with existing {{TERM:MDB}} databases, each db will immediately need its indices to be rebuilt while slapd is offline with the "slapindex -q -t" command. If this setting is increased on a server with existing {{TERM:MDB}} databases, each db will need its indices rebuilt to take advantage of the change for indices that have already been converted to ranges. H3: MDB Database Directives Directives in this category only apply to the {{TERM:MDB}} database backend. That is, they must follow a "database mdb" line and come before any subsequent "backend" or "database" lines. For a complete reference of MDB configuration directives, see {{slapd-mdb}}(5). H4: directory This directive specifies the directory where the MDB files containing the database and associated indices live. \Default: > directory /usr/local/var/openldap-data H4: checkpoint This directive specifies the frequency for flushing the database disk buffers. This directive is only needed if the {{dbnosync}} option is {{EX:TRUE}}. The checkpoint will occur if either data has been written or minutes have passed since the last checkpoint. Both arguments default to zero, in which case they are ignored. When the argument is non-zero, an internal task will run every minutes to perform the checkpoint. Note: currently the _kbyte_ setting is unimplemented. \Example: > checkpoint: 1024 10 H4: dbnosync: { TRUE | FALSE } This directive causes on-disk database contents to not be immediately synchronized with in memory changes upon change. Setting this option to {{EX:TRUE}} may improve performance at the expense of data integrity. H4: envflags: {nosync,nometasync,writemap,mapasync,nordahead} This option specifies flags for finer-grained control of the LMDB library's operation. * {{F:nosync}}: This is exactly the same as the dbnosync directive. * {{F:nometasync}}: Flush the data on a commit, but skip the sync of the meta page. This mode is slightly faster than doing a full sync, but can potentially lose the last committed transaction if the operating system crashes. If both nometasync and nosync are set, the nosync flag takes precedence. * {{F:writemap}}: Use a writable memory map instead of just read-only. This speeds up write operations but makes the database vulnerable to corruption in case any bugs in slapd cause stray writes into the mmap region. * {{F:mapasync}}: When using a writable memory map and performing flushes on each commit, use an asynchronous flush instead of a synchronous flush (the default). This option has no effect if writemap has not been set. It also has no effect if nosync is set. * {{F:nordahead}}: Turn off file readahead. Usually the OS performs readahead on every read request. This usually boosts read performance but can be harmful to random access read performance if the system's memory is full and the DB is larger than RAM. This option is not implemented on Windows. H4: index: { | default} [pres,eq,approx,sub,none] This directive specifies the indices to maintain for the given attribute. If only an {{EX:}} is given, the default indices are maintained. The index keywords correspond to the common types of matches that may be used in an LDAP search filter. \Example: > index: default pres,eq > index: uid > index: cn,sn pres,eq,sub > index: objectClass eq The first line sets the default set of indices to maintain to present and equality. The second line causes the default (pres,eq) set of indices to be maintained for the {{EX:uid}} attribute type. The third line causes present, equality, and substring indices to be maintained for {{EX:cn}} and {{EX:sn}} attribute types. The fourth line causes an equality index for the {{EX:objectClass}} attribute type. There is no index keyword for inequality matches. Generally these matches do not use an index. However, some attributes do support indexing for inequality matches, based on the equality index. A substring index can be more explicitly specified as {{EX:subinitial}}, {{EX:subany}}, or {{EX:subfinal}}, corresponding to the three possible components of a substring match filter. A subinitial index only indexes substrings that appear at the beginning of an attribute value. A subfinal index only indexes substrings that appear at the end of an attribute value, while subany indexes substrings that occur anywhere in a value. Note that by default, setting an index for an attribute also affects every subtype of that attribute. E.g., setting an equality index on the {{EX:name}} attribute causes {{EX:cn}}, {{EX:sn}}, and every other attribute that inherits from {{EX:name}} to be indexed. By default, no indices are maintained. It is generally advised that minimally an equality index upon objectClass be maintained. > index: objectClass eq Additional indices should be configured corresponding to the most common searches that are used on the database. Presence indexing should not be configured for an attribute unless the attribute occurs very rarely in the database, and presence searches on the attribute occur very frequently during normal use of the directory. Most applications don't use presence searches, so usually presence indexing is not very useful. H4: maxentrysize: Specify the maximum size of an entry in bytes. Attempts to store an entry larger than this size will be rejected with the error LDAP_ADMINLIMIT_EXCEEDED. The default is 0, which is unlimited. H4: maxreaders: This directive specifies the maximum number of threads that may have concurrent read access to the database. Tools such as slapcat count as a single thread, in addition to threads in any active slapd processes. The default is 126. H4: maxsize: This directive specifies the maximum size of the database in bytes. A memory map of this size is allocated at startup time and the database will not be allowed to grow beyond this size. The default is 10485760 bytes (10MB). This setting may be changed upward if the configured limit needs to be increased. Note: It is important to set this to as large a value as possible, (relative to anticipated growth of the actual data over time) since growing the size later may not be practical when the system is under heavy load. H4: mode: { | } This directive specifies the file protection mode that newly created database index files should have. This can be in the form {{EX:0600}} or {{EX:-rw-------}} \Default: > mode: 0600 H4: multival: { | default } hi, lo Specify the number of values for which a multivalued attribute is stored in a separate table. Normally entries are stored as a single blob inside the database. When an entry gets very large or contains attributes with a very large number of values, modifications on that entry may get very slow. Splitting the large attributes out to a separate table can improve the performance of modification operations. The threshold is specified as a pair of integers. If the number of values exceeds the hi threshold the values will be split out. If a modification deletes enough values to bring an attribute below the lo threshold the values will be removed from the separate table and merged back into the main entry blob. The threshold can be set for a specific list of attributes, or the default can be configured for all other attributes. The default value for both hi and lo thresholds is UINT_MAX, which keeps all attributes in the main blob. In addition to increasing write performance of operations the use of multival can also decrease fragmentation of the primary {{TERM:MDB}} database. H4: rtxnsize: This directive specifies the maximum number of entries to process in a single read transaction when executing a large search. Long-lived read transactions prevent old database pages from being reused in write transactions, and so can cause significant growth of the database file when there is heavy write traffic. This setting causes the read transaction in large searches to be released and reacquired after the given number of entries has been read, to give writers the opportunity to reclaim old database pages. The default is 10000. H4: searchstack: Specify the depth of the stack used for search filter evaluation. Search filters are evaluated on a stack to accommodate nested {{EX:AND}} / {{EX:OR}} clauses. An individual stack is allocated for each server thread. The depth of the stack determines how complex a filter can be evaluated without requiring any additional memory allocation. Filters that are nested deeper than the search stack depth will cause a separate stack to be allocated for that particular search operation. These separate allocations can have a major negative impact on server performance, but specifying too much stack will also consume a great deal of memory. Each search uses 512K bytes per level on a 32-bit machine, or 1024K bytes per level on a 64-bit machine. The default stack depth is 16, thus 8MB or 16MB per thread is used on 32 and 64 bit machines, respectively. Also the 512KB size of a single stack slot is set by a compile-time constant which may be changed if needed; the code must be recompiled for the change to take effect. \Default: > searchstack: 16 H4: Sample Entry >database mdb >suffix: "dc=example,dc=com" >directory: /usr/local/var/openldap-data >index: objectClass eq H2: Configuration File Example The following is an example configuration file, interspersed with explanatory text. It defines two databases to handle different parts of the {{TERM:X.500}} tree; both are {{TERM:MDB}} database instances. The line numbers shown are provided for reference only and are not included in the actual file. First, the global configuration section: E: 1. # example config file - global configuration section E: 2. include /usr/local/etc/schema/core.schema E: 3. referral ldap://root.openldap.org E: 4. access to * by * read Line 1 is a comment. Line 2 includes another config file which contains {{core}} schema definitions. The {{EX:referral}} directive on line 3 means that queries not local to one of the databases defined below will be referred to the LDAP server running on the standard port (389) at the host {{EX:root.openldap.org}}. Line 4 is a global access control. It applies to all entries (after any applicable database-specific access controls). The next section of the configuration file defines a MDB backend that will handle queries for things in the "dc=example,dc=com" portion of the tree. The database is to be replicated to two replica slapds, one on truelies, the other on judgmentday. Indices are to be maintained for several attributes, and the {{EX:userPassword}} attribute is to be protected from unauthorized access. E: 5. # MDB definition for the example.com E: 6. database mdb E: 7. suffix "dc=example,dc=com" E: 8. directory /usr/local/var/openldap-data E: 9. rootdn "cn=Manager,dc=example,dc=com" E: 10. rootpw secret E: 11. # indexed attribute definitions E: 12. index uid pres,eq E: 13. index cn,sn pres,eq,approx,sub E: 14. index objectClass eq E: 15. # database access control definitions E: 16. access to attrs=userPassword E: 17. by self write E: 18. by anonymous auth E: 19. by dn.base="cn=Admin,dc=example,dc=com" write E: 20. by * none E: 21. access to * E: 22. by self write E: 23. by dn.base="cn=Admin,dc=example,dc=com" write E: 24. by * read Line 5 is a comment. The start of the database definition is marked by the database keyword on line 6. Line 7 specifies the DN suffix for queries to pass to this database. Line 8 specifies the directory in which the database files will live. Lines 9 and 10 identify the database {{super-user}} entry and associated password. This entry is not subject to access control or size or time limit restrictions. Lines 12 through 14 indicate the indices to maintain for various attributes. Lines 16 through 24 specify access control for entries in this database. For all applicable entries, the {{EX:userPassword}} attribute is writable by the entry itself and by the "admin" entry. It may be used for authentication/authorization purposes, but is otherwise not readable. All other attributes are writable by the entry and the "admin" entry, but may be read by all users (authenticated or not). The next section of the example configuration file defines another MDB database. This one handles queries involving the {{EX:dc=example,dc=net}} subtree but is managed by the same entity as the first database. Note that without line 39, the read access would be allowed due to the global access rule at line 4. E: 33. # MDB definition for example.net E: 34. database mdb E: 35. suffix "dc=example,dc=net" E: 36. directory /usr/local/var/openldap-data-net E: 37. rootdn "cn=Manager,dc=example,dc=com" E: 38. index objectClass eq E: 39. access to * by users read