Developing A White Pages Service with LDAP and JNDI
Pages: 1, 2, 3, 4, 5, 6, 7

Configuring slapd

If installation is as expected, you are now ready to configure slapd. The configuration file is called slapd.conf and can be found at the /usr/local/etc/openldap/ 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

Running slapd requires root access, so run

su root -c /usr/local/libexec/slapd

or

/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 /usr/local/openldap-2.0.7/etc/openldap/schema/. It 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.

The LDAP v3 schema is specified in RFC 2252 and RFC 2256.

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 top and 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 the entry.

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 organizationalPerson, person, and top classes. The organizationalPerson, person, and top objects are listed as the following entries in the core.schema file.

objectclass ( 2.5.6.0 NAME 'top' ABSTRACT
  MUST objectClass )

objectclass ( 2.5.6.6 NAME 'person' SUP top STRUCTURAL
  MUST ( sn $ cn )
  MAY ( userPassword $ telephoneNumber $ seeAlso $ description )
)

objectclass ( 2.5.6.7 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.

Pages: 1, 2, 3, 4, 5, 6, 7

Next Page