(M)  s i s t e m a   o p e r a c i o n a l   m a g n u x   l i n u x ~/ · documentação · suporte · sobre

  Next Previous Contents

3. Configuring the LDAP Server

Once the software has been installed and built, you are ready to configure it for use at your site. All slapd runtime configuration is accomplished through the slapd.conf file, installed in the prefix directory you specified in the configuration script or by default in /usr/local/etc/openldap.

This section details the commonly used configuration directives on slapd.conf. For a complete list, see slapd.conf(5) manual page. The configuration file directives are separated into global, backend-specific and data-specific categories. Here you will find descriptions of directives, together with their default values (if any) and with examples of their use.

3.1 Configuration File Format

The slapd.conf 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 a backend and/or database directives, backend directives can be overridden by database directives.

Blank lines and comment lines beginning with a '#' 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
<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 white space. If an argument contains white space, the argument should be enclosed in double quotes "like this". If an argument contains a double quote or a backslash character `\', the character should be preceded by a backslash character `\'.

The distribution contains an example configuration file that will be installed in the /usr/local/etc/openldap directory. A number of files containing schema definitions (attribute types and object classes) are also provided in the /usr/local/etc/openldap/schema directory.

3.2 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 <>.

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 requesters (specified by <who>). See the Access Control
examples for more details.

attributetype <RFC2252 Attribute Type Description>

This directive defines an attribute type.

defaultaccess { none | compare | search | read | write }

This directive specifies the default access to grant requesters when no access directives have been 
specified. Any given access level implies all lesser access levels (e.g., read access implies search 
and compare but not write).

Default:
defaultaccess read

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.

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.

loglevel <integer>

This directive specifies the level at which debugging statements and operation statistics should be syslogged (currently logged to the syslogd(8) LOCAL4 facility). You must have configured OpenLDAP --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 -? or consult the table below. The possible values for <integer> are:

-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 

Example: 
loglevel 255 or loglevel -1
This will cause lots and lots of debugging information to be syslogged. 
Default: 
loglevel 256 

objectclass <RFC2252 Object Class Description>

This directive defines an object class.

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.

sizelimit <integer>

This directive specifies the maximum number of entries to return from a search operation.

Default:
sizelimit 500

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

3.3 General Backend Options

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.

backend <type>

This directive marks the beginning of a backend definition. <type> should be one of 
ldbm, shell, passwd, or other supported backend type.

3.4 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.

database <type>

This directive marks the beginning of a new database instance definition. <type> should be one of
ldbm, shell, passwd, or other supported database type.

Example:
database ldbm

This marks the beginning of a new LDBM backend database instance definition.

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

replica

replica host=<hostname>[:<port>] [bindmethod={ simple | kerberos | sasl }] ["binddn=<DN>"] [mech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<password>] [srvtab=<filename>]

This directive specifies a replication site for this database. The 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 <hostname>. If <port> is not given, the standard LDAP port number (389) is used.

The 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 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 "binddn=<DN>" string should be enclosed in double quotes.

The bindmethod is simple or kerberos or sasl, depending on whether simple password-based authentication
or Kerberos authentication or SASL authentication is to be used when connecting to the slave slapd.

Simple authentication should not be used unless adequate integrity and privacy protections are in
place (e.g. TLS or IPSEC). Simple authentication requires specification of binddn and credentials parameters.

Kerberos authentication is deprecated in favor of SASL authentication mechanisms, in particular the
KERBEROS_V4 and GSSAPI mechanisms. Kerberos authentication requires binddn and srvtab parameters.

SASL authentication is generally recommended. SASL authentication requires specification of a mechanism 
using the mech parameter. Depending on the mechanism, an authentication identity and/or credentials can
be specified using authcid and credentials respectively. The authzid parameter may be used to specify 
an authorization identity.

replogfile <filename>

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.

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 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@EXAMPLE.COM"

rootpw <password>

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 deprecated in favor of SASL based authentication.

Example:
rootpw secret

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. 

updatedn <dn>

This directive is only applicable in a slave slapd. It specifies the DN allowed to make changes to the 
replica. This may be the DN slurpd(8) binds as when making changes to the replica or the DN associated
with a SASL identity.

Entry-based Example:
updatedn "cn=Update Daemon, dc=example, dc=com"

SASL-based Example:
updatedn "uid=slurpd@EXAMPLE.COM"

updateref <URL>

This directive is only applicable in a slave slapd. It specifies the URL to return to clients which 
submit update requests upon the replica. If specified multiple times, each URL is provided.

Example:
update  ldap://master.example.net

3.5 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.

cachesize <integer>

This directive specifies the size in entries of the in-memory cache maintained by the LDBM backend database instance.

Default:
cachesize 1000

dbcachesize <integer>

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

dbnolocking

This option, if present, disables database locking. Enabling this option may improve performance at
the expense of data security.

dbnosync

This option causes on-disk database contents not be immediately synchronized with in memory changes upon change. 
Enabling this option may improve performance at the expense of data security.

directory <directory>

This directive specifies the directory where the LDBM files containing the database and associated indexes live.

Default:
directory /usr/local/var/openldap-ldbm

index {<attrlist> | default} [pres,eq,approx,sub,none]

This directive specifies the indexes to maintain for the given attribute. If only an <attrlist> is given, 
the default indexes are maintained.

Example:
index default pres,eq
index objectClass,uid
index cn,sn eq,sub,approx

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 objectClass and uid attribute types. 
The third line causes equality, substring, and approximate indices to be maintained for cn and sn attribute types.

mode <integer>

This directive specifies the file protection mode that newly created database index files should have.

Default:
mode 0600

3.6 Other Backend Databases

slapd supports a number of backend database types besides the default LDBM:

  • ldbm: Berkeley or GNU DBM compatible backend
  • passwd: Provides read-only access to /etc/passwd
  • shell: Shell (extern program) backend
  • sql: SQL Programmable backend

Take a look on the slapd.conf(5) manpage for details.

3.7 Access Control Examples

The access control facility presented on section 3.2 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. If it appears alone it is the same as the following defaultaccess line.

defaultaccess 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=".*, o=U of M, c=US" 
by * search 
access to dn=".*, c=US" 
by * read 

Read access is granted to entries under the c=US subtree, except for those entries under the "o=University of Michigan, c=US" subtree, to which search access is granted. If the order of these access directives was reversed, the U-M-specific directive would never be matched, since all U-M entries are also c=US entries.

The next example again shows the importance of ordering, both of the access directives and the "by" clauses. It also shows the use of an attribute selector to grant access to a specific attribute and various <who> selectors.

access to dn=".*, o=U of M, c=US" attr=homePhone 
by self write 
by dn=".*, o=U of M, c=US" search 
by domain=.*\.umich\.edu read 
by * compare 
access to dn=".*, o=U of M, c=US" 
by self write 
by dn=".*, o=U of M, c=US" search 
by * none 

This example applies to entries in the "o=U of M, c=US" subtree. To all attributes except homePhone, the entry itself can write them, other U-M entries can search by them, anybody else has no access. The homePhone attribute is writable by the entry, searchable by other U-M entries, readable by clients connecting from somewhere in the umich.edu domain, and comparable by everybody else.

Sometimes it is usefull 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 <who> 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 <what> clause is a shorthand for the clause "dn=* attr=member" (i.e., it matches the member attribute in all entries).

Note: Take a look on OpenLDAP Administrator's Guide at http://www.openldap.org to learn more about Access Control on Ldap.

3.8 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:

  1.    # example config file - global configuration section
  2.    include /usr/local/etc/schema/core.schema
  3.    referral ldap://root.openldap.org
  4.    access to * by * read

Line 1 is a comment. Line 2 includes another config file which containing core schema definitions. The 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 root.openldap.org.

Line 4 is a global access control. It is used only if no database access controls match or when the target objects are not under the control of any database (such as the Root DSE).

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 userPassword attribute is to be protected from unauthorized access.

  5.    # ldbm definition for the example.com
  6.    database ldbm
  7.    suffix "dc=example, dc=com"
  8.    directory /usr/local/var/openldap
  9.    rootdn "cn=Manager, dc=example, dc=com"
 10.    rootpw secret
 11.    # replication directives
 12.    replogfile /usr/local/var/openldap/slapd.replog
 13.    replica host=slave1.example.com:389
 14.            binddn="cn=Replicator, dc=example, dc=com"
 15.            bindmethod=simple credentials=secret
 16.    replica host=slave2.example.com
 17.            binddn="cn=Replicator, dc=example, dc=com"
 18.            bindmethod=simple credentials=secret
 19.    # indexed attribute definitions
 20.    index uid pres,eq
 21.    index cn,sn,uid pres,eq,approx,sub
 22.    index objectClass eq
 23.    # ldbm access control definitions
 24.    access to attr=userPassword
 25.            by self write
 26.            by anonymous auth
 27.            by dn="cn=Admin,dc=example,dc=com" write
 28.            by * none
 29.    access to *
 30.            by dn="cn=Admin,dc=example,dc=com" write
 31.            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 11 through 18 are for replication. Line 11 specifies the replication log file (where changes to the database are logged - this file is written by slapd and read by slurpd). Lines 12 through 14 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 15 through 18 specify a second replication site.

Lines 20 through 22 indicate the indexes to maintain for various attributes.

Lines 24 through 31 specify access control for entries in the database. For all entries, the 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 "admin" entry and may be read by authenticated users.

The next section of the example configuration file defines another LDBM database. This one handles queries involving the dc=example,dc=net subtree. Note that without line 37, the read access would be allowed due to the global access rule at line 4.

 32.    # ldbm definition for example.net
 33.    database ldbm
 34.    suffix "dc=example, dc=net"
 35.    directory /usr/local/var/ldbm-example-net
 36.    rootdn "cn=Manager, dc=example, dc=com"
 37.    access to * by users read


Next Previous Contents