# $OpenLDAP$ # Copyright 1999-2000, 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 it for use at your site. All slapd runtime configuration is accomplished through the {{I:slapd.conf}}(5) file, normally installed in the {{EX:/usr/local/etc/openldap}} directory. An alternate configuration file can be specified via a command-line option to slapd or slurpd (see Sections 5 and 8, respectively). This section describes the general format of the config file, followed by a detailed description of each config file directive. H2: Configuration File Format The {{slapd.conf}}(5) file consists three types of configuration information: global, backend specific, 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 a backend and/or database directives, 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. 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 definition (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 {{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, unless specifically overridden in a backend definition. Arguments to directives 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 requesters (specified by ). See Section 5.3 on access control for more details and examples. H4: attributetype This directive defines an attribute type. H4: defaultaccess { none | compare | search | read | write } This directive specifies the default access to grant requesters not matched by any other access line (see Section 5.3). Note that an access level implies all lesser access levels (e.g., write access implies read, search and compare). \Default: E: defaultaccess read 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. 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) LOG_LOCAL4 facility). You must have compiled slapd with -DLDAP_DEBUG for this to work (except for the two stats levels, which are always enabled). Log levels are additive. To display what numbers correspond to what kind of debugging, invoke slapd with the ? flag or consult the table below. The possible values for are: *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 \Example: E: loglevel 255 This will cause lots and lots of debugging information to be syslogged. \Default: E: loglevel 256 H4: objectclass This directive defines an object class. 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: schemacheck { on | off } This directive turns schema checking on or off. If schema checking is on, entries added or modified through LDAP operations will be checked to ensure they obey the schema rules implied by their object class(es) as defined by the corresponding objectclass directive(s). If schema checking is off this check is not done. \Default: > schemacheck on H4: sizelimit This directive specifies the maximum number of entries to return from a search operation. \Default: > sizelimit 500 H4: srvtab This directive specifies the srvtab file in which slapd can find the kerberos keys necessary for authenticating clients using kerberos. This directive is only meaningful if you are using kerberos authentication, which must be enabled at compile time by including the appropriate definitions in the {{EX:Make-common}} file. \Default: > srvtab /etc/srvtab 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 H3: General Database Directives Directives in this section only apply 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 new database instance definition. should be one of ldbm, shell, or passwd, depending on which backend will serve the database. \Example: > database ldbm This marks the beginning of a new LDBM backend database instance definition. H4: lastmod { on | off } This directive controls whether slapd will automatically maintain the modifiersName, modifyTimestamp, creatorsName, and createTimestamp attributes for entries. \Default: > lastmod on 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: replica > replica host=[:] > "binddn=" > [bindmethod={ simple | kerberos }] > [credentials=] > [srvtab=] This directive specifies a replication site for this database. The {{EX:host=}} parameter specifies a host and optionally a port where the slave slapd instance can be found. Either a domain name or IP address may be used for . If is not given, the standard LDAP port number (389) is used. The {{EX:binddn=}} parameter gives the DN to bind as for updates to the slave slapd. It should be a DN which has read/write access to the slave slapd's database, typically given as a {{EX:rootdn}} in the slave's config file. It must also match the updatedn directive in the slave slapd's config file. Since DNs are likely to contain embedded spaces, the entire {{EX:"binddn="}} string should be enclosed in double quotes. The {{EX:bindmethod}} is either simple or kerberos, depending on whether simple password-based authentication or kerberos authentication is to be used when connecting to the slave slapd. Simple authentication requires a valid password be given. Kerberos authentication requires a valid srvtab file. The {{EX:credentials=}} parameter, which is only required if using simple authentication, gives the password for {{EX:binddn}} on the slave slapd. The {{EX:srvtab=}} parameter, which is only required if using kerberos, specifies the filename which holds the kerberos key for the slave slapd. If omitted, {{F:/etc/srvtab}} is used. See Section 10 for more details on replication. H4: replogfile This directive specifies the name of the replication log file to which slapd will log changes. The replication log is typically written by slapd and read by slurpd. Normally, this directive is only used if slurpd is being used to replicate the database. However, you can also use it to generate a transaction log, if slurpd is not running. In this case, you will need to periodically truncate the file, since it will grow indefinitely otherwise. See Section 10 for more details on replication. H4: rootdn This directive specifies the DN of an entry that is not subject to access control or administrative limit restrictions for operations on this database. \Example: > rootdn "cn=Manager, dc=example, dc=com" H4: rootkrbname This directive specifies a kerberos name for the DN given above that will always work, regardless of whether an entry with the given DN exists or has a {{EX:krbName}} attribute. This directive is useful when creating a database and also when using slurpd to provide replication service (see Section 10). \Example: > rootkrbname admin@openldap.org H4: rootpw This directive specifies a password for the DN given above that will always work, regardless of whether an entry with the given DN exists or has a password. This directive is useful when creating a database and also when using slurpd to provide replication service (see Section 10). \Example: > rootpw 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: updatedn This directive is only applicable in a slave slapd. It specifies the DN allowed to make changes to the replica (typically, this is the DN slurpd binds as when making changes to the replica). H3: LDBM Backend-Specific Directives Directives in this category only apply to the LDBM backend database. That is, they must follow a "database ldbm" line and come before any other "database" line. H4: cachesize This directive specifies the size in entries of the in-memory cache maintained by the LDBM backend database instance. \Default: > cachesize 1000 H4: dbcachesize This directive specifies the size in bytes of the in-memory cache associated with each open index file. If not supported by the underlying database method, this directive is ignored without comment. Increasing this number uses more memory but can cause a dramatic performance increase, especially during modifies or when building indexes. \Default: > dbcachesize 100000 H4: directory This directive specifies the directory where the LDBM files containing the database and associated indexes live. \Default: > directory /usr/local/var/openldap-ldbm H4: index { | default} [pres,eq,approx,sub,none] This directive specifies the indexes to maintain for the given attribute. If only an is given, all possible indexes are maintained. \Example: > index default pres,eq > index objectclass,uid > index cn,sn eq,sub,approx The first line sets the default to indices to maintain to present and equality. The second line causes the default (pres,eq) set of indices to be maintained for objectclass and uid. The third line causes equality, substring, and approximate filters to be maintained for cn and sn attributes. H4: mode This directive specifies the file protection mode that newly created database index files should have. \Default: > mode 0600 H3: Shell Backend-Specific Directives > bind > unbind > search > compare > modify > modrdn > add > delete > abandon These directives specify the pathname of the command to execute in response to the given LDAP operation. The command given should understand and follow the input/output conventions described in Appendix B. \Example: > search /usr/local/bin/search.sh Note that you need only supply those commands you want the backend to handle. Operations for which a command is not supplied will be refused with an "unwilling to perform" error. H3: Password Backend-Specific Directives Directives in this category only apply to the PASSWD backend database. That is, they must follow a "database passwd" line and come before any other "database" line. H4: file This directive specifies an alternate passwd file to use. \Default: > file /etc/passwd H3: TCL Backend-Specific Directives H4: scriptpath This is the full path to a file containing the TCL command(s) to handle the LDAP operations. H4: Proc specifiers > bind > unbind > search > compare > modify > modrdn > add > delete > abandon These directives specify the name of the proc (function) in the TCL script specified in {{EX:scriptpath}} to execute in response to the given LDAP operation. \Example: > search proc_search Note that you need only supply those commands you want the TCL backend to handle. Operations for which a command is not supplied will be refused with an "unwilling to perform" error. H4: tclrealm This is one of the biggest pluses of using the TCL backend. The realm let's you group several databases to the same interpretor. This basically means they share the same global variables and proc space. So global variables, as well as all the procs are callable between databases. If no {{EX:tclrealm}} is specified, it is put into the "default" realm. H2: Access Control Access to slapd entries and attributes is controlled by the access configuration file directive. The general form of an access line is: > ::= access to > [by ]+ > ::= * | [ dn[.]=] > [filter=] [attrs=] > ::= regex | base | one | subtree | children > ::= | , > ::= | entry | children > ::= [* | anonymous | users | self | > dn[.]=] > [dnattr= ] > [group[/[/][.]]= ] > [peername[.]=] > [sockname[.]=] > [domain[.]=] > [sockurl[.]=] > [set=] > [aci=] > ::= regex | exact | base | one | subtree | children > ::= regex | exact > ::= [self]{|} > ::= none | auth | compare | search | read | write > ::= {=|+|-}{w|r|s|c|x}+ > ::= [stop | continue | break] where the part selects the entries and/or attributes to which the access applies, the {{EX:}} part specifies which entities are granted access, and the {{EX:}} part specifies the access granted. Multiple {{EX: }} triplets are supported, allowing many entities to be granted different access to the same set of entries and attributes. H3: What to control access to The part of an access specification determines the entries and attributes to which the access control applies. Entries can be selected in two ways: by a regular expression matching the entry's distinguished name: > dn= Note: The DN pattern specified should be "normalized", meaning that there should be no extra spaces, and commas should be used to separate components. An example normalized DN is "cn=Babs Jensen,dc=example,dc=com". An example of a non-normalized DN is "cn=Babs Jensen; dc=example, dc=com". Or, entries may be selected by a filter matching some attribute(s) in the entry: > filter= where is a string representation of an LDAP search filter, as described in RFC 2254. The special entry selector "*" is used to select any entry, and is a convenient shorthand for the equivalent "dn=.*" selector. Attributes within an entry are selected by including a comma-separated list of attribute names in the selector: > attrs= Access to the entry itself must be granted or denied using the special attribute name "{{EX:entry}}". Note that giving access to an attribute is not enough; access to the entry itself through the {{EX:entry}} attribute is also required. The complete examples at the end of this section should help clear things up. H2: Who to grant access to The part identifies the entity or entities being granted access. Note that access is granted to "entities" not "entries." Entities can be specified by the special "*" identifier, matching any entry, the keyword "self" matching the entry protected by the access, or by a regular expression matching an entry's distinguished name: > dn= Note: The DN pattern specified should be "normalized", meaning that there should be no extra spaces, and commas should be used to separate components. Or entities can be specified by a regular expression matching the client's IP address or domain name: > addr= > domain= or by an entry listed in a DN-valued attribute in the entry to which the access applies: > dnattr= The dnattr specification is used to give access to an entry whose DN is listed in an attribute of the entry (e.g., give access to a group entry to whoever is listed as the owner of the group entry). H3: The access to grant The kind of granted can be one of the following: > none | auth | compare | search | read | write Note that each level implies all lower levels of access. So, for example, granting someone write access to an entry also grants them read, search, compare, and auth access. H3: Access Control Evaluation When evaluating whether some requester should be given access to an entry and/or attribute, slapd compares the entry and/or attribute to the {{EX:}} selectors given in the configuration file. Access directives local to the current database are examined first, followed by global access directives. Within this priority, access directives are examined in the order in which they appear in the config file. Slapd stops with the first {{EX:}} selector that matches the entry and/or attribute. The corresponding access directive is the one slapd will use to evaluate access. Next, slapd compares the entity requesting access to the {{EX:}} selectors within the access directive selected above, in the order in which they appear. It stops with the first {{EX:}} selector that matches the requester. This determines the access the entity requesting access has to the entry and/or attribute. Finally, slapd compares the access granted in the selected {{EX:}} clause to the access requested by the client. If it allows greater or equal access, access is granted. Otherwise, access is denied. The order of evaluation of access directives makes their placement in the configuration file important. If one access directive is more specific than another in terms of the entries it selects, it should appear first in the config file. Similarly, if one {{EX:}} selector is more specific than another it should come first in the access directive. The access control examples given below should help make this clear. H3: Access Control Examples The access control facility described above is quite powerful. This section shows some examples of its use. First, some simple examples: > access to * by * read This access directive grants read access to everyone. > access to * > by self write > by anonymous auth > by * read This directive allows users to modify their own entries, allows authenticate, and allows authenticated users to read. Note that only the first {{EX:by }} clause which matches applies. Hence, the anonymous users are granted {{EX:auth}}, not {{EX:read}}. The following example shows the use of a regular expression to select the entries by DN in two access directives where ordering is significant. > access to dn=".*,dc=example,dc=com" > by * search > access to dn=".*,dc=com" > by * read Read access is granted to entries under the {{EX:dc=com}} subtree, except for those entries under the {{EX:dc=example,dc=com}} subtree, to which search access is granted. If the order of these access directives was reversed, the trailing directive would never be reached, since all {{EX:dc=example,dc=com}} entries are also {{EX:dc=com}} entries. Also note that if no {{EX:access to}} directive matches or no {{EX:by }} clause, {{B:access is denied}}. That is, every {{EX:access to}} directive ends with a implicit {{EX:by * none}} clause and access list itself ends with {{EX:access to * by * none}} directive. Only if no access controls are specified, is the defaultaccess granted. The next example again shows the importance of ordering, both of the access directives and the {{EX:by }} clauses. It also shows the use of an attribute selector to grant access to a specific attribute and various selectors. > access to dn="(.*,)?dc=example,dc=com" attr=homePhone > by self write > by dn="(.*,)?dc=example,dc=com" search > by domain=.*\.example\.com read > access to dn="(.*,)?dc=example,dc=com" > by self write > by dn=".*,dc=example,dc=com" search > by anonymous auth This example applies to entries in the "dc=example, dc=com" subtree. To all attributes except homePhone, the entry itself can write them, other Example.com entries can search by them, anybody else has no access ((implicit {{EX:by * none}}) excepting for authentication/authorization (which is always done anonymously). The homePhone attribute is writable by the entry, searchable by other Example.com entries, readable by clients connecting from somewhere in the example.com domain, and otherwise not readable (implicit {{EX:by * none}}). All other access is denied by the implicit {{EX:access to * by * none}}. Sometimes it is useful to permit a particular DN to add or remove itself from an attribute. For example, if you would like to create a group and allow people too add and remove only their own DN from the member attribute, you could accomplish it with an access directive like this: > access to attr=member,entry > by dnattr=member selfwrite The dnattr {{EX:}} selector says that the access applies to entries listed in the member attribute. The selfwrite access selector says that such members can only add or delete their own DN from the attribute, not other values. The addition of the entry attribute is required because access to the entry is required to access any of the entry's attributes. Note that the attr=member construct in the {{EX:}} clause is a shorthand for the clause "{{EX:dn=.* attr=member}}" (i.e., it matches the member attribute in all entries). H2: Schema Enforcement The {{EX:objectclass}} and schemacheck configuration file directives can be used to enforce schema rules on entries in the directory. The schema rules are defined by one or more objectclass lines, and enforcement is turned on or off via the schemacheck directives. The format of an {{EX:objectclass}} line is: > objectclass This directive defines the schema rules for the object class given by {{EX:}}. Schema rules consist of the attributes the entry is required to have (given by the requires {{EX:}} clause) and those attributes that it may optionally have (given by the allows {{EX:}} clause). In both clauses, {{EX:}} is a comma-separated list of attribute names. Note that object class inheritance (that is, defining one object class in terms of another) is not supported directly. All of an object class's required and allowed attributes must be listed in the objectclass definition. For example, to define an objectclass called myPerson, you might include a definition like this: > objectclass myperson > requires cn, sn, objectclass > allows mail, phone, fax To then enforce this rule (i.e., to make sure an entry with an objectclass of myperson contains the cn, sn and objectclass attributes, and that it contains no other attributes besides mail, phone, and fax), turn on schema checking with a line like this: > schemacheck on 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 X.500 tree; both are LDBM 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 Line 1 is a comment. Lines 2 include another config file which containing {{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}}. The next section of the configuration file defines an LDBM 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. Indexes are to be maintained for several attributes, and the {{EX:userPassword}} attribute is to be protected from unauthorized access. E: 1. # ldbm definition for the U-M database E: 2. database ldbm E: 3. suffix "dc=example, dc=com" E: 4. directory /usr/local/var/openldap E: 6. rootdn "cn=Manager, dc=example, dc=com" E: 7. rootpw secret E: 8. replogfile /usr/local/var/openldap/slapd.replog E: 9. replica host=slave1.example.com:389 E: 10. binddn="cn=Replicator, dc=example, dc=com" E: 11. bindmethod=simple credentials=secret E: 12.replica host=slave2.example.com E: 13. binddn="cn=Replicator, dc=example, dc=com" E: 14. bindmethod=kerberos E: 15. srvtab=/etc/srvtab.slave2 E: 16.# ldbm indexed attribute definitions E: 17.index cn,sn,uid pres,eq,approx,sub E: 18.index objectclass pres,eq E: 19.index default none E: 20.# ldbm access control definitions E: 21.access to attr=userPassword E: 23. by self write E: 22. by anonymous auth E: 23. by dn="cn=Admin,dc=example,dc=com" write E: 25. by * none E: 26.access to * E: 27. by self write E: 28. by anonymous auth E: 29. by dn="cn=Admin,dc=example,dc=com" write E: 30. by * read Line 1 is a comment. The start of the database definition is marked by the database keyword on line 2. Line 3 specifies the DN suffix for queries to pass to this database. Line 4 specifies the directory in which the database files will live Lines 6 and 7 identify the database "super user" entry and associated password. This entry is not subject to access control or size or time limit restrictions. Lines 8 through 15 are for replication. Line 8 specifies the replication log file (where changes to the database are logged \- this file is written by slapd and read by slurpd). Lines 9 through 11 specify the hostname and port for a replicated host, the DN to bind as when performing updates, the bind method (simple) and the credentials (password) for the binddn. Lines 12 through 15 specify a second replication site, using kerberos instead of simple authentication. See Section 10 on slurpd for more information on these directives. Lines 16 through 19 indicate the indexes to maintain for various attributes. The default is not to maintain any indexes (line 19). Lines 20 through 30 specify access control for entries in the database. For all entries, the {{EX:userPassword}} attribute is writable by the entry and the "admin" entry, may be used for authentication/authorization purposes, but is otherwise not readable. All other attributes by writable by the entry and the "admin" entry, may be used for authentication/authorization purposes, but may be read by authenticated users. The next section of the example configuration file defines another LDBM database. This one handles queries involving the {{EX:dc=example,dc=net}} subtree. E: 1. # ldbm definition for Babs, Inc. database E: 2. database ldbm E: 3. suffix "dc=example, dc=net" E: 4. directory /usr/local/var/ldbm-example-net E: 5. rootdn "cn=Manager, dc=example, dc=net"