Skip Headers

Oracle9i Directory Service Integration and Deployment Guide
Release 2 (9.2)

Part Number A96579-01
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index


Go to previous page Go to next page

Directory Server Concepts

This chapter lays a foundation for understanding LDAP-compliant directories. It begins by describing the function of directories--be they paper based or electronic--proceeds through a definition of the LDAP protocol, version 3, and ends by identifying the fundamental components of an online directory.

The chapter covers the following topics:

What Is a Directory?

A directory is an index or list that helps people find information. The directories most familiar to us are offline, usually paper based, resources like telephone books and yellow pages, merchandise catalogs, card catalogs in libraries, and dictionaries.

What Is an Online Directory?

Online directories are computer databases that serve much the same function that offline directories do, but add the following benefits.

These added benefits make online directories ideal for storing critical information at large companies. Typical entries in an online directory include employee names, enterprise roles, e-mail addresses, and information about printers, conference rooms and other company resources.

Directories and Relational Databases Compared

It is easy to confuse a directory with a relational database, because a directory is, after all, a special kind of database. But there are some significant differences between the two, as Table 2-1 shows.

Table 2-1 Directories Versus Relational Databases
Directories Relational Databases

Read more frequently than written

Written more frequently than read

Handle small, simple units of data

Handle large, complex, transaction-oriented units of data

Distributed widely

Not distributed widely

Store information in hierarchically arranged entries

Store information as records in relational tables

Read-to-Write Ratio

A directory is sometimes read 1,000 to 10,000 times more than it is written. That is because it stores information that is updated infrequently, but accessed constantly--information such as user IDs, e-mail addresses, and catalog data. Relational databases by contrast serve as repositories for data that changes frequently, such sales orders, salaries, and student grades. As a result, they are written to frequently, but read infrequently.

Data Units

Directory objects are generally small because they must be representable in an attribute format--for example, surname=hay. This feature optimizes the directory for searching. Databases by contrast can accommodate large objects.


Directory applications expect at all times to see the same information throughout the deployment environment--regardless of which server they are querying. If a queried server does not store the information locally, then it must either retrieve the information or point the client application to it transparently. A relational database, while it can be distributed, usually resides on a particular server.


Just as the small size of directory objects optimizes the directory for searching, so too does the way the objects are stored. Represented as a discrete entry in a directory information tree, each piece of directory data can be retrieved quickly. A database search operation, on the other hand, is more suitable for relational transactions--that is, transactions that encompass several pieces of data and several tables.

Typical Directory Applications

Common directory applications include the following:

The Benefits of Standards-Based Online Directories

The primary benefit of online directories is that they can centralize the storage of information. This feature is critical in a distributed database environment, and it cannot be accomplished without a common standard that governs how enterprise applications interact with directories. Without such a standard, large companies might have to deploy hundreds of application-specific directories, all equipped with their own protocols. Collectively, these application-specific directories pose three major problems:

These problems become apparent when, for example, an employee leaves a company or transfers to another department. When this happens, network administrators might have to disable multiple accounts on multiple databases.The time required to effect these changes and the difficulty involved in synchronizing them across databases is an administrative burden and also a security risk.

Fortunately, Lightweight Directory Access Protocol (LDAP) eases the burden of managing application-specific directories.

What Is LDAP?

LDAP is a standard, extensible directory access protocol that enables directory clients and servers to interact using a common language. LDAP, as the name suggests, is a lightweight implementation the X.500 Directory Access Protocol (DAP), first published in 1990. The X.500 protocol grew out of a need for a directory model that bridged applications and operating systems. However, it proved cumbersome, partly because it runs over the OSI networking stack. LDAP by contrast runs directly over TCP/IP, which is popular, fast, simple, and relatively inexpensive to implement.

This section contains the following topics:

The Benefits of LDAP

LDAP simplifies directory management in the following ways.

LDAP Version 3

The most recent version of the LDAP protocol is version 3, which in December 1997 was approved as an Internet standard. Version 3 improves on version 2 in fìve ways.


The C LDAP API, introduced with LDAP version 2, provides a standard API for accessing and modifying directory entries from the command line. The API offers the programmer of an LDAP-enabled application a set of functions that covers every LDAP protocol operation.

APIs for the Java and Perl programming languages are also available.

See Also:


Lightweight Directory Interchange Format (LDIF) is a text-based format used to describe and modify--change, add, and delete--directory entries. In the latter capacity, it provides input to command-line utilities.

The two LDIF files immediately following represent a directory entry for a printer. The string in the first line of each entry is the entry's name, called a distinguished name. The difference between the files is that the first describes the entry--that is, the format is an index of the information that the entry contains. The second, when used as input to the command-line utility ldapmodify, adds information about the speed of the printer.


dn: cn=LaserPrinter1, ou=Devices, dc=acme,dc=com
objectclass: top
objectclass: printer
objectclass: epsonPrinter
cn: LaserPrinter1
resolution: 600
description: In room 407


dn: cn=LaserPrinter1, ou=Devices, dc=acme, dc=com
changetype: modify
add: pagesPerMinute
pagesPerMinute: 6

Directory Information Flow: An Example

To visualize how information is retrieved from an LDAP-compliant directory, consider how the process works in Oracle Internet Directory:

  1. The client issues a search request, using either a graphical user interface (GUI) tool or a command-line tool and one or more authentication methods.
  2. The command-line tool or the GUI tool invokes the C API, directly if the command-line tool is used and by way of the Java Native Interface if the GUI tool is used.
  3. The search request is transmitted to the directory server using the LDAP protocol.
  4. The directory server authenticates, or binds, the client and then checks access control lists (ACLs) to determine whether it can grant the client's request.
  5. The directory server transmits the request to the database server, using the remote database access software Oracle Net to convert the search request from LDAP to language that the database can understand.
  6. The database retrieves the requested information, sending it back to the directory server, back to the C API, and back to the client.

Figure 2-1 illustrates the process.

Figure 2-1 Information Flow for Oracle Internet Directory

Text description of dirig001.gif follows
Text description of the illustration dirig001.gif

Directory Components and Features

This section describes the information that a directory contains. It explains how this information is organized and who gains access to it. The section contains the following topics:


In a directory, each collection of information about an object is called an entry. This object may be a person, but it can also be a printer or other shared resource, a department within a company, or even the company itself.

To name it and to identify its location in the directory hierarchy, each entry is assigned a unique distinguished name (DN). The DN of an entry consists of the entry itself, known as the relative distinguished name (RDN), and its parent entries, connected in ascending order, from the entry itself up to the root (top) entry in the tree. Collectively, these entries form a directory information tree (DIT) such as the one shown in Figure 2-2. A directory server uses this tree to determine what information to extract from a relational, or other, database.

Figure 2-2 Directory Information Tree with a Distinguished Name Highlighted

Text description of dirig017.gif follows
Text description of the illustration dirig017.gif

Figure 2-2 represents a portion of a DIT belonging to the company acme, designated by the entry dc (domain component) =acme, dc=com. The highlighted DN uid=jhay, ou=Human Resources, ou=People, dc=acme, dc=com is an entry within the DIT.


Spaces after commas are optional for DNs.

This entry represents the user ID (uid) for a person belonging to the organizational unit (ou) Human Resources in the company acme.

The format of a DN places the lowest hierarchical component of the name, the RDN, to the extreme left. In the example, this RDN is uid=jhay.


An entry consists of a set of attributes, each describing a unique feature of the entry. An attribute consists of two components, an attribute type and one, or sometimes more, values. Table 2-2 lists, in LDIF notation, some of the attributes that the entry uid=jhay, ou=Human Resources, ou=People, dc=acme, dc=com might contain.

Table 2-2 A Typical Directory Entry with Attributes Shown
Attribute Type Attribute Value


John Hay


Jack Hay









+1 650 555 0167

Note that LDAP permits some of the attributes listed to be abbreviated. The attribute cn could just as easily have been written as commonName, and the attribute sn as surname.

Types of Attributes

Attributes take two forms: user and operational. The former are application specific and can be retrieved and modified by the user. The latter are used to control directory operations and are generally not available to the user. Examples of user attributes include commonName, surname, telephoneNumber, and mail. Examples of operational attributes include the following:

Attribute Syntaxes and Matching Rules

Under LDAP rules, each attribute type must conform to a particular syntax and associated matching rule. A syntax determines the form that an attribute value takes. A matching rule specifies how attribute values are compared in directory searches.

Table 2-3 lists common syntaxes and associated matching rules defined by the X.500 standard.

Table 2-3 Attribute Syntaxes and Associated Matching Rules
Syntax Matching Rule


Text string


Ignore letter case and leading, trailing, and multiple spaces


Match case of letters. Ignore letter case and leading, trailing, and multiple spaces


Text string for a telephone number


The same as caseIgnoreMatch, but it also ignores space and hypen characters




Follow rules for comparing integers


Directory names


Follow special rules for comparing DNs


Binary data


Compare data byte by byte



Your directory might use different names for syntaxes and matching rules depending upon the kind of schema format that it uses to describe entries.

Suppose that you are searching the directory for an employee named Kit Karston. Following X.500 rules, the syntax used to represent this name is DirectoryString. The matching rule can be either caseIgnoreMatch or caseExactMatch. If it is the former, you might enter the name as (cn=kit karston) or (cn=kitKarston) or even (cn= kit karston). In all cases, the directory returns the name.

Foreign-Language Options for Attributes

In addition to containing multiple values, attributes can store language codes. This feature is useful for accessing text in the many languages that LDAP supports. For example, the attribute cn;lang-ja represents a common name in Japanese. Note that a semicolon separates the attribute type and the value.

You can also specify that the directory return attributes in a given dialect. For example, the language code lang-en-GB, returns attribute values in British English.

Object Classes

An object class is a collection of attributes that you use to define an entry. Some of these attributes are mandatory; others are optional.

If, for example, you assign the LDAP-defined object class organizationalPerson to the entry uid=jhay, ou=Human Resources, ou=People, dc=acme, dc=com, you must include commonName (cn) and surname (sn) as attributes for the entry. Rules for the object class organizationalPerson also allow you to include the attributes telephoneNumber, uid, and userPassword, but these are not required.

Excluding optional attributes, the entry preceding might look something like this in LDIF notation:

dn: uid=jhay, ou=Human Resources, ou=People, dc=acme, dc=com
objectclass: top
objectclass: person
objectclass: organizationalPerson
cn: John Hay
cn: Jack Hay
sn: Hay

Note that three object classes are present in the entry, an indication that object subclasses are represented. In this case, organizationalPerson is a subclass of the object class person, which is a subclass of the object class, top.

In addition to defining the attributes of an entry, object classes provide a way of locating a related group of entries. To restrict your directory search to printers housed in a certain area of your organization, for instance, your directory access GUI might construct an LDAP search filter that uses an AND operator to combine the object class printer with the attribute description, which might contain a value for the location of the printers.

See Also:

"Creating New Object Classes and Redefining Old Ones", for a discussion of object subclasses

Types of Object Classes

Object classes take three forms:

Structural Object Classes

Most of the object classes in a directory are structural, because they define what an entry is. They also impose rules on the entries that are stored beneath them. For example, the object class organization (o) might require that all objects stored beneath it belong to the object class organizational units (ou). Other examples of structural object classes are person, printer, and groupOfNames.

Auxiliary Object Classes

LDAP rules require each entry to belong to one, and only one, structural class, but an entry can also belong to one or more auxiliary classes. An auxiliary class, as its name suggests, is used to add attributes to entries that are already defined by a structural object class. Note that an auxiliary class cannot stand on its own in an entry. The entry must also contain a structural object class. Unlike structural object classes, auxiliary classes place no restrictions on where an entry is stored.

Abstract Object Classes

The third type of object class, abstract, is a class whose primary function is to determine the structure of an LDAP directory. The object class top, for example, is the root object class from which all structural object classes are derived. It contains one mandatory attribute, objectClass, and because all entries inherit its attributes, it ensures that these entries are defined by an object class. An abstract object class cannot stand alone in an entry. The entry must also contain a structural object class.


Some directory vendors may not distinguish between object class types and therefore may not enforce structure rules.

Creating New Object Classes and Redefining Old Ones

LDAP enables you to create entirely new structural object classes and attributes to accommodate new objects in a directory. The challenge in creating new object classes is to come up with unique names because object class and attribute namespaces are flat.

A far more common--and easier--practice is to create subclasses of existing classes, which then become superclasses. This feature provides a way of adding mandatory, as well as optional attributes to a predefined object class. A subclass inherits all of the attributes of a superclass, and because an entry can contain more than one object class, it can inherit numerous attributes.

The object class printer, for example, might have the object class epsonPrinter as a subclass to provide information about a specific kind of printer that an organization uses.

Auxiliary object classes provide the easiest, most flexible method for redefining existing directory entries because you are not required to subclass them to specific object classes and can use them to add attributes to any number of entries. An object class that can be used to add uniform resource locaters (URLs) to any directory entry is a good example of an auxiliary object class.

Naming Contexts

A naming context is a DIT that resides entirely on one server. It can consist of a single entry, a subtree, or even the entire DIT. Any directory entry can serve as the root of a naming context as long as the entries below it are contiguous with it. These subordinate entries can be either leaf entries or naming contexts in their own right.

Some, but not all, of the naming and non-naming contexts in Figure 2-3 are highlighted. Naming contexts are indicated by solid-line circles, non-naming contexts by dotted-line circles.

Figure 2-3 Naming Contexts and Non-Naming Contexts

Text description of dirig013.gif follows
Text description of the illustration dirig013.gif

To enable you to specify specific naming contexts as search targets, LDAP enables you to publish them in a directory's root DSE (directory server-specific entry). You publish a naming context by assigning the root, or topmost entry, of the context as a value to an attribute called namingContexts.


The schema of a directory comprises the metadata that determine what objects a directory can store. The metadata of a directory are its object classes, attribute types, attribute syntaxes, and matching rules.

The schema of a directory typically amounts to dozens of object classes, hundreds of attributes, and a dozen or fewer syntaxes.

To facilitate directory navigation and modification, LDAP version 3 requires directories to publish their schema in an operational attribute called subschemaSubentry, located in a directory server's root DSE (directory server-specific entry). This attribute is analogous to the data dictionary of a relational database. It is in the entry subschemaSubentry that you add new object classes and attributes and redefine existing object classes.

See Also:

Appendix A, "Oracle-Specific LDAP Schema Extensions"


Gaining access to a directory is a two-part process that consists of using one or more authentication methods to establish the identity of a directory client and then using access control lists (ACLs) to determine what kind of information clients can access and what they can do with it once they have accessed it.


LDAP version 3 supports four levels of authentication:

Access Control Lists

Once you gain access to a directory, a mechanism called an access control list (ACL) determines what kind of information you are able to retrieve and modify.

An ACL consists of one or more operational attributes called ACIs (access control items). These ACIs specify permissions for an entry. Theoretically, you can place an ACL anywhere in the directory hierarchy, down to the level of an entry. In reality, ACL placement is subject to whatever restrictions your directory software imposes. An ACL specifies three things:

The following example shows the format of an ACL that is constructed using the command line tool ldapmodify. This ACL is based on the Oracle Internet Directory attribute orclEntryLevelACI, which sets access control rules for one entry only.

dn: uid=jhay, ou=Human Resources, ou=People, dc=acme, dc=com
changetype: modify
replace: orclentrylevelaci:
orclentrylevelaci: access to entry
 by dn= "cn=directory manager, dc=acme, dc=com" (browse, add, delete)
 by *  (browse, noadd, nodelete)
orclentrylevelaci: access to attr=(*)
 by dn= "cn=directory manager, dc=acme, dc=com" (search, read, write, 
 by * (search, read, nowrite, nocompare)

The ACL above consists of two ACIs (in boldface) that set access control rules for the entry uid=jhay, ou=Human Resources, ou=People, dc=acme, dc=com. These ACIs give directory managers falling within the domain dc=acme, dc=com read and modify privileges over the entry and its attributes. They give all other users, designated by the wildcard "*" read but not write privileges. The entity assigned privileges by an ACI can be a privilege group as well as an individual.

The Oracle Context

A directory stores all information pertaining to Oracle software under one or more entries called an Oracle Context, which has an RDN of cn=OracleContext. You can create an Oracle Context under any entry in the DIT. To help you, Oracle Net Configuration Assistant, an Oracle tool for configuring directory access, displays a list of published entries as suggested locations. If you are using Oracle Internet Directory, a starter Oracle Context is created when the directory is installed.

A starter Oracle Context, as Figure 2-4 illustrates, is a directory subtree that, at the top level, consists of four containers--Products, Groups, Services, and Computers--and entries for three of the administrative groups applicable to the entire context. The only product-related entries installed at this stage are entries for enterprise user security and Enterprise Security Manager, a GUI tool.

After using Oracle Net Configuration Assistant to configure access to a directory, you can use another tool, Database Configuration Assistant, to register databases. Registration adds entries for database servers and their associated Oracle Net connect descriptors.

Figure 2-4 Starter Oracle Context with Added Entries for a Database and a Database Connect Descriptor

Text description of dirig006.gif follows
Text description of the illustration dirig006.gif

Table 2-4 shows the contents of the four containers represented in Figure 2-4.

Table 2-4 Containers Under the Oracle Context
Container Description


The Products container is the repository for product-specific entries for every Oracle product except Oracle Net Services and Oracle Advanced Queuing. The entries in this container are private to the product and may be protected by access control policies. The entry Common (cn=Common) stores attributes common to all objects--for instance, attributes that uniquely identify a user.


The Groups container stores entries for the administrative groups applicable to the entire Oracle Context. At present, these groups are OracleContextAdmins, OracleUserSecurityAdmins, and OraclePasswordAccessibleDomains. Entries for the groups OracleNetAdmins, OracleDBCreators, and OracleDBSecurityAdmins appear just below the Oracle Context.


The Services container stores entries for the services offered by Oracle products. Storing these entries separately facilitates discovery of required services. In the future, Services will be a repository for database server entries.


The Computers container stores entries containing information about each machine--for example, configuration information for a particular server running in a particular Oracle home on a particular machine.

See Also:

Go to previous page Go to next page
Copyright © 2002 Oracle Corporation.

All Rights Reserved.
Go To Documentation Library
Go To Product List
Book List
Go To Table Of Contents
Go To Index

Master Index