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.
37.3.1 Global Directives in slapd.conf
Example 37-2
slapd.conf: Include Directive for Schemes
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 37-2, specifies the scheme by which the
LDAP directory is organized. The entry core.schema is
required. Additionally required schemes are appended to this directive.
Find information in the included OpenLDAP documentation.
Example 37-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
with which the slapd process is started. There
is no need for modifications here.
Example 37-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 37-4 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—the first
rule slapd regards as valid is evaluated and
all following entries 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 37-2 are possible.
Table 37-2 User Groups and Their Access Grants
* |
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 37-3.
Table 37-3 Types 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 37-5 shows
an example of a simple access control that can be arbitrarily
developed using regular expressions.
Example 37-5
slapd.conf: Example for Access Control
access to dn.regex="ou=([^,]+),dc=suse,dc=de"
by dn.regex="cn=administrator,ou=$1,dc=suse,dc=de" 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.
HINT: 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 https://www.openldap.org/faq/data/cache/758.html for
information.
37.3.2 Database-Specific Directives in slapd.conf
Example 37-6
slapd.conf: Database-Specific Directives
database bdb
checkpoint 1024 5
cachesize 10000
suffix "dc=suse,dc=de"
rootdn "cn=admin,dc=suse,dc=de"
# Cleartext passwords, especially for the rootdn, should
# be avoided. See slappasswd(8) and slapd.conf(5) for details.
# Use of strong authentication encouraged.
rootpw secret
# The database directory MUST exist prior to running slapd AND
# should only be accessible by the slapd/tools. Mode 700 recommended.
directory /var/lib/ldap
# Indices to maintain
index objectClass eq
The type of database, a Berkeley database in this case, is set
in the first line of this section (see Example 37-6). 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. cachesize sets the number of objects kept in
the database's cache. suffix determines for which
portion of the LDAP tree this server should be responsible. The following
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. The administrator password is set with
rootpw. Instead of using secret here,
it is possible to enter the hash of the administrator password created by
slappasswd. The directory directive
indicates the directory in the file system where the database directories
are stored on the server. 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. Custom Access rules defined
here for the database are used instead of the global
Access rules.
37.3.3 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 37.4,
Data Handling in the LDAP Directory, 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 20.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 20.2.2,
Init Scripts.