diff options
Diffstat (limited to 'doc/guide/admin/slapdconfig.sdf')
| -rw-r--r-- | doc/guide/admin/slapdconfig.sdf | 692 |
1 files changed, 692 insertions, 0 deletions
diff --git a/doc/guide/admin/slapdconfig.sdf b/doc/guide/admin/slapdconfig.sdf new file mode 100644 index 0000000..f0c0330 --- /dev/null +++ b/doc/guide/admin/slapdconfig.sdf @@ -0,0 +1,692 @@ +# $OpenLDAP$ +# Copyright 1999-2018 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 +> <global config directives> +> +> # backend definition +> backend <typeA> +> <backend-specific directives> +> +> # first database definition & config directives +> database <typeA> +> <database-specific directives> +> +> # second database definition & config directives +> database <typeB> +> <database-specific directives> +> +> # second database definition & config directives +> database <typeA> +> <database-specific directives> +> +> # 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 <what> [ by <who> [<accesslevel>] [<control>] ]+ + +This directive grants access (specified by <accesslevel>) to a set +of entries and/or attributes (specified by <what>) by one or more +requestors (specified by <who>). 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 <integer> + +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 <filename> + +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 <level> + +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 may be specified as integers or by keyword. +Multiple log levels may be used and the levels are additive. To display what +numbers correspond to what kind of debugging, invoke slapd with {{EX:-d?}} +or consult the table below. The possible values for <integer> are: + +!block table; colaligns="RL"; align=Center; \ + title="Table 6.1: Debugging 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 whatever log level is set +!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 cause lots and lots of debugging information to be +logged. + +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. However, if no loglevel is +defined, no logging occurs (equivalent to a 0 level). + +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 <URI> + +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 <integer> + +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 <integer> + +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 <type> + +This directive marks the beginning of a backend declaration. +{{EX:<type>}} 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 +bdb Berkeley DB transactional backend (deprecated) +dnssrv DNS SRV backend +hdb Hierarchical variant of bdb backend (deprecated) +ldap Lightweight Directory Access Protocol (Proxy) backend +mdb Memory-Mapped DB 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 <type> + +This directive marks the beginning of a database instance +declaration. +{{EX:<type>}} 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: limits <selector> <limit> [<limit> [...]] + +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 <DN> + +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 <password> + +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 <dn 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=<replica ID> +> provider=ldap[s]://<hostname>[:port] +> searchbase=<base DN> +> [type=refreshOnly|refreshAndPersist] +> [interval=dd:hh:mm:ss] +> [retry=[<retry interval> <# of retries>]+] +> [filter=<filter str>] +> [scope=sub|one|base] +> [attrs=<attr list>] +> [exattrs=<attr list>] +> [attrsonly] +> [sizelimit=<limit>] +> [timelimit=<limit>] +> [schemachecking=on|off] +> [network-timeout=<seconds>] +> [timeout=<seconds>] +> [bindmethod=simple|sasl] +> [binddn=<DN>] +> [saslmech=<mech>] +> [authcid=<identity>] +> [authzid=<identity>] +> [credentials=<passwd>] +> [realm=<realm>] +> [secprops=<properties>] +> [keepalive=<idle>:<probes>:<interval>] +> [starttls=yes|critical] +> [tls_cert=<file>] +> [tls_key=<file>] +> [tls_cacert=<file>] +> [tls_cacertdir=<path>] +> [tls_reqcert=never|allow|try|demand] +> [tls_cipher_suite=<ciphers>] +> [tls_crlcheck=none|peer|all] +> [tls_protocol_min=<major>[.<minor>]] +> [suffixmassage=<real DN>] +> [logbase=<base DN>] +> [logfilter=<filter str>] +> [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:<replica ID>}} uniquely identifies the syncrepl specification +described by the current {{EX:syncrepl}} directive. {{EX:<replica ID>}} +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 <hostname>. Examples are +{{EX:ldap://provider.example.com:389}} or {{EX:ldaps://192.168.1.1:636}}. +If <port> 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: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 +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 <retry interval> +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: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 +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: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 {{bdb}}, +{{hdb}}, and {{mdb}} backends. + +See the {{SECT:LDAP Sync Replication}} chapter of this guide for +more information on how to use this directive. + + +H4: updateref <URL> + +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 <directory> + +This directive specifies the directory where the BDB files +containing the database and associated indices live. + +\Default: + +> directory /usr/local/var/openldap-data + + +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:BDB}} +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 BDB +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 slave 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. # BDB definition for the example.com +E: 6. database bdb +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 +BDB 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. # BDB definition for example.net +E: 34. database bdb +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 |