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.
26.7.1 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, 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 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 are possible.
Table 26-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 26-3.
Table 26-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 26-5 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.
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.
26.7.2 Database-Specific Directives in slapd.conf
|
The type of database, a Berkeley database in this case, is set in the
first line of this section (see
Example 26-6).
|
|
suffix determines for which portion of the LDAP
tree this server should be responsible.
|
|
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.
|
|
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.
|
|
rootpw sets the administrator password. 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.
|
|
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.
26.7.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 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.
