# $OpenLDAP: pkg/openldap-guide/admin/slapdconfig.sdf,v 1.87.2.14 2008/04/14 20:48:16 quanah Exp $ # Copyright 1999-2008 The OpenLDAP Foundation, All Rights Reserved. # COPYING RESTRICTIONS APPLY, see COPYRIGHT. H1: The slapd Configuration File Once the software has been built and installed, you are ready to configure {{slapd}}(8) for use at your site. The slapd runtime configuration is primarily accomplished through the {{slapd.conf}}(5) file, 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). This chapter describes the general format of the {{slapd.conf}}(5) configuration file, followed by a detailed description of commonly used config file directives. 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 white space, 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 white space. If an argument contains white space, 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 debugging statements and operation statistics should be syslogged (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 are additive. To display what numbers correspond to what kind of debugging, invoke slapd with {{EX:-?}} or consult the table below. The possible values for are: !block table; colaligns="RL"; align=Center; \ title="Table 6.1: Debugging Levels" Level Description -1 enable all debugging 0 no debugging 1 trace function calls 2 debug packet handling 4 heavy trace debugging 8 connection management 16 print out packets sent and received 32 search filter processing 64 configuration file processing 128 access control list processing 256 stats log connections/operations/results 512 stats log entries sent 1024 print communication with shell backends 2048 print entry parsing debugging !endblock \Example: E: loglevel -1 This will cause lots and lots of debugging information to be logged. \Default: E: loglevel 256 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 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 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 5.2: Database Backends" Types Description bdb Berkeley DB transactional backend dnssrv DNS SRV backend hdb Hierarchical variant of bdb backend ldap Lightweight Directory Access Protocol (Proxy) backend meta Meta Directory backend monitor Monitor backend passwd Provides read-only access to {{passwd}}(5) perl Perl Programmable backend shell Shell (extern program) backend sql SQL Programmable backend !endblock \Example: > backend bdb This marks the beginning of a new {{TERM:BDB}} backend definition. 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 bdb This marks the beginning of a new {{TERM:BDB}} database instance declaration. 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. \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] > [type=refreshOnly|refreshAndPersist] > [interval=dd:hh:mm:ss] > [retry=[ <# of retries>]+] > searchbase= > [filter=] > [scope=sub|one|base] > [attrs=] > [attrsonly] > [sizelimit=] > [timelimit=] > [schemachecking=on|off] > [bindmethod=simple|sasl] > [binddn=] > [saslmech=] > [authcid=] > [authzid=] > [credentials=] > [realm=] > [secprops=] > [starttls=yes|critical] > [tls_cert=] > [tls_key=] > [tls_cacert=] > [tls_cacertdir=] > [tls_reqcert=never|allow|try|demand] > [tls_ciphersuite=] > [tls_crlcheck=none|peer|all] > [logbase=] > [logfilter=] > [syncdata=default|accesslog|changelog] This directive specifies the current database as a replica of the master content by establishing the current {{slapd}}(8) as a replication consumer site running a syncrepl replication engine. The master database is located at the replication provider site specified by the {{EX:provider}} parameter. The replica database is kept up-to-date with the master 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 master 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 at the consumer site, whereas the {{EX:replica}} specification is located at the provider site. {{EX:syncrepl}} and {{EX:replica}} directives define two independent replication mechanisms. They do not represent the replication peers of each other. The content of the syncrepl replica 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: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 {{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 master replica 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 into the replica content. Every entry in the replica 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: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 master 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: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. Note that the main slapd TLS settings are not used by the syncrepl engine; by default the TLS parameters from a {{ldap.conf}}(5) configuration file will be used. TLS settings may be specified here, in which case any {{ldap.conf}}(5) settings will be completely ignored. 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 {{bdb}} and {{hdb}} backends. 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 {{slave}} (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://master.example.net H3: BDB and HDB Database Directives Directives in this category only apply to both the {{TERM:BDB}} and the {{TERM:HDB}} database. That is, they must follow a "database bdb" or "database hdb" line and come before any subsequent "backend" or "database" line. For a complete reference of BDB/HDB configuration directives, see {{slapd-bdb}}(5). H4: directory This directive specifies the directory where the BDB files containing the database and associated indices live. \Default: > directory /usr/local/var/openldap-data