Documentation
Chapter 26. LDAP—A Directory Service / 26.7. Manually Configuring an LDAP Server
Prev26.6. Browsing the LDAP Directory Tree26.8. Manually Administering LDAP DataNext

Manually Configuring an LDAP Server

Your installed system contains a complete configuration file for your LDAP server at /etc/openldap/slapd.conf. The single entries are briefly described here and necessary adjustments are explained. Entries prefixed with a hash (#) are inactive. This comment character must be removed to activate them.

Global Directives in slapd.conf

Example 26.2. slapd.conf: Include Directive for Schemas

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/rfc2307bis.schema
include         /etc/openldap/schema/yast.schema

This first directive in slapd.conf, shown in Example 26.2, “slapd.conf: Include Directive for Schemas”, specifies the Schema by which the LDAP directory is organized. The entry core.schema is required. Additionally required Schemas are appended to this directive. Find information in the included OpenLDAP documentation.

Example 26.3. slapd.conf: pidfile and argsfile

pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args

These two files contain the PID (process ID) and some of the arguments the slapd process is started with. There is no need for modifications here.

Example 26.4. slapd.conf: Access Control

# Sample Access Control
#       Allow read access of root DSE
# Allow self write access
#       Allow authenticated users read access
#       Allow anonymous users to authenticate
# access to dn="" by * read
  access to * by self write
              by users read
              by anonymous auth
#
# if no access controls are present, the default is:
#       Allow read by all
#
# rootdn can always write!

Example 26.4, “slapd.conf: Access Control” is the excerpt from slapd.conf that regulates the access permissions for the LDAP directory on the server. The settings made here in the global section of slapd.conf are valid as long as no custom access rules are declared in the database-specific section. These would overwrite the global declarations. As presented here, all users have read access to the directory, but only the administrator (rootdn) can write to this directory. Access control regulation in LDAP is a highly complex process. The following tips can help:

  • Every access rule has the following structure: 

    access to <what> by <who> <access>

  • what is a placeholder for the object or attribute to which access is granted. Individual directory branches can be protected explicitly with separate rules. It is also possible to process regions of the directory tree with one rule by using regular expressions. slapd evaluates all rules in the order in which they are listed in the configuration file. More general rules should be listed after more specific ones— slapd will apply the first rule that matches, and all the following rules are ignored.

  • who determines who should be granted access to the areas determined with what. Regular expressions may be used. slapd again aborts the evaluation of who after the first match, so more specific rules should be listed before the more general ones. The entries shown in Table 26.2, “User Groups and Their Access Grants” are possible.

    Table 26.2. User Groups and Their Access Grants

    Tag

    Scope

    *

    All users without exception

    anonymous

    Not authenticated (“anonymous”) users

    users

    Authenticated users

    self

    Users connected with the target object

    dn.regex=<regex>

    All users matching the regular expression


  • access specifies the type of access. Use the options listed in Table 26.3, “Types of Access”.

    Table 26.3. Types of Access

    Tag

    Scope of Access

    none

    No access

    auth

    For contacting the server

    compare

    To objects for comparison access

    search

    For the employment of search filters

    read

    Read access

    write

    Write access


    slapd compares the access right requested by the client with those granted in slapd.conf. The client is granted access if the rules allow a higher or equal right than the requested one. If the client requests higher rights than those declared in the rules, it is denied access.

Example 26.5, “slapd.conf: Example for Access Control” shows an example of a simple access control that can be arbitrarily developed using regular expressions.

Example 26.5. slapd.conf: Example for Access Control

access to  dn.regex="ou=([^,]+),dc=example,dc=com" 
by dn.regex="cn=Administrator,ou=$1,dc=example,dc=com" write  
by user read 
by * none

This rule declares that only its respective administrator has write access to an individual ou entry. All other authenticated users have read access and the rest of the world has no access.

[Tip]Establishing Access Rules

If there is no access to rule or no matching by directive, access is denied. Only explicitly declared access rights are granted. If no rules are declared at all, the default principle is write access for the administrator and read access for the rest of the world.

Find detailed information and an example configuration for LDAP access rights in the online documentation of the installed openldap2 package.

Apart from the possibility to administer access permissions with the central server configuration file (slapd.conf), there is access control information (ACI). ACI allows storage of the access information for individual objects within the LDAP tree. This type of access control is not yet common and is still considered experimental by the developers. Refer to http://www.openldap.org/faq/data/cache/758.html for information.

Database-Specific Directives in slapd.conf

Example 26.6. slapd.conf: Database-Specific Directives

database bdb1
suffix "dc=example,dc=com"2 
checkpoint      1024    53
cachesize       100004
rootdn "cn=Administrator,dc=example,dc=com"5 
# Cleartext passwords, especially for the rootdn, should 
# be avoided.  See slappasswd(8) and slapd.conf(5) for details. 
# Use of strong authentication encouraged.
rootpw secret6 
# The database directory MUST exist prior to running slapd AND 
# should only be accessible by the slapd/tools. Mode 700 recommended. 
directory /var/lib/ldap7 
# Indices to maintain 
index   objectClass     eq8
overlay ppolicy9
ppolicy_default "cn=Default Password Policy,dc=example,dc=com"
ppolicy_hash_cleartext
ppolicy_use_lockout

1

The type of database, a Berkeley database in this case, is set in the first line of this section (see Example 26.6, “slapd.conf: Database-Specific Directives”).

2

suffix determines for which portion of the LDAP tree this server should be responsible.

3

checkpoint determines the amount of data (in KB) that is kept in the transaction log before it is written to the actual database and the time (in minutes) between two write actions.

4

cachesize sets the number of objects kept in the database's cache.

5

rootdn determines who owns administrator rights to this server. The user declared here does not need to have an LDAP entry or exist as regular user.

6

rootpw sets the administrator password. Instead of using secret here, it is possible to enter the hash of the administrator password created by slappasswd.

7

The directory directive indicates the directory in the file system where the database directories are stored on the server.

8

The last directive, index objectClass eq, results in the maintenance of an index of all object classes. Attributes for which users search most often can be added here according to experience.

9

overlay ppolicy adds a layer of password control mechanisms. ppolicy_default specifies the DN of the pwdPolicy object to use when no specific policy is set on a given user's entry. If there is no specific policy for an entry and no default is given, no policies are enforced. ppolicy_hash_cleartext specifies that clear text passwords present in add and modify requests are hashed before being stored in the database. When this option is used, it is recommended to deny compare, search, and read access to the userPassword attribute for all directory users, because ppolicy_hash_cleartext violates the X.500/LDAP information model. ppolicy_use_lockout sends a specific error code when a client tries to connect to a locked account. When your site is sensitive to security issues, disable this option as the error code provides useful information to attackers.

Custom Access rules defined here for the database are used instead of the global Access rules.

Starting and Stopping the Servers

Once the LDAP server is fully configured and all desired entries have been made according to the pattern described in Section 26.8, “Manually Administering LDAP Data”, start the LDAP server as root by entering rcldap start. To stop the server manually, enter the command rcldap stop. Request the status of the running LDAP server with rcldap status.

The YaST runlevel editor, described in Section 14.2.3, “Configuring System Services (Runlevel) with YaST”, can be used to have the server started and stopped automatically on boot and halt of the system. It is also possible to create the corresponding links to the start and stop scripts with the insserv command from a command prompt as described in Section 14.2.2, “Init Scripts”.

Prev26.6. Browsing the LDAP Directory TreeHome26.8. Manually Administering LDAP DataNext