2
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.

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.

Flexibility

Online directories can organize data in many different ways, allowing users to specify different search criteria.

Security

Online directories centralize data, making it easier to manage and to restrict access to it.

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.

Distribution

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.

Entries

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:

Online telephone books

These might serve as a repository not only for phone numbers, but for e-mail addresses and employee names.

These require detailed information about people, information that is easily stored in a directory. This information consists of employee identification numbers, birth dates, salary levels, hire dates, and job titles.

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:

Inconsistent data: Information that is updated in one directory might not be updated in others.

Data redundancy: Entries must be duplicated across directories.

Administrative headaches: Application-specific directories increase the time and cost of managing them because directory entries must be entered or modified not once, but many times.

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.

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.

The Benefits of LDAP

It provides users and applications in an enterprise with a single, well-defined, standard interface to a single, extensible directory service.

It reduces the need to manage and coordinate application-specific directories

Its well-defined protocol and array of programmatic interfaces make it more practical to deploy internet-ready applications that leverage the directory.

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.

Globalization Support

LDAP version 3 supports UTF-8, an encoding of Unicode, the 16-bit encoding standard used to store and retrieve information in any language.

Referrals

LDAP 3 supports knowledge references, LDAP URLs that refer users to other directory servers if the requested information does not reside on the server being queried. This feature enables a directory to be partitioned--that is, distributed across different servers.

Security

LDAP version 3 supports SASL (Simple Authentication and Security Layer), an Internet standard that enables clients to choose the authentication protocols that they want to use. It also supports Transport Layer Security (TLS), a standardized version of Secure Sockets Layer (SSL), which encrypts data that passes between client and server.

Extensibility

LDAP version 3 enables new LDAP operations to be defined, uses mechanisms called controls to modify existing operations, and permits new authentication methods through SASL.

Feature and schema discovery

LDAP version 3 servers publish the versions of the LDAP protocol that they support and their schemas in a directory entry called the root DSE (directory server-specific entry). This feature facilitates interaction with other LDAP clients and servers.

C LDAP API

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:

RFC (Request for Comment) 1823 on the IETF Web site at http://www.ietf.org/. This RFC documents the LDAP C API for LDAP

LDIF

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.

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:

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.

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.

The search request is transmitted to the directory server using the LDAP protocol.

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.

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.

The database retrieves the requested information, sending it back to the directory server, back to the C API, and back to the client.

Entries

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

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.

Note:

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.

Attributes

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

cn:

John Hay

cn:

Jack Hay

givenname:

John

sn:

Hay

uid:

jhay

mail:

jhay@acme.com

telephoneNumber:

+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.

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

Integer

Numbers

integerMatch

Follow rules for comparing integers

DistinguishedName

Directory names

distinguishedNameMatch

Follow special rules for comparing DNs

OctetString

Binary data

octetStringMatch

Compare data byte by byte

`

Note:

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.

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.

Types of Object Classes

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 organizationalunits(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.

Note:

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

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.

Schema

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.

Security

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.

Authentication

LDAP version 3 supports four levels of authentication:

Anonymous

Users log in without providing a user name and password, but once they are logged on, they may have limited privileges.

Simple

Clients supply a user name, in the form of a DN, and an unprotected password--that is, a password sent in clear text.

Simple over SSL

Users supply a user name and a password, which is protected using Secure Sockets Layer (SSL), a public key encryption technology.

SSL with certificates

This method provides maximum protection because it supplements public key encryption with certificates that clients use to authenticate themselves. Because they are issued by a certificate authority, certificates provide a considerable degree of certainty about a client's identity.

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 directory objects that are subject to access control

The clients that are granted or denied access

The access rights that clients are granted

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.

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

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

Products

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.

Groups

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.

Services

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.

Computers

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.