If installation is as expected, you are now ready to configure
slapd. The configuration file is called
can be found at the
directory. Open this file with your favorite text editor.
You should see the following lines.
database ldbm suffix "dc=<MY-DOMAIN>,dc=<COM>" rootdn "cn=Manager,dc=<MY-DOMAIN>,dc=<COM>" rootpw secret directory /usr/local/var/openldap-ldbm
You need to edit the <MY-DOMAIN> and the <COM> parts to reflect your domain name. Using the correct names ensures that your LDAP server can be accessed from the Internet.
For example, for the brainysoftware.com domain, the configuration lines will look like
database ldbm suffix "dc=brainysoftware,dc=com" rootdn "cn=Manager,dc=brainysoftware,dc=com" rootpw secret directory /usr/local/var/openldap-ldbm
If your domain contains additional components -- like
sandal.jepit.edu.au -- do something like
database ldbm suffix "dc=sandal,dc=jepit,dc=edu,dc=au" rootdn "cn=Manager,dc=sandal,dc=jepit,dc=edu,dc=au" rootpw secret directory /usr/local/var/openldap-ldbm
The fourth line (
rootpw secret) contains the root password
that you need to supply to the server to make changes to the entries and do
some other functions.
Running slapd requires root access, so run
su root -c /usr/local/libexec/slapd
if you're already logged in as root.
To check that the server is running and configured correctly, you
can search it with
ldapsearch. By default,
ldapsearch is installed as
/usr/local/bin/ldapsearch. Use the following command:
ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts
The Schema file
An important file in an LDAP server is the schema file, which, for
slapd, is called
core.schema, located at
contains the directory schema of the LDAP server.
A directory schema specifies, among other things, the types of objects that a directory may have and the attributes that are mandatory and optional to that object. A directory schema also contains attribute type definitions, object class definitions, and other information which a server uses to determine how to match a filter or attribute value assertion against the attributes of an entry, and whether to permit add and modify operations.
The LDAP v3 schema is based on the X.500 standard for common objects found in a network like countries, localities, organizations, users/persons, groups and devices.
All LDAP entries in the directory are typed. Each entry belongs to
object classes that identify the type of data represented by the
entry. The object class specifies the mandatory and optional
attributes that can be associated with an entry of that class. The
object classes for all objects in the directory form a class
hierarchy. The classes
alias are at
the root of the hierarchy. For example, the
organizationalPerson object class is a subclass of the
Person object class, which in turn is a subclass of
top. When creating a new LDAP entry, you must always
specify all of the object classes to which the new entry
belongs. Because many directories do not support object class
subclassing, you also should always include all of the superclasses of
Three types of object classes are possible:
- Structural. Indicates the attributes that the entry may have and where each entry may occur in the DIT.
- Auxiliary. Indicates the attributes that the entry may have.
- Abstract. Indicates a "partial" specification in the object class hierarchy; only structural and auxiliary subclasses may appear as entries in the directory.
For example, for an
organizationalPerson object, you
should list in its object classes the
top classes. The
top objects are listed as the
following entries in the
objectclass ( 126.96.36.199 NAME 'top' ABSTRACT MUST objectClass ) objectclass ( 188.8.131.52 NAME 'person' SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) ) objectclass ( 184.108.40.206 NAME 'organizationalPerson' SUP person STRUCTURAL MAY ( title $ x121Address $ registeredAddress $ destinationIndicator $ preferredDeliveryMethod $ telexNumber $ teletexTerminalIdentifier $ telephoneNumber $ internationaliSDNNumber $ facsimileTelephoneNumber $ street $ postOfficeBox $ postalCode $ postalAddress $ physicalDeliveryOfficeName $ ou $ st $ l ) )
LDAP v3 specifies that each directory entry may contain an operational attribute that identifies its subschema subentry. A subschema subentry contains the schema definitions for the object classes and attribute type definitions used by entries in a particular part of the directory tree. If a particular entry does not have a subschema subentry, then the subschema subentry of the root DSE, which is named by the empty DN, is used. For more information about the schema, refer to RFCs 2252 and 2256.